Solve: TGW Attachments Fail When the Route Table Is Deleted in a Central Network Account

Solve: TGW Attachments Fail When the Route Table Is Deleted in a Central Network Account

Problem

A developer in a spoke (development) AWS account attempted to create a VPC attachment to a Transit Gateway (TGW) using CloudFormation. The attachment entered a PendingAcceptance state, but the usual "Accept" option wasn’t available. Upon further inspection, the TGW route table linked to previous attachments showed as deleted. Additionally, the developer was unsure whether it was safe to delete the associated service-linked role, AWSServiceRoleForVPCTransitGateway.

Clarifying the Issue

The TGW and its routing infrastructure had been originally set up by a third party in a centralized network account. The developer was working from a different account (the spoke), and the attachments being created were cross-account. However, there was little documentation, and the ownership and structure of the TGW resources weren’t clear.

The missing route table turned out to be owned by the network account, and it had been deleted—leaving dangling references in older attachments. As a result, new attachments couldn't propagate properly, and confusion around TGW permissions and resource visibility added to the complexity.

Why It Matters

This situation represents a common architectural pattern: centralized networking via AWS Transit Gateway, where a network account owns the TGW and route tables, while development teams operate from separate accounts. When route tables are deleted or misconfigured—and when service-linked roles are removed without understanding their scope—TGW attachments fail silently or get stuck.

The result? Time-consuming debugging, unexpected side effects in production, and fragile infrastructure that breaks during handoff between teams or vendors.

Key Terms

• Transit Gateway (TGW): A networking hub that connects VPCs and on-prem networks via a central AWS-managed router.
• Spoke account: A secondary AWS account connected to a central TGW via attachments.
• Route Table: Defines how traffic is routed through the TGW to its attachments.
• Service-linked role: An IAM role that allows AWS services to perform actions on your behalf.

Steps at a Glance

1. Identify the account that owns the Transit Gateway and its route tables.
2. Check for any deleted or missing TGW route tables referenced by attachments.
3. Use the AWS CLI to verify current TGW configuration.
4. Recreate or reassign a valid route table if needed.
5. Avoid deleting AWSServiceRoleForVPCTransitGateway if the TGW is still in use.

Detailed Steps

1. Identify TGW ownership.

Use the AWS Console or CLI to confirm which account owns the TGW. You can only accept TGW attachments and manage route tables from the owning account.

Run the following command to inspect your TGW resources: 

Bash

aws ec2 describe-transit-gateways \
  --region us-east-1 \
  --query "TransitGateways[*].{ID:TransitGatewayId, Owner:OwnerId, State:State}" \
  --output table

Sample output:

Bash

ID                    Owner          State
--------------------  -------------  -----------
tgw-0abc...56789      123456789012   available

The Owner column tells you which AWS account owns the TGW — this is the only account that can manage its route tables and accept incoming attachments.You can only accept TGW attachments and manage route tables from the owning account.

2. Check for deleted route tables.

If older attachments reference a route table that no longer exists, the attachment will stall. From the owning account, run: 

Bash

aws ec2 describe-transit-gateway-route-tables \
  --region us-east-1 \
  --query "TransitGatewayRouteTables[*].{ID:TransitGatewayRouteTableId, State:State}" \
  --output table  

This will return all existing route tables and their current states. If the one you're referencing isn't listed, it's likely been deleted.

3. Inspect TGW attachments.

Use the AWS Console in the network account to view all attachments. Cross-account attachments should appear with an option to accept if they’re pending.

If you prefer using the CLI, you can list all TGW attachments and filter for their state: 

Bash

aws ec2 describe-transit-gateway-attachments \
  --region us-east-1 \
  --query "TransitGatewayAttachments[*].{ID:TransitGatewayAttachmentId, State:State, Type:ResourceType, TGW:TransitGatewayId}" \
  --output table  

Sample output: 

Bash

Attachment ID             State              Type   TGW ID
------------------------  -----------------  -----  --------------------
tgw-attach-0a1b...6g7h    pendingAcceptance  vpc    tgw-0abc...4def
tgw-attach-1x2y...9z0q    available          vpc    tgw-0abc...4def
tgw-attach-7r8s...3k2m    pendingAcceptance  vpc    tgw-0abc...4def

The State column will show pendingAcceptance for attachments that require manual approval from the TGW owner account.

Use the AWS Console in the network account to view all attachments. Cross-account attachments should appear with an option to accept if they’re pending.

4. Recreate a valid TGW route table.

If the route table was deleted, create a new one and associate it with your TGW: 

Bash

aws ec2 create-transit-gateway-route-table \
  --transit-gateway-id tgw-xxxxxxxx \
  --region us-east-1 

Output will look like this: 

Bash

{
  "TransitGatewayRouteTable": {
    "TransitGatewayRouteTableId": "tgw-rtb-0abc1234def567890",
    "State": "pending",
    "TransitGatewayId": "tgw-xxxxxxxx",
    "CreationTime": "2025-05-05T14:22:00.000Z"
  }
}   

You’ll then need to explicitly associate and propagate the relevant attachments to the new route table.

Associate the new route table with a TGW attachment: 

Bash

aws ec2 associate-transit-gateway-route-table \
  --transit-gateway-route-table-id tgw-rtb-0abc1234def567890 \
  --transit-gateway-attachment-id tgw-attach-0a1b2c3d4e5f6g7h \
  --region us-east-1

Enable propagation for the attachment: 

Bash

aws ec2 enable-transit-gateway-route-table-propagation \
  --transit-gateway-route-table-id tgw-rtb-0abc1234def567890 \
  --transit-gateway-attachment-id tgw-attach-0a1b2c3d4e5f6g7h \
  --region us-east-1  

These two steps ensure that routes are both explicitly associated and automatically propagated for the attachment to and from the route table.

5. Be cautious with the service-linked role.

⚠️ Do not delete AWSServiceRoleForVPCTransitGateway unless no TGW resources are in use. Deleting it while TGWs or attachments still exist may cause undefined behavior — even if things appear to be working temporarily.

Conclusion

When using centralized AWS networking patterns, resource ownership becomes critical. TGW route tables belong to the TGW owner account, and their deletion—even accidental—can disrupt multiple attachments silently. Without documentation or clear account boundaries, developers in spoke accounts may struggle to diagnose the real cause.

If you're inheriting infrastructure or rebuilding around an existing TGW setup, always start by mapping which account owns what, confirm that route tables exist and are correctly associated, and approach service-linked role cleanup with extreme caution.

This is one of those cases where infrastructure-as-code doesn’t fail—but shared account architecture and undocumented deletions do.

Need AWS Expertise?

We'd love to help you with your AWS projects.  Feel free to reach out to us at info@pacificw.com.

Written by Aaron Rose, software engineer and technology writer at Tech-Reader.blog.