Amazon VPC attachments in Amazon VPC Transit Gateways - Amazon VPC
VPC attachment lifecycleSecurity group referencing

Amazon VPC attachments in Amazon VPC Transit Gateways

An Amazon Virtual Private Cloud (VPC) attachment to a transit gateway allows you to route traffic to and from one or more VPC subnets. When you attach a VPC to a transit gateway, you must specify one subnet from each Availability Zone to be used by the transit gateway to route traffic. Specifying one subnet from an Availability Zone enables traffic to reach resources in every subnet in that Availability Zone.

Limits

  • When you attach a VPC to a transit gateway, any resources in Availability Zones where there is no transit gateway attachment cannot reach the transit gateway. If there is a route to the transit gateway in a subnet route table, traffic is forwarded to the transit gateway only when the transit gateway has an attachment in a subnet in the same Availability Zone.

  • A transit gateway does not support DNS resolution for custom DNS names of attached VPCs set up using private hosted zones in Amazon Route 53. To configure name resolution for private hosted zones for all VPCs attached to a transit gateway, see Centralized DNS management of hybrid cloud with Amazon Route 53 and AWS Transit Gateway.

  • A transit gateway doesn't support routing between VPCs with identical CIDRs. If you attach a VPC to a transit gateway and its CIDR is identical to the CIDR of another VPC that's already attached to the transit gateway, the routes for the newly attached VPC aren't propagated to the transit gateway route table.

  • You can't create an attachment for a VPC subnet that resides in a Local Zone. However, you can configure your network so that subnets in the Local Zone can connect to a transit gateway through the parent Availability Zone. For more information, see Connect Local Zone subnets to a transit gateway.

  • You can't create a transit gateway attachment using IPv6-only subnets. Transit gateway attachment subnets must also support IPv4 addresses.

  • A transit gateway must have at least one VPC attachment before that transit gateway can be added to a route table.

VPC attachment lifecycle

A VPC attachment goes through various stages, starting when the request is initiated. At each stage, there may be actions that you can take, and at the end of its lifecycle, the VPC attachment remains visible in the Amazon Virtual Private Cloud Console and in API or command line output, for a period of time.

The following diagram shows the states an attachment can go through in a single account configuration, or a cross-account configuration that has Auto accept shared attachments turned on.

VPC attachment lifecycle

  • Pending: A request for a VPC attachment has been initiated and is in the provisioning process. At this stage, the attachment can fail, or can go to available.

  • Failing: A request for a VPC attachment is failing. At this stage, the VPC attachment goes to failed.

  • Failed: The request for the VPC attachment has failed. While in this state, it cannot be deleted. The failed VPC attachment remains visible for 2 hours, and then is no longer visible.

  • Available: The VPC attachment is available, and traffic can flow between the VPC and the transit gateway. At this stage, the attachment can go to modifying, or go to deleting.

  • Deleting: A VPC attachment that is in the process of being deleted. At this stage, the attachment can go to deleted.

  • Deleted: An available VPC attachment has been deleted. While in this state, the VPC attachment cannot be modified. The VPC attachment remains visible for 2 hours, and then is no longer visible.

  • Modifying: A request has been made to modify the properties of the VPC attachment. At this stage, the attachment can go to available, or go to rolling back.

  • Rolling back: The VPC attachment modification request cannot be completed, and the system is undoing any changes that were made. At this stage, the attachment can go to available.

The following diagram shows the states an attachment can go through in a cross-account configuration that has Auto accept shared attachments turned off.

Cross-account VPC attachment lifecycle that has Auto accept shared attachments turned off

  • Pending-acceptance: The VPC attachment request is awaiting acceptance. At this stage, the attachment can go to pending, to rejecting, or to deleting.

  • Rejecting: A VPC attachment that is in the process of being rejected. At this stage, the attachment can go to rejected.

  • Rejected: A pending acceptance VPC attachment has been rejected. While in this state, the VPC attachment cannot be modified. The VPC attachment remains visible for 2 hours, and then is no longer visible.

  • Pending: The VPC attachment has been accepted and is in the provisioning process. At this stage, the attachment can fail, or can go to available.

  • Failing: A request for a VPC attachment is failing. At this stage, the VPC attachment goes to failed.

  • Failed: The request for the VPC attachment has failed. While in this state, it cannot be deleted. The failed VPC attachment remains visible for 2 hours, and then is no longer visible.

  • Available: The VPC attachment is available, and traffic can flow between the VPC and the transit gateway. At this stage, the attachment can go to modifying, or go to deleting.

  • Deleting: A VPC attachment that is in the process of being deleted. At this stage, the attachment can go to deleted.

  • Deleted: An available or pending acceptance VPC attachment has been deleted. While in this state, the VPC attachment cannot be modified. The VPC attachment remains visible 2 hours, and then is no longer visible.

  • Modifying: A request has been made to modify the properties of the VPC attachment. At this stage, the attachment can go to available, or go to rolling back.

  • Rolling back: The VPC attachment modification request cannot be completed, and the system is undoing any changes that were made. At this stage, the attachment can go to available.

Security group referencing

You can use this feature to simplify security group management and control of instance-to-instance traffic across VPCs that are attached to the same transit gateway. You can cross-reference security groups in inbound rules only. Outbound security rules do not support security group referencing. There are no additional costs associated with enabling or using security group referencing.

Security group referencing support can be configured for both transit gateways and transit gateway VPC attachments and will only work if it has been enabled for both a transit gateway and its VPC attachments.

Limitations

The following limitations apply when using security group referencing with a VPC attachment.

  • Security group referencing is not supported for VPC attachments in the availability zone use1-az3.

  • Security group referencing is not supported for PrivateLink endpoints. We recommend using IP CIDR-based security rules as an alternative.

  • Security group referencing works for Elastic File System (EFS) as long as an allow all egress security group rule is configured for the EFS interfaces in the VPC.

  • For Local Zone connectivity via a transit gateway, only the following Local Zones are supported: us-east-1-atl-2a, us-east-1-dfw-2a, us-east-1-iah-2a, us-west-2-lax-1a, us-west-2-lax-1b, us-east-1-mia-2a, us-east-1-chi-2a, and us-west-2-phx-2a.

  • We recommend disabling this feature at the VPC attachment level for VPCs with subnets in unsupported Local Zones, AWS Outposts, and AWS Wavelength Zones, as it might cause service disruption.

  • If you have an inspection VPC, then security group referencing through the transit gateway does not work across AWS Gateway Load Balancer or an AWS Network Firewall.

Tasks