VPC Networking and Private Connectivity for SOA-C03

A VPC is a private, isolated network you define inside an AWS Region, carved into subnets that each live in exactly one Availability Zone. The VPC's IPv4 CIDR block can range from /16 down to /28, and every subnet takes a slice of it — subnets in the same VPC can never overlap. Plan CIDRs deliberately: a subnet's CIDR cannot be changed after creation, and if the VPC will ever peer with another network, its range must not overlap that network's range either. At scale, Amazon VPC IP Address Manager (IPAM) exists to plan, track, and allocate CIDR blocks across accounts and Regions — know it by name and purpose.

In every subnet, AWS reserves five IP addresses you cannot assign. In 10.0.0.0/24:

• 10.0.0.0 — the network address
• 10.0.0.1 — the VPC router
• 10.0.0.2 — the Amazon DNS resolver
• 10.0.0.3 — reserved for future use
• 10.0.0.255 — the broadcast address (broadcast is not supported, but the address is still held back)

So a /28 subnet yields 11 usable addresses, not 16 — a real operational pain when a load balancer, an endpoint, or pods that take VPC addresses (as Amazon EKS does by default) quietly consume them.

When a VPC runs out of addresses

You cannot grow an existing subnet, and you cannot change a VPC's primary CIDR block. What you can do is associate a secondary IPv4 CIDR block with the VPC and create new subnets from it. Existing subnets and the workloads in them are untouched; you then point new capacity (an Auto Scaling group, an EKS node group or pod networking) at the new subnets. The secondary block must not overlap the existing ones or any connected network, and AWS restricts which ranges can be added alongside a given primary range, so check before you plan. Rebuilding the VPC with a larger range is the disruptive alternative, not the first move.

Finally, “public subnet” is not a property you set on the subnet itself. A subnet is public purely because of where its route table points, which is the next section's job.

A route table decides where each subnet's traffic goes. Every VPC has one main route table; you create custom tables and associate them with specific subnets, and each subnet uses exactly one table (subnets with no explicit association fall back to the main table — so a new subnet you forgot to associate silently uses the main table's routes). Every table carries an unremovable local route covering the VPC CIDR, so intra-VPC traffic always works. When routes overlap, the most specific prefix wins — a /32 beats a /16, which beats 0.0.0.0/0.

An internet gateway (IGW) is a horizontally scaled gateway attached to the VPC. A subnet is public when two things are true: its route table sends 0.0.0.0/0 to the IGW, and instances in it have public IPv4 addresses (auto-assign or Elastic IP). Miss either one and nothing is reachable from the internet.

NAT gateways: zonal and regional

Private subnets that need outbound internet access — patching, package downloads, external APIs — route 0.0.0.0/0 to a NAT gateway. A NAT gateway handles only outbound-initiated traffic; the internet cannot open connections inward through it. Since November 2025 a NAT gateway has an availability mode:

With zonal gateways, the classic mistake is a single NAT gateway that every AZ's subnets route to: lose that AZ and the surviving AZs lose outbound access too. A regional NAT gateway removes that per-AZ plumbing: there is no public subnet to maintain per AZ, no per-AZ route table to keep pointed at the right gateway, and it follows your workloads into new AZs on its own. The trade-off is that it cannot do private NAT. Converting from zonal to regional (either creating a new gateway and re-pointing routes, or deleting the zonal gateway and reusing its released Elastic IPs on the regional one) resets existing connections. The self-managed alternative, a NAT instance on EC2, still appears as a distractor: workable for tiny workloads, but you patch it, size it, and build its failover story yourself.

IPv6: egress-only internet gateways and NAT64

VPC IPv6 addresses are globally unique and publicly routable, so IPv6 needs no address translation to reach the internet. For outbound-only IPv6, route ::/0 to an egress-only internet gateway — stateful, allows outbound connections and their replies, blocks everything inbound-initiated. A NAT gateway does not provide IPv6-to-IPv6 egress.

The one IPv6 job a NAT gateway does do is NAT64: letting IPv6-only workloads reach IPv4-only destinations. Enable DNS64 on the IPv6-only subnet so the Amazon resolver synthesises IPv6 addresses (in 64:ff9b::/96) for names that have only IPv4 records, then route 64:ff9b::/96 to a NAT gateway, which translates the traffic to IPv4. Inbound-initiated connections are still blocked. Sending that prefix to an egress-only internet gateway fails, because only the NAT gateway translates.

Security groups and network ACLs are the two VPC firewall layers, and the exam relentlessly tests their differences. A security group attaches to an elastic network interface — effectively to an instance, load balancer node, or endpoint — and is stateful: allow a request in, and the response is automatically allowed out regardless of outbound rules. It supports allow rules only; anything not allowed is implicitly denied, and all rules are evaluated as one set. A network ACL attaches to a subnet and is stateless: return traffic must be explicitly allowed. It supports both allow and deny rules, evaluated in rule-number order from the lowest, and the first match wins.

Rule numbers matter. A network ACL evaluates rules from the lowest number upward and stops at the first rule that matches; later rules are never consulted. So a deny only works if it is numbered below any allow that would also match. If rule 100 allows all inbound traffic, a new deny for a hostile range numbered 200 never takes effect — renumber it below 100 (for example 90). Leaving gaps between rule numbers (100, 200, 300) makes such inserts easy.

Statelessness creates the classic ephemeral-port question. A client connects to your web server on port 443; the response returns to a high-numbered ephemeral port chosen by the client — commonly within 1024–65535, varying by operating system. A NACL that allows inbound 443 but has no outbound allow for the ephemeral range silently kills every response. Security groups never hit this; statefulness handles it. Operational default: use security groups for workload rules, and reach for NACLs when you need a subnet-wide deny, such as blocking a hostile IP range without touching every security group — security groups cannot express a deny at all.

VPC endpoints let resources in private subnets reach AWS services without an internet gateway, NAT device, or public IPs — the traffic stays on the AWS network. There are two kinds, and choosing between them is a guaranteed exam moment.

Gateway endpoints are the free answer for private S3 or DynamoDB access. Interface endpoints, powered by AWS PrivateLink, cover services such as Systems Manager, Secrets Manager, or CloudWatch; with private DNS enabled, applications need no endpoint configuration change.

Controlling access through an endpoint

Two policies work from opposite sides. An endpoint policy is a resource policy on the endpoint that limits what callers in the VPC can reach through it — for example, only the company's own S3 buckets. A bucket policy (or other resource policy) on the destination decides which paths it accepts: a deny for requests whose aws:SourceVpce is not your endpoint ID (or whose aws:SourceVpc is not your VPC) makes a bucket reachable only through that endpoint. Don't build that rule on aws:SourceIp: for requests through a VPC endpoint it does not carry the instance's private address (that is aws:VpcSourceIp), so an IP-based allow list blocks the endpoint path. Security groups and network ACLs cannot filter by bucket name, so they are never the bucket-scoping tool.

When an interface endpoint does not answer

The error type tells you which layer to check. A timeout means packets are being dropped — most often the endpoint's own security group lacks an inbound HTTPS (TCP 443) rule from the callers, or a network ACL blocks the path. An access denied error means the network works and a policy (endpoint policy, IAM, or resource policy) refused the call. Name resolution returning public IPs means private DNS is off (or the VPC's DNS hostnames and DNS support attributes are disabled). Routes are rarely the issue: the local route reaches endpoint interfaces in any AZ of the VPC, so an instance in an AZ without an endpoint interface still connects (at inter-AZ data rates).

Offering your own service with PrivateLink

PrivateLink also works in the provider direction. You place the service behind a Network Load Balancer and create an endpoint service; consumers create interface endpoints to it from their own VPCs and accounts. (Inline security appliances behind a Gateway Load Balancer use the same endpoint-service model, but consumers create Gateway Load Balancer endpoints, which are route-table targets rather than interfaces.) Because traffic flows through endpoint interfaces rather than routes between networks, overlapping consumer CIDRs are irrelevant, and consumers reach only that service, never the rest of your network — the standout advantages over peering. Connections are initiated by consumers toward the provider, not the reverse.

The provider controls who connects with two settings: allowed principals (the accounts, users, or roles permitted to discover and request a connection) and acceptance required (each endpoint connection request waits until the provider accepts it). Endpoint services are not shared through AWS RAM, and consumer CIDR filtering cannot do this job because consumer ranges may overlap.

VPC peering creates a private, one-to-one connection between two VPCs — same account or different accounts, same Region or across Regions. Four facts do most of the exam work. First, the CIDR ranges must not overlap; overlapping VPCs simply cannot peer. Second, routing is manual on both sides: each VPC adds a route for the other's CIDR targeting the peering connection, and security groups still apply on top. Third, peering is never transitive: if VPC A peers with B and B peers with C, A cannot reach C through B. Fourth, peering does not support edge-to-edge routing: a VPC cannot use its peer's internet gateway, NAT gateway, gateway endpoint, Site-to-Site VPN, or Direct Connect connection, so on-premises traffic arriving in one VPC cannot continue across a peering connection to another. A full mesh of many VPCs grows quadratically, which is why peering fits a handful of VPCs, not a fleet.

AWS Transit Gateway is the hub-and-spoke answer. Each VPC, Site-to-Site VPN, or Direct Connect gateway becomes an attachment to the hub, and the hub routes between them. Operationally, you create the VPC attachment — choosing a subnet per AZ where the transit gateway places its interface — then add routes in each VPC's subnet route tables pointing remote CIDRs at the transit gateway.

Transit gateway route tables: association and propagation

The hub has route tables of its own, and two separate relationships decide who reaches whom:

• Association — each attachment is associated with exactly one transit gateway route table. That is the table the transit gateway looks up for traffic arriving from the attachment.
• Propagation — an attachment can propagate its routes into one or more route tables. Those tables learn how to reach it. (You can also add static routes, including blackhole routes.)

An attachment can reach a destination only if the table it is associated with holds a route to that destination. The isolated-spokes, shared-services pattern follows directly: associate every spoke with a spokes table into which only the shared-services VPC and the VPN propagate, and associate shared services and the VPN with a table into which every spoke propagates. Spokes reach shared services and on-premises, but never each other, and a new spoke needs only one association and one propagation.

By default a transit gateway turns on default route table association and default route table propagation: every new attachment joins the default table and propagates into it, so every attachment can reach every other. That is convenient for a flat network and wrong for a segmented one — turn both defaults off so a new attachment is isolated until you associate and propagate it deliberately.

Selection cue: two or three VPCs at lowest cost points to peering; “transitive routing,” “hub and spoke,” on-premises traffic reaching many VPCs, or dozens of VPCs points to Transit Gateway.

AWS Site-to-Site VPN extends your on-premises network to AWS through IPsec tunnels over the internet. You configure three resources. A customer gateway represents the on-premises side: your firewall or router and its public IP address. On the AWS side, tunnels terminate on either a virtual private gateway attached to a single VPC, or a transit gateway VPN attachment when several VPCs need the same on-premises connectivity — never on an internet gateway. The VPN connection always provisions two tunnels to distinct AWS endpoints; configure your customer device for both, because a connection built on one tunnel goes down whenever AWS maintains that endpoint.

Static vs dynamic routing, and route propagation

Getting routes into the VPC is a second, separate step. With a virtual private gateway, either add routes to the subnet route tables by hand or enable route propagation on those route tables, so whatever the virtual private gateway learns (static or BGP) appears automatically. BGP plus route propagation together remove both manual steps. With a transit gateway, the VPN attachment propagates into transit gateway route tables instead.

AWS Client VPN answers a different scenario: individual users rather than a whole site. It is a managed, OpenVPN-based endpoint. You create it with a client CIDR pool (the addresses connecting users receive), associate it with subnets in a VPC to give it network paths, and write authorization rules defining which destination CIDRs users may reach. Authentication is certificate-based (mutual TLS) or user-based through Active Directory or a SAML identity provider. Connected clients can be routed onward — to peered VPCs or across your Site-to-Site VPN — by adding entries to the Client VPN endpoint's route table.

Cue mapping: “connect the data center or office network to AWS” is Site-to-Site VPN; “remote employees need secure access from their laptops” is Client VPN.

Auditing network protection in one account means checking two things for each service: that it is configured, and that it is actually attached to the traffic it should protect. Each service attaches somewhere different, and that is where audits find gaps.

AWS WAF

WAF is a layer 7 web application firewall. Web ACLs hold rules — rate-based rules, IP sets, and AWS managed rule groups (kept updated by AWS) for SQL injection, cross-site scripting, and known bad inputs. A web ACL has a scope chosen at creation and never changed: CloudFront scope, managed in us-east-1, or regional scope for resources in that Region. So protecting a CloudFront distribution and an ALB in another Region with the same rules needs two web ACLs. WAF does not attach to VPCs, EC2 instances, or Network Load Balancers. A web ACL that protects nothing is a common audit finding.

AWS Shield

Shield Standard is automatic and free for every AWS customer, absorbing common layer 3 and 4 DDoS attacks such as SYN floods and UDP reflection — nothing to configure. Shield Advanced is a paid subscription, and its benefits apply only to the resources you explicitly add as protected resources (CloudFront distributions, Route 53 hosted zones, Global Accelerator accelerators, load balancers, and Elastic IPs): enhanced detection and mitigation, DDoS cost protection (credits for scaling charges caused by an attack), and 24/7 access to the Shield Response Team, which requires a Business Support plan or higher. Subscribing alone protects nothing extra — cost protection and SRT engagement apply only to resources you have added, so every internet-facing entry point in the request path needs adding, not just the first one. Shield does not filter SQL injection; that is WAF's job.

AWS Network Firewall

Network Firewall is a managed, stateful network firewall for VPC traffic. You deploy firewall endpoints into dedicated firewall subnets, one per AZ, and inspect with stateless and stateful rule groups, including domain lists and Suricata-compatible rules. It only inspects traffic that route tables send through its endpoints. Outbound inspection comes from subnet route tables pointing at the endpoint; inbound inspection from the internet needs an ingress route table associated with the internet gateway (an edge association) that sends each protected public subnet's CIDR to the firewall endpoint in the same AZ. Without it, the internet gateway delivers inbound traffic straight to the subnet over the local route and the firewall never sees it. An audit verifies the firewall policy and the route steering in both directions.

Route 53 Resolver DNS Firewall

DNS Firewall filters outbound DNS queries that resources in your VPCs send through the Route 53 Resolver, against domain lists — block known-bad domains or allow only an approved set. Rule groups are associated with VPCs (not hosted zones), so audit the association on every VPC. It complements, rather than replaces, the packet-level services above.

Network cost questions almost always turn on one of three levers: NAT data processing, cross-AZ transfer, and choosing the cheapest private-connectivity construct that meets the requirement.

Walk the classic scenario. An analytics fleet in private subnets uploads hundreds of gigabytes to S3 daily through a NAT gateway, so every byte pays the NAT data-processing rate on top of the gateway's hourly charge. The fix costs nothing: create a gateway endpoint for S3 and associate it with the private subnets' route tables. AWS inserts a managed prefix-list route for S3 that is more specific than the default route, so S3 traffic immediately diverts through the endpoint — free, and never touching the internet. Do the same for DynamoDB. An interface endpoint for S3 would also keep traffic private, but adds its own hourly and per-GB charges.

Second lever: Availability Zones. Traffic between AZs over private IPs is charged in both directions, while same-AZ private-IP traffic is free. Keep chatty tiers — an app fleet and the cache replica it reads, say — in the same AZ where the availability design allows, The same logic sits behind NAT topology: one shared zonal NAT gateway saves hourly fees but adds cross-AZ charges from other AZs plus a single-AZ failure domain. Per-AZ (or regional) NAT is the resilient default; one shared NAT is the frugal exception for light, non-critical traffic.

Read the requirement, then pick the cheapest construct that meets it: peering for two VPCs that only need each other, Transit Gateway when transitive or many-VPC routing is genuinely required, and interface endpoints when private access to AWS APIs is the goal — usually cheaper than sending heavy AWS API traffic through NAT.