Cloud / Amazon VPC (Virtual Private Cloud) Interview questions

Amazon VPC (Virtual Private Cloud) is a logically isolated network you provision inside AWS, where you control your own IP address range, subnets, route tables, and gateways.

It behaves like a traditional data center network but runs on AWS's shared infrastructure - resources you launch inside it, such as EC2 instances or RDS databases, only talk to each other or the outside world the way you've configured routing and security to allow.

Every AWS account gets a default VPC in each Region automatically, but most production workloads use a custom VPC so the CIDR range, subnet layout, and internet exposure match the application's actual needs.

A VPC is built from a handful of pieces that work together: the VPC itself defines the overall CIDR block, and subnets carve that range into smaller pieces tied to specific Availability Zones.

1. Route tables decide where traffic from each subnet is allowed to go.
2. Internet Gateway (IGW) gives resources with public IPs a path to and from the internet.
3. NAT Gateway lets private-subnet resources reach the internet outbound without being reachable from it.
4. Security Groups and Network ACLs filter traffic at the instance and subnet level.
5. VPC endpoints, peering connections, and Transit Gateway attachments extend connectivity to AWS services, other VPCs, or on-premises networks.

Not every VPC needs all of these - a small isolated dev VPC might only have subnets, a route table, and Security Groups.

A subnet is a segment of a VPC's IP address range that you place inside a single Availability Zone - it can't span multiple AZs.

Each subnet gets its own smaller CIDR block carved out of the VPC's larger range, and its own route table association, which is what actually determines whether the subnet behaves as public or private.

AWS reserves five IP addresses in every subnet (the network address, the VPC router, DNS, a future-use address, and the broadcast address), so a /24 subnet with 256 addresses only has 251 usable for your resources.

Spreading workloads across subnets in multiple AZs is the standard way to build fault tolerance into a VPC design.

A VPC subnet is either public or private, and the label comes entirely from its route table, not from any special subnet setting.

A subnet is public when its route table has a route sending 0.0.0.0/0 traffic to an Internet Gateway, and its instances have public or Elastic IPs to actually use that path.

A subnet is private when it has no route to an Internet Gateway - it may still reach the internet outbound through a NAT Gateway in a public subnet, which counts as private since nothing can initiate a connection into it from outside.

A third variant, sometimes called an isolated subnet, has no route to the internet at all, not even through NAT, and typically only reaches other resources inside the VPC or through VPC endpoints.

An Internet Gateway (IGW) is the VPC component that lets resources with a public IP address send and receive traffic directly to and from the internet.

It's horizontally scaled and highly available by design - there's nothing to size or patch - and exactly one IGW can be attached to a VPC at a time.

Attaching an IGW alone doesn't make anything public; a subnet's route table also needs a 0.0.0.0/0 route pointing at the IGW, and the instance itself needs a public or Elastic IP, before traffic can actually flow.

The IGW also performs the 1:1 NAT translation between an instance's private IP and its public or Elastic IP for internet-bound traffic.

A NAT Gateway is a managed AWS resource that lets instances in a private subnet initiate outbound connections to the internet or other AWS services, while blocking unsolicited inbound connections from reaching them.

You deploy it inside a public subnet, attach an Elastic IP to it, and then point the private subnet's route table at the NAT Gateway for its 0.0.0.0/0 route.

AWS manages its availability, patching, and bandwidth scaling automatically, up to 100 Gbps, but each NAT Gateway lives in a single Availability Zone, so a multi-AZ design typically deploys one NAT Gateway per AZ to avoid a cross-AZ single point of failure.

You're billed hourly for the NAT Gateway plus a per-GB data processing charge, which is a common source of unexpected VPC cost.

A route table is a set of rules, called routes, that determine where network traffic from a subnet is directed based on its destination IP range.

Every VPC has a main route table by default, and any subnet not explicitly associated with a custom route table uses it; you can also create custom route tables and associate specific subnets with them.

Each route pairs a destination CIDR with a target, for example 10.0.0.0/16 -> local for traffic staying inside the VPC, or 0.0.0.0/0 -> igw-id for internet-bound traffic.

When multiple routes could match a destination, AWS always uses the most specific (longest-prefix) match, not the order the routes were added in.

A Security Group is a virtual, stateful firewall attached at the network interface (ENI) level, controlling what traffic is allowed in and out of the resources using it, most commonly EC2 instances.

Security Groups only support allow rules - there's no explicit deny - so anything not permitted is implicitly blocked.

Because they're stateful, a response to an allowed inbound request is automatically permitted back out, and vice versa, without needing a matching outbound rule.

An instance can belong to multiple Security Groups at once, and the effective rule set is the union of all of them; rules can also reference other Security Groups as the source or destination instead of a raw CIDR block, which is handy for tiered application designs.

A Network ACL is a stateless firewall that operates at the subnet boundary, evaluating every packet entering or leaving any subnet it's associated with.

Unlike Security Groups, NACLs support both allow and explicit deny rules, and they're evaluated in numbered order from lowest to highest, stopping at the first rule that matches.

Because NACLs are stateless, return traffic isn't automatically permitted - if you allow inbound traffic on an ephemeral port range, you also need a matching outbound rule, or replies get silently dropped.

Every VPC comes with a default NACL that allows all traffic; a custom NACL, by contrast, denies everything until you add explicit allow rules, so it's easy to accidentally break connectivity when locking one down.

The default VPC is a pre-configured VPC that AWS automatically creates in every Region of a new account, sized as a 172.31.0.0/16 CIDR block.

It ships with a default subnet in each Availability Zone of the Region (typically a /20 per AZ), an Internet Gateway already attached, and a main route table sending 0.0.0.0/0 to that gateway, so instances launched into it get public IPs and internet access with zero networking setup.

That convenience is exactly why production environments usually avoid it: everything in the default VPC is internet-facing by default, which isn't the isolation model most real workloads want.

You can delete the default VPC and recreate one later if needed, but it must be empty of resources like ENIs first.

CIDR (Classless Inter-Domain Routing) notation expresses an IP range as a base address plus a prefix length, like 10.0.0.0/16, where the prefix length tells you how many bits are fixed for the network portion.

In VPC design, the CIDR block you choose for the VPC sets the total address space available, and each subnet then gets a smaller CIDR carved from that range - a /16 gives 65,536 addresses, while a /24 gives 256.

AWS requires a VPC's CIDR block to be between /16 and /28, and subnet CIDRs must fit entirely within the VPC's range without overlapping other subnets.

Planning CIDR ranges carefully up front matters because it directly determines whether you can later peer VPCs without an overlap conflict, or attach them to the same Transit Gateway.

VPC Peering is a direct, private networking connection between two VPCs that lets resources in either one communicate using private IP addresses, as if they were on the same network.

Traffic between peered VPCs never touches the public internet, and it can be set up between VPCs in the same account, different accounts, or even different Regions.

A peering connection is not transitive - if VPC A is peered with VPC B, and B is peered with C, A cannot reach C through B unless a separate direct peering connection is created between A and C.

Setup requires the owner of the requester VPC to send a request, and the owner of the accepter VPC to accept it, followed by route table updates on both sides pointing at the peering connection.

A VPC endpoint lets resources inside a VPC connect privately to supported AWS services, or to services published by other accounts, without routing traffic through an Internet Gateway or NAT Gateway.

Traffic to the endpoint stays entirely on the AWS network backbone rather than crossing the public internet, which improves both security posture and, in many cases, latency.

Endpoints come in two flavors: Gateway endpoints, which work by adding a route table entry, and Interface endpoints, which place an Elastic Network Interface with a private IP directly inside your subnet.

Using an endpoint means a private subnet with no NAT Gateway at all can still reach services like S3 or DynamoDB.

AWS supports two categories of VPC endpoint, and the difference is mostly in how they're implemented and which services they support.

A single VPC can use both types side by side - Gateway endpoints for S3 and DynamoDB, Interface endpoints for everything else that needs private connectivity.

An Elastic IP (EIP) is a static, public IPv4 address that you allocate to your AWS account and can associate with an EC2 instance, NAT Gateway, or network interface.

Unlike an auto-assigned public IP, an Elastic IP stays the same even if you stop and start the underlying instance, which matters for DNS records, firewall allowlists, or partner integrations that expect a fixed address.

You can remap an Elastic IP from one instance to another in seconds, which is useful for quickly replacing a failed instance without updating downstream configuration.

AWS charges for an Elastic IP that's allocated but not attached to a running resource, specifically to discourage hoarding scarce IPv4 addresses.

VPC Flow Logs capture metadata about the IP traffic flowing to and from network interfaces in your VPC - source and destination IP, ports, protocol, byte and packet counts, and whether the traffic was accepted or rejected.

They can be enabled at the VPC, subnet, or individual ENI level, and delivered to Amazon CloudWatch Logs, Amazon S3, or Amazon Data Firehose for further processing.

Flow Logs record connection metadata only, not packet contents, so they're useful for diagnosing why traffic is being blocked, spotting unexpected traffic patterns, or feeding a SIEM, but they won't show you application-layer data.

They're a separate feature from CloudTrail, which logs API calls rather than network traffic.

AWS Transit Gateway is a managed regional network hub that connects VPCs, VPN connections, and Direct Connect gateways through a single set of attachments instead of a mesh of individual connections.

Each VPC or on-premises network attaches to the Transit Gateway once, and the Transit Gateway's route tables decide which attachments can reach which other attachments, similar to how a router works between separate networks.

It scales to thousands of attachments and supports inter-Region peering between Transit Gateways, which lets you build a global network backbone without individually peering every VPC pair.

Because routing between attachments is centralized and Transit Gateway is inherently a hub, it's the standard building block for hub-and-spoke network designs at scale, where VPC Peering's non-transitive nature would otherwise require dozens or hundreds of individual peering connections.

AWS enforces a set of default quotas per Region that shape how many VPC resources you can create before requesting an increase.

• VPCs per Region: 5 (adjustable)
• Subnets per VPC: 200 (adjustable)
• IPv4 CIDR blocks per VPC: 5, including the primary block (adjustable up to 50)
• Rules per Network ACL: 20 inbound and 20 outbound by default (adjustable up to 40 each)
• Elastic IPs per Region: 5 (adjustable)

Most of these are soft limits you can raise through the Service Quotas console or a support request, but they're worth knowing before designing a large multi-VPC environment, since hitting one mid-deployment can stall an automated rollout.

A request from the internet first hits the VPC's Internet Gateway, which performs 1:1 NAT to translate the instance's public or Elastic IP into its private IP inside the VPC.

The subnet's route table must have a route sending that traffic toward the IGW; from there, it's evaluated against the subnet's Network ACL, then the instance's Security Group, before finally reaching the instance's network interface.

The return path runs in reverse, but since Security Groups are stateful, the reply doesn't need a separate outbound rule - only the NACL does, since it evaluates each direction independently.

flowchart LR
  A["Client on internet"] --> B["Internet Gateway"]
  B --> C["Route table: 0.0.0.0/0 -> igw"]
  C --> D["Subnet Network ACL"]
  D --> E["Instance Security Group"]
  E --> F["EC2 instance"]

An Internet Gateway enables two-way traffic: it lets resources with a public IP both initiate outbound connections and accept inbound connections from the internet.

A NAT Gateway only enables one-way, outbound-initiated traffic - it lets private-subnet instances reach the internet, but nothing on the internet can initiate a new connection to them through it.

In short: the IGW is what makes a subnet public, while the NAT Gateway is what gives a private subnet limited, outbound-only internet reach.

Security Groups and NACLs both filter traffic, but they operate at different layers and with different statefulness, which changes how you configure each one.

In practice, Security Groups do most of the fine-grained access control, while NACLs are typically used more sparingly, for coarse subnet-wide blocks like denying a known-bad CIDR range regardless of which instance it targets.

Both let private-subnet resources reach the internet, but a NAT Gateway is a fully managed AWS service while a NAT instance is a regular EC2 instance running NAT software that you patch and scale yourself.

AWS itself recommends NAT Gateway for nearly all use cases today; NAT instances mainly survive in legacy designs or where a Security Group needs to filter the NAT traffic itself, which a NAT Gateway doesn't expose.

Both give private access to AWS services, but they're implemented completely differently under the hood, which affects cost, reach, and which services they support.

A Gateway endpoint works purely at the routing layer: AWS adds a special target to your route table, and only S3 and DynamoDB support it, at no extra cost.

An Interface endpoint is a real Elastic Network Interface with a private IP address placed inside your subnet, backed by AWS PrivateLink; it supports the vast majority of other AWS services plus custom PrivateLink-published services, and it's billed hourly plus per-GB processed.

Because an Interface endpoint has a routable private IP, it can also be reached from on-premises networks over Direct Connect or VPN - something a Gateway endpoint, being VPC-route-table-only, cannot do.

A subnet has no inherent "public" or "private" flag in AWS - its behavior is entirely a function of which route table it's associated with and what that table points at.

If the associated route table has a 0.0.0.0/0 route targeting an Internet Gateway, any instance in that subnet with a public IP can reach and be reached from the internet, making it a public subnet.

If instead the 0.0.0.0/0 route targets a NAT Gateway, the subnet is private - outbound internet access works, but nothing outside can initiate a connection in.

This means you can flip a subnet's classification without touching the subnet itself, just by changing which route table it's associated with - a detail that trips people up when auditing a VPC, since the subnet console view doesn't label it "public" anywhere.

Routing traffic between two VPCs over the public internet means it would need public IPs, an Internet Gateway on both sides, and Security Group rules opening ports to a public range, all of which meaningfully increases the attack surface.

VPC Peering instead lets instances communicate using their private IPs directly, with traffic carried entirely over AWS's internal backbone rather than any public path.

That has real, concrete benefits: no data egress charges for crossing to the public internet, lower and more consistent latency since it avoids public routing hops, and no need to manage public-facing endpoints or TLS termination just to let two internal services talk to each other.

It also keeps the two VPCs' internal topologies invisible to each other beyond the specific peered CIDR ranges, which is a meaningfully smaller exposure than opening resources to the internet.

VPC Peering makes sense for a small, stable number of VPC-to-VPC relationships - a handful of connections are easy to reason about, and Peering has no hourly cost of its own.

Transit Gateway becomes the better choice once the number of VPCs grows past roughly ten or so, because Peering's non-transitive nature means every new VPC needs a direct connection to every other VPC it must reach, growing as n(n-1)/2 connections.

Transit Gateway also wins when you need centralized routing control, shared connectivity to on-premises networks via a single VPN or Direct Connect attachment reused by many VPCs, or multi-Region connectivity through inter-Region Transit Gateway peering.

The trade-off is cost and a small amount of added latency per hop, since Transit Gateway is billed per attachment-hour and per GB processed, on top of what Peering would cost for the same traffic (which is free for same-Region peering).

VPC Peering simply won't work between two VPCs whose CIDR blocks overlap, even partially - AWS blocks the peering connection from being created in that state.

The reason is routing ambiguity: if both VPCs used, say, 10.0.0.0/16, a route table entry pointing that whole range at the peering connection would also try to match local traffic, and AWS has no way to tell which destination you actually meant.

This is why CIDR planning across an organization matters well before peering is ever attempted - once a VPC is created and populated with resources, changing its primary CIDR isn't possible, though you can add a secondary CIDR block in a non-overlapping range for new resources.

The practical fix for two already-overlapping VPCs is usually to route between them through a NAT-based transit VPC or an overlay solution, since a direct peering connection is not an option.

Security Groups are stateful, so they only need to evaluate the traffic direction that initiated a connection - once an inbound request is allowed, the corresponding outbound reply is automatically permitted, with no separate rule lookup.

NACLs are stateless, so they evaluate inbound and outbound traffic completely independently, as two separate rule sets, regardless of which side initiated the connection.

In practice this means an inbound allow rule on a NACL for, say, port 443, doesn't automatically permit the reply traffic going back out on an ephemeral port - you need a separate outbound rule allowing traffic on the ephemeral port range (typically 1024-65535) for replies to actually leave the subnet.

Forgetting this ephemeral-port outbound rule is one of the most common reasons a custom NACL silently breaks connectivity that Security Group rules alone would have allowed.

An Availability Zone is one or more physically separate data centers within a Region, engineered so a failure in one AZ - power, cooling, or a hardware fault - doesn't take down another.

Since a subnet is confined to a single AZ, placing all of an application's subnets in just one AZ means an AZ-level outage takes the entire application down, regardless of how much redundancy exists within that AZ.

Spreading subnets, and the resources inside them, across at least two AZs lets services like an Application Load Balancer, Auto Scaling group, or Multi-AZ RDS deployment keep serving traffic by failing over to the healthy AZ automatically.

The typical pattern is a matching pair of public and private subnets per AZ - for example, a public and private subnet in us-east-1a and an identical pair in us-east-1b - so NAT Gateways, load balancers, and application tiers all have a same-AZ path that avoids unnecessary cross-AZ data transfer charges.

Work through the path methodically rather than guessing, starting from the instance and moving outward toward the internet.

1. Confirm the instance has a public IP (if the subnet is meant to be public) or that its route goes through a working NAT Gateway (if private).
2. Check the subnet's route table for a 0.0.0.0/0 route pointing at the correct Internet Gateway or NAT Gateway ID.
3. Verify the Security Group allows the relevant outbound traffic (often overlooked, since default Security Groups allow all outbound, but custom ones may not).
4. Check the subnet's NACL for both inbound and outbound rules, remembering the ephemeral port range needs to be open in both directions.
5. For private-subnet instances, confirm the NAT Gateway itself sits in a public subnet with its own working route to an Internet Gateway.

AWS's VPC Reachability Analyzer can automate most of this by tracing the actual path and reporting exactly which hop blocks the connection, which is faster than manually walking through the console for a complex path.

aws ec2 start-network-insights-analysis \
  --network-insights-path-id nip-0123456789abcdef0

A VPC is scoped to a single AWS Region - it exists across all the Availability Zones in that Region, but it doesn't extend into any other Region.

A subnet is scoped one level down, to a single Availability Zone within that VPC's Region - it cannot span multiple AZs, and every subnet belongs to exactly one VPC for its entire lifetime.

This nesting - Region contains VPC, VPC contains subnets across AZs - is the backbone of how AWS network isolation and fault-tolerance both work at the same time.

AWS Site-to-Site VPN creates encrypted IPsec tunnels between a Virtual Private Gateway (or Transit Gateway) on the AWS side and a Customer Gateway device on the on-premises side.

Each VPN connection provisions two tunnels, terminating in different AWS Availability Zones for redundancy, and either static routes or BGP dynamic routing is used to exchange which CIDR ranges are reachable through each tunnel.

Once the tunnels are up, the VPC's route table gets routes pointing on-premises CIDR ranges at the Virtual Private Gateway, and the on-premises router gets matching routes pointing AWS-bound ranges back through the Customer Gateway.

flowchart LR
  A["On-premises network"] --> B["Customer Gateway device"]
  B -- IPsec Tunnel 1 --> C["Virtual Private Gateway - AZ1"]
  B -- IPsec Tunnel 2 --> D["Virtual Private Gateway - AZ2"]
  C --> E["VPC route table"]
  D --> E
  E --> F["VPC subnets"]

Because it runs over the public internet with encryption, Site-to-Site VPN is quicker to set up than AWS Direct Connect, though it typically has less predictable throughput and latency.

A private subnet has no route to an Internet Gateway in its route table - that's the entire definition of "private" in VPC terms, not a separate switch that needs to be turned off.

Without that route, any packet destined for a public internet address simply has nowhere to go once it leaves the local VPC range, so it's dropped rather than forwarded, regardless of Security Group or NACL settings.

This is intentional isolation: databases, internal services, and other resources that should never be reachable from, or need to reach out to, the open internet stay that way by construction, not by relying on firewall rules alone as the only line of defense.

If outbound-only internet access is actually needed, you add a route through a NAT Gateway (or NAT instance) deployed in a public subnet - the private subnet itself never gets a direct IGW route.

A standard (auto-assigned) public IP is handed out from AWS's pool when an instance launches in a subnet configured to auto-assign one, and it's released back to the pool the moment the instance is stopped or terminated.

An Elastic IP is a static address you explicitly allocate to your account, and it stays reserved for you - and keeps the same value - across stop/start cycles, until you deliberately release it.

Elastic IPs are the right choice whenever an external system needs to reference your resource by a fixed address - a DNS A record, a partner's firewall allowlist, or a licensing server tied to an IP.

The most direct lever is reducing how much data actually flows through NAT Gateways, since the per-GB data processing charge, not the hourly fee, is usually the larger line item at scale.

1. Add Gateway VPC endpoints for S3 and DynamoDB traffic, since that traffic is free and never needs to touch NAT at all.
2. Add Interface endpoints for other frequently-used AWS services (like ECR, Secrets Manager, or CloudWatch Logs) if the endpoint cost is lower than the NAT data processing it would otherwise incur - this depends on traffic volume and needs a rough cost comparison.
3. Consider one shared NAT Gateway per AZ instead of per subnet, since NAT Gateways are already sized to handle heavy throughput and multiple private subnets in the same AZ can share one.
4. For non-production environments, a single NAT Gateway (accepting a temporary single-AZ dependency) or a scheduled NAT instance can be cheaper than fully redundant NAT Gateways, since dev/test rarely needs the same availability guarantees as production.

None of these should compromise the multi-AZ redundancy pattern in production - the goal is cutting unnecessary data volume and choosing the right number of NAT Gateways, not removing redundancy to save money.

These two logging services answer fundamentally different questions, and mixing them up is a common early mistake.

In a real investigation you often need both: CloudTrail to see that someone opened a Security Group rule, and Flow Logs to see the traffic that started flowing once that rule was opened.

A Bastion Host is an EC2 instance placed in a public subnet specifically to be an SSH/RDP jump box into private-subnet resources - it needs a Security Group opening 22 or 3389 to at least some source range, its own patching, and key management.

AWS Systems Manager Session Manager instead gives you a shell into a private instance without any inbound port open at all - the Systems Manager agent on the instance makes an outbound connection to the Systems Manager service, and your session is brokered through that, authenticated and authorized entirely through IAM.

Session Manager is the better default for most modern environments: no bastion to patch or scale, no open inbound ports to manage, and every session is automatically logged for audit through CloudTrail and optionally to S3 or CloudWatch Logs.

A Bastion Host still shows up where Session Manager's agent-based model doesn't fit - for example, connecting into a legacy on-premises-style network segment, or a non-EC2 device that can't run the SSM agent.

Every VPC has a built-in DNS resolver, the Amazon Route 53 Resolver, reachable at the base of the VPC's CIDR range plus two - for example 10.0.0.2 in a 10.0.0.0/16 VPC.

Two VPC-level settings control how this works: enableDnsSupport, which turns the resolver on for the VPC, and enableDnsHostnames, which controls whether instances actually get public or private DNS hostnames assigned to them.

For a plain public DNS lookup, like resolving a public website, the Resolver forwards the query out to the public DNS system; for an AWS service's private endpoint, or a Route 53 private hosted zone associated with the VPC, it resolves internally without leaving AWS's network.

flowchart LR
  A["EC2 instance"] --> B["VPC DNS Resolver at .2 address"]
  B -->|Public domain| C["Public DNS / Route 53 public zone"]
  B -->|Private hosted zone or endpoint record| D["Internal resolution, no internet"]

This is also why an Interface endpoint's Private DNS setting matters - it lets the service's normal public hostname resolve to the endpoint's private IP instead, so existing code doesn't need to change its endpoint URL at all.

The instance issues a request to S3's standard public hostname, like my-bucket.s3.amazonaws.com, exactly as it would with no endpoint configured at all - nothing changes on the application side.

DNS resolves that hostname to one of S3's public IP ranges, but instead of that traffic needing a route to the internet, the subnet's route table has an entry matching S3's IP prefix list (a managed, AWS-updated list of S3's address ranges) with the Gateway endpoint as the target.

Because that route is more specific than a generic 0.0.0.0/0 route would be for those particular prefixes, AWS's routing layer sends the packet to the Gateway endpoint instead of out through a NAT Gateway or Internet Gateway - the private subnet never actually needs either for this traffic.

The endpoint policy attached to the Gateway endpoint is evaluated as an additional authorization layer on top of the bucket policy and IAM permissions, and the request is served entirely over AWS's internal network.

flowchart LR
  A["Private EC2 instance"] --> B["DNS resolves S3 hostname"]
  B --> C["Route table: S3 prefix list -> Gateway Endpoint"]
  C --> D["Gateway Endpoint policy evaluation"]
  D --> E["S3 bucket policy + IAM check"]
  E --> F["S3 bucket"]

Every time a Security Group allows a new connection, the underlying hypervisor's connection-tracking layer records an entry describing that flow - source and destination IP, ports, and protocol - so it can recognize return traffic as part of the same session rather than a brand-new request.

This is exactly what makes Security Groups stateful: once the tracked entry exists, reply packets matching it are permitted automatically, without being checked against the outbound rule set again.

Tracked entries eventually expire after a period of inactivity - TCP connections are tracked until closed or timed out, and UDP "connections" (which have no real handshake) are tracked based on a shorter idle timeout, since there's no explicit close signal to rely on.

This matters operationally in a specific edge case: if you change a Security Group rule, already-established tracked connections that were allowed under the old rule can keep flowing until they naturally close, since the change doesn't necessarily terminate them immediately - only new connection attempts are evaluated against the updated rule set right away, and for some instance types existing flows are also actively re-evaluated shortly after a rule change.

The core idea is to stop treating each account's VPC as an island and instead centralize the networking pieces that don't need to be duplicated per account.

1. Centralize egress: route all accounts' internet-bound traffic through a shared NAT Gateway or egress VPC attached via Transit Gateway, instead of paying for and managing NAT per account.
2. Use AWS Resource Access Manager (RAM) to share subnets from a central networking account into workload accounts, so application teams get subnets to deploy into without owning VPC infrastructure themselves.
3. Standardize on Transit Gateway as the hub, rather than a mesh of Peering connections, since the number of accounts and VPCs in an Organization tends to grow well past what Peering can reasonably manage.
4. Reserve non-overlapping CIDR ranges per account or environment up front using IPAM (IP Address Manager), so two teams never accidentally claim the same range and block future peering or Transit Gateway attachment.
5. Centralize inspection and logging: route traffic through a shared inspection VPC for firewall appliances, and aggregate Flow Logs from every account into one central logging account.

The net effect is that individual account teams focus on their application, while the network foundation - IP planning, egress, inspection, and connectivity - is owned and evolved centrally.

A peering connection moves through a defined set of states from creation to either an active connection or a terminal non-active state, and understanding these states is what makes troubleshooting a stuck peering request straightforward.

The requester initiates the connection, which enters pending-acceptance - at this point nothing flows yet, and the request simply waits for the accepter account (or the same account, for a same-account peer) to act.

If the accepter approves it, the connection moves to active, and both sides can now add routes to their route tables pointing at it. If the accepter explicitly declines it, it moves to rejected. If nobody acts within the request's time window, it moves to expired. An active connection can later be terminated by either side, moving it to deleted.

flowchart LR
  A["Requester initiates"] --> B[pending-acceptance]
  B -->|Accepter approves| C[active]
  B -->|Accepter declines| D[rejected]
  B -->|No action in time| E[expired]
  C -->|Either side deletes| F[deleted]

Being active only means the connection itself exists - traffic still won't flow until both VPCs' route tables and Security Groups are updated to actually use it, which is the step most often forgotten.

Asymmetric routing happens when outbound traffic from a resource takes one path - say, through a NAT Gateway or a firewall appliance - but the return traffic takes a different path back, often bypassing that same appliance, which breaks stateful inspection or connection tracking along the way.

This most commonly shows up in VPC designs with multiple route tables per subnet tier, or where traffic is meant to flow through a centralized inspection VPC in one direction but a more direct route exists for the return path.

1. Map the actual route tables involved for both directions of the flow, not just the one you assume is used - use describe-route-tables to confirm exactly which table each subnet is associated with.
2. Check for a more specific route that unintentionally overrides the intended path on the return leg, since AWS always honors the longest-prefix match regardless of design intent.
3. If a stateful appliance (like a NAT instance or third-party firewall) is involved, confirm both legs of the conversation actually traverse it - stateful devices will silently drop return traffic they never saw the outbound leg for.
4. Use VPC Reachability Analyzer in both directions, source-to-destination and destination-to-source, since a one-directional trace won't reveal an asymmetric path.

aws ec2 describe-route-tables \
  --filters "Name=association.subnet-id,Values=subnet-0abc123" \
  --query "RouteTables[].Routes"

Every attachment to a Transit Gateway - a VPC, VPN, or Direct Connect gateway - is associated with one Transit Gateway route table, which controls what that attachment can send traffic to.

Route propagation is the mechanism that automatically populates a Transit Gateway route table with the CIDR ranges reachable from an attachment, without an administrator manually entering each one - a VPC attachment propagates its own CIDR block, while a VPN or Direct Connect attachment propagates whatever routes are learned dynamically via BGP.

Association and propagation are deliberately separate concepts: an attachment can propagate its routes into a Transit Gateway route table it isn't even associated with, which is exactly what enables asymmetric hub-and-spoke designs, like a shared services VPC visible to every spoke, while spokes stay isolated from each other.

flowchart LR
  A["Spoke VPC attachment"] -->|Propagates its CIDR| B["Transit Gateway route table"]
  C["VPN attachment - BGP learned routes"] -->|Propagates learned routes| B
  B -->|Associated with| D["Spoke VPC's traffic lookups"]
  B -->|Associated with| E["Another spoke's traffic lookups"]

On the VPC side, the VPC's own route table still needs a static route pointing relevant CIDR ranges at the Transit Gateway attachment - propagation only automates the Transit Gateway's internal routing table, not the VPC's own.

At small scale the two can look similar - both let VPCs reach each other privately - but they diverge sharply once you're connecting more than a handful of VPCs together.

At 5 VPCs, a mesh of Peering connections (10 links) is manageable; at 50 VPCs, that same mesh would need 1,225 connections, which is operationally unworkable, while Transit Gateway still needs just 50 attachments and one central routing policy.

VPC Peering connects two entire VPC networks to each other - once peered and routed, any resource in VPC A can potentially reach any resource in VPC B's peered CIDR range, subject to Security Groups and NACLs.

AWS PrivateLink instead exposes a single specific service, not a whole network - a service provider publishes an endpoint service backed by a Network Load Balancer, and consumers connect to just that one service through an Interface endpoint in their own VPC.

This is a meaningfully different security model: PrivateLink consumers never gain any visibility into the provider's VPC topology, IP ranges, or other resources, and there's no CIDR overlap concern at all, since no VPC-to-VPC routing ever happens - the connection terminates at the specific service.

PrivateLink is the standard pattern for SaaS vendors offering private connectivity to their product, or for a platform team publishing one specific internal service to many consumer VPCs across different accounts, without exposing anything else in the provider's network.

In a centralized inspection design, spoke VPCs don't route traffic directly to the internet or to each other - instead, their route tables send relevant traffic to a Transit Gateway attachment, which forwards it into a dedicated inspection VPC running firewall appliances.

The inspection VPC evaluates the traffic against its security policy, then either drops it or forwards it onward - to the internet via its own NAT/Internet Gateway for egress traffic, or back through the Transit Gateway to another spoke VPC for east-west traffic between spokes.

This requires careful Transit Gateway route table design: spoke route tables send default routes to the inspection VPC's attachment, while the inspection VPC's own route table sends default routes onward to egress infrastructure, and the return leg has to traverse the same appliance to avoid the asymmetric routing problem covered earlier.

flowchart LR
  A["Spoke VPC A"] -->|Default route| B["Transit Gateway"]
  B --> C["Inspection VPC firewall appliance"]
  C -->|Egress allowed| D["NAT/Internet Gateway"]
  C -->|Inter-spoke allowed| B
  B --> E["Spoke VPC B"]

The benefit is a single, consistently enforced policy point for all traffic leaving or moving between spokes, instead of replicating firewall rules and NAT infrastructure in every individual VPC.

Flow Logs at full verbosity across every ENI in a large environment generate a genuinely large volume of data, so scaling them well means being deliberate about what's captured and where it goes.

1. Use the custom log format instead of the default fields, capturing only the fields your monitoring or SIEM actually consumes, which reduces both storage size and downstream processing cost.
2. Send logs to S3 rather than CloudWatch Logs for high-volume, long-retention use cases, since S3 storage is materially cheaper, and use S3 lifecycle rules to transition older logs to Glacier for compliance retention.
3. Enable Flow Logs at the VPC level rather than per-ENI where possible, since it's simpler to manage and consistently captures new resources without per-resource configuration drift.
4. Filter to REJECT-only logs for certain use cases, like detecting scanning or misconfigured Security Groups, since rejected-traffic volume is usually far lower than the full ALL traffic capture.
5. Aggregate logs from all accounts in an Organization into one central logging account, so security monitoring has a single place to query rather than assembling data from dozens of accounts.

The right mix depends on whether the goal is cost-efficient long-term compliance storage, active real-time threat detection, or both, since those two goals often call for different destinations and retention settings for the same underlying data.

When Private DNS is enabled on an Interface endpoint, AWS automatically creates a Route 53 private hosted zone (or a record within one) matching the AWS service's standard public domain name, and associates that hosted zone with your VPC.

Because a private hosted zone takes priority over public DNS for any domain it's authoritative for, a lookup from inside the VPC for the service's normal public hostname - like secretsmanager.us-east-1.amazonaws.com - now resolves to the endpoint's private IP address instead of the service's actual public IP range.

This is what allows existing application code, SDKs, and configuration to keep using the exact same standard endpoint URL they always have, with zero code change required to start routing through the private endpoint.

flowchart LR
  A["App calls standard AWS service hostname"] --> B["VPC DNS Resolver"]
  B --> C{Private hosted zone matches domain?}
  C -- Yes, Private DNS enabled --> D["Resolves to Interface Endpoint's private IP"]
  C -- No, Private DNS disabled --> E["Resolves to service's public IP"]

Disabling Private DNS is sometimes intentional, in cases where you need to reach both the private endpoint (via its own endpoint-specific DNS name) and the public service simultaneously from the same VPC, since enabling it removes the option to resolve the standard hostname publicly.

Intermittent, rather than total, failure between peered VPCs across Regions usually points to something environmental or capacity-related rather than a flat-out misconfiguration, since a hard misconfiguration would normally fail consistently.

1. Confirm the peering connection is inter-Region (it uses encrypted AWS backbone links between Regions) and check whether either Region is showing any AWS Health Dashboard events for networking around the time of the drops.
2. Check both VPCs' route tables for the peering connection - a route present in one direction but missing or stale in the other produces exactly this kind of asymmetric, intermittent-looking failure depending on which side initiates.
3. Review Security Group and NACL rules on both ends for anything referencing the peer VPC's CIDR with a narrower range than intended, which can silently drop a subset of traffic while allowing the rest through.
4. Pull VPC Flow Logs from both sides for the affected window and compare REJECT entries - a mismatch, where one side shows a clean send but the other shows a reject, usually isolates which side owns the problem.
5. Rule out application-layer causes, like connection pool timeouts or DNS TTL issues unrelated to the network path itself, since not every "intermittent connectivity" report is actually a VPC networking problem.

aws ec2 describe-vpc-peering-connections \
  --vpc-peering-connection-ids pcx-0123456789abcdef0 \
  --region us-west-2