Q: What three AWS networking features solve this without internet access, and what are their security and cost trade-offs?

Option 1: **VPC Endpoint (Gateway) for S3**. This is a route-table-level endpoint that routes S3 traffic over the AWS backbone, not the internet. It is free but only supports S3 and DynamoDB. Security: traffic never leaves AWS. Limitation: it is regional and does not support cross-region S3 access. Option 2: **VPC Endpoint (Interface) for S3**. This creates an ENI in your subnet with a private IP. It supports private DNS and works with all S3 API operations including cross-region. Cost: $0.01/hour per AZ + $0.01/GB data processed. Security: traffic is encrypted with TLS and stays on the AWS network. Option 3: **AWS PrivateLink for S3 (via Interface Endpoint)** with **endpoint policies**. I attach a resource policy to the endpoint restricting access to specific buckets: `{"Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::trusted-bucket/*"}`. This is the most secure because even if credentials are compromised, the endpoint policy blocks access to untrusted buckets. Trade-off: Interface endpoints cost ~$7.30/month per AZ plus data charges. For high-throughput Lambda (10+ TB/month), Gateway endpoints are preferred because they have no data processing fee. I verify with `aws s3api list-buckets --endpoint-url https://vpce-xxx.s3.us-east-1.vpce.amazonaws.com` from the Lambda.

Q: What five things do you check, in order of most to least likely?

1. **Route table**: the private subnet route table must have a route `0.0.0.0/0 -> nat-gateway-id`. I verify with `aws ec2 describe-route-tables --filters Name=association.subnet-id,Values=subnet-private`. 2. **NAT Gateway state**: NAT Gateways can be in `pending`, `available`, `deleting`, or `failed`. If it is `failed`, AWS usually sends an email but the console may not show it clearly. I check `aws ec2 describe-nat-gateways`. 3. **Security group egress**: the EC2 security group must allow outbound traffic. By default it allows all, but if modified, it may block HTTPS (TCP 443). 4. **NACL egress/ingress**: NACLs are stateless. The private subnet NACL must allow outbound ephemeral ports (1024-65535) and return traffic. A common mistake is NACL rules with incorrect CIDR blocks or rule number ordering (NACLs process lowest rule number first). 5. **NAT Gateway ENI deletion**: if the NAT Gateway's ENI was manually detached or its security group modified, traffic drops. I check the ENI status in the EC2 console. Less likely: the NAT Gateway is in a different AZ than the private subnet (NAT Gateway is AZ-specific, but you can route cross-AZ — it works but incurs $0.01/GB inter-AZ charge).

Question 1

Why is VPC peering insufficient at this scale, and what is the correct Transit Gateway architecture with route table segmentation?

Accepted Answer

VPC peering does not support transitive routing: if VPC A peers with B and B peers with C, A cannot reach C through B. At 50 accounts, full-mesh requires N(N-1)/2 = 1,225 peering connections, each with manual route table management, no central point for traffic inspection, and no cross-region support without inter-region peering. The fix is **AWS Transit Gateway (TGW)**. Architecture: (1) **Shared TGW** in a Network Services account, shared via RAM to all OU accounts. (2) **TGW Route Table segmentation**: create separate route tables per business unit (e.g., `rt-bu-finance`, `rt-bu-engineering`) and associate each BU's VPC attachments to their respective table. This provides **isolation by default** — Finance VPCs cannot talk to Engineering unless both tables propagate to a shared `rt-inter-bu` table. (3) **Propagation control**: use static routes or BGP for on-prem prefixes via Direct Connect Gateway, avoiding full prefix flooding. (4) **Inspection VPC**: attach a centralized inspection VPC with Palo Alto/AWS Network Firewall to the TGW using **TGW appliance mode** to ensure symmetric routing through the firewall. Cost note: TGW charges $0.05/hour per attachment + $0.02/GB processed. For 1,200 peering connections replaced by 150 TGW attachments, the cost typically drops 40-60% because data transfer over peering is $0.01/GB but management overhead is exponentially higher.

Question 2

What is the correct resilient Direct Connect architecture, and what is the SLA implication of each option?

Accepted Answer

The single DX connection is a single point of failure. AWS DX SLA is 99.9% for a single connection, but location-level outages (power, cooling, carrier issues) are outside AWS's control. The correct architecture has three layers of resilience: (1) **Dual DX connections to different locations**: order two DX connections — one to Equinix DC1 and another to Coresite DC2. Connect them to the same DX Gateway. AWS automatically load-balances and fails over. SLA: 99.99% because AWS guarantees path diversity. (2) **Dual DX connections to the same location but different devices**: if you cannot afford two locations, at minimum order two connections terminated on separate AWS DX routers in the same facility. This protects against AWS device failure but not facility-wide outage. (3) **VPN backup**: for <1 Gbps traffic or non-critical workloads, use AWS Site-to-Site VPN as a backup over the public internet. Configure the VPN to advertise the same BGP prefixes with a higher AS_PATH prepend so it is less preferred. I also recommend **DX + VPN active-active** for bandwidth aggregation using ECMP if the customer router supports it. For critical financial workloads, I add **MACsec encryption** on DX to meet compliance requirements. I verify resilience by failing over connections in the AWS DX console and monitoring BGP session drops via CloudWatch.

Question 3

What three AWS networking features solve this without internet access, and what are their security and cost trade-offs?

Accepted Answer

Option 1: **VPC Endpoint (Gateway) for S3**. This is a route-table-level endpoint that routes S3 traffic over the AWS backbone, not the internet. It is free but only supports S3 and DynamoDB. Security: traffic never leaves AWS. Limitation: it is regional and does not support cross-region S3 access. Option 2: **VPC Endpoint (Interface) for S3**. This creates an ENI in your subnet with a private IP. It supports private DNS and works with all S3 API operations including cross-region. Cost: $0.01/hour per AZ + $0.01/GB data processed. Security: traffic is encrypted with TLS and stays on the AWS network. Option 3: **AWS PrivateLink for S3 (via Interface Endpoint)** with **endpoint policies**. I attach a resource policy to the endpoint restricting access to specific buckets: `{"Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::trusted-bucket/*"}`. This is the most secure because even if credentials are compromised, the endpoint policy blocks access to untrusted buckets. Trade-off: Interface endpoints cost ~$7.30/month per AZ plus data charges. For high-throughput Lambda (10+ TB/month), Gateway endpoints are preferred because they have no data processing fee. I verify with `aws s3api list-buckets --endpoint-url https://vpce-xxx.s3.us-east-1.vpce.amazonaws.com` from the Lambda.

Question 4

What five things do you check, in order of most to least likely?

Accepted Answer

1. **Route table**: the private subnet route table must have a route `0.0.0.0/0 -> nat-gateway-id`. I verify with `aws ec2 describe-route-tables --filters Name=association.subnet-id,Values=subnet-private`. 2. **NAT Gateway state**: NAT Gateways can be in `pending`, `available`, `deleting`, or `failed`. If it is `failed`, AWS usually sends an email but the console may not show it clearly. I check `aws ec2 describe-nat-gateways`. 3. **Security group egress**: the EC2 security group must allow outbound traffic. By default it allows all, but if modified, it may block HTTPS (TCP 443). 4. **NACL egress/ingress**: NACLs are stateless. The private subnet NACL must allow outbound ephemeral ports (1024-65535) and return traffic. A common mistake is NACL rules with incorrect CIDR blocks or rule number ordering (NACLs process lowest rule number first). 5. **NAT Gateway ENI deletion**: if the NAT Gateway's ENI was manually detached or its security group modified, traffic drops. I check the ENI status in the EC2 console. Less likely: the NAT Gateway is in a different AZ than the private subnet (NAT Gateway is AZ-specific, but you can route cross-AZ — it works but incurs $0.01/GB inter-AZ charge).

Question 5

What is the correct subnet and security group design, and why are NACLs alone insufficient for this requirement?

Accepted Answer

Architecture: (1) **Public subnets** for ALB in AZ-a and AZ-b. (2) **Private subnets** for app tier EC2/ECS in AZ-a and AZ-b. (3) **Isolated (DB) subnets** for RDS in AZ-a and AZ-b — these have no NAT Gateway route, no IGW route, and no direct internet path. (4) **Security groups**: ALB-SG allows HTTPS (443) from `0.0.0.0/0`. App-SG allows traffic only from ALB-SG (source = security group ID, not IP). DB-SG allows MySQL (3306) only from App-SG. This is **security group referencing**, which is stateful and self-documenting. NACLs alone are insufficient because: (a) NACLs are stateless — you must explicitly allow return traffic, which is error-prone. (b) NACLs cannot reference security groups — they only use CIDR blocks, so if the app tier auto-scales, you must update NACL rules manually. (c) NACLs are subnet-level, not instance-level. If two apps share a subnet, NACLs cannot distinguish between them. I also enable **VPC Flow Logs** on the DB subnet and send them to S3 for analysis. For extra security, I use **AWS Network Firewall** with TLS inspection between app and DB tiers, though this adds latency. I verify with `telnet db-endpoint 3306` from an app instance (should succeed) and from a bastion host in the public subnet (should fail).

Question 6

What is the PrivateLink scaling limit, and what two architectures overcome it?

Accepted Answer

AWS Interface VPC Endpoints create an ENI in each consumer subnet per service. The limit is not on the endpoint service side but on the **consumer VPC IP address space** and **endpoint per VPC limit** (default 255 interface endpoints per VPC). If 30 VPCs each have 3 AZs, the service owner sees 90 ENIs on their side (one per AZ per consumer VPC). Each endpoint service supports up to 10,000 connections, but the practical limit is **bandwidth per ENI**: each Interface Endpoint ENI supports up to 10 Gbps. If 30 VPCs hammer the service, you need **horizontal scaling**. Solution 1: **Multiple endpoint services with DNS load balancing**. Split the service across 3 NLBs, each with its own endpoint service (`svc-1`, `svc-2`, `svc-3`). Use Route 53 weighted routing or a single DNS record with multiple A records to distribute consumers. Solution 2: **NLB with cross-zone load balancing and multiple targets**. Place the service behind an NLB with targets in multiple subnets/AZs. The NLB handles the traffic distribution, and the endpoint service points to the NLB. This is the standard pattern. For very high scale (>1,000 consumer VPCs), use **AWS CloudFront with Origin Access Identity** or **API Gateway** instead of PrivateLink, as they are designed for massive fan-out. I also monitor endpoint metrics via CloudWatch: `ActiveConnections`, `NewConnections`, and `ProcessedBytes`. If `ProcessedBytes` exceeds 10 Gbps per AZ consistently, I add more NLB targets or enable **Anycast** via Global Accelerator.

Question 7

What is missing for IPv6 internet access, and how does IPv6 subnetting differ from IPv4 in AWS?

Accepted Answer

For IPv6 internet access, the VPC needs an **IPv6-only egress-only internet gateway (EIGW)** or a standard **Internet Gateway with IPv6 support**. The EIGW allows outbound-only IPv6 traffic (preventing inbound connections to instances), which is the AWS-recommended pattern for IPv6. The missing component is likely the **route table entry**: `::/0 -> eigw-id` in the subnet route table. I verify with `aws ec2 describe-route-tables`. IPv6 subnetting in AWS differs from IPv4 in three ways: (1) **Fixed /64 per subnet**: AWS automatically assigns a /64 from the VPC's /56 IPv6 CIDR. You cannot choose custom sizes like /28 or /24. (2) **No NAT**: IPv6 does not use NAT Gateways. EIGW provides outbound-only access, and instances with public IPv6 addresses are directly reachable from the internet unless security groups block them. (3) **Dual-stack by default**: subnets can have both IPv4 and IPv6 CIDRs. If you want IPv6-only subnets, you must explicitly disable IPv4 auto-assignment. For DNS, **Route 53 Resolver** supports AAAA records, and you should verify that the VPC has `enableDnsHostnames` and `enableDnsSupport` set to true for IPv6. I also check that the instance OS has IPv6 enabled (`ip -6 addr show`) and that the security group allows ICMPv6 (type 128 for echo request) for troubleshooting.

Question 8

What three changes reduce flow log costs by 80% while preserving security visibility?

Accepted Answer

VPC Flow Logs charge for data ingestion ($0.50/GB into CloudWatch Logs) and storage ($0.03/GB/month). All-traffic logging on a busy VPC easily generates 8+ TB/month. Change 1: **Filter to REJECT only**. Most security use cases only need denied traffic. Use `aws ec2 create-flow-logs --traffic-type REJECT`. This typically reduces volume by 85-95% because accepted traffic is 90%+ of total flows. Change 2: **Send to S3 instead of CloudWatch Logs**. S3 ingestion is $0.25/GB (half the price) and supports Parquet format with Hive partitioning (`aws-account-id=xxx/year=2026/month=04/...`), making Athena queries much cheaper. Change 3: **Sampling**. If REJECT-only is still too high, use a custom flow log format and sample at the source, or use **Traffic Mirroring** for targeted deep inspection instead of blanket flow logging. For the security team, I set up **Athena queries** on the S3 Parquet files: `SELECT srcaddr, dstaddr, action, reject_reason FROM vpc_flow_logs WHERE action = 'REJECT' AND date_partition >= '2026-04-01'`. I also enable **GuardDuty** for anomaly detection, which is $4/VPC/month and does not require flow logs at all — it uses its own underlying data source. The combination of REJECT-only + S3 Parquet + GuardDuty typically drops costs from $4,200 to ~$400/month.

Question 9

How does Global Accelerator differ from CloudFront for DDoS protection, and what two AWS features should be added?

Accepted Answer

Global Accelerator provides static anycast IPs that route users to the optimal AWS edge location, then tunnels traffic over the AWS backbone to the origin. It does **not** provide Layer 7 caching or DDoS scrubbing — it is primarily a performance and failover tool. CloudFront, in contrast, is a CDN that caches content at edge locations and includes **AWS Shield Standard** (L3/L4 DDoS protection) and **AWS WAF** (L7 protection) integration. For DDoS mitigation, I add two features: (1) **AWS Shield Advanced** on the Global Accelerator. Shield Advanced provides 24/7 DRT (DDoS Response Team) support, cost protection, and real-time visibility into L3/L4 attacks. It costs $3,000/month plus data fees but is essential for critical applications. (2) **AWS WAF on the ALB** (not on Global Accelerator directly, since GA is L4). I configure WAF rules: rate-based rules (block IPs with >2,000 requests/5min), managed rule sets (Common Rule Set, Known Bad Inputs), and geographic blocking if the app is region-specific. I also enable **ALB access logs** and **AWS Firewall Manager** for centralized WAF policy management across accounts. For volumetric attacks exceeding ALB capacity, I add **CloudFront in front of Global Accelerator** — this is an unusual but valid architecture: users → CloudFront (caching + WAF + Shield) → Global Accelerator (static IP + anycast) → ALB. This combines the best of both services.

Question 10

What two misconfigurations cause inter-region TGW latency, and how do you verify the optimal path?

Accepted Answer

First, **TGW peering attachment not in the same region as the source VPC**. If the us-east-1 VPC sends traffic to a TGW peering attachment located in us-west-2 (instead of us-east-1), traffic hairpins across the US, adding ~100ms. I verify with `aws ec2 describe-transit-gateway-peering-attachments` and check the `accepterTgwInfo.region` and `requesterTgwInfo.region`. Second, **route table propagation missing the correct CIDR**. If the us-east-1 TGW route table has a static route for the EU VPC CIDR pointing to an incorrect peering attachment (e.g., one going to ap-southeast-1 instead of eu-west-1), traffic follows the wrong path. I verify with `aws ec2 search-transit-gateway-routes` and check the ` TransitGatewayRoute` state and attachments. For path verification, I use **AWS Network Manager** (part of CloudWAN) which provides a visual topology and latency metrics per link. I also run `mtr` or `ping` from an EC2 instance in the source VPC to the destination and correlate the IP hops with AWS backbone router IPs (they typically have `amazon` in reverse DNS). For optimization, I ensure **TGW peering is between the closest regions** and consider using **AWS CloudFront or Global Accelerator** for user-facing traffic instead of cross-region VPC traffic. For database replication, I use **Aurora Global Database** with write forwarding instead of cross-region SQL queries.

Question 11

Why does TGW connectivity not enable cross-account DNS resolution, and what two solutions enable it?

Accepted Answer

TGW provides Layer 3 IP connectivity but does **not** propagate DNS information across VPCs. Each VPC's Route 53 Resolver is independent and authoritative only for its own private hosted zones. Cross-account DNS resolution requires additional configuration. Solution 1: **Route 53 Resolver Rules with outbound endpoints**. In the consumer VPC, I create a Resolver outbound endpoint (2 ENIs in different AZs) and a forwarding rule: "Forward queries for `internal.corp` to the on-prem DNS server IP or to the producer VPC's Resolver inbound endpoint IP." In the producer VPC, I create a Resolver inbound endpoint and associate the private hosted zone `internal.corp` with it. This is the standard enterprise pattern. Solution 2: **Cross-account VPC association with private hosted zones**. The producer account shares the private hosted zone via RAM to the consumer account's VPC. This is simpler but requires the hosted zone to be associated with the consumer VPC, which may violate network segmentation if the consumer should not directly resolve all records. For hybrid scenarios, I also use **Route 53 Profiles** (newer feature) which centralize DNS management across accounts and VPCs. I verify DNS resolution with `dig @169.254.169.253 service.internal.corp` (using the VPC Resolver IP) and `nslookup` from the EC2 instance. If resolution works but traffic fails, I check the TGW route table to confirm the target VPC CIDR is propagated.

Question 12

What three parameters cause VPN/BGP flapping, and what is the correct AWS-side and Palo Alto-side configuration?

Accepted Answer

First, **BGP hold time / keepalive mismatch**. AWS VPN supports BGP with default hold time of 30 seconds and keepalive of 10 seconds. If the Palo Alto firewall uses aggressive timers (hold 9, keepalive 3), minor packet loss causes rapid session drops. I align both sides to 30/10 or increase to 90/30 for stability over internet paths. Second, **IPsec SA lifetime mismatch**. AWS uses 3,600 seconds (1 hour) for Phase 1 and Phase 2 by default. If Palo Alto uses 28,800 seconds (8 hours), the tunnel rekeys at different times, causing brief drops. I set both sides to 3,600 seconds for Phase 2 and 28,800 for Phase 1. Third, **MTU / TCP MSS clamping**. AWS VPN tunnels support 1,394 bytes MTU (1,500 - IPsec overhead). If the Palo Alto does not clamp TCP MSS to 1,359 (1,394 - 20 IP - 20 TCP), large packets are fragmented or dropped, causing BGP TCP resets. On Palo Alto, I set `adjust-tcp-mss enable` under the tunnel interface. On the AWS side, I verify the VPN connection uses **BGP with dynamic routing** (not static) and check `TunnelInsideCidr` does not overlap with on-prem or VPC CIDRs. I also enable **Dead Peer Detection (DPD)** with a 10-second interval and 3 retries. For high availability, I configure **two VPN tunnels** and use **AS_PATH prepending** on the secondary tunnel so it is backup only. I monitor with CloudWatch `TunnelState` and Palo Alto `show bgp summary`.

Question 13

What VPC networking feature ensures private DynamoDB access from Lambda, and what audit trail captures the traffic?

Accepted Answer

Lambda functions can run inside a VPC using **VPC-enabled Lambda** (via Hyperplane ENIs). To reach DynamoDB privately, I create a **Gateway VPC Endpoint for DynamoDB** in the VPC route table. This routes DynamoDB traffic over the AWS backbone without NAT Gateway or internet access. However, Gateway endpoints do not support private DNS for DynamoDB — the Lambda function must use the regional DynamoDB endpoint (`dynamodb.us-east-1.amazonaws.com`) and the VPC route table intercepts it. For auditability, Gateway endpoints support **endpoint policies** but do not generate flow logs per se. For detailed audit trails, I add **CloudTrail data events** for DynamoDB: `aws cloudtrail put-event-selectors --event-selector ReadWriteType=All,DataResources=[{Type=AWS::DynamoDB::Table,Values=arn:aws:dynamodb:::table/*}]`. This logs every API call with source IP (which will be the Lambda ENI IP). For even deeper inspection, I use **VPC Traffic Mirroring** to mirror the Lambda ENI traffic to a monitoring appliance, though this is complex for serverless. A simpler alternative is **AWS PrivateLink Interface Endpoint for DynamoDB** (if available in the region) which creates an ENI and supports CloudWatch metrics per endpoint. I verify private access by checking the Lambda function's security group allows HTTPS (443) outbound and that the VPC route table has the DynamoDB prefix list route. I also verify no NAT Gateway data transfer charges appear in the bill for DynamoDB traffic.

Question 14

What AWS networking architecture supports inline appliance inspection at 20 Gbps with active-active HA?

Accepted Answer

The architecture is **Transit Gateway with appliance mode + GWLB (Gateway Load Balancer)**. (1) **GWLB**: deploys a fleet of firewall instances across multiple AZs. GWLB uses GENEVE encapsulation to forward traffic to appliances while preserving the original source/destination IP. It supports 20 Gbps+ by auto-scaling the firewall fleet based on GWLB target group metrics. (2) **TGW appliance mode**: enabled on the VPC attachment where the firewall fleet lives. This ensures symmetric routing — return traffic goes back through the same firewall instance that processed the outbound flow, critical for stateful inspection. Without appliance mode, asymmetric routing breaks the firewall state table. (3) **Spoke VPC routing**: each spoke VPC's TGW route table sends `0.0.0.0/0` and on-prem CIDRs to the TGW. The TGW sends this traffic to the inspection VPC attachment. (4) **Firewall VPC routing**: after inspection, the firewall sends allowed traffic back to the TGW, which routes to the destination (spoke or on-prem via DX). (5) **Health checks**: GWLB performs health checks on firewall instances. If an instance fails, traffic is rerouted in <10 seconds. For 20 Gbps, I size the firewall instances as `c6i.4xlarge` or larger with ENA Express enabled. I also use **multiple TGW route tables**: one for pre-inspection traffic (spoke → inspection) and one for post-inspection (inspection → destination). This prevents routing loops. For cost optimization, I use **AWS Network Firewall** as a managed alternative if the feature set suffices — it scales automatically and costs ~$0.065/hour per endpoint + $0.065/GB inspected.

Question 15

What is the architectural difference, and when does Cloud WAN become the better choice over TGW?

Accepted Answer

AWS Cloud WAN is a managed **wide-area network (WAN)** service built on top of the AWS global backbone. It uses **core network policies** (JSON documents) to define segments, attachment policies, and routing behavior across all regions in a single control plane. Transit Gateway is regional — you create one TGW per region and peer them manually. Cloud WAN becomes better than TGW when: (1) **Global scale**: 15+ regions with 100+ VPCs. Cloud WAN's core network spans all regions automatically; TGW requires N*(N-1)/2 peering attachments. (2) **Segmentation complexity**: PCI, HIPAA, and general segments with shared services (logging, DNS). Cloud WAN segments are defined in policy and automatically enforced across all regions. With TGW, you must replicate route table segmentation in every region. (3) **On-prem integration**: Cloud WAN integrates SD-WAN appliances (Cisco, Aruba, Fortinet) via **Connect attachments** using GRE over the internet or DX. TGW requires separate VPN or DX Gateway attachments per region. (4) **Centralized policy management**: Cloud WAN policies are version-controlled JSON, enabling GitOps. TGW routing is API-driven per region. Cloud WAN limitations: it is newer (2022+), has fewer third-party integrations, and core network policy debugging can be opaque. TGW is more mature, better documented, and has broader community support. For this scenario, I recommend **Cloud WAN with a hybrid TGW migration**: keep existing TGWs for stable regions, attach them to Cloud WAN core network edges, and gradually migrate VPCs. This provides immediate segmentation benefits without a big-bang cutover. I also use **AWS Network Manager** to visualize both TGW and Cloud WAN topologies.

AWS VPC Deep Dive: 15 Interview Questions on TGW, Direct Connect & PrivateLink

More Cloud Networking Interview Prep