Google Cloud VPC Peering

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.
  • Traffic stays within Google’s network and doesn’t traverse public internet
  • 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 – GCP 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.
  • 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.
  • 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.
  • VPC network can peer with multiple VPC networks (limit of 25 currently)
  • IAM permissions for creating and deleting VPC Network Peering are included as part of the Compute Network Admin role.
  • 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. The constraint applies to new peering configurations and doesn’t affect existing connections. An existing peering connection can continue to work even if a new policy denies new connections.

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.
  • 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.
  • Tags or service account from one peered network in the other peered network CANNOT be used.
  • Compute Engine internal DNS names created in a network are NOT accessible to peered networks. Use the IP address instead.
  • By default, VPC Network Peering with GKE is supported when used with IP aliases. If you don’t use IP aliases, custom routes can be exported so that GKE containers are reachable from peered 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.

Reference

Google Cloud – VPC Peering

AWS VPC Peering

VPC Peering

  • 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.
  • Instances in either VPC can communicate with each other as if they are within the same network
  • VPC peering connection can be established between your own VPCs, or with a VPC in another AWS account in a single different region.
  • A VPC peering connection is a one-to-one relationship between two VPCs.
  • With VPC peering, there is no single point of failure for communication or a bandwidth bottleneck
  • AWS uses the existing infrastructure of a VPC to create a VPC peering connection; it is neither a gateway nor a VPN connection and does not rely on a separate piece of physical hardware.
  • VPC peering now supports inter-region VPC peering connection. However, when introduced was limited to the same region.
  • 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.
  • VPC peering does not have any separate charges. However, there are data transfer charges.

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 VPC peering connection request, the VPC 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. VPC peering connections cannot be created between VPCs that have matching or overlapping IPv4 or IPv6 CIDR blocks.
  2. VPC peering connections cannot be created between VPCs in different regions. (NOTEVPC Peering is now supported inter-region.)
  3. VPC peering connections are limited on the number of active and pending VPC peering connections that you can have per VPC.
  4. VPC peering does not support transitive peering relationships. In a VPC peering connection, 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
  5. VPC peering does not support Edge to Edge Routing Through a Gateway or Private Connection
  6. 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 ClassicLink connection to an EC2-Classic instance
    5. A VPC endpoint to an AWS service; for example, an endpoint to S3.
  7. Only one VPC peering connection can be established between the same two VPCs at the same time
  8. The Maximum Transmission Unit (MTU) across a VPC peering connection is 1500 bytes.
  9. 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
  10. Any tags created for the VPC peering connection are only applied in the account or region in which they were created
  11. Unicast reverse path forwarding in VPC peering connections is not supported
  12. Circa July 2016, Instance’s Public DNS can now be resolved to its private IP address across peered VPCs. Instance’s public DNS hostname does not resolve to its private IP address across peered VPCs.

VPC Peering Troubleshooting

  • Verify that the VPC peering connection is in the Active state.
  • Be sure to update the route tables for your VPC 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 (network ACL) 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).

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 VPC vs Transit Gateway

VPC Peering vs Transit VPC vs Transit Gateway

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