Topic 3.4
Connecting Networks & Debugging with Flow Logs
In one line
VPC peering joins two VPCs directly, Transit Gateway acts as a hub for many VPCs and on-prem links, and VPC Flow Logs record accepted and rejected traffic so you can see exactly where packets stop.
Think of it like this
Peering is a private footbridge between two housing societies — great for two, a mess for ten (every pair needs its own bridge). A Transit Gateway is a central bus station everyone connects to once.
Key ideas
- 01
VPC PEERING is a one-to-one private connection between two VPCs (same or different account/region). It's NOT TRANSITIVE: if A peers with B and B with C, A can't reach C through B. Both sides must add routes, and security groups must allow the peer's CIDR (or SG, within a region).
- 02
TRANSIT GATEWAY (TGW) is a regional router: each VPC and VPN/Direct Connect attaches once, and TGW route tables control who can reach whom — including segmentation such as 'dev and prod both reach shared-services, but not each other'. It costs per attachment-hour and per GB, so it's for when peering meshes become unmanageable.
- 03
Reaching on-premises: SITE-TO-SITE VPN (IPsec tunnels over the internet, quick to set up) or DIRECT CONNECT (a dedicated physical link — consistent bandwidth and latency, weeks to provision). PRIVATELINK is different again: it exposes one specific service (behind an NLB) to consumers in other VPCs without connecting the networks at all.
- 04
VPC FLOW LOGS capture metadata for traffic on a VPC, subnet, or network interface: source/destination IP and port, protocol, bytes, and ACCEPT or REJECT. They don't capture payloads. Send them to CloudWatch Logs or S3 and query them.
- 05
Debugging rule of thumb: a REJECT in flow logs means a security group or NACL dropped it; no record at all usually means the packet never got there — a routing problem (missing route, wrong route table association) or DNS resolving to the wrong address. VPC REACHABILITY ANALYZER can trace a path between two resources and name the exact component blocking it.
Code & diagrams
aws ec2 create-flow-logs --resource-type VPC --resource-ids $VPC \
--traffic-type ALL --log-destination-type cloud-watch-logs \
--log-group-name /vpc/prod/flow \
--deliver-logs-permission-arn arn:aws:iam::123456789012:role/flow-logs
# Static path analysis: can the app instance reach the DB on 5432?
PATH_ID=$(aws ec2 create-network-insights-path \
--source i-0app --destination i-0db --protocol tcp --destination-port 5432 \
--query NetworkInsightsPath.NetworkInsightsPathId --output text)
aws ec2 start-network-insights-analysis --network-insights-path-id $PATH_IDCloudWatch Logs Insights query — top rejected flows in the last hour.
fields @timestamp, srcAddr, dstAddr, dstPort, action
| filter action = "REJECT"
| stats count(*) as rejects by srcAddr, dstAddr, dstPort
| sort rejects desc
| limit 20Explain it without notes
VPC A is peered with B, and B with C. An instance in A can't reach C. Why, and what are your options?
In flow logs you see REJECT records for app → db on port 5432. What does that tell you, and what doesn't it tell you?
Practice
You have 12 VPCs that all need to reach a shared-services VPC, and none should reach each other. Peering or Transit Gateway? Sketch the approach.
App → DB connections time out but flow logs show NO records for that traffic at all. What are the likely causes?
Trade-offs
- ↔
Peering has no per-hour cost and the lowest latency but becomes an unmanageable mesh past a handful of VPCs; Transit Gateway centralizes routing and segmentation at a per-attachment and per-GB cost.
Done when you can
I know peering is non-transitive and when to switch to Transit Gateway.
I can name the options for connecting AWS to an on-premises network.
I can enable flow logs and query them for rejects.
I can tell a routing problem from a firewall problem using flow logs.