Amazon VPC attachments in Amazon VPC Transit Gateways - Amazon VPC
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

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.

  • The resources in a VPC attached to a transit gateway cannot access the security groups of a different VPC that is also attached to the same transit gateway.

  • 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 Amazon 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. Security group referencing will only work if it has been enabled for both a transit gateway and its VPC attachments.

Important
  • If you disable security group referencing for a transit gateway, it will be disabled on all VPC attachments.

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

  • 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, Amazon Outposts, and Amazon Wavelength Zones, as it might cause service disruption.