Setting up AWS Transit Gateway with centralised network firewall

Centralising east-west and egress inspection gives distributed teams a single policy and logging boundary without placing a firewall appliance in every workload VPC. The pattern suits Australian organisations running production across AWS accounts and hybrid branches connected by VPN or AWS Direct Connect.

The target design uses AWS Transit Gateway as the routing hub and a dedicated inspection VPC containing AWS Network Firewall endpoints. Workload VPCs attach to the gateway, relevant routes point into the inspection VPC, and protected traffic is evaluated by stateful, stateless and domain-list rules before continuing to its destination.

A regional design is essential because Transit Gateway does not span AWS Regions. Australian teams can anchor an inspection VPC in Sydney while workloads remain in Sydney, Melbourne or Brisbane, but cross-region traffic needs a separate peering or cloud WAN path with independent latency, cost and policy validation.

This walkthrough assumes AWS CLI access, a non-production account for testing and permission to manage VPC routes, firewall policies and logging. The background on the authors explains the practitioner focus behind IT Diversified, whose material covers AWS, VMware, HashiCorp, PowerShell and infrastructure operations.

Design a resilient inspection path

Start with a route matrix showing each source, destination, inspection point and return path. The matrix should distinguish spoke-to-spoke, spoke-to-on-premises and approved egress flows; placing every route through the firewall without this map creates loops, black holes and unexpected gaps in stateful inspection.

Run active Network Firewall endpoints in the Availability Zones used by protected subnets. Centralisation therefore means a shared policy boundary, not a single zonal appliance. Appliance-mode routing, matching source and destination CIDRs, and deliberate handling of asymmetric traffic help the endpoints preserve state while packets cross AWS Transit Gateway.

Keep regional designs separate unless there is a business requirement for global inspection. A Transit Gateway peering attachment can extend a hub across Sydney and Melbourne, but prefix-list handling and failover need independent tests. This matters for Australian latency expectations and for local market deployments that must keep sensitive workloads in approved Regions.

Build the inspection VPC

Plan non-overlapping CIDRs for the inspection VPC, Network Firewall subnets and centralised egress components. Create endpoints in at least two Availability Zones and associate them with a dedicated endpoint route table rather than sharing ordinary application routing.

Apply a least-privilege egress design. Workload subnets can reach the inspection path, while firewall endpoint subnets can reach only the required Transit Gateway, DNS, update and logging destinations. For controlled internet access, place zonal NAT gateways in the inspection VPC and route approved egress through them, using restrictive security groups and explicit DNS controls.

Define the network firewall, rule groups, logging configuration and endpoints through Terraform, CloudFormation or Pulumi where possible. Consistent tags for account, environment, owner and cost allocation make multi-account operations easier, while CloudTrail and AWS Config records provide evidence of changes for internal reviews.

Attach and route the workloads

Share the regional Transit Gateway through AWS Resource Access Manager when spoke VPCs live in different accounts, or attach them directly in a single account. Create one TGW route table for normal east-west flows and separate tables for shared services or untrusted workloads, then use route propagation only where the attached resources need the shared routes.

The inspection VPC attachment should send approved inter-VPC CIDRs toward the firewall endpoints, while each spoke route table directs protected destinations to the TGW. Confirm the return path before enabling enforcement; a destination route without a matching return route can bypass central inspection or break established sessions.

Use a staged rollout:

• Attach each spoke VPC to the selected TGW and record its attachment ID.
• Route only approved destination CIDRs through the inspection path.
• Keep on-premises and shared-service routes separate where policy differs.
• Test IPv4 and IPv6 behaviour before adding a default route to the hub.

Validate the active configuration with aws ec2 describe-route-tables after every change, then use a deliberate deny test to prove traffic reaches the firewall. Keep the route matrix under version control so an emergency change can be reversed without guessing which route caused the outage.

Apply policy at the inspection boundary

Build rule groups around business services rather than individual server pairs where possible. Stateful rules can permit application flows, stateless rules should be reserved for cases that must bypass state tracking, and domain-list rules depend on accurate DNS visibility. AWS Network Firewall evaluates rules in order, so review their sequence during every change.

Enable flow and alert logging from the beginning, and add TLS logging only after its certificate, storage and privacy implications are understood. Send logs to the organisation’s approved archive, protect the logging account with restrictive access, and correlate alerts with CloudTrail, GuardDuty and security-ticket identifiers.

Document how firewall controls support the ACSC Essential Eight and, for APRA-regulated organisations, APRA CPS 234. The Australian Privacy Act may also apply to personal information, while sector guidance and contractual obligations can require regional data placement. These requirements should shape routing and evidence design, not be added after deployment.

Test and operate the firewall platform

Test more than an allowed SSH flow. Exercise denied traffic, DNS behaviour, large sessions, UDP, IPv6 if used, and failure of one endpoint Availability Zone. The expected result is continued service through another endpoint, correct return routing and an alert trail showing where enforcement occurred.

Monitor Network Firewall metrics for invalid packets, drops and flow idle timeouts, check endpoint status, and use CloudTrail to track Transit Gateway route and attachment changes. Australian support teams can arrange AEST and ACST handovers for critical incidents, while local AWS partner or managed-service expertise remains valuable for estates with limited in-house networking depth.

Use a recurring operational check:

• Probe known-allowed and known-denied paths through every active Availability Zone.
• Alarm on firewall drops, endpoint errors and unexpected route changes.
• Review flow, alert and TLS logs after each policy deployment.
• Track Transit Gateway, Network Firewall, NAT, storage and data-processing charges.

Maintain the route matrix, rule rationale and recovery procedure as version-controlled documentation. Teams publishing a companion portal can use the Elementor theme shortlist to select a suitable presentation layer for diagrams and runbooks, while the runbook and infrastructure code remain the authoritative operational sources.