SOA-C02 Networking and Content Delivery Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  VPC Peering

  Why this is correct

  VPC Peering establishes a direct, logical connection between exactly two VPCs, using a 1:1 relationship that relies on AWS's existing routing infrastructure—no gateways, virtual appliances, or dedicated physical lines are required. Traffic between the peered VPCs uses private IPv4 or IPv6 addresses and stays entirely on the AWS global network, avoiding public-internet exposure and providing low, predictable latency. It is cost-effective for a pair of VPCs because there is no hourly fee or minimum revenue commitment; you pay only for inter-VPC data transfer, which is usually significantly cheaper than traffic traversing the internet. Although VPC peering is non-transitive, that property is irrelevant for a two-VPC architecture, making it the simplest and most operationally efficient solution for this requirement.

• ✗

  AWS Transit Gateway

  Why it's wrong here

  Transit Gateway introduces unnecessary complexity and cost for a two-VPC peering scenario, as it requires a central hub router and additional attachments, whereas VPC peering provides direct, low-cost connectivity using the AWS backbone without such overhead. It is tempting because Transit Gateway is designed for hub-and-spoke architectures with many VPCs, where it simplifies routing and centralised management—making it the correct choice for large-scale multi-VPC topologies, but not for a simple two-VPC requirement.

• ✗

  AWS Direct Connect

  Why it's wrong here

  AWS Direct Connect is a dedicated physical network connection that links an on-premises data center or colocation facility to AWS via a private circuit, typically delivered through a Direct Connect partner or location. It is designed exclusively for hybrid-cloud workloads where you need reliable, high-bandwidth, low-latency connectivity from your own infrastructure to AWS resources. Using Direct Connect for VPC-to-VPC traffic would force you to hairpin data through an external router on-premises, which is not only architecturally nonsensical but also introduces unnecessary physical infrastructure, carrier costs, and latency. Direct Connect does not provide a mechanism to connect two VPCs directly; instead, it attaches to a virtual private gateway for one VPC at a time, and inter-VPC communication would require complex routing that defeats the purpose of private AWS backbone connectivity.

• ✗

  AWS Site-to-Site VPN

  Why it's wrong here

  AWS Site-to-Site VPN creates an encrypted IPsec tunnel between a VPN device on an on-premises network and a virtual private gateway attached to an AWS VPC, with traffic traversing the public internet. For VPC-to-VPC communication, you would need to establish two separate VPN connections—one from each VPC to some external VPN endpoint—and route all inter-VPC traffic through that external location, which is convoluted, introduces significant latency, and incurs hourly connection charges for each VPN tunnel. Unlike VPC peering, which uses AWS's private backbone, a Site-to-Site VPN relies on the public internet, so traffic is exposed to encryption overhead and potential variability in network performance. Even in the unlikely scenario where both VPCs are configured with VPN connections to the same endpoint, the architecture would be far more expensive and complex than a simple peering connection, making it an inappropriate choice for same-region inter-VPC connectivity.

Go deeper

Related to this question