VPC Peering Limitations

AWS VPC Peering – Cross-Account, Cross-Region & Limitations

AWS VPC Peering
~ Last updated on : ~ jayendrapatil ~ 32 Comments

VPC Peering

🆕 Recent Updates (2025)

  • March 2025: Inter-region VPC peering now supports jumbo frames (up to 8500 bytes MTU) and full instance bandwidth.
  • April 2025: VPC Peering billing simplified with dedicated usage type for better cost visibility.
  • November 2025: VPC Encryption Controls launched to audit and enforce encryption on VPC peering traffic.
  • A VPC peering connection is a networking connection between two VPCs that enables routing of traffic between them using private IPv4 addresses or IPv6 addresses.
  • VPC peering connection
    • can be established between your own VPCs, or with a VPC in another AWS account in the same or different region.
    • is a one-to-one relationship between two VPCs.
    • supports intra and inter-region peering connections.
  • With VPC peering,
    • Instances in either VPC can communicate with each other as if they are within the same network
    • AWS uses the existing infrastructure of a VPC to create a peering connection; it is neither a gateway nor a VPN connection and does not rely on a separate piece of physical hardware.
    • There is no single point of failure for communication or a bandwidth bottleneck
    • All inter-region traffic is encrypted with no single point of failure, or bandwidth bottleneck. Traffic always stays on the global AWS backbone, and never traverses the public internet, which reduces threats, such as common exploits, and DDoS attacks.
    • EC2 instances can use full instance bandwidth for inter-region VPC peering traffic (previously limited to 50% for instances with 32+ vCPUs, or 5 Gbps for smaller instances).
  • VPC peering pricing
    • There is no charge to create a VPC peering connection.
    • All data transfer over a VPC peering connection that stays within an Availability Zone (AZ) is free, even if it’s between different accounts.
    • Charges apply for data transfer over VPC peering connections that cross Availability Zones and Regions.
    • Since April 2025, VPC Peering billing uses a dedicated usage type (Region-Name-VpcPeering-In/Out-Bytes) for easier cost tracking in Cost Explorer and Cost and Usage Reports.

AWS VPC Peering

VPC Peering Connectivity

  • To create a VPC peering connection, the owner of the requester VPC sends a request to the owner of the accepted VPC.
  • Accepter VPC can be owned by the same account or a different AWS account.
  • Once the Accepter VPC accepts the peering connection request, the peering connection is activated.
  • Route tables on both the VPCs should be manually updated to allow traffic
  • Security groups on the instances should allow traffic to and from the peered VPCs.

VPC Peering Limitations & Rules

  1. Does not support Overlapping or matching IPv4 or IPv6 CIDR blocks.
  2. Does not support transitive peering relationships i.e. the VPC does not have access to any other VPCs that the peer VPC may be peered with even if established entirely within your own AWS account
  3. Does not support Edge to Edge Routing Through a Gateway or Private Connection
  4. In a VPC peering connection, the VPC does not have access to any other connection that the peer VPC may have and vice versa. Connections that the peer VPC can include
    1. A VPN connection or an AWS Direct Connect connection to a corporate network
    2. An Internet connection through an Internet gateway
    3. An Internet connection in a private subnet through a NAT device
    4. A VPC endpoint to an AWS service; for example, an endpoint to S3.
  5. VPC peering connections quotas
    • Default limit of 50 active VPC peering connections per VPC, which can be increased up to a maximum of 125.
    • Default limit of 25 outstanding VPC peering connection requests.
    • Unaccepted VPC peering connection requests expire after 1 week (168 hours).
  6. Only one peering connection can be established between the same two VPCs at the same time.
  7. Jumbo frames (MTU up to 8500 bytes) are supported for peering connections both within the same region and across regions.
  8. A placement group can span peered VPCs that are in the same region; however, you do not get full-bisection bandwidth between instances in peered VPCs
  9. Inter-region VPC peering connections
    1. Updated March 2025: The Maximum Transmission Unit (MTU) across an inter-region peering connection is now 8500 bytes (jumbo frames supported). Previously limited to 1500 bytes.
    2. Security group rule that references a peer VPC security group cannot be created for cross-region peering.
    3. EC2 instances can use full instance bandwidth for inter-region peering (no longer limited to 50% or 5 Gbps).
  10. Any tags created for the peering connection are only applied in the account or region in which they were created
  11. Unicast reverse path forwarding in peering connections is not supported
  12. Instance’s Public DNS can be resolved to its private IP address across peered VPCs when DNS resolution is enabled for the VPC peering connection.

⚠️ DEPRECATED FEATURE

EC2-Classic and ClassicLink were retired on August 15, 2023.

The original content mentioned ClassicLink connections to EC2-Classic instances. This feature is no longer available.

Migration: All resources must be migrated to VPC. EC2-Classic is no longer supported.

VPC Peering Encryption

  • All inter-region VPC peering traffic is encrypted with AES-256 before leaving AWS data centers.
  • Intra-region traffic between Nitro-based EC2 instances is also encrypted transparently.
  • VPC Encryption Controls (November 2025):
    • Provides ability to monitor, audit, and enforce encryption in transit within and across VPCs.
    • Automatically applies hardware-based AES-256 encryption on traffic between VPC resources including Fargate, NLB, and ALB.
    • Helps demonstrate compliance with encryption standards (HIPAA, PCI DSS).
    • Can identify VPC resources unintentionally allowing plaintext traffic.
    • Generates audit logs for compliance and reporting.

VPC Peering Troubleshooting

  • Verify that the VPC peering connection is in the Active state.
  • Be sure to update the route tables for the peering connection. Verify that the correct routes exist for connections to the IP address range of the peered VPCs through the appropriate gateway.
  • Verify that an ALLOW rule exists in the network access control (NACL) table for the required traffic.
  • Verify that the security group rules allow network traffic between the peered VPCs.
  • Verify using VPC flow logs that the required traffic isn’t rejected at the source or destination. This rejection might occur due to the permissions associated with security groups or network ACLs.
  • Be sure that no firewall rules block network traffic between the peered VPCs. Use network utilities such as traceroute (Linux) or tracert (Windows) to check rules for firewalls such as iptables (Linux) or Windows Firewall (Windows).
  • For DNS resolution issues, ensure that DNS resolution is enabled for the VPC peering connection to resolve public DNS hostnames to private IP addresses.

VPC Peering Architecture

AWS VPC Architecture

  • VPC Peering can be applied to create shared services or perform authentication with an on-premises instance
  • This would help create a single point of contact, as well limiting the VPN connections to a single account or VPC

VPC Peering vs Transit Gateway vs PrivateLink vs VPC Lattice

VPC Peering vs Transit VPC vs Transit Gateway

When to Use Each Solution

  • VPC Peering
    • Best for: Simple, direct connections between a small number of VPCs (typically less than 10)
    • Advantages: No additional cost for the connection itself, low latency, simple setup, full instance bandwidth inter-region
    • Limitations: Does not support transitive routing, becomes complex at scale (mesh topology), limited to 125 peering connections per VPC
  • AWS Transit Gateway
    • Best for: Hub-and-spoke architecture with many VPCs (10+), centralized routing, hybrid connectivity
    • Advantages: Supports transitive routing, centralized management, scales to thousands of VPCs, integrates with Direct Connect and VPN
    • Limitations: Additional cost per attachment and data processing, slightly higher latency than direct peering
  • AWS PrivateLink
    • Best for: Service-to-service connectivity, exposing services to multiple consumers, SaaS applications
    • Advantages: Unidirectional access, no VPC CIDR overlap issues, enhanced security, supports cross-account and cross-region access
    • Limitations: Requires Network Load Balancer or Gateway Load Balancer, additional cost, one-way communication by default
  • Amazon VPC Lattice
    • Best for: Application-layer service-to-service networking across VPCs and accounts
    • Advantages: No NLB required (unlike PrivateLink), built-in service discovery, IAM-based authorization, cross-VPC/cross-account without CIDR coordination, TLS termination at data plane
    • Limitations: Application-layer (L7) only, newer service with evolving feature set
    • Note: AWS App Mesh is being discontinued (EOL September 30, 2026); VPC Lattice is the recommended migration path

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You currently have 2 development environments hosted in 2 different VPCs in an AWS account in the same region. There is now a need for resources from one VPC to access another. How can this be accomplished?
    1. Establish a Direct Connect connection.
    2. Establish a VPN connection.
    3. Establish VPC Peering.
    4. Establish Subnet Peering.
  2. A company has an AWS account that contains three VPCs (Dev, Test, and Prod) in the same region. Test is peered to both Prod and Dev. All VPCs have non-overlapping CIDR blocks. The company wants to push minor code releases from Dev to Prod to speed up the time to market. Which of the following options helps the company accomplish this?
    1. Create a new peering connection Between Prod and Dev along with appropriate routes.
    2. Create a new entry to Prod in the Dev route table using the peering connection as the target.
    3. Attach a second gateway to Dev. Add a new entry in the Prod route table identifying the gateway as the target.
    4. The VPCs have non-overlapping CIDR blocks in the same account. The route tables contain local routes for all VPCs.
  3. A company has 2 AWS accounts that have individual VPCs. The VPCs are in different AWS regions and need to communicate with each other. The VPCs have non-overlapping CIDR blocks. Which of the following would be a cost-effective connectivity option?
    1. Use VPN connections
    2. Use VPC peering between the 2 VPC’s
    3. Use AWS Direct Connect
    4. Use a NAT gateway
  4. A company needs to connect 15 VPCs across multiple AWS accounts and regions with centralized routing and management. Which solution is most appropriate?
    1. Create VPC peering connections between all VPCs
    2. Use AWS Transit Gateway with a hub-and-spoke architecture
    3. Use AWS PrivateLink for all connections
    4. Use multiple VPN connections
  5. A SaaS provider wants to expose their application running in their VPC to multiple customer VPCs without requiring VPC peering or overlapping CIDR concerns. Which solution should they use?
    1. VPC Peering with each customer VPC
    2. AWS Transit Gateway
    3. AWS PrivateLink with VPC endpoint service
    4. Internet Gateway with security groups
  6. A company needs to transfer large amounts of data between VPCs in different AWS regions with maximum throughput. Which statement about inter-region VPC peering is correct? (Updated 2025)
    1. Inter-region VPC peering is limited to 1500 bytes MTU and 5 Gbps bandwidth
    2. Inter-region VPC peering does not support encryption
    3. Inter-region VPC peering supports jumbo frames (8500 bytes MTU) and full EC2 instance bandwidth
    4. Inter-region VPC peering requires a Transit Gateway attachment
  7. A company wants to audit and enforce encryption on all traffic flowing through their VPC peering connections to meet PCI DSS compliance. Which AWS feature should they use?
    1. AWS CloudTrail encryption logging
    2. VPC Flow Logs with encryption filter
    3. VPC Encryption Controls
    4. AWS Network Firewall with TLS inspection

Related Posts

References

AWS VPC Peering

VPC Peering Connection Quotas

EC2 Bandwidth and Jumbo Frames for Inter-Region Peering (March 2025)

VPC Peering Billing Simplification (April 2025)

VPC Encryption Controls (November 2025)

Google Cloud VPC Peering

~ Last updated on : ~ jayendrapatil

Google Cloud VPC Peering

  • Google Cloud VPC Network Peering allows internal IP address or private connectivity across two VPC networks regardless of whether they belong to the same project or the same organization.
  • VPC Network Peering enables VPC networks connection, so that workloads in different VPC networks can communicate internally.
  • VPC Network Peering provides internal IPv4 and IPv6 connectivity between pairs of VPC networks.
  • Traffic stays within Google’s network and doesn’t traverse public internet.
  • Peering supports connectivity between networks having any combination of IPv4-only, dual-stack, and IPv6-only subnets.
  • VPC Network Peering provides following advantages over using external IP addresses or VPNs to connect networks, including:
    • Network Latency – connectivity uses only internal addresses and provides lower latency than connectivity that uses external addresses
    • Network Security – service owners do not need to have their services exposed to the public Internet and deal with its associated risks.
    • Network Cost – Google Cloud charges egress bandwidth or outbound traffic for networks using external IPs to communicate even if the traffic is within the same zone. However, for peered networks as they use internal IPs to communicate and save on those egress costs.
  • VPC Network Peering is useful in these environments:
    • SaaS (Software-as-a-Service) ecosystems in Google Cloud, which can be made available privately across different VPC networks within and across organizations.
    • Organizations that have several network administrative domains that need to communicate using internal IP addresses.

VPC Peering Properties

  • VPC Network Peering works with Compute Engine, GKE, and App Engine flexible environment.
  • VPC Network Peering supports VPC-native GKE clusters by exchanging subnet routes.
  • VPC Network Peering supports routes-based GKE clusters when configured to exchange static routes.
  • Peered VPC networks remain administratively separate. Routes, firewalls, VPNs, and other traffic management tools are administered and applied separately in each of the VPC networks.
  • Each side of a peering association is set up independently. Peering will be active only when the configuration from both sides matches. Either side can choose to delete the peering association at any time (in independent mode).
  • VPC peers always exchange subnet routes that don’t use privately used public IP addresses. Networks must explicitly export privately used public IP subnet routes for other networks to use them and must explicitly import privately used public IP subnet routes to receive them from other networks.
  • Subnet and static routes are global. Dynamic routes can be regional or global, depending on the VPC network’s dynamic routing mode.
  • A VPC network can peer with multiple VPC networks (default quota of 25 peerings per network).
  • IAM permissions for creating and deleting VPC Network Peering are included as part of the Compute Network Admin role (roles/compute.networkAdmin).
  • Peering traffic (traffic flowing between peered networks) has the same latency, throughput, and availability as private traffic in the same network.
  • Billing policy for peering traffic is the same as the billing policy for private traffic in the same network.
  • Peering is allowed with Shared VPC.
  • An organization policy administrator can use an organization policy to constrain which VPC networks can peer with VPC networks in the organization. Peering connections to particular VPC networks or to VPC networks in a particular folder or organization can be denied.

VPC Peering Connection Modes

  • VPC Network Peering supports two connection modes that determine how a peering connection is administered:
    • Independent Mode (default) – Either network can update or delete the peering connection at any time unilaterally.
    • Consensus Mode – Requires agreement from both networks to update or delete the peering connection. Prevents accidental, unilateral changes to network behavior.
  • When creating a peering connection, both peering configurations must specify the same connection mode.
  • An existing connection can be changed from independent to consensus mode (both sides must update), but changing from consensus to independent is NOT supported.
  • Consensus mode is recommended for critical services where accidental deletion of the peering connection would cause a service outage.
  • In consensus mode:
    • Update requests require complementary changes from both sides (e.g., if one side exports custom routes, the peer must import them).
    • Deletion requires both sides to submit a deletion request.
    • Pending update or deletion requests do not cause downtime—the connection remains active.

IPv6 Support in VPC Peering

  • VPC Network Peering provides internal IPv4 and IPv6 connectivity between pairs of VPC networks.
  • Peering supports connectivity between networks having any combination of IPv4-only, dual-stack, and IPv6-only subnets.
  • To exchange IPv6 routes (both internal and external IPv6 subnet ranges), the peering stack type must be set to IPV4_IPV6 using the --stack-type=IPV4_IPV6 flag.
  • IPv6 static and dynamic routes exchange also requires --stack-type=IPV4_IPV6 in addition to the --export-custom-routes / --import-custom-routes flags.
  • VPC Network Peering also provides certain external IPv6 connectivity to destination external IPv6 address ranges of dual-stack/IPv6-only VM instances, external protocol forwarding rules, and external passthrough Network Load Balancer forwarding rules.
  • IPv6 subnet routes are unique by definition — no two VPC networks can use the same internal or external IPv6 subnet ranges.
  • IPv6 functionality is available only in Premium Tier.

Route Exchange Options

  • When a VPC network shares local routes with a peered VPC network, it exports the routes. The peered VPC network can then import the routes.
  • Subnet routes (using private IPv4 ranges) are always exchanged and cannot be disabled.
  • Subnet routes using privately used public IPv4 addresses – exported by default, not imported by default. Controlled via --export-subnet-routes-with-public-ip and --import-subnet-routes-with-public-ip flags.
  • IPv6 subnet routes (internal and external) – not exchanged by default. Enabled by setting --stack-type=IPV4_IPV6.
  • Static and dynamic IPv4 routes – not exchanged by default. Controlled via --export-custom-routes and --import-custom-routes flags.
  • IPv6 static/dynamic routes – require both --export-custom-routes / --import-custom-routes AND --stack-type=IPV4_IPV6.
  • Static routes with network tags or using the default internet gateway as next hop can NEVER be exported or imported.
  • Policy-based routes are NOT supported for exchange via VPC Network Peering.
  • Route exchange options can be updated before peering is established or while peering is active.

VPC Peering Restrictions

  • A subnet CIDR range in one peered VPC network cannot overlap with a static route in another peered network. This rule covers both subnet routes and static routes.

GCP VPC Peering - Overlapping Subnet IP ranges between two peers

  • A dynamic route can overlap with a subnet route in a peer network. For dynamic routes, the destination ranges that overlap with a subnet route from the peer network are silently dropped. Google Cloud uses the subnet route.
  • Only VPC networks are supported for VPC Network Peering. Peering is NOT supported for legacy networks.
  • Two auto mode VPC networks cannot be peered because each auto mode VPC uses subnet IP ranges that fit within 10.128.0.0/9. A custom mode VPC can be peered with an auto mode VPC as long as the custom mode VPC doesn’t have subnets within 10.128.0.0/9.
  • Subnet route exchange can’t be disabled or subnet routes that can be exchanged cannot be selected. After peering is established, all resources within subnet IP addresses are accessible across directly peered networks.
  • VPC Network Peering doesn’t provide granular route controls to filter out which subnet CIDR ranges are reachable across peered networks. It needs to be done using firewall rules.
  • Transitive peering is NOT supported. For transitive connectivity, use Network Connectivity Center with VPC spokes.
  • Network tags or service accounts from one peered network in the other peered network CANNOT be used in VPC firewall rules.
  • However, secure Tags (different from network tags) used in network firewall policies CAN identify sources in peered VPC networks connected to the VPC network to which the Tag is scoped.
  • Compute Engine internal DNS names created in a network are NOT accessible to peered networks. Use Cloud DNS peering zones or authorize the managed private zone to all peered VPC networks instead.
  • By default, VPC Network Peering with GKE is supported when used with IP aliases (VPC-native clusters). If you don’t use IP aliases (routes-based clusters), custom routes can be exported so that GKE containers are reachable from peered networks.

Peering Group and Quotas

  • VPC peering quotas depend on a concept called a peering group.
  • Each VPC network has its own peering group consisting of itself and all other VPC networks connected to it using VPC Network Peering.
  • Quotas such as internal forwarding rules, subnet ranges, and instances are evaluated across the entire peering group, not per individual network.
  • Default quota for VPC peerings within a single VPC is 25 (can be increased via quota request).
  • Google Cloud allows only one peering operation at a time across peered networks.

Network Connectivity Center (NCC) vs VPC Peering

  • Network Connectivity Center (NCC) is an alternative to VPC Network Peering for connecting multiple VPC networks, providing a hub-and-spoke model.
  • Transitivity: NCC provides full bandwidth and transitivity between workload VPCs (VPC spokes). VPC Peering does NOT provide transitivity.
  • Scale: NCC supports up to 250 VPC spokes per hub. VPC Peering is limited to 25 peerings per VPC by default.
  • When to use VPC Peering: Simple point-to-point connectivity between two VPCs without transitive requirements.
  • When to use NCC: Hub-and-spoke topologies, transitive routing across multiple VPCs, enterprise-scale connectivity, or when centralizing network management.
  • A VPC that is a VPC spoke in NCC can still use VPC Network Peering, provided the peered VPC network isn’t a VPC spoke itself.
  • NCC VPC spokes support IPv4 and IPv6 subnet route connectivity and IPv4 dynamic route connectivity using hybrid spokes.

Internal Load Balancer Support

  • Clients in a local VPC network can access internal load balancers in a peer VPC network.
  • Supported internal load balancers:
    • Internal passthrough Network Load Balancers
    • Internal proxy Network Load Balancers
    • Internal Application Load Balancers
  • Peered networks can exchange static routes that use internal passthrough Network Load Balancers as next hops.

DNS Support in Peered Networks

  • Resources in a peered VPC network cannot use Compute Engine internal DNS names created by a local VPC network.
  • To make DNS names available to resources in a peered VPC network, use one of the following:
    • Cloud DNS peering zones – Recommended approach for cross-network DNS resolution.
    • Authorize the managed private zone to all peered VPC networks.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your company is working with a partner to provide a solution for a customer. Both your company and the partner organization are using GCP. There are applications in the partner’s network that need access to some resources in your company’s VPC. There is no CIDR overlap between the VPCs. Which two solutions can you implement to achieve the desired results without compromising security?
    1. VPC peering
    2. Shared VPC
    3. Dedicated Interconnect
    4. Cloud NAT
  2. Your organization is deploying a single project for 3 separate departments. Two of these departments require network connectivity between each other, but the third department should remain in isolation. Your design should create separate network administrative domains between these departments. You want to minimize operational overhead. How should you design the topology?
    1. Create a Shared VPC Host Project and the respective Service Projects for each of the 3 separate departments.
    2. Create 3 separate VPCs, and use Cloud VPN to establish connectivity between the two appropriate VPCs.
    3. Create 3 separate VPCs, and use VPC peering to establish connectivity between the two appropriate VPCs.
    4. Create a single project, and deploy specific firewall rules. Use network tags to isolate access between the departments.
  3. Your organization has 15 VPC networks that all need to communicate with each other. You need full-mesh transitive connectivity with centralized management. What should you use?
    1. VPC Network Peering between all 15 networks
    2. Network Connectivity Center with VPC spokes
    3. Cloud VPN tunnels between all networks
    4. Shared VPC with service projects
  4. You have two VPC networks peered together. A critical production service runs across the peering connection. You want to prevent accidental deletion of the peering connection by either network administrator. What should you configure?
    1. IAM deny policies on the peering resource
    2. Organization policy constraints
    3. Consensus mode for the peering connection
    4. Read-only access for both network administrators
  5. You have peered two VPC networks and need to enable IPv6 communication between resources in both networks. What must you configure on the peering connection?
    1. Enable the --export-custom-routes flag
    2. Create IPv6 firewall rules only
    3. Set the peering stack type to IPV4_IPV6
    4. Enable Private Google Access for IPv6
  6. You want to use network firewall policy rules to identify traffic sources from peered VPC networks. Which identifier can be used to match sources across peered networks?
    1. Network tags
    2. Service accounts
    3. Secure Tags (resource manager tags)
    4. IP ranges only

References