Transit Gateway is an AWS networking hub that connects multiple VPCs and on-premises networks through a shared routing layer. It centralises connectivity so organisations can manage network paths and attachments in one place, but that centralisation also increases the need for careful governance, dependency tracking, and change control.
Expanded Definition
A transit gateway is a shared network hub that lets multiple virtual private clouds, branch networks, and on-premises environments exchange traffic through one managed routing plane. In AWS-heavy environments, it replaces many point-to-point links with a central attachment model, which can simplify routing, segmentation, and scale. From an NHI security perspective, the key issue is not the hub itself but the identities, secrets, and automation that are allowed to create, modify, or route through it. That means access policies, change approvals, and dependency mapping must be treated as part of the network control surface, not as an afterthought. The concept overlaps with hub-and-spoke routing, but it is distinct from simple peering because the gateway becomes a governance choke point for traffic policy. Definitions vary across vendors, but the operational meaning is consistent: a transit gateway is a shared dependency that concentrates both connectivity and risk. The most common misapplication is treating it as a purely network-layer convenience, which occurs when teams ignore the identity and change-control authority behind automated routing updates.
For baseline control expectations, NIST SP 800-53 Rev 5 Security and Privacy Controls remains a useful reference for access restriction, configuration management, and boundary protection.
Examples and Use Cases
Implementing a transit gateway rigorously often introduces routing and ownership complexity, requiring organisations to weigh simpler connectivity against tighter governance and dependency tracking.
- A platform team attaches several application VPCs to one gateway so shared inspection and central egress rules can be enforced consistently.
- An infrastructure pipeline updates route tables automatically after deployment, but the automation must be tied to a tightly scoped NHI rather than a broad admin credential.
- A hybrid estate uses the gateway to connect an on-premises network to multiple cloud workloads, reducing the number of direct links that must be monitored and rotated.
- A security team reviews attachment permissions and route propagation after learning that overly permissive service accounts can alter paths between environments.
- For broader NHI context, the Ultimate Guide to NHIs explains why routing authorities, automation secrets, and lifecycle controls must be governed together, while NIST SP 800-53 Rev 5 Security and Privacy Controls provides control language for configuration and access management.
Why It Matters in NHI Security
Transit gateways matter because centralised connectivity often becomes a high-value target for compromised NHIs. If a service account, API key, or CI/CD credential can alter attachments or routes, an attacker can expand access laterally across otherwise separated environments. That is why route ownership, least privilege, and change approval need to be designed around the identities that operate the gateway, not just around the network topology. NHIMG research shows that 97% of NHIs carry excessive privileges, which directly increases the chance that a single compromised automation path can affect multiple connected networks; the Ultimate Guide to NHIs is explicit about that privilege problem. A transit gateway also complicates offboarding because deleted workloads, stale route entries, and orphaned automation can leave unintended paths open. Practitioners should treat it as part of identity governance as much as infrastructure governance, and align it with least-privilege access and boundary protection expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls. Organisations typically encounter the operational risk only after a route change, incident, or compromise exposes unintended connectivity, at which point transit gateway governance becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207), NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Central routing depends on NHI permissions, making excessive access a direct concern. |
| NIST CSF 2.0 | PR.AC-4 | Transit gateway governance maps to least-privilege access and controlled network connections. |
| NIST Zero Trust (SP 800-207) | Shared transit layers must still be segmented and continuously validated under zero trust. | |
| NIST SP 800-63 | AAL2 | Automations managing shared connectivity need strong authenticator assurance for privileged actions. |
| NIST AI RMF | Automation-driven routing is a socio-technical risk that needs documented governance and monitoring. |
Assess routing automation, failure modes, and oversight before granting connectivity authority.
