VPC — DVA-C02 Mastery Guide

• Sources: course chapter 05 (VPC). The slides serve as the syllabus only; all wording here is original.
• Written 2026-10-12; values checked against AWS docs on 2026-10-12. The marker ⚠️ Changed: <current>. Older material may say <old>. flags a value or behaviour that differs from the course or from older practice tests: learn the current value. ⚠️ unverified marks anything that could not be confirmed in AWS documentation. Every change is listed in Changed vs older material; rows enter notes/current-facts.md once you confirm them.
• Tier 4 (skim: developer-facing features only), bank target 10 questions. Domains: Troubleshooting and Optimization (primary), Security.
• Scope: public vs private subnets, internet and NAT gateways, security groups vs network ACLs, VPC endpoints (gateway vs interface), flow logs, peering, Lambda in a VPC (reaching the internet and AWS services), Site-to-Site VPN and Direct Connect awareness. Covered elsewhere: security group rules, defaults, quotas and the timeout-vs-refused diagnosis → notes/ec2-mastery-guide.md §4; EFS mount targets → notes/ec2-mastery-guide.md §7; Lambda VpcConfig, execution-role permissions, Hyperplane ENI states and VPC invoke errors → notes/lambda-guide.md §10; private REST APIs → notes/api-gateway-guide.md §2; aws:SourceIp and other condition-key basics → notes/iam-guide.md §5; explicit-deny evaluation → notes/advanced-identity-guide.md §11; DynamoDB table policies → notes/dynamodb-guide.md §13; bucket policy grammar → notes/s3-guide.md §2; CloudWatch Logs Insights → notes/monitoring-guide.md §4; CodeBuild vpcConfig → notes/cicd-guide.md §3.
• How to use it: /explain <topic> teaches from these sections (concept → exam facts → developer angle → traps → 3 check questions); /quiz vpc asks bank questions whose source_note links point at the ## N. headings below; /drill vpc fires short recall prompts from notes/vpc-cheat-sheet.md. Suggested loop: read a section, answer its practice questions before opening the answers, /explain what is still unclear, then /quiz vpc and /drill vpc.

How VPC appears on DVA-C02

DVA-C02 doesn't test network design. VPC shows up as the environment around your code: a function or instance that can't reach something, a resource that must stay private, a log that has to explain a dropped connection. What you must get right:

• Reachability: what a public or private subnet can reach, and which piece (route, NAT gateway, endpoint, security group, NACL) is missing when a call hangs.
• Reaching AWS APIs without the internet: gateway vs interface endpoints, private DNS, and the policies that pin access to one endpoint or VPC.
• Troubleshooting evidence: reading flow log ACCEPT/REJECT records and NAT gateway metrics instead of guessing.
• Serverless networking: what changes when a Lambda function is attached to a VPC, and the cheapest way to restore each call.
• Connecting networks: peering rules, and when a Site-to-Site VPN or Direct Connect is the answer.

Typical question shapes: a timeout after a configuration change; "MOST secure" or "MOST cost-effective" private access to S3 or DynamoDB; a flow log excerpt to interpret; "Which TWO…" steps to make a connection work.

Domain map: Troubleshooting and Optimization → §1 (NAT metrics), §2 (flow logs), §4 (timeouts) · Security → §2 (filtering), §3 (endpoint policies and condition keys), §5 (encryption of links).

Out of scope here: CIDR planning, routing architecture, Transit Gateway and Cloud WAN design, BGP, IPv6 migration, appliance inspection designs, and the rarer endpoint types (Gateway Load Balancer endpoints, the resource and service-network endpoints added in Dec 2024 for VPC Lattice and shared resources, and endpoint services that publish your own load-balancer-fronted service to other VPCs).

1. Subnets route tables and gateways

Concept

• A VPC is an isolated network in one Region; each subnet is a slice of its address range that lives in exactly one Availability Zone, so a multi-AZ application uses one subnet per AZ for each tier.
• A subnet is public or private only because of its route table: a route to an internet gateway (IGW) makes it public; without one it is private and needs a NAT device for outbound internet access. A subnet with no route out of the VPC is isolated; one that routes only to a virtual private gateway is VPN-only.
• Classic three-tier layout: the load balancer in public subnets, the application tier (Auto Scaling group or containers) in private subnets, RDS and ElastiCache in private data subnets. Only the load balancer is reachable from the internet; the app tier goes out through NAT. Shared files for such a fleet (EFS, one mount target per AZ): notes/ec2-mastery-guide.md §7.
• The IGW is the VPC's door to the internet: horizontally scaled and redundant, one per VPC, free of charge; it maps each resource's private IPv4 address one-to-one to its public IPv4 or Elastic IP address. A NAT gateway lets private resources open outbound connections while refusing connections that start outside the VPC; for IPv6 the outbound-only device is the egress-only internet gateway (IPv6 only, stateful, no charge, no security group; the subnet's NACL applies).

Exam facts

• Internet access needs all of: an IGW attached to the VPC, a 0.0.0.0/0 (or ::/0) route to it in the subnet's route table, a public IPv4, Elastic IP or IPv6 address, and security group plus NACL rules that allow the traffic; a public IP in a subnet without the IGW route still gets no internet access. The default VPC ships with the IGW, that route and auto-assigned public IPv4 addresses in its default subnets; a VPC you create has none of them until you add them.
• Subnets are /16 to /28; AWS reserves 5 addresses in each (network, VPC router, DNS at base + 2, future use, broadcast), so a /24 leaves 251 usable addresses for instances, Lambda ENIs and endpoints. A subnet without an explicit association uses the VPC's main route table.
• Zonal NAT gateway (default --availability-mode zonal): created in a public subnet, with an Elastic IP at creation for the public type. It lives in one AZ, so when that AZ fails every subnet routed to it loses internet access: create one per AZ and route each private subnet to the NAT gateway in its own AZ.
• ⚠️ Changed: a regional NAT gateway (since 19 Nov 2025, --availability-mode regional) needs no public subnet, expands into AZs where you have network interfaces (up to 60 minutes for a new AZ, served cross-AZ until then), appears as one NAT ID in every route table, gets its own route table with a route to the IGW and supports up to 32 IP addresses per AZ; it has no private connectivity mode. Older material may say a NAT gateway always sits in one AZ inside a public subnet.
• NAT gateway behaviour: TCP, UDP and ICMP only; 55,000 simultaneous connections per IP address to each unique destination (IP, port, protocol); up to 8 IPs per zonal NAT gateway (a public one is limited to 2 Elastic IPs by default, raisable to 8); a connection idle for 350 s times out and later packets get an RST; no security group can be attached, but the NACL of its subnet applies; quota 5 per AZ (adjustable); billed per hour and per GB processed, and its Elastic IP is billed as a public IPv4 address (notes/ec2-mastery-guide.md §4); it never answers ping.
• ⚠️ Changed: NAT gateway bandwidth is 5 Gbps scaling automatically to 100 Gbps, and its packet rate 1 million scaling to 10 million packets per second (since June 2022). Older material may say 45 Gbps and 4 million packets per second.
• A private NAT gateway (--connectivity-type private) gives outbound-only access to other VPCs or on-premises networks through a transit gateway or virtual private gateway; it takes no Elastic IP, and an IGW drops any traffic it sends there.
• ⚠️ Changed: a NAT instance is an EC2 instance you run yourself (public subnet, public IP, source/destination check disabled, your own failover, scaling and patching); the AWS NAT AMI is built on Amazon Linux AMI 2018.03, which reached end of maintenance support on 31 Dec 2023, and AWS recommends migrating to NAT gateways or building your own NAT AMI from AL2023 or Amazon Linux 2. Older material may present the AWS NAT AMI as a ready-made option.
• ⚠️ Changed: VPC Block Public Access (since 19 Nov 2024) blocks IGW and egress-only IGW traffic for an account and Region (bidirectional or ingress-only mode), with exclusions per VPC or subnet; blocked flows show reject-reason BPA in flow logs. Older material may say an IGW route plus a public IP always means internet access.

Developer angle

# Zonal public NAT gateway (Elastic IP from: aws ec2 allocate-address --domain vpc) + the private default route
aws ec2 create-nat-gateway --subnet-id subnet-0a1b2c3d4e5f60718 --allocation-id eipalloc-0123456789abcdef0
aws ec2 create-route --route-table-id rtb-0b2c3d4e5f6071829 \
  --destination-cidr-block 0.0.0.0/0 --nat-gateway-id nat-0123456789abcdef0
aws ec2 create-nat-gateway --vpc-id vpc-0123456789abcdef0 --availability-mode regional  # regional, automatic mode: no subnet
# Routes a subnet uses; empty output = implicit association with the main route table
# (gateway endpoint routes have no CIDR: DestinationPrefixListId shows their pl-… destination)
aws ec2 describe-route-tables --filters Name=association.subnet-id,Values=subnet-0f1e2d3c4b5a69788 \
  --query 'RouteTables[].Routes[].[DestinationCidrBlock,DestinationPrefixListId,GatewayId,NatGatewayId,State]' --output table

• NAT gateway metrics (namespace AWS/NATGateway, 1-minute data): ErrorPortAllocation above zero means too many concurrent connections to one destination (add secondary IPs, reuse connections, spread clients over more NAT gateways); a rising IdleTimeoutCount points at clients reusing stale connections (send TCP keepalives more often than every 350 s); ConnectionEstablishedCount below ConnectionAttemptCount means destinations don't answer; PacketsDropCount counts drops.
• "Private instance can't reach the internet" checklist: NAT gateway Available; private route 0.0.0.0/0 → nat-…; the NAT gateway's own subnet routes 0.0.0.0/0 → igw-…; client security group egress; NACLs of both subnets (NAT gateways use ports 1024–65535).

Traps

• Trap: "Give the private instance a public IP so it can download packages." → Reality: without an IGW route in its subnet the address is useless; route the subnet to a NAT gateway.
• Trap: "One NAT gateway serves every AZ with high availability." → Reality: a zonal NAT gateway fails with its AZ; use one per AZ, or a regional NAT gateway.
• Trap: "Attach a security group to the NAT gateway to restrict egress." → Reality: not possible; filter with the clients' security groups and the subnets' NACLs.
• Trap: "Use an egress-only internet gateway for outbound IPv4." → Reality: it carries IPv6 only; IPv4 goes through NAT.

Practice questions

1. A team runs containers on EC2 instances in private subnets across three Availability Zones. One NAT gateway in the first AZ serves every private subnet. The team must keep outbound internet access if any single AZ fails and wants the fewest route-table changes when workloads later expand into a fourth AZ. What should the developer do?

   • A. Create an egress-only internet gateway and route 0.0.0.0/0 from every private subnet to it.
   • B. Launch a NAT instance in each AZ from the AWS NAT AMI and route each subnet to its local instance.
   • C. Create a regional NAT gateway and point the default route of every private subnet at its ID.
   • D. Associate two secondary Elastic IP addresses with the existing NAT gateway.

2. An application in private subnets opens thousands of short HTTPS connections per minute to one partner endpoint through a public NAT gateway. New connections fail intermittently, and the NAT gateway's ErrorPortAllocation metric is above zero. Which TWO actions reduce these failures? (Select TWO.)

   • A. Attach a security group to the NAT gateway that allows the whole ephemeral port range.
   • B. Associate secondary IPv4 addresses with the NAT gateway.
   • C. Raise the rules-per-network-ACL quota for the NAT gateway's subnet.
   • D. Reuse connections through keep-alive connection pooling in the HTTP client.
   • E. Send the private subnets' default route to an egress-only internet gateway.

2. Security groups network ACLs and flow logs

Concept

• Two independent filters guard every packet that enters or leaves a subnet; traffic between ENIs inside one subnet meets only their SGs, because NACL rules aren't evaluated within a subnet. A network ACL (NACL) sits at the subnet boundary, is stateless and evaluates numbered allow and deny rules; a security group (SG) sits on each network interface, is stateful and only allows. Traffic entering a subnet crosses its NACL, then the SG of the target ENI; the reply must pass the NACL again because NACLs remember nothing. SGs are the primary control and the tool for least privilege (SG-to-SG references); NACLs are coarse subnet guardrails, mostly used to deny specific ranges (SG rules, defaults, quotas and the timeout-vs-refused diagnosis: notes/ec2-mastery-guide.md §4).
• VPC Flow Logs record metadata about IP flows per ENI (addresses, ports, protocol, packets, bytes, ACCEPT or REJECT). They carry no payload and aren't real time, but they prove whether a packet arrived and which direction was refused.

Exam facts

• Neither SGs nor NACLs filter traffic to the Amazon DNS server (Route 53 Resolver, VPC base + 2), instance metadata, Amazon Time Sync, DHCP, ECS task metadata, Windows license activation or the VPC router's reserved addresses. Flow logs skip most of the same traffic (Amazon DNS queries, 169.254.169.254, 169.254.169.123, DHCP, license activation, the router's reserved address) plus ARP, mirrored source traffic and traffic between an endpoint ENI and an NLB ENI.
• Flow logs attach to a VPC, subnet or ENI; a VPC or subnet flow log covers every ENI in it, including those other services create (load balancers, RDS, ElastiCache, NAT gateways). ⚠️ Changed: transit gateways, transit gateway attachments and regional NAT gateways take flow logs too (--resource-type). Older material may list only VPC, subnet and network interface flow logs. They capture ACCEPT, REJECT or ALL and publish to CloudWatch Logs, S3 (text or Parquet, queryable with Athena) or Amazon Data Firehose. ⚠️ Changed: the Firehose destination is Amazon Data Firehose (renamed in Feb 2024; the CLI value is still kinesis-data-firehose). Older material may say Kinesis Data Firehose.
• Default record (version 2): version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status. Custom formats add fields such as vpc-id, instance-id, tcp-flags, pkt-srcaddr/pkt-dstaddr (original addresses behind a NAT gateway), flow-direction, traffic-path and reject-reason (BPA = Block Public Access, EC = encryption controls). log-status NODATA = no traffic in the interval; SKIPDATA = records were skipped. Timing and limits: aggregation interval 10 minutes by default or 1 minute (always 1 minute or less on Nitro instances); delivery typically takes about 5 minutes to CloudWatch Logs and 10 minutes to S3, best effort. A flow log can't be edited after creation (format, role): delete it and create a new one. Flow logs don't affect throughput or latency, and you can't log a peer VPC owned by another account.
• Reading records: an inbound ACCEPT followed by an outbound REJECT of the reply points at a NACL missing the return rule; a single inbound REJECT means the SG or NACL refused the request. CloudWatch Logs Insights discovers the default-format fields automatically (filter action = "REJECT" | stats count(*) as rejects by srcAddr, dstPort; Insights itself: notes/monitoring-guide.md §4). For a static check without traffic, Reachability Analyzer names the blocking SG, NACL, route table or load balancer (charged per analysis).
• Delivery permissions: CloudWatch Logs needs an IAM role trusted by vpc-flow-logs.amazonaws.com with logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents, logs:DescribeLogGroups and logs:DescribeLogStreams, and the caller needs iam:PassRole on it. S3 needs a bucket policy that lets delivery.logs.amazonaws.com call s3:PutObject and s3:GetBucketAcl; if the creator owns the bucket and may read and write its policy, AWS attaches that policy itself and overwrites the existing one.

Developer angle

# Deny one abusive address at rule 90, before rule 100 that allows 443 from 0.0.0.0/0; let replies out
aws ec2 create-network-acl-entry --network-acl-id acl-0123456789abcdef0 --ingress --rule-number 90 \
  --protocol tcp --port-range From=443,To=443 --cidr-block 198.51.100.7/32 --rule-action deny
aws ec2 create-network-acl-entry --network-acl-id acl-0123456789abcdef0 --egress --rule-number 100 --protocol tcp --port-range From=1024,To=65535 --cidr-block 0.0.0.0/0 --rule-action allow
# Rejected traffic of one subnet to CloudWatch Logs, 1-minute aggregation
aws ec2 create-flow-logs --resource-type Subnet --resource-ids subnet-0a1b2c3d4e5f60718 --traffic-type REJECT \
  --log-group-name /vpc/app-subnet/rejects --max-aggregation-interval 60 --deliver-logs-permission-arn arn:aws:iam::111122223333:role/FlowLogsToCloudWatch

Traps

• Trap: "Add an outbound SG rule so the responses can leave." → Reality: SGs are stateful; only a NACL needs a rule for return traffic.
• Trap: "Deny the attacker's IP in the security group." → Reality: SGs have no deny rules; use a lower-numbered NACL deny (or AWS WAF for HTTP).
• Trap: "An allow at rule 200 overrides a deny at rule 100." → Reality: the lowest-numbered match wins and evaluation stops there.
• Trap: "Reference the app tier's SG or the S3 prefix list in a NACL rule." → Reality: NACL rules take CIDR blocks only.
• Trap: "Add a field to the existing flow log." → Reality: flow logs are immutable; create a new one with a custom format.

Practice questions

1. A developer runs an HTTPS service on an instance in a public subnet that uses a custom network ACL. Requests from internet clients time out. The flow log for the instance's network interface shows an ACCEPT record from a client to port 443 and a REJECT record from port 443 back to the client's port 51544. What is the most likely cause?

   • A. The instance's security group has no outbound rule that allows the HTTPS responses.
   • B. The network ACL has no outbound rule that allows TCP 1024–65535 to the clients.
   • C. The instance's security group has no inbound rule for TCP 443.
   • D. The subnet's route table has no route to the internet gateway.

2. A CI role runs aws ec2 create-flow-logs to send one subnet's rejected traffic to a CloudWatch Logs log group. Which TWO are required for the flow log to be created and delivered? (Select TWO.)

   • A. An IAM role that vpc-flow-logs.amazonaws.com can assume, with CloudWatch Logs write permissions.
   • B. The CloudWatch agent installed and running on every instance in the subnet.
   • C. iam:PassRole permission for the CI role on that delivery role.
   • D. A bucket policy that lets delivery.logs.amazonaws.com call s3:PutObject.
   • E. The enableDnsHostnames attribute turned on for the VPC.

3. VPC endpoints for AWS services

Concept

• AWS APIs have public endpoints, so without help a private subnet reaches them through a NAT gateway and the IGW: the traffic stays on the AWS network, but it needs an internet path and pays NAT processing. VPC endpoints give a private path with no IGW or NAT.
• Gateway endpoint (S3 and DynamoDB only): a route-table target. AWS adds a route whose destination is the service's managed prefix list (pl-…) to each route table you associate; requests still go to the service's public addresses, over that private path. No charge.
• Interface endpoint (AWS PrivateLink; S3, DynamoDB and the large majority of other AWS services): a requester-managed ENI with private IPs in each subnet you pick (one per AZ), protected by a security group and found through DNS. Billed per hour per AZ plus per GB.

Exam facts

• Gateway routes are added and removed by AWS and can't be edited; the most specific route wins, so the endpoint route beats 0.0.0.0/0 for that service in the same Region, while S3 traffic to other Regions still leaves through the IGW or NAT. One endpoint route per service per route table; creating or changing one resets open TCP connections. NACLs can't reference prefix lists, so allow the service CIDRs there.
• Private DNS (interface endpoints): a hidden, AWS-managed private hosted zone makes the default name (for example secretsmanager.eu-west-1.amazonaws.com) resolve to the endpoint's private IPs, so SDK code needs no change. It requires both VPC attributes enableDnsSupport (default true) and enableDnsHostnames (default false except in the default VPC). Without private DNS, call the endpoint-specific name vpce-…-xxxx.<service>.<region>.vpce.amazonaws.com through --endpoint-url. ⚠️ Changed: S3 interface endpoints support private DNS; the option "private DNS only for inbound endpoint" (the default when you enable it) sends in-VPC requests to the S3 gateway endpoint, which must exist, and on-premises requests to the interface endpoint. Older material may say S3 interface endpoints always need endpoint-specific DNS names.
• ⚠️ Changed: DynamoDB has interface endpoints too (since 19 Mar 2024), without private DNS: point the SDK at the endpoint URL, for example boto3.client("dynamodb", endpoint_url="https://vpce-0123456789abcdef0-abcd1234.dynamodb.eu-west-1.vpce.amazonaws.com") (CLI: --endpoint-url). Older material may say DynamoDB supports only gateway endpoints.
• ⚠️ Changed: interface endpoints can reach some AWS services in another Region (for example S3, IAM, ECR, KMS, ECS, Lambda and Amazon Data Firehose) with --service-region; callers need the permission-only action vpce:AllowMultiRegion. Older material may say endpoints only reach services in their own Region. Gateway endpoints remain same-Region only.
• Endpoint policy: a resource policy on the endpoint, in IAM policy language with a Principal (gateway endpoints: "*" plus aws:PrincipalArn conditions); the default allows everything; 20,480 characters at most; changes take a few minutes. It only limits what may pass and replaces none of the other policies: the call still needs the usual allow, from an identity-based or a resource-based policy in the same account, from both for cross-account access (notes/advanced-identity-guide.md §11).
• Condition keys present only on requests that arrive through a VPC endpoint: aws:SourceVpce (endpoint ID), aws:SourceVpc (VPC ID), aws:SourceVpcArn (preferred where the service supports it) and aws:VpcSourceIp (the caller's private IP; always pair it with one of the others). aws:SourceIp is absent on such requests, so a NotIpAddress deny on it blocks endpoint traffic. A bucket policy that denies requests without the expected aws:SourceVpce also blocks console and on-premises access; an explicit deny beats every allow (notes/advanced-identity-guide.md §11). Private REST APIs use an execute-api interface endpoint (notes/api-gateway-guide.md §2).

Developer angle

# S3 gateway endpoint (Gateway is the default --vpc-endpoint-type); then an interface endpoint with private DNS
aws ec2 create-vpc-endpoint --vpc-id vpc-0123456789abcdef0 --service-name com.amazonaws.eu-west-1.s3 --route-table-ids rtb-0b2c3d4e5f6071829 rtb-0c3d4e5f607182930
aws ec2 modify-vpc-attribute --vpc-id vpc-0123456789abcdef0 --enable-dns-hostnames "{\"Value\":true}"  # one attribute per call
aws ec2 create-vpc-endpoint --vpc-id vpc-0123456789abcdef0 --vpc-endpoint-type Interface --private-dns-enabled \
  --service-name com.amazonaws.eu-west-1.secretsmanager --subnet-ids subnet-0a1b2c3d4e5f60718 subnet-0f1e2d3c4b5a69788 --security-group-ids sg-0aa11bb22cc33dd44

• Bucket policy that refuses everything not arriving through one endpoint: one statement with "Effect": "Deny", "Principal": "*", "Action": "s3:*", both arn:aws:s3:::orders-archive and arn:aws:s3:::orders-archive/* as Resource, and "Condition": {"StringNotEquals": {"aws:SourceVpce": "vpce-0123456789abcdef0"}} (aws:SourceVpc instead admits a whole VPC). Read the symptom: a call through an endpoint that times out is networking (endpoint SG inbound 443, caller SG egress, NACL, or a name still resolving to public IPs with no NAT); an AccessDenied is policy (endpoint policy, bucket or table conditions, identity policy).

Traps

• Trap: "On-premises servers can use the S3 gateway endpoint over Direct Connect." → Reality: gateway endpoints serve only traffic routed by the VPC's own route tables; use an interface endpoint.
• Trap: "Turn on private DNS and it works in any VPC." → Reality: both enableDnsSupport and enableDnsHostnames must be true, and every VPC except the default one starts with enableDnsHostnames false.
• Trap: "An endpoint policy that allows s3:GetObject lets any role read the bucket." → Reality: it only filters; the role still needs an allow from its IAM policy or the bucket policy (from both if the bucket is in another account).
• Trap: "Restrict the bucket to the VPC with aws:SourceIp and the private CIDR." → Reality: use aws:SourceVpce or aws:SourceVpc (or aws:VpcSourceIp together with one of them).

Practice questions

1. Instances in private subnets with no NAT gateway write nightly exports to an S3 bucket in the same Region. Security requires that the traffic never uses an internet path, and the team wants the MOST cost-effective solution. What should the developer do?

   • A. Create an interface endpoint for S3 in each private subnet and enable private DNS.
   • B. Add a NAT gateway in a public subnet and limit the bucket policy to its Elastic IP with aws:SourceIp.
   • C. Turn on S3 Transfer Acceleration and upload to the accelerate endpoint.
   • D. Create a gateway endpoint for S3 and associate it with the private subnets' route tables.

2. An application on instances in private subnets calls Amazon SQS through an interface endpoint with private DNS; from the instances the queue's hostname resolves to private IPs. The endpoint uses a new security group with no inbound rules, and the instances' security group allows outbound traffic only to the database security group on TCP 5432. Calls to SQS time out. Which TWO changes fix the timeouts? (Select TWO.)

   • A. Add a 0.0.0.0/0 route that targets the endpoint in the private subnets' route tables.
   • B. Add an inbound TCP 443 rule to the endpoint's security group with the instances' security group as the source.
   • C. Replace the default endpoint policy with one that allows sqs:SendMessage for the instance role.
   • D. Turn on the enableDnsHostnames attribute of the VPC so that private DNS names resolve.
   • E. Add an outbound TCP 443 rule to the instances' security group with the endpoint's security group as the destination.

4. Lambda functions in a VPC

Concept

• Every function runs in a Lambda-owned VPC that has internet access but can't see your private resources. Adding VpcConfig (subnets plus security groups) makes Lambda place Hyperplane ENIs in your subnets: the function can now reach RDS, ElastiCache or internal services, but all its outbound traffic follows your VPC's routes.
• From then on the function has no public IP, not even in a public subnet. Internet calls need private subnets routed to a NAT gateway; AWS API calls need that NAT path or VPC endpoints.
• Configuration commands, execution-role permissions (AWSLambdaVPCAccessExecutionRole), ENI lifecycle states and VPC invoke errors are in notes/lambda-guide.md §10; this section covers the network path.

Exam facts

• Working pattern: the function in private subnets in at least two AZs → each private route table sends 0.0.0.0/0 to a NAT gateway (a zonal one in a public subnet of that AZ, or one regional NAT gateway) → the NAT gateway's route table sends 0.0.0.0/0 to the IGW. Choosing public subnets doesn't help: Lambda never assigns public IPs, so a function there has neither internet access nor a public address.
• AWS services without NAT: gateway endpoints for S3 and DynamoDB (free) and interface endpoints for the rest, for example SQS, SNS, Secrets Manager, Systems Manager, KMS, STS, or lambda to invoke other functions.
• A missing path shows up as a timeout, not an error code: Task timed out after N seconds, or client errors such as Error: connect ETIMEDOUT and ReadTimeoutError while the SDK waits and retries; check the subnets' routes for 0.0.0.0/0 → nat-… and for pl-… endpoint routes (§1 command). Logs are unaffected: Lambda itself captures function output and sends it to CloudWatch Logs, so no NAT or Logs endpoint is needed (Lambda Managed Instances are the exception: they need a network path for telemetry).
• Security groups: the function's SG needs outbound rules to its targets; each target (database, cache, endpoint ENI) allows inbound from the function's SG. With custom NACLs, allow Lambda's ephemeral ports 1024–65535 for both TCP and UDP, or connections fail intermittently.
• IPv6 outbound needs Ipv6AllowedForDualStack=true with dual-stack subnets only (IPv6-only subnets aren't supported) and a ::/0 route to an egress-only internet gateway.
• Hyperplane ENIs are shared by functions with the same subnet and SG combination, each handling up to 65,000 connections; size subnets with the 5 reserved addresses in mind (§1). Functions can't attach directly to a VPC with dedicated instance tenancy.
• Governance: deny lambda:CreateFunction and lambda:UpdateFunctionConfiguration when lambda:VpcIds is null to force VPC attachment, or pin lambda:SubnetIds and lambda:SecurityGroupIds.

Developer angle

# Attach the function to two private subnets with its own security group; detach again with empty lists
aws lambda update-function-configuration --function-name orders-api \
  --vpc-config SubnetIds=subnet-0a1b2c3d4e5f60718,subnet-0f1e2d3c4b5a69788,SecurityGroupIds=sg-0aa11bb22cc33dd44
aws lambda update-function-configuration --function-name orders-api --vpc-config SubnetIds=[],SecurityGroupIds=[]

Fail fast instead of burning the whole function timeout when a path is missing:

import boto3
from botocore.config import Config
sns = boto3.client("sns", config=Config(connect_timeout=3, read_timeout=5, retries={"max_attempts": 2, "mode": "standard"}))

Traps

• Trap: "Move the function to a public subnet to restore internet access." → Reality: no public IP is ever assigned; use private subnets plus NAT.
• Trap: "Put the NAT gateway in the function's private subnet." → Reality: a zonal public NAT gateway must sit in a public subnet whose route table points to the IGW (or use a regional NAT gateway).
• Trap: "After VPC attachment the function needs NAT just to write logs." → Reality: Lambda itself sends the logs to CloudWatch Logs (Lambda Managed Instances excepted).
• Trap: "A NAT gateway is the cheapest way to reach DynamoDB from a VPC function." → Reality: a DynamoDB gateway endpoint is free and needs no internet path.
• Trap: "A timeout right after VPC attachment means the code got slower." → Reality: it usually means no route (NAT or endpoint) or a blocking SG or NACL.

Practice questions

1. A function was attached to private subnets so it can read from an ElastiCache cluster. It must also publish to an Amazon SNS topic, and the security team forbids any route from these subnets to the internet. Since the change, the publish calls time out. What should the developer do?

   • A. Create an SNS interface endpoint with private DNS in the function's subnets.
   • B. Move the function to public subnets that route to the internet gateway.
   • C. Create a gateway VPC endpoint for SNS and associate the subnets' route tables.
   • D. Add a NAT gateway and send the private subnets' default route to it.

2. A developer attaches an existing function to private subnets so it can query an Aurora cluster. The function also downloads large objects from an S3 bucket in the same Region and calls a public exchange-rate API over HTTPS. The VPC has an internet gateway but no NAT gateway. Which TWO actions restore both calls at the LOWEST cost? (Select TWO.)

   • A. Create an S3 interface endpoint in each private subnet.
   • B. Move the function to public subnets that auto-assign public IPv4 addresses.
   • C. Create an S3 gateway endpoint and associate it with the private subnets' route tables.
   • D. Create a NAT gateway in a public subnet and route the private subnets' 0.0.0.0/0 traffic to it.
   • E. Create an interface endpoint for the exchange-rate API's domain name.

5. Peering VPN and Direct Connect

Concept

• VPC peering joins exactly two VPCs (same or different accounts and Regions) so they route to each other's private addresses over the AWS backbone. It isn't a gateway or appliance, so there's no single point of failure or bandwidth bottleneck, but it is strictly point to point.
• AWS Transit Gateway is the managed hub when many VPCs and on-premises networks must all reach each other; know it as the answer, not its design.
• AWS Site-to-Site VPN: IPsec tunnels across the internet between your customer gateway device and a virtual private gateway (attached to one VPC) or a transit gateway. Quick to set up, performance varies with the internet.
• AWS Direct Connect (DX): a physical Ethernet link from your network to a DX location that bypasses internet providers: consistent bandwidth and latency on a private path, after a provisioning lead time, and without encryption unless you add it.

Exam facts

• A working peering needs: a request (create-vpc-peering-connection), acceptance by the accepter VPC's owner within 7 days (accept-vpc-peering-connection), routes to the peer's CIDR in both VPCs' route tables, and SG and NACL rules that allow the traffic.
• Blockers: matching or overlapping IPv4 or IPv6 CIDR blocks (any overlapping block, even an unused secondary one); a second peering between the same two VPCs; transitive paths (A–B plus B–C doesn't connect A and C); edge-to-edge use of the peer's IGW, NAT device, VPN, Direct Connect or gateway endpoint (a peer's interface endpoints, by contrast, are reachable, as they are over VPN and Direct Connect: §3).
• SG rules can reference a peer's SG only when both VPCs are in the same Region; inter-Region peers use CIDRs. DNS resolution is a per-side option of an active peering: a side's option makes the public DNS hostnames of instances in its own VPC resolve to private IPs when queried from the peer VPC (the requester option serves queries from the accepter VPC, the accepter option queries from the requester VPC). Each VPC's owner sets its own side (inter-Region: in that VPC's Region), and both VPCs need both DNS attributes on.
• Quotas and cost: 50 active peerings per VPC (adjustable to 125), 25 outstanding requests; no charge to create; data transfer within one AZ is free, across AZs and Regions it's charged; inter-Region traffic is encrypted and stays on the AWS backbone.
• Site-to-Site VPN: two tunnels per connection for redundancy; IPsec with IKEv2 support; one virtual private gateway per VPC. ⚠️ Changed: a standard tunnel carries up to 1.25 Gbps and 140,000 packets per second, and a Large Bandwidth Tunnel up to 5 Gbps and 400,000 packets per second (VPN attached to a transit gateway or Cloud WAN only). Older material may give 1.25 Gbps as the only tunnel size. Billed per connection hour plus data transfer out.
• Direct Connect: dedicated connections at 1, 10, 100 or 400 Gbps (port speed fixed once requested) or hosted connections from 50 Mbps to 25 Gbps through a DX Partner; a private VIF reaches one VPC (or a DX gateway), a public VIF reaches public AWS services, a transit VIF reaches transit gateways; billed per port hour plus data transfer out.
• ⚠️ Changed: Direct Connect doesn't encrypt traffic in transit by default (AWS's physical-layer encryption covers only its own network between DX locations and Regions, not your link to the DX location); use MACsec on 10, 100 or 400 Gbps dedicated connections at supported locations, an IPsec Site-to-Site VPN over DX, or TLS in the application. Older material may treat a private DX line as already secure, with no encryption needed.
• Lead time: AWS reviews the request and provisions the port within up to 72 business hours, then your provider orders the cross-connect with the LOA-CFA; the DX User Guide gives no end-to-end lead time (⚠️ unverified: the course puts it at a month or more). A Site-to-Site VPN covers the wait, because it's quick to set up, and can stay afterwards as DX's backup path: for the same prefix, the virtual private gateway prefers routes propagated from DX over VPN routes.

Developer angle

# Cross-account, cross-Region peering: request, accept (as the accepter), route both ways
aws ec2 create-vpc-peering-connection --vpc-id vpc-0aaa1111bbbb22223 \
  --peer-vpc-id vpc-0ccc3333dddd44445 --peer-owner-id 444455556666 --peer-region eu-central-1
aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id pcx-0123456789abcdef0 --region eu-central-1
aws ec2 create-route --route-table-id rtb-0b2c3d4e5f6071829 \
  --destination-cidr-block 10.20.0.0/16 --vpc-peering-connection-id pcx-0123456789abcdef0
# Requester's side, set by its owner in its Region: lets the accepter VPC resolve the requester's public DNS hostnames
# to private IPs; for the reverse, the accepter's owner sets --accepter-peering-connection-options in eu-central-1
aws ec2 modify-vpc-peering-connection-options --vpc-peering-connection-id pcx-0123456789abcdef0 \
  --requester-peering-connection-options AllowDnsResolutionFromRemoteVpc=true

• Application code doesn't change: it calls the peer's private IPs or private DNS names. The work is the mirror route in the peer's route tables, SG rules (the peer's SG ID in the same Region, its CIDR otherwise) and the DNS option.
• Code that reaches an on-premises database over VPN or DX needs a route to the on-premises CIDR (static, or propagated from the virtual private gateway), SG egress to that CIDR and port, and NACL rules in both directions.

Traps

• Trap: "VPC A peers with B and B peers with C, so A reaches C." → Reality: peering isn't transitive; peer A with C or use a transit gateway.
• Trap: "Peered VPC A can use VPC B's NAT gateway for internet access." → Reality: a peer's gateways can't be used edge to edge.
• Trap: "The peering is active, so traffic flows." → Reality: both route tables need routes and the SGs must allow the peer.
• Trap: "Reference the peer's security group across Regions." → Reality: only for same-Region peers; use the peer's CIDR.
• Trap: "Direct Connect traffic is encrypted." → Reality: not by default; add MACsec or a VPN over DX.

Practice questions

1. A company has VPCs A, B and C in one Region with non-overlapping CIDRs. A is peered with B, and B is peered with C. An application in VPC A must call a service in VPC C. Which solution needs the fewest new resources?

   • A. Add a route in VPC A for VPC C's CIDR that targets the existing A–B peering connection.
   • B. Enable DNS resolution on both existing peering connections.
   • C. Peer VPC A with VPC C and add routes for each other's CIDR in both VPCs.
   • D. Create a NAT gateway in VPC B and route VPC A's traffic for VPC C through it.

2. A company moves a nightly 20 TB database export from its data center to AWS. It needs consistent throughput that doesn't depend on internet conditions, and its policy requires encryption on the network link itself. Which TWO steps meet the requirements? (Select TWO.)

   • A. Order a 10 Gbps dedicated Direct Connect connection at a location that supports MACsec.
   • B. Rely on the encryption that Direct Connect applies to all traffic by default.
   • C. Use a Site-to-Site VPN over the internet as the only connection.
   • D. Configure MACsec on the dedicated connection with a CKN/CAK key pair.
   • E. Peer the data center network with the VPC through VPC peering.

Quick decision rules

Subnets, NAT and filtering (§1–§2)

• If you see a private-subnet resource that can't reach the internet, think 0.0.0.0/0 to a NAT gateway that itself sits in a public subnet routed to the IGW (or a regional NAT gateway).
• If you see a public IP that still gives no internet access, think missing IGW route in the subnet's route table (or VPC Block Public Access).
• If you see "only the load balancer may face the internet", think load balancer in public subnets, app and data tiers in private subnets, NAT for the app tier's outbound calls.
• If you see "NAT that survives an AZ failure without per-AZ routes", think regional NAT gateway (--availability-mode regional).
• If you see ErrorPortAllocation, think too many connections to one destination: add NAT IPs and reuse connections.
• If you see idle connections through NAT dropped after about six minutes, think the 350 s idle timeout and TCP keepalive.
• If you see outbound-only IPv6, think egress-only internet gateway.
• If you see "block one IP address", think a NACL deny with a lower rule number (security groups can't deny).
• If you see a request ACCEPT followed by a reply REJECT in flow logs, think stateless NACL missing the ephemeral-port return rule.
• If you see flow logs that never reach CloudWatch Logs, think delivery role trusted by vpc-flow-logs.amazonaws.com plus iam:PassRole.
• If you see "find the blocking component without sending traffic", think Reachability Analyzer.

Endpoints and Lambda (§3–§4)

• If you see private, free access to S3 or DynamoDB from inside the VPC, think gateway endpoint.
• If you see S3 or DynamoDB access from on-premises or another Region, think interface endpoint.
• If you see "the bucket must accept traffic only from our endpoint", think a deny on aws:SourceVpce (or aws:SourceVpc for the whole VPC).
• If you see a timeout through an interface endpoint, think endpoint SG inbound 443, caller SG egress and private DNS; AccessDenied means a policy.
• If you see private DNS failing on an interface endpoint, think enableDnsSupport plus enableDnsHostnames.
• If you see a VPC-attached function that lost internet access, think private subnets plus NAT; public subnets never help.
• If you see a VPC function that must reach AWS services with no internet route, think VPC endpoints (gateway for S3 and DynamoDB, interface for the rest).

Connecting networks (§5)

• If you see two VPCs that must talk privately, think peering with non-overlapping CIDRs and routes on both sides; many VPCs all-to-all, think Transit Gateway.
• If you see a quick, encrypted link over the internet, think Site-to-Site VPN; consistent private bandwidth, think Direct Connect.
• If you see Direct Connect plus an encryption requirement, think MACsec or a VPN over DX.

Changed vs older material

Learn the Current column; older practice material may still show the Older material may say value. Once you confirm them, the same rows go to notes/current-facts.md with their verification dates.