How Network Orchestration for AWS Transit Gateway Automates Multi-Account Connectivity at Scale

Overview

Managing Transit Gateway (TGW) attachments manually in a multi-account environment becomes operationally unsustainable as organizations scale. Each new VPC requires: creating a TGW attachment, associating to the correct route table, configuring propagations, and updating routes — often across account boundaries using RAM shares and cross-account IAM roles.

Network Orchestration for AWS Transit Gateway solves this by providing:

• A tag-driven model where application teams declare connectivity intent via VPC tags
• An event-driven orchestration engine that automatically provisions TGW attachments
• Approval workflows with auto-approve, auto-reject, and manual approval rules
• A web UI for visibility, audit, and approval management
• Multi-region support via TGW peering automation

Official Documentation: https://docs.aws.amazon.com/solutions/latest/network-orchestration-aws-transit-gateway/
GitHub (open-source): https://github.com/aws-solutions/network-orchestration-for-aws-transit-gateway

---

Architecture

The solution deploys two primary stacks in a hub-and-spoke model:

Hub Stack (Networking/Hub Account)

The hub stack is the brain of the solution. It deploys in your central networking account and contains:

Component	Purpose
Amazon EventBridge	Receives tag-change events from spoke accounts
AWS Step Functions	Orchestrates the validation → approval → execution workflow
AWS Lambda	Executes TGW operations (create attachment, associate route table, configure propagations)
Amazon DynamoDB	Stores state, action history, and audit trail
Amazon Cognito + CloudFront + S3	Web UI for dashboard, approvals, and visualization
Amazon SNS	Notifications for approval requests and state changes

Spoke Stack (Each Workload Account)

The spoke stack is lightweight — a single EventBridge rule that monitors VPC-level tag changes and forwards the event cross-account to the hub's EventBridge.

Component	Purpose
Amazon EventBridge Rule	Watches for CreateTags / DeleteTags API calls on EC2 VPC resources
IAM Role	Allows EventBridge to put events on the hub account's event bus

Organization Role Stack (Optional — Management Account)

Deploys an IAM role in the AWS Organizations management account to enable the hub to discover accounts and OUs automatically for the web UI visualization.

---

How It Works — The Tag-Driven Workflow

The entire workflow is triggered by a single VPC tag. Here's the step-by-step flow:

Step 1: Application Team Tags a VPC

An application team (or IaC pipeline) adds a tag to their VPC:

Key: Associate-with
Value: tgw-rt-spoke

The tag value corresponds to a TGW route table name configured in the solution.

Step 2: Spoke EventBridge Detects the Tag Change

The spoke account's EventBridge rule is configured to match CreateTags events on EC2 VPC resources. When the tag is applied, EventBridge captures the event and forwards it cross-account to the hub's event bus.

The event pattern looks like:

{
  "source": ["aws.ec2"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["ec2.amazonaws.com"],
    "eventName": ["CreateTags"],
    "requestParameters": {
      "resourcesSet": {
        "items": {
          "resourceId": [{"prefix": "vpc-"}]
        }
      }
    }
  }
}

Step 3: Hub EventBridge Triggers Step Functions

The hub's EventBridge receives the cross-account event and triggers the orchestration state machine. The Step Functions workflow:

1. Extracts the VPC ID, account ID, region, and tag value from the event
2. Validates the tag value against configured route table mappings
3. Checks approval rules:
   • If the account/OU matches an auto-approve rule → proceeds to execution
   • If it matches an auto-reject rule → denies and notifies
   • Otherwise → creates a pending approval in the web UI and sends SNS notification
4. On approval → invokes the execution Lambda

Step 4: Lambda Creates the TGW Attachment

The Lambda function executes the TGW operations using cross-account IAM roles (established by RAM sharing):

1. CreateTransitGatewayVpcAttachment (in the spoke account, using the shared TGW)
2. AssociateTransitGatewayRouteTable (associates to the route table matching the tag value)
3. EnableTransitGatewayRouteTablePropagation (configures propagation per policy)
4. CreateRoute (adds routes to the spoke VPC route tables pointing to the TGW)

Step 5: DynamoDB Records the Action

Every action is logged in DynamoDB with:

• Timestamp, account ID, VPC ID, requester
• Action taken (create/update/delete)
• Route table association and propagation details
• Approval status and approver (if manual)

Step 6: Web UI Updates

The web UI reflects the new attachment in the dashboard. Networking teams can see all attachments across accounts and regions in a single pane.

---

Lifecycle Management

The solution manages the full attachment lifecycle, not just creation:

Action	Trigger	Result
Create	VPC tagged with Associate-with: <route-table>	TGW attachment created, associated, propagated
Update	Tag value changed to a different route table	Attachment disassociated from old RT, associated to new RT
Delete	Tag removed from VPC	TGW attachment deleted, routes cleaned up

This means zero orphaned attachments and zero configuration drift — the tag IS the source of truth.

---

Deploying at Scale: 200+ Accounts with StackSets

The spoke template must be deployed to every account that needs TGW connectivity. For organizations with hundreds of accounts, Service-Managed CloudFormation StackSets is the recommended approach.

Configuration

Setting	Value
Permission model	Service-managed
Template	aws-transit-network-orchestrator-spoke.template
Deployment targets	Organizational Units (select your Workloads OUs)
Automatic deployment	Enabled
Account removal behavior	Delete stacks
Regions	Your home region(s)
Max concurrent accounts	10 (or percentage-based)
Failure tolerance	5

Why Service-Managed StackSets

• Zero-touch for new accounts — any account created in the target OU automatically gets the spoke stack
• OU-scoped — deploy to Workloads/Prod, Workloads/NonProd, Sandbox and you're done
• Automatic removal — if an account moves to Suspended OU, the spoke stack is deleted
• No per-account IAM roles — uses Organizations trusted access

Alternative: LZA Customizations

If using Landing Zone Accelerator, add to customizations-config.yaml:

customizations:
  cloudFormationStackSets:
    - name: network-orchestrator-spoke
      template: templates/aws-transit-network-orchestrator-spoke.template
      runOrder: 1
      deploymentTargets:
        organizationalUnits:
          - Workloads/Prod
          - Workloads/NonProd
          - Sandbox
      regions:
        - ca-central-1

---

Approval Rules — Governance Without Bottlenecks

The solution's approval engine lets you define granular rules:

Rule Type	Example	Use Case
Auto-approve	Dev OU accounts → tgw-rt-dev	Low risk, high volume — no human needed
Auto-approve	Any account → tgw-rt-spoke (non-production RT)	Standard connectivity, pre-approved
Manual approval	Production OU → any route table	High risk — networking team reviews
Auto-reject	Any account → tgw-rt-management	Governance guardrail — block invalid requests

Rules are configured in the web UI and stored in DynamoDB. They evaluate against account ID, OU membership, and target route table.

---

Web UI Capabilities

The solution deploys a web interface accessible via Amazon Cognito authentication:

• Dashboard — All TGW attachments across accounts and regions at a glance
• Pending Approvals — Queue of requests awaiting manual approval with full context
• Action History — Complete audit trail: who tagged what, when, and what happened
• Network Visualization — Topology view of your transit network
• Configuration — Manage approval rules and route table mappings

---

Key Operational Considerations

1. Tag is the source of truth — If you delete the tag, the attachment is removed. Educate teams that the tag is not decorative.
2. One tag per VPC — Each VPC can only associate to one route table at a time via this mechanism.
3. RAM sharing must be pre-configured — The TGW must be shared via AWS RAM to the spoke accounts before tagging works.
4. CloudTrail must be enabled — The spoke EventBridge rule relies on CloudTrail CreateTags events.
5. Cross-region — For multi-region, deploy separate hub stacks per region or use TGW peering tags.

---

Conclusion

Network Orchestration for AWS Transit Gateway transforms TGW management from a manual, ticket-driven process to an automated, self-service model with governance. By making connectivity declarative (tags) with automated enforcement (approval rules), it addresses the fundamental tension in enterprise networking: developers want speed, security wants control, and operations wants consistency.

The event-driven architecture (EventBridge → Step Functions → Lambda → DynamoDB) ensures the solution scales linearly with your account count, while the StackSet-based spoke deployment ensures new accounts are automatically enrolled with zero operational overhead.

For organizations managing 10+ accounts with Transit Gateway, this solution eliminates the networking bottleneck while maintaining the visibility and control that governance requires.

---

Resources:

Implementation Guide: https://docs.aws.amazon.com/solutions/latest/network-orchestration-aws-transit-gateway/

Source Code: https://github.com/aws-solutions/network-orchestration-for-aws-transit-gateway

Architecture Overview: https://docs.aws.amazon.com/solutions/latest/network-orchestration-aws-transit-gateway/architecture-overview.html