# Ensure VPC peering route tables do not route 0.0.0.0/0 or the entire requester VPC CIDR

- Source: https://support.icompaas.com/support/solutions/articles/a_1793292227360522-ensure-vpc-peering-route-tables-do-not-route-00000-or-the-entire-requester-vpc-cidr
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS_Checks_v5.39.1](https://support.icompaas.com/support/solutions/c_1793285913477877) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1793287194371224)
- Last updated: 2026-10-29
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Description**

Ensure that the route tables used with each VPC peering connection follow least privilege. Routes that send traffic to a peering connection should cover only the specific subnets or narrower address ranges that need to communicate, rather than 0.0.0.0/0 or the entire CIDR block of a peered VPC.

**Rationale**

Broad peering routes make every resource in one VPC reachable from the other, which allows lateral movement and unauthorized discovery if a resource is compromised. Routes to 0.0.0.0/0 or to a whole VPC range also increase the risk of misrouting when address ranges overlap. Advertising only the required subnets across the peering connection, keeping routes symmetric on both sides, and layering security groups and network ACLs limits cross-VPC access to what is needed.

**Impact**

-   Limits which subnets can communicate across the peering connection
    
-   Reduces the impact of a compromised resource in either VPC
    
-   Traffic between subnets that are no longer routed will stop, so all required communication paths must be identified before routes are narrowed
    

**Default Value**

A new VPC peering connection has no routes. Routes to the peer VPC exist only if they were added to the route tables manually.

**Pre-Requisites**

-   IAM permissions: ec2:DescribeVpcPeeringConnections, ec2:DescribeRouteTables, ec2:DeleteRoute and ec2:CreateRoute
    
-   A list of the subnet CIDR ranges in each VPC that legitimately need to communicate over the peering connection
    

**Remediation**

**Test Plan**

**Console:**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the Amazon VPC console and select **Peering connections**.
    
3.  Select a peering connection and note the CIDR blocks of the requester and accepter VPCs.
    
4.  Select **Route tables** and review the **Routes** tab of each route table.
    
5.  Check for any route whose target is the peering connection (pcx-...) and whose destination is 0.0.0.0/0 or the full CIDR block of a peered VPC.
    
6.  Repeat for each peering connection in each region in use.
    
7.  If such a route exists, follow the implementation steps.
    

**CLI:**

List the peering connections and the CIDR blocks of both VPCs:

aws ec2 describe-vpc-peering-connections --region <REGION> --query "VpcPeeringConnections\[\].\[VpcPeeringConnectionId,RequesterVpcInfo.VpcId,RequesterVpcInfo.CidrBlock,AccepterVpcInfo.VpcId,AccepterVpcInfo.CidrBlock\]" --output table

List the routes that target a peering connection:

aws ec2 describe-route-tables --region <REGION> --filters Name=route.vpc-peering-connection-id,Values=<PEERING\_CONNECTION\_ID> --query "RouteTables\[\].{RouteTable:RouteTableId,Destinations:Routes\[?VpcPeeringConnectionId=='<PEERING\_CONNECTION\_ID>'\].DestinationCidrBlock}"

A peering connection fails if any route that targets it has the destination 0.0.0.0/0 or the full primary CIDR block of the requester VPC. Routes covering the accepter VPC's CIDR, secondary CIDR blocks and broader supernets are not detected.

**Implementation Steps**

**Console:**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the Amazon VPC console and select **Route tables**.
    
3.  Select a route table that has a route to the peering connection and open the **Routes** tab.
    
4.  Choose **Edit routes**.
    
5.  Remove each route that targets the peering connection with the destination 0.0.0.0/0 or the full CIDR block of the peered VPC.
    
6.  Choose **Add route** for each subnet that needs access, enter the subnet's CIDR as the destination and select the same peering connection as the target.
    
7.  Choose **Save changes**.
    
8.  Repeat in the route tables of the peered VPC, so that the routes are symmetric.
    
9.  Repeat for each affected peering connection in each region in use.
    

**Backout Plan**

Before making changes, save the current route tables:

aws ec2 describe-route-tables --region <REGION> --filters Name=route.vpc-peering-connection-id,Values=<PEERING\_CONNECTION\_ID> > <PEERING\_CONNECTION\_ID>-routes-backup.json

To roll back:

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the Amazon VPC console and select **Route tables**.
    
3.  Select the route table, open the **Routes** tab and choose **Edit routes**.
    
4.  Re-add the removed routes from the saved backup, with the peering connection as the target.
    
5.  Choose **Save changes**.
    

**CLI:**

aws ec2 create-route --region <REGION> --route-table-id <ROUTE\_TABLE\_ID> --destination-cidr-block <PEER\_VPC\_CIDR> --vpc-peering-connection-id <PEERING\_CONNECTION\_ID>

Note: rolling back makes all resources in the peered VPCs reachable from each other again.

**Reference**

-   [https://docs.aws.amazon.com/vpc/latest/peering/peering-configurations-partial-access.html](https://docs.aws.amazon.com/vpc/latest/peering/peering-configurations-partial-access.html)
    
-   [https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-routing.html](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-routing.html)
    
-   [https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-route-tables.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-route-tables.html)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.
