Lesson 274 · AWS Learning Path

AWS 274: Centralized ingress, egress and inspection

Anil Jalela · Published Mar 26, 2026 · 16 min read

Why this lesson matters

Centralizing firewalls and internet access can make policy consistent across many VPCs, but it also adds routing hops, shared failure domains, throughput limits, logs, and several per-hour or per-GB charges. A diagram that shows a firewall between two clouds does not prove that the packet actually crosses it, that the reply uses the same stateful endpoint, or that IPv6 and alternate routes cannot bypass it.

This lesson builds four separate models: outbound internet, inbound internet, east-west or hybrid traffic, and DNS/service egress. You will compare distributed and centralized controls using AWS Network Firewall, Gateway Load Balancer (GWLB), third-party appliances, NAT gateways, Transit Gateway (TGW), VPC ingress routing, AWS WAF, Route 53 Resolver DNS Firewall, and VPC endpoints. The practical work changes no AWS resource.

Outcomes

By the end, you can:

• distinguish ingress, egress, east-west, hybrid, management, DNS, and control-plane traffic;
• trace every VPC, TGW, firewall, NAT, internet gateway, load-balancer, and return lookup;
• explain stateless versus stateful inspection and why flow symmetry matters;
• design Network Firewall and GWLB appliance topologies in multiple AZs;
• use TGW appliance mode correctly without treating it as a universal symmetry fix;
• place NAT and inspection in a deliberate order and predict source-address visibility;
• compare centralized, distributed, and combined deployment models;
• explain TLS inspection, metadata-only visibility, certificate trust, and bypass limits;
• validate rule order, HOME_NET, logging, metrics, scale, failure, and policy governance;
• calculate repeated TGW, firewall, NAT, cross-AZ, and logging cost per flow; and
• complete a 25-VPC inspection workbook with positive, negative, bypass, and failure proofs.

Start with traffic class, not a firewall product

One topology rarely optimizes every class. AWS WAF understands HTTP requests but not arbitrary TCP. Network Firewall and third-party appliances inspect network flows but do not replace application authorization. DNS Firewall filters domain queries, not subsequent connections to an IP. VPC endpoints can remove AWS-service traffic from internet egress entirely.

Define first: source, destination, address family, protocol/port, expected allow or deny, inspection depth, source preservation, latency, throughput, availability, compliance evidence, and cost owner.

Packet-processing foundations

Routing selects a next hop. A network ACL evaluates subnet-bound traffic statelessly. A security group tracks allowed connections for associated ENIs. NAT translates addresses and keeps state. A stateful firewall tracks a bidirectional flow and can make decisions using connection context. These are complementary controls.

For each flow, use this algorithm:

1. Resolve the destination name and record the selected IP/address family.
2. Apply the source subnet route table's longest-prefix match.
3. At TGW, identify the route table associated with the source attachment and its selected route.
4. In an inspection VPC, evaluate the TGW attachment-subnet route, same-AZ firewall/GWLB endpoint, post-inspection route, and second TGW lookup.
5. Evaluate NAT, internet gateway edge routing, load balancer, or destination VPC routing in their actual order.
6. Evaluate NACLs, security groups, firewall policy, host listener, TLS, and application identity.
7. Repeat every lookup for the reply. Never write “same path back” without evidence.
8. Match the prediction to VPC/TGW Flow Logs, firewall logs, NAT/NLB metrics, application logs, and a controlled probe.

Stateful devices must see both directions of the flow, normally through the same stateful processing context. Asymmetry can result from a more-specific route, another AZ endpoint, cross-zone load balancing, BGP choice, an internet gateway edge table, or a different TGW attachment.

Distributed, centralized, and combined models

Distributed

Each workload VPC owns NAT gateways and possibly Network Firewall endpoints in its AZs. Paths are short, failures are isolated, and cost allocation is clear. However, hourly resources and policy operations multiply across VPCs. Firewall Manager and infrastructure as code can centrally govern distributed firewalls without centralizing the data path.

Centralized

Spokes send selected traffic through TGW or Cloud WAN to an inspection/egress VPC. A platform team operates shared firewalls, NAT, logs, and routes. This can reduce duplicated resources and simplify policy, but it adds TGW processing, shared capacity/failure domains, more route tables, and potentially cross-AZ processing.

Combined

Keep latency-sensitive or high-volume egress local, centralize inter-zone/hybrid inspection, use WAF at public applications, and use VPC endpoints for AWS services. A combined model often minimizes tromboning. “Centralized security” can mean centralized governance rather than forcing every byte through one VPC.

Centralized IPv4 outbound internet path

A common path is:

spoke private subnet default -> TGW
  -> spoke-associated TGW table -> egress/inspection attachment
  -> same-AZ firewall endpoint
  -> public NAT gateway in that AZ
  -> internet gateway
  -> internet destination

The return path is:

internet -> internet gateway -> NAT gateway state
  -> firewall endpoint/state
  -> TGW attachment
  -> inspection-associated TGW table -> spoke attachment
  -> spoke subnet -> workload

Exact route tables depend on the chosen AWS reference pattern. Do not improvise a single route table for all egress VPC subnets. TGW attachment subnets, firewall endpoint subnets, NAT public subnets, and sometimes intermediate subnets need distinct routes so traffic cannot skip inspection or bounce in a loop.

NAT before firewall makes the firewall see translated source addresses and can reduce workload attribution. Firewall before NAT preserves source identity during policy evaluation and is a common goal, but the return route must still re-enter the same stateful endpoint. Document the actual order, not the intended order.

Deploy NAT gateways and firewall endpoints per AZ and keep traffic zonally aligned. Sending every AZ through one NAT saves hourly cost at the expense of a single-AZ dependency and cross-AZ data charges. A NAT gateway is zonal; AWS does not move its stateful flows to another NAT automatically.

For IPv6, do not copy the IPv4 NAT diagram. IPv6 commonly uses an egress-only internet gateway without address translation, or centralized proxy/NAT appliances for specific requirements. Build separate ::/0 routes, firewall policy, security controls, logs, and failure tests. A protected IPv4 path with direct IPv6 egress is a bypass.

East-west and hybrid centralized inspection

For spoke A to spoke B, spoke A's TGW table sends the destination to the inspection attachment. Inside the inspection VPC, a same-AZ firewall endpoint receives the flow, then a post-inspection route returns it to TGW. The inspection attachment's associated TGW table selects spoke B. The reply repeats this chain in reverse.

Enable appliance mode on the inspection VPC TGW attachment. TGW then uses a flow hash to keep both directions on the same attachment ENI/AZ for the flow lifetime, supporting stateful inspection. Appliance mode does not:

• repair a route that bypasses the inspection attachment;
• make two different TGWs share flow state;
• fix paths entering through an internet gateway and returning through TGW;
• synchronize state across independent third-party appliances; or
• replace per-AZ route tables and healthy endpoints.

The inspection VPC normally has a dedicated TGW attachment subnet and dedicated firewall endpoint subnet in each AZ. Network Firewall endpoints cannot inspect traffic in their own endpoint subnets. Preserve source and destination addresses where policy and logs require them.

For hybrid flows, prove both AWS and customer-router return choices. A packet may enter through Direct Connect, cross TGW/firewall, and return through a VPN if BGP preferences differ. That may break state and performance even when every individual route is valid.

Centralized inbound internet inspection

Inbound architectures are not outbound diagrams reversed. Common patterns include:

• CloudFront plus AWS WAF and Shield before an ALB/API in each application VPC;
• edge VPC public ALB/NLB, Network Firewall, then TGW to private application targets;
• VPC ingress routing that redirects traffic entering an internet gateway through GWLB endpoints and third-party appliances; and
• distributed public load balancers with centrally governed WAF/Network Firewall policy.

Trace source preservation and target registration. An edge load balancer using IP targets in spoke VPCs can lose automatic target discovery unless registration automation exists. TLS may terminate at CloudFront, ALB, NLB, firewall, or workload. WAF can inspect decrypted HTTP only where integrated; a network firewall without TLS decryption sees addresses, ports, flow behavior, and some handshake metadata, not encrypted payload content.

Internet gateway ingress route tables can steer traffic to a GWLB endpoint or firewall path. Their lookup and the return route are independent. A direct application-subnet default route to the internet gateway can bypass a stateful ingress path. Test every public IP, AZ, load balancer node/path, IPv4/IPv6 family, and failover state.

Layer controls deliberately:

AWS Network Firewall internals

Network Firewall creates a firewall endpoint in each selected subnet/AZ. A firewall policy combines stateless rule groups, stateless default actions, stateful rule groups, and optional TLS inspection. Stateful rules can use standard 5-tuple/domain-list rules or Suricata-compatible rules.

Know the evaluation model:

• stateless rules use priorities and actions such as pass, drop, or forward to stateful;
• default stateless actions apply when no stateless rule matches;
• stateful action order evaluates pass before drop/reject/alert, then priority within action;
• stateful strict order evaluates in configured order with explicit default actions;
• HOME_NET must include the protected spoke/hybrid CIDRs needed by rules;
• domain filtering depends on DNS/TLS/HTTP details and cannot govern direct IP or every encrypted protocol.

A broad stateful pass can stop further inspection before a later alert/drop. Strict-order drop established can block traffic while producing no expected alert unless an alert default action is also configured. Validate rules in a test policy against positive, negative, fragmented, established, retransmitted, and asymmetric flows.

Network Firewall scales managed endpoint capacity, but rule complexity, flow patterns, packet size, connection rates, and service quotas still matter. Monitor dropped packets, passed packets, received packets, stream exceptions, TLS outcomes, endpoint status, and AZ distribution.

Gateway Load Balancer and appliances

GWLB distributes GENEVE-encapsulated flows to compatible virtual appliances, normally over UDP port 6081 between GWLB and appliances. GWLB endpoints are PrivateLink-powered route targets placed in traffic VPCs or edge VPCs. Appliances must support GENEVE, health checks, flow stickiness, return encapsulation, and the selected deployment pattern.

The appliance fleet needs one or more healthy targets per AZ, scaling warm-up, licensed capacity, configuration synchronization, patching, management isolation, and failure semantics. Decide whether unhealthy capacity fails closed or routing bypasses inspection. Auto Scaling adds instances but cannot guarantee policy is loaded before health checks pass unless bootstrap acceptance tests enforce it.

Use GWLB when third-party or custom appliance features are required. Use Network Firewall when managed AWS integration and Suricata-compatible controls fit. Compare feature depth, operations, licensing, scale, TLS, logging, policy rollout, support, and total path cost rather than only hourly firewall price.

TLS, DNS, and unavoidable visibility limits

Encryption limits payload inspection. Without TLS decryption, a firewall may observe IPs, ports, certificate/handshake metadata where exposed, SNI in applicable TLS versions, and flow behavior. Encrypted Client Hello, certificate pinning, QUIC/HTTP3, custom protocols, and direct IP use affect visibility.

Network Firewall TLS inspection can decrypt, inspect, and re-encrypt selected traffic using ACM-managed certificate configuration. This creates a trust boundary:

• clients must trust the inspection CA;
• private keys and certificate rotation require strict ownership;
• pinned applications may fail;
• excluded financial/health/private traffic must be explicit;
• inbound and outbound inspection capabilities/constraints differ;
• decryption increases privacy, performance, logging, and incident obligations; and
• TLS logs do not record every successful connection merely because TLS logging is enabled.

DNS Firewall blocks or alerts on queried domains but does not prevent direct-IP, alternate resolver, cached, DoH, or later-changing-IP access by itself. Force approved Resolver paths where appropriate, control external DoH, log queries with privacy safeguards, and combine DNS evidence with network/application controls.

VPC gateway/interface endpoints remove eligible AWS service calls from NAT/internet paths. Their policies, private DNS, centralized-versus-distributed placement, and data charges need separate analysis. Do not inspect trusted AWS API traffic through NAT by default when a least-privilege endpoint is safer and cheaper.

Route and bypass proof

Build an allow-path and a bypass-path matrix. Search:

• every spoke subnet route table for more-specific internet, peer, NAT, endpoint, or TGW routes;
• each TGW associated table for direct spoke-to-spoke routes that outrank inspection;
• propagation that can introduce a new more-specific route;
• default association/propagation for newly attached VPCs;
• IPv6 routes and egress-only gateways;
• internet gateway edge route tables;
• peering, Cloud WAN, VPN, Direct Connect, and secondary TGWs;
• appliance management interfaces and public IPs;
• alternate DNS/DoH and proxy paths; and
• fail-open policy or automation that changes routes during endpoint failure.

A denied test alone does not prove every bypass is closed. Combine configuration inventory, route calculation, Reachability Analyzer where applicable, Flow Logs, firewall evidence, and controlled probes. Maintain route-policy tests in CI before accepting infrastructure changes.

Read-only evidence collection

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws network-firewall list-firewalls --output json
aws network-firewall list-firewall-policies --output json
aws network-firewall list-rule-groups --output json
aws ec2 describe-nat-gateways --output json
aws ec2 describe-vpc-endpoints +  --filters Name=vpc-endpoint-type,Values=GatewayLoadBalancer --output json
aws ec2 describe-transit-gateway-vpc-attachments --output json

For approved identifiers:

FIREWALL_NAME="approved-firewall-name"
TGW_ATTACHMENT_ID="tgw-attach-approved-id"
aws network-firewall describe-firewall +  --firewall-name "$FIREWALL_NAME" --output json
aws network-firewall describe-logging-configuration +  --firewall-name "$FIREWALL_NAME" --output json
aws ec2 describe-transit-gateway-vpc-attachments +  --transit-gateway-attachment-ids "$TGW_ATTACHMENT_ID" +  --query 'TransitGatewayVpcAttachments[].Options' --output json

Also inspect all relevant VPC/TGW route tables, route propagations, GWLB/NLB listeners and target health, security groups/NACLs, firewall policy/rule variables/order, TLS configuration, Resolver/DNS Firewall, Flow Logs, CloudWatch alarms, CloudTrail, Firewall Manager policy, quotas, and Cost and Usage Report. Redact IDs, CIDRs, domains, rule signatures, accounts, and topology.

Telemetry and diagnosis

Network Firewall flow logs are unidirectional Suricata EVE netflow events. Alert logs require matching alert-capable actions and logging configuration. TLS logs focus on TLS errors and relevant revocation outcomes, not all successful TLS. Destinations include CloudWatch Logs, S3, and Firehose, with storage, query, and privacy cost.

Correlate timestamps and 5-tuples across client, VPC/TGW Flow Logs, firewall flow/alert/TLS logs, NAT metrics, load-balancer logs/metrics, DNS logs, and application logs. A Flow Log ACCEPT means the recorded network interface policy accepted traffic, not that the firewall, TLS, or application succeeded.

Failure, change, and rollback

Test one endpoint, AZ, NAT, TGW attachment, target group, appliance, policy deployment, log destination, DNS control, DX/VPN path, and Region failure. Existing stateful flows may reset rather than migrate. Define recovery-time and recovery-point expectations for policy/configuration, not only appliance replacement.

Treat firewall and route policy as software:

1. version infrastructure, rules, variables, certificates, and route intent;
2. lint and run semantic/duplicate/shadowed-rule checks;
3. test known allowed, denied, established, fragmented, IPv6, and bypass cases;
4. deploy to a canary VPC/AZ;
5. compare metrics/logs and application SLOs against gates;
6. roll out gradually with independent approval; and
7. preserve the exact previous policy/route version for rollback.

Rollback must consider state. Restoring a route can strand connections created on the newer path. Restoring firewall policy does not restore lost connection state. Define whether rollback drains, resets, or temporarily supports both paths. Never create a direct bypass route as an undocumented emergency fix.

Cost model per packet path

List every billable boundary in both directions:

• TGW attachment hours and data processing, possibly multiple crossings;
• Network Firewall endpoint hours and data processing;
• GWLB endpoint, GWLB capacity, appliance, and license charges;
• NAT gateway hours and bytes;
• cross-AZ and cross-Region transfer where applicable;
• load balancer hours/capacity and WAF requests;
• DNS Firewall, Resolver endpoint/query, and PrivateLink processing;
• CloudWatch/S3/Firehose logging, retention, analytics, and archive; and
• support/on-call, rule engineering, testing, certificate, and compliance operations.

Centralization may reduce hourly NAT/firewall count while adding TGW and longer per-GB paths. Calculate low-volume and high-volume VPCs separately. Keep same-AZ paths and VPC endpoints in the model. A flow may cross TGW twice and inspection/NAT once in each direction; do not price only the source-to-firewall leg.

Twenty-five-VPC architecture workbook

Design inspection for 25 VPCs across production, development, shared services, and data zones. Include internet egress, public ingress, east-west, on-premises, DNS, AWS APIs, management, IPv4, and IPv6.

Compare at least:

1. distributed NAT plus distributed Network Firewall;
2. centralized TGW, Network Firewall, and zonal NAT; and
3. centralized TGW/GWLB third-party appliances with selected local endpoints.

For at least 20 flows record:

Submit the topology comparison, 25-VPC route/attachment inventory, 20-flow matrix, rule-order analysis, TLS/DNS decision, AZ capacity plan, quota and cost forecast, logging/privacy plan, 10 failure tests, RACI, and no-change proof.

Knowledge check

1. Why is appliance mode needed on an inspection VPC TGW attachment?

It keeps both directions of a flow on the same attachment ENI/AZ for stateful processing.

1. Does appliance mode force every route through the firewall?

No. Route tables can still select a bypass.

1. Why place inspection before NAT for many policies?

The firewall retains original workload source visibility before translation.

1. Does DNS Firewall block a direct connection to an IP?

No. It filters DNS queries, so network/application controls remain necessary.

1. Does TLS inspection logging contain every successful HTTPS flow?

No. TLS logging has specific error/revocation behavior; use flow and application evidence too.

1. Why is centralized egress not always cheaper?

Saved endpoint hours can be outweighed by TGW, firewall, NAT, transfer, and logging bytes.

Lesson acceptance

The lesson is complete only when the learner can:

• classify all traffic and choose distributed, centralized, or combined controls;
• execute the eight-step packet proof in both directions;
• draw exact outbound, inbound, east-west, hybrid, DNS, and AWS-service paths;
• preserve stateful symmetry with zonal routes and appliance mode while finding bypasses;
• explain Network Firewall rule order, HOME_NET, GWLB/GENEVE, TLS, DNS, and IPv6 limits;
• diagnose route, state, policy, capacity, TLS, DNS, and application failures from evidence;
• test AZ/endpoint/NAT/appliance/policy/log/hybrid failures and rollback safely;
• calculate every hourly, per-GB, request, transfer, and telemetry cost boundary;
• complete the 25-VPC and 20-flow architecture dossier; and
• attest that no staging or production AWS resource changed.

Official sources

• AWS Network Firewall deployment models
• Centralized network security inspection
• Centralized egress to the internet
• Centralized inbound inspection
• Gateway Load Balancer
• Network Firewall rule actions
• Network Firewall logging contents
• Network Firewall TLS inspection
• TGW appliance mode