Deploying AWS Transit Gateway With a Shared Services VPC
A shared services VPC provides a central network location for services used by multiple application environments. AWS Transit Gateway (TGW) connects that VPC to spoke VPCs, on-premises networks, and other AWS accounts without creating a growing mesh of VPC peering links.
This design suits organisations running separate production, development, security, and data accounts. A centralised model can simplify DNS, directory services, patch repositories, monitoring, and outbound inspection while keeping workloads isolated. It is particularly useful when a business operates across Sydney, Melbourne, Brisbane, or regional sites with different connectivity requirements.
The main design work is in routing and ownership. A TGW attachment alone does not provide reachability: each VPC route table, TGW route table, security group, and network firewall path must align. The following model keeps those dependencies visible and manageable.
| Design area | Recommended approach | Main benefit |
|---|---|---|
| Network hub | Dedicated TGW in the networking account | Central route control |
| Shared services | Separate VPC for DNS, directory, logging, and tooling | Consistent platform services |
| Workload networks | Spoke VPCs attached through AWS RAM | Account-level isolation |
| Internet egress | Central inspection and NAT path where required | Uniform security controls |
| Hybrid connectivity | Direct Connect or VPN attached to TGW | Shared access to on-premises systems |
Define The Shared Services Boundary
The shared services VPC should host services that genuinely need to be consumed across accounts. Typical examples include Active Directory domain controllers, Route 53 Resolver endpoints, internal certificate services, patch mirrors, vulnerability scanners, SIEM collectors, and private interface VPC endpoints.
Keep application databases and workload-specific components in their owning VPCs. Placing too much in the central VPC turns it into a dependency bottleneck and makes account separation less meaningful. A central logging service is useful; a shared application database usually creates operational and ownership problems.
Use at least two Availability Zones for critical services. Subnets for directory servers, resolver endpoints, and inspection appliances should be deliberately separated from management and endpoint subnets. AWS documentation and practical configuration notes from IT Diversified can complement the design work when building the surrounding AWS infrastructure.
Establish Accounts And Ownership
A common landing zone uses a dedicated networking or infrastructure account to own the TGW. The shared services VPC can live in that account or in a separate platform account, depending on security and billing requirements. AWS Resource Access Manager (RAM) shares the TGW with selected accounts or with the organisation as a whole.
Central ownership should cover TGW route tables, attachment approvals, appliance insertion, and changes to shared connectivity. Workload teams can still own their VPC subnets, security groups, and application routes. This split prevents an application team from accidentally changing connectivity for every other environment.
Enable AWS Organisations integration with RAM and establish tagging standards before attachments are created. Useful tags include environment, business owner, data classification, cost centre, and managed-by status. Australian organisations handling regulated or sensitive data should map the design to internal controls, the Essential Eight, and relevant ISM expectations rather than treating connectivity as purely a networking concern.
Build Routing And DNS Deliberately
Create separate TGW route tables for different trust zones, such as production, non-production, inspection, and shared services. Associate each VPC attachment with the appropriate route table and control propagation explicitly. This is safer than allowing every learned route to appear everywhere.
For example, production spokes may receive routes to the shared services CIDRs and approved on-premises prefixes, while non-production spokes receive a smaller set. A default route can point to an inspection VPC if all internet-bound traffic must pass through firewalls. Avoid overlapping CIDRs, especially when integrating older data centres or acquired businesses.
Central DNS normally uses Route 53 Resolver inbound and outbound endpoints in the shared services VPC. Add resolver rules for corporate domains and associate them with the required VPCs. Confirm that DNS support and DNS hostnames are enabled on every participating VPC, and remember that DNS reachability does not imply application-level access.
Add Inspection And Egress Controls
A centralised inspection VPC can contain AWS Network Firewall, third-party firewalls, or specialised appliances. For stateful appliances, enable TGW appliance mode on the relevant attachment so forward and return traffic remains aligned with the same Availability Zone path. The exact route design depends on whether inspection is required for east-west traffic, internet egress, or both.
A typical egress path is spoke VPC to TGW, TGW to inspection subnet, inspection device to NAT Gateway, and then to an Internet Gateway. Return routes must mirror that path. Network ACLs, security groups, firewall policies, and NAT rules should be documented together; troubleshooting only one layer often leads to misleading results.
Keep management access separate from application traffic. Use Systems Manager Session Manager where possible instead of exposing bastion hosts. If a Brisbane office, a Melbourne data centre, and AWS workloads in Sydney all share services, define which traffic is allowed across those boundaries and log accepted as well as denied flows.
Automate Provisioning And Operations
Infrastructure as Code is essential once several accounts and regions are involved. Terraform modules or CloudFormation stacks should create TGW route tables, RAM shares, VPC attachments, routes, resolver rules, and logging consistently. Treat route-table associations as explicit resources rather than relying on default behaviour.
Useful operational checks include:
- Confirm every attachment has the intended TGW route-table association.
- Check propagation status after adding VPN or Direct Connect routes.
- Verify Resolver endpoint security groups allow required DNS traffic.
- Review Flow Logs and firewall logs during controlled tests.
Use CloudWatch, AWS Config, and EventBridge to detect unmanaged attachments, route changes, and failed appliance health checks. Centralise logs in a security account with retention aligned to business and regulatory requirements. If teams describe a short maintenance window as “just an arvo change,” the same peer review and rollback process should still apply.
Validate Failover And Troubleshoot Methodically
Test from an instance in each trust zone to a shared service, an approved on-premises address, and an internet destination. Record the source subnet, destination address, route selected, security group decision, firewall action, and return path. Testing only from a bastion host can hide subnet-specific errors.
Common failure points include:
- A VPC route points to the TGW, but the TGW route table has no matching destination.
- The attachment is associated with the wrong TGW route table.
- A propagated on-premises route is missing or more specific than expected.
- Firewall or security group rules permit the outbound path but block the return traffic.
Test Availability Zone failure by removing or isolating one appliance, NAT Gateway, or shared service endpoint at a time. Validate Direct Connect and VPN failover separately, including BGP route convergence. For Australian deployments, also check the impact of cross-region recovery between Sydney and Melbourne, including latency, data residency, and any service dependencies that were assumed to remain local.