# Work with AWS Transit Gateway
You can work with transit gateways using the Amazon VPC console or the AWS CLI. For information about enabling and managing Encryption support for your transit gateway, see [Encryption Support for AWS Transit Gateway](tgw-encryption-support.md).
**Topics**
+ [Shared transit gateways](#transit-gateway-share)
+ [Transit gateways](tgw-transit-gateways.md)
+ [VPC attachments](tgw-vpc-attachments.md)
+ [Network function attachments](tgw-nf-fw.md)
+ [VPN attachments](tgw-vpn-attachments.md)
+ [VPN Concentrator attachments](tgw-vpn-concentrator-attachments.md)
+ [Client VPN attachments](tgw-client-vpn-attachments.md)
+ [Transit gateway attachments to a Direct Connect gateway](tgw-dcg-attachments.md)
+ [Peering attachments](tgw-peering.md)
+ [Connect attachments and Connect peers](tgw-connect.md)
+ [Transit gateway route tables](tgw-route-tables.md)
+ [Transit gateway policy tables](tgw-policy-tables.md)
+ [Multicast on transit gateways](tgw-multicast-overview.md)
+ [Flexible cost allocation](metering-policy.md)
## Shared transit gateways
You can use AWS Resource Access Manager (RAM) to share a transit gateway for VPC attachments across accounts or across your organization in AWS Organizations. RAM must be enabled and resources shared with an organization. For more information, see [Enable resource sharing with AWS Organizations](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs) in the *AWS RAM User Guide*.
### Considerations
Take the following into account when you want to share a transit gateway.
+ An AWS Site-to-Site VPN attachment must be created in the same AWS account that owns the transit gateway.
+ An attachment to a Direct Connect gateway uses a transit gateway association and can be in the same AWS account as the Direct Connect gateway, or a different one from the Direct Connect gateway.
By default, users do not have permission to create or modify AWS RAM resources. To allow users to create or modify resources and perform tasks, you must create IAM policies that grant permission to use specific resources and API actions. You then attach those policies to the IAM users or groups that require those permissions.
Only the resource owner can perform the following operations:
+ Create a resource share.
+ Update a resource share.
+ View a resource share.
+ View the resources that are shared by your account, across all resource shares.
+ View the principals with whom you are sharing your resources, across all resource shares. Viewing the principals with whom you are sharing enables you to determine who has access to your shared resources.
+ Delete a resource share.
+ Run all transit gateway, transit gateway attachment, and transit gateway route tables APIs.
You can perform the following operations on resources that are shared with you:
+ Accept, or reject a resource share invitation.
+ View a resource share.
+ View the shared resources that you can access.
+ View a list of all the principals that are sharing resources with you. You can see which resources and resource shares they have shared with you.
+ Can run the `DescribeTransitGateways` API.
+ Run the APIs that create and describe attachments, for example `CreateTransitGatewayVpcAttachment` and `DescribeTransitGatewayVpcAttachments`, in their VPCs.
+ Leave a resource share.
When a transit gateway is shared with you, you cannot create, modify, or delete its transit gateway route tables, or its transit gateway route table propagations and associations.
When you create a transit gateway, the transit gateway, is created in the Availability Zone that is mapped to your account and is independent from other accounts. When the transit gateway and the attachment entities are in different accounts, use the Availability Zone ID to uniquely and consistently identify the Availability Zone. For example, use1-az1 is an AZ ID for the us-east-1 Region and maps to the same location in every AWS account.
### Unshare a transit gateway
When the share owner unshares the transit gateway, the following rules apply:
+ The transit gateway attachment remains functional.
+ The shared account can not describe the transit gateway.
+ The transit gateway owner, and the share owner can delete the transit gateway attachment.
When a transit gateway is unshared with another AWS account, or if the AWS account that the transit gateway is shared with is removed from the organization, the transit gateway itself won't be impacted.
### Shared subnets
A VPC owner can attach a transit gateway to a shared VPC subnet. Participants cannot. The traffic from participant’s resources can use the attachments depending on the routes set up on the shared VPC subnet by the VPC owner.
For more information, see [Share your VPC with other accounts](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html) in the *Amazon VPC User Guide*.
# Transit gateways in AWS Transit Gateway
A transit gateway enables you to attach VPCs and VPN connections and route traffic between them. A transit gateway works across AWS accounts, and you can use AWS RAM to share your transit gateway with other accounts. After you share a transit gateway with another AWS account, the account owner can attach their VPCs to your transit gateway. A user from either account can delete the attachment at any time.
You can enable multicast on a transit gateway, and then create a transit gateway multicast domain that allows multicast traffic to be sent from your multicast source to multicast group members over VPC attachments that you associate with the domain.
Each VPC or VPN attachment is associated with a single route table. That route table decides the next hop for the traffic coming from that resource attachment. A route table inside the transit gateway allows for both IPv4 or IPv6 CIDRs and targets. The targets are VPCs and VPN connections. When you attach a VPC or create a VPN connection on a transit gateway, the attachment is associated with the default route table of the transit gateway.
You can create additional route tables inside the transit gateway, and change the VPC or VPN association to these route tables. This enables you to segment your network. For example, you can associate development VPCs with one route table and production VPCs with a different route table. This enables you to create isolated networks inside a transit gateway similar to virtual routing and forwarding (VRFs) in traditional networks.
Transit gateways support dynamic and static routing between attached VPCs and VPN connections. You can enable or disable route propagation for each attachment. VPN Concentrator attachments support BGP (dynamic) routing only. Transit gateway peering attachments support static routing only. You can point routes in transit gateway route tables to the peering attachment for routing traffic between the peered transit gateways.
You can optionally associate one or more IPv4 or IPv6 CIDR blocks with your transit gateway. You specify an IP address from the CIDR block when you establish a Transit Gateway Connect peer for a [Transit Gateway Connect attachment](tgw-connect.md). You can associate any public or private IP address range, except for addresses in the `169.254.0.0/16` range, and ranges that overlap with addresses for your VPC attachments and on-premises networks. For more information about IPv4 and IPv6 CIDR blocks, see [IP addressing](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html) in the *Amazon VPC User Guide*.
**Topics**
+ [Create a transit gateway](create-tgw.md)
+ [View a transit gateway](view-tgws.md)
+ [Manage transit gateway tags](tgw-tagging.md)
+ [Modify a transit gateway](tgw-modifying.md)
+ [Accept a resource share](share-accept-tgw.md)
+ [Accept a shared attachment](acccept-tgw-attach.md)
+ [Delete a transit gateway](delete-tgw.md)
+ [Encryption Support](tgw-encryption-support.md)
# Create a transit gateway in AWS Transit Gateway
When you create a transit gateway, we create a default transit gateway route table and use it as the default association route table and the default propagation route table. If you choose not to create the default transit gateway route table, you can create one later on. For more information about routes and route tables, see [Routing](how-transit-gateways-work.md#tgw-routing-overview).
**Note**
If you want to enable Encryption support on a transit gateway, you can’t enable it while creating the gateway. After you create the transit gateway, and it’s in the available state, you can then modify it to enable Encryption support. For more information, see [Encryption Support for AWS Transit Gateway](tgw-encryption-support.md).
**To create a transit gateway using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateways**.
1. Choose **Create transit gateway**.
1. For **Name tag**, optionally enter a name for the transit gateway. A name tag can make it easier to identify a specific gateway from the list of gateways. When you add a **Name tag**, a tag is created with a key of **Name** and with a value equal to the value you enter.
1. For **Description**, optionally enter a description for the transit gateway.
1. For **Amazon side Autonomous System Number (ASN)**, either leave the default value to use the default ASN or enter the private ASN for your transit gateway. This should be the ASN for the AWS side of a Border Gateway Protocol (BGP) session.
The range is 64512 to 65534 for 16-bit ASNs.
The range is 4200000000 to 4294967294 for 32-bit ASNs.
If you have a multi-Region deployment, we recommend that you use a unique ASN for each of your transit gateways.
1. For **DNS support**, select this option if you need the VPC to resolve public IPv4 DNS host names to private IPv4 addresses when queried from instances in another VPC attached to the transit gateway.
1. For **Security Group Referencing support**, enable this feature to reference a security group across VPCs attached to a transit gateway. For more information about security group referencing see [Security group referencing](tgw-vpc-attachments.md#vpc-attachment-security).
1. For **VPN ECMP support**, select this option if you need Equal Cost Multipath (ECMP) routing support between VPN tunnels. If connections advertise the same CIDRs, the traffic is distributed equally between them.
When you select this option, the advertised BGP ASN, then the BGP attributes such as the AS-path, must be the same.
**Note**
To use ECMP, you must create a VPN connection that uses dynamic routing. VPN connections that use static routing do not support ECMP.
1. For **Default route table association**, select this option to automatically associate transit gateway attachments with the default route table for the transit gateway.
1. For **Default route table propagation**, select this option to automatically propagate transit gateway attachments to the default route table for the transit gateway.
1. (Optional) To use the transit gateway as a router for multicast traffic, select **Multicast support**.
1. (Optional) In the **Configure-cross-account sharing options** section, choose whether to **Auto accept shared attachments**. If enabled, attachments are automatically accepted. Otherwise, you must accept or reject attachment requests.
For **Auto accept shared attachments**, select this option to automatically accept cross-account attachments.
1. (Optional) For **Transit gateway CIDR blocks**, specify one or more IPv4 or IPv6 CIDR blocks for your transit gateway.
You can specify a size /24 CIDR block or larger (for example, /23 or /22) for IPv4, or a size /64 CIDR block or larger (for example, /63 or /62) for IPv6. You can associate any public or private IP address range, except for addresses in the 169.254.0.0/16 range, and ranges that overlap with the addresses for your VPC attachments and on-premises networks.
**Note**
Transit gateway CIDR blocks are used if you are configuring Connect (GRE) attachments, PrivateIP VPNs, or Client VPN attachments. Transit Gateway assigns IPs for the Tunnel endpoints (GRE/PrivateIP VPN) and Client VPN attachments from this range.
1. Choose **Create transit gateway**.
**To create a transit gateway using the AWS CLI**
Use the [create-transit-gateway](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-transit-gateway.html) command.
# View transit gateway information in AWS Transit Gateway
View any of your transit gateways.
**To view a transit gateway using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateways**. Details for the transit gateway are displayed below the list of gateways on the page.
**To view a transit gateway using the AWS CLI**
Use the [describe-transit-gateways](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-transit-gateways.html) command.
# Manage transit gateway tags in AWS Transit Gateway
Add tags to your resources to help organize and identify them, such as by purpose, owner, or environment. You can add multiple tags to each transit gateway. Tag keys must be unique for each transit gateway. If you add a tag with a key that is already associated with the transit gateway, it updates the value of that tag. For more information, see [Tagging your Amazon EC2 Resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html).
**Add tags to a transit gateway using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateways**.
1. Choose the transit gateway that you want to add or edit tags for.
1. Choose the **Tags** tab in the lower part of the page.
1. Choose **Manage tags**.
1. Choose **Add new tag**.
1. Enter a **Key** and **Value** for the tag.
1. Choose **Save**.
# Modify a transit gateway in AWS Transit Gateway
You can modify the configuration options for a transit gateway. When you modify a transit gateway, any existing transit gateway attachments don't experience any service interruptions.
You cannot modify a transit gateway that has been shared with you.
You cannot remove a CIDR block for the transit gateway if any of the IP addresses are currently used for a [Connect peer](tgw-connect.md).
**Note**
Transit gateways that have Encryption Support enabled can be attached to VPCs with Encryption Controls in monitor or Enforce mode, or to VPCs that don’t have Encryption Controls enabled. VPCs that have Encryption Controls in Enforce mode can ONLY be attached to Transit Gateways that have Encryption Support enabled.
For more detailed information, see [Encryption Support for AWS Transit Gateway](tgw-encryption-support.md).
**To modify a transit gateway**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateways**.
1. Choose the transit gateway to modify.
1. Choose **Actions**, **Modify transit gateway**.
1. Modify the options as needed, and choose **Modify transit gateway**.
**To modify your transit gateway using the AWS CLI**
Use the [modify-transit-gateway](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-transit-gateway.html) command.
# Accept an AWS Transit Gateway resource share using the AWS Resource Access Manager console
If you were added to a resource share, you receive an invitation to join the resource share. You must accept the resource share through the AWS Resource Access Manager (AWS RAM) console before you can access the shared resources.
**To accept a resource share**
1. Open the AWS RAM console at [https://console.aws.amazon.com/ram/](https://console.aws.amazon.com/ram/).
1. In the navigation pane, choose **Shared with me**, **Resource shares**.
1. Select the resource share.
1. Choose **Accept resource share**.
1. To view the shared transit gateway, open the **Transit Gateways** page in the Amazon VPC console.
# Accept a shared attachment in AWS Transit Gateway
If you didn't enable the **Auto accept shared attachments** functionality when you created your transit gateway, you must manually accept cross-account (shared) attachment using either the Amazon VPC Console or the AWS CLI.
**To manually accept a shared attachment**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Attachments**.
1. Select the transit gateway attachment that's pending acceptance.
1. Choose **Actions**, **Accept transit gateway attachment**.
**To accept a shared attachment using the AWS CLI**
Use the [accept-transit-gateway-vpc-attachment](https://docs.aws.amazon.com/cli/latest/reference/ec2/accept-transit-gateway-vpc-attachment.html) command.
# Delete a transit gateway in AWS Transit Gateway
You can't delete a transit gateway with existing attachments. You need to delete all attachments before you can delete a transit gateway.
**To delete a transit gateway using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Choose the transit gateway to delete.
1. Choose **Actions**, **Delete transit gateway**. Enter **delete** and choose **Delete** to confirm the deletion.
**To delete a transit gateway using the AWS CLI**
Use the [delete-transit-gateway](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-transit-gateway.html) command.
# Encryption Support for AWS Transit Gateway
Encryption Controls allows you to audit the encryption status of the traffic flows in your VPC and then enforce encryption-in-transit for all traffic within the VPC. When VPC Encryption Control is in enforce mode, all Elastic Network Interfaces (ENI) in that VPC will be restricted to attach only to AWS Nitro encryption capable instances; and only AWS services that encrypt data in transit will be allowed to attach to Encryption Controls enforced VPC. For more information on VPC Encryption Controls, please refer to this [documentation](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-encryption-controls.html).
## Transit Gateway Encryption Support and VPC Encryption Control
Encryption Support on Transit Gateway allows you to enforce encryption-in-transit for traffic between VPCs attached to a Transit Gateway. You will need to manually activate Encryption Support on the Transit Gateway using the [modify-transit-gateway](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-transit-gateway.html) command to encrypt traffic between the VPCs. Once enabled, all traffic will traverse 100% encrypted links between VPCs that are in Enforce mode (without exclusions) through the Transit Gateway. You can also connect VPCs that don’t have Encryption Controls turned on, or are in Monitor mode through a Transit Gateway that has Encryption Support enabled. In this scenario Transit Gateway is guaranteed to encrypt traffic up to the Transit Gateway attachment in the VPC not running in enforce mode. Beyond that, it depends on the instance the traffic is being sent to in the VPC not running in enforce mode.
You can only add encryption support to an existing transit gateway and not while you're creating one. As the Transit Gateway transitions to Encryption Support Enabled state, there will be no downtime on the Transit Gateway or the attachments. The migration is seamless and transparent with no traffic being dropped. For the steps to modify a transit gateway to add Encryption Support, see [Modify a transit gateway](tgw-modifying.md#tgw-modifying.title).
### Requirements
Before enabling encryption support on a transit gateway, ensure that:
+ The transit gateway doesn't have Connect attachments
+ The transit gateway doesn't have Peering attachments
+ The transit gateway doesn't have Network Firewall attachments
+ The transit gateway doesn't have VPN Concentrator attachments
+ The transit gateway doesn't have security group references enabled
+ The transit gateway doesn't have Multicast features enabled
### Encryption Support states
A transit gateway can have one of the following encryption states:
+ **enabling** - The transit gateway is in the process of enabling encryption support. This process can take up to 14 days to complete.
+ **enabled** - Encryption support is enabled on the transit gateway. You can create VPC attachments with Encryption Control enforced.
+ **disabling** - The transit gateway is in the process of disabling Encryption support.
+ **disabled** - Encryption support is disabled on the transit gateway.
### Transit Gateway attachment rules
When a transit gateway has Encryption support enabled, the following attachment rules apply:
+ When the transit gateway encryption state is **enabling** or **disabling**, you can create Direct Connect attachments, VPN attachments, and VPC attachment not in Encryption Control enforced or enforcing mode.
+ When the transit gateway encryption state is **enabled**, you can create VPC, Direct Connect attachments, VPN attachments, and VPC attachments in any Encryption Control mode.
+ When the transit gateway encryption state is **disabling**, you cannot create new VPC attachments with Encryption control enforced.
+ Connect attachments, peering attachments, security group references, and multicast features are not supported with Encryption Support.
Attempting to create incompatible attachments will fail with an API error.
# Amazon VPC attachments in AWS Transit Gateway
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. The specified subnets serve as the entry and exit points for transit gateway traffic. Traffic can only reach resources in other subnets within the same Availability Zone if the transit gateway attachment subnets have appropriate routes configured in their route tables pointing to the target subnets.
**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.
**Note**
Within Availability Zones that do have transit gateway attachments, traffic is only forwarded to the transit gateway from the specific subnets that are associated with the attachment. 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 and the attachment subnet's route table contains appropriate routes to the traffic's intended destination within the VPC.
+ 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](https://aws.amazon.com/blogs/networking-and-content-delivery/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, or if a CIDR in a range overlaps a CIDR in an attached VPC. If you attach a VPC to a transit gateway and its CIDR is identical to, or overlaps with, 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](https://docs.aws.amazon.com/vpc/latest/userguide/Extend_VPCs.html#connect-local-zone-tgw).
+ 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.
## Route table requirements for VPC attachments
Transit gateway VPC attachments require specific route table configurations to function properly:
+ **Attachment subnet route tables**: The subnets associated with the transit gateway attachment must have route table entries for any destinations within the VPC that need to be reachable via the transit gateway. This includes routes to other subnets, internet gateways, NAT gateways, and VPC endpoints.
+ **Target subnet route tables**: Subnets containing resources that need to communicate through the transit gateway must have routes pointing back to the transit gateway for return traffic to external destinations.
+ **Local VPC traffic**: Transit gateway attachment does not automatically enable communication between subnets within the same VPC. Standard VPC routing rules apply, and the local route (VPC CIDR) must be present in route tables for intra-VPC communication.
**Note**
Having routes configured in non-attachment subnets within the same Availability Zone does not enable traffic flow. Only the specific subnets associated with the transit gateway attachment can serve as entry/exit points for transit gateway traffic.
## 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\]](http://docs.aws.amazon.com/vpc/latest/tgw/images/vpc-attachment-lifecycle.png)
+ **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\]](http://docs.aws.amazon.com/vpc/latest/tgw/images/vpc-attachment-lifecycle-cross-account.png)
+ **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`.
## Appliance mode
If you plan to configure a stateful network appliance in your VPC, you can enable appliance mode support for the VPC attachment in which the appliance is located when you create an attachment. This ensures that AWS Transit Gateway uses the same Availability Zone for that VPC attachment for the lifetime of the flow of traffic between a source and destination. It also allows a transit gateway to send traffic to any Availability Zone in the VPC as long as there is a subnet association in that zone. While appliance mode is only supported on VPC attachments, the network flow can come from any other transit gateway attachment type, including VPC, VPN, and Connect attachments. Appliance mode also works for network flows that have sources and destinations across different AWS Regions. Network flows can potentially be rebalanced across different Availability Zones if you don't initially enable appliance mode but later edit the attachment configuration to enable it. You can enable or disable appliance mode using either the console or the command line or API.
Appliance mode in AWS Transit Gateway optimizes traffic routing by considering the source and destination Availability Zones when determining the path through an appliance mode VPC. This approach enhances efficiency and reduces latency. The behavior varies depending on the specific configuration and traffic patterns. The following are example scenarios.
### Scenario 1: Intra-Availability Zone Traffic Routing via Appliance VPC
When traffic flows from source Availability Zone us-east-1a to destination Availability Zone us-east-1a, with Appliance Mode VPC attachments in both us-east-1a and us-east-1b, Transit Gateway selects a network interface from us-east-1a within the appliance VPC. This Availability Zone is maintained for the entire duration of the traffic flow between source and destination.
### Scenario 2: Inter-Availability Zone Traffic Routing via Appliance VPC
For traffic flowing from source Availability Zone us-east-1a to destination Availability Zone us-east-1b, with Appliance Mode VPC attachments in both us-east-1a and us-east-1b, Transit Gateway uses a flow hash algorithm to select either us-east-1a or us-east-1b in the appliance VPC. The chosen Availability Zone is used consistently for the lifetime of the flow.
### Scenario 3: Routing traffic through an appliance VPC without Availability Zone data
When traffic originates from source Availability Zone us-east-1a to a destination without Availability Zone information (e.g., internet-bound traffic), with Appliance Mode VPC attachments in both us-east-1a and us-east-1b, Transit Gateway selects a network interface from us-east-1a within the appliance VPC.
### Scenario 4: Routing traffic through an appliance VPC in an Availability Zone distinct from either the source or destination
When traffic flows from source Availability Zone us-east-1a to destination Availability Zone us-east-1b, with Appliance Mode VPC attachments in different Availability Zone example us-east-1c and us-east-1d, Transit Gateway uses a flow hash algorithm to select either us-east-1c or us-east-1d in the appliance VPC. The chosen Availability Zone is used consistently for the lifetime of the flow.
**Note**
Appliance mode is only supported for VPC attachments. Ensure that route propagation is enabled for a route table associated with an appliance VPC attachment.
## 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 across transit gateway peering connections. Both VPCs must be attached to the same transit gateway.
+ 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.
**Topics**
+ [Route table requirements for VPC attachments](#vpc-attachment-routing-requirements)
+ [VPC attachment lifecycle](#vpc-attachment-lifecycle)
+ [Appliance mode](#tgw-appliancemode)
+ [Security group referencing](#vpc-attachment-security)
+ [Create a VPC attachment](create-vpc-attachment.md)
+ [Modify a VPC attachment](modify-vpc-attachment.md)
+ [Modify VPC attachment tags](modify-vpc-attachment-tag.md)
+ [View a VPC attachment](view-vpc-attachment.md)
+ [Delete a VPC attachment](delete-vpc-attachment.md)
+ [Update security group inbound rules](tgw-sg-updates-update.md)
+ [Identify referenced security groups](tgw-sg-updates-identify.md)
+ [Remove stale security group rules](tgw-sg-updates-stale.md)
+ [Troubleshoot VPC attachments](transit-gateway-vpc-attach-troubleshooting.md)
# Create a VPC attachment in AWS Transit Gateway
**To create a VPC attachment using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Attachments**.
1. Choose **Create transit gateway attachment**.
1. For **Name tag**, optionally enter a name for the transit gateway attachment.
1. For **Transit gateway ID**, choose the transit gateway for the attachment. You can choose a transit gateway that you own or a transit gateway that was shared with you.
1. For **Attachment type**, choose **VPC**.
1. Choose whether to enable **DNS Support**, **IPv6 Support** and **Appliance mode support**.
If appliance mode is chosen, traffic flow between a source and destination uses the same Availability Zone for the VPC attachment for the lifetime of that flow.
1. Choose whether to enable **Security Group Referencing support**. Enable this feature to reference a security group across VPCs attached to a transit gateway. For more information about security group referencing, see [Security group referencing](tgw-vpc-attachments.md#vpc-attachment-security).
1. Choose whether to enable **IPv6 Support**.
1. For **VPC ID**, choose the VPC to attach to the transit gateway.
This VPC must have at least one subnet associated with it.
1. For **Subnet IDs**, select one subnet for each Availability Zone to be used by the transit gateway to route traffic. You must select at least one subnet. You can select only one subnet per Availability Zone.
1. Choose **Create transit gateway attachment**.
**To create a VPC attachment using the AWS CLI**
Use the [create-transit-gateway-vpc-attachment](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-transit-gateway-vpc-attachment.html) command.
# Modify a VPC attachment in AWS Transit Gateway
**To modify your VPC attachments using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Attachments**.
1. Select the VPC attachment, and then choose **Actions**, **Modify transit gateway attachment**.
1. Enable or disable any of the following:
+ **DNS support**
+ **IPv6 support**
+ **Appliance mode support**
1. To add or remove a subnet from the attachment, choose or clear the checkbox by the **Subnet ID** you want to add or remove.
**Note**
Adding or modifying a VPC attachment subnet might impact data traffic while the attachment is in a modifying state.
1. To be able to reference a security group across VPCs attached to a transit gateway, select **Security Group Referencing support**. For more information about security group referencing, see [Security group referencing](tgw-vpc-attachments.md#vpc-attachment-security).
**Note**
If you disable security group referencing for an existing transit gateway, it will be disabled on all VPC attachments.
1. Choose **Modify transit gateway attachment**.
**To modify your VPC attachments using the AWS CLI**
Use the [modify-transit-gateway-vpc-attachment](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-transit-gateway-vpc-attachment.html) command.
# Modify VPC attachment tags in AWS Transit Gateway
**To modify your VPC attachment tags using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Attachments**.
1. Select the VPC attachment, and then choose **Actions**, **Manage tags**.
1. [Add a tag] Choose **Add new tag** and do the following:
+ For **Key**, enter the key name.
+ For **Value**, enter the key value.
1. [Remove a tag] Next to the tag, choose **Remove**.
1. Choose **Save**.
VPC attachment tags can only be modified using the console.
# View a VPC attachment in AWS Transit Gateway
**To view your VPC attachments using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Attachments**.
1. In the **Resource type** column, look for **VPC**. These are the VPC attachments.
1. Choose an attachment to view its details.
**To view your VPC attachments using the AWS CLI**
Use the [describe-transit-gateway-vpc-attachments](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-transit-gateway-vpc-attachments.html) command.
# Delete a VPC attachment in AWS Transit Gateway
**To delete a VPC attachment using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Attachments**.
1. Select the VPC attachment.
1. Choose **Actions**, **Delete transit gateway attachment**.
1. When prompted, enter **delete** and choose **Delete**.
**To delete a VPC attachment using the AWS CLI**
Use the [delete-transit-gateway-vpc-attachment](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-transit-gateway-vpc-attachment.html) command.
# Update AWS Transit Gateway security group inbound rules
You can update any of the inbound security group rules associated with a transit gateway. You can update security group rules using either the Amazon VPC Console console or by using the command-line or API. For more information about security group referencing, see [Security group referencing](tgw-vpc-attachments.md#vpc-attachment-security).
**To update your security group rules using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Security groups**.
1. Select the security group, and choose **Actions**, **Edit inbound rules** to modify the inbound rules.
1. To add a rule, choose **Add rule** and specify the type, protocol, and port range. For **Source** (inbound rule), enter the ID of the security group in the VPC connected to the transit gateway.
**Note**
Security groups in a VPC connected to the transit gateway are not automatically displayed.
1. To edit an existing rule, change its values (for example, the source or the description).
1. To delete a rule, choose **Delete** next to the rule.
1. Choose **Save rules**.
**To update inbound rules using the command line**
+ [authorize-security-group-ingress](https://docs.aws.amazon.com/cli/latest/reference/ec2/authorize-security-group-ingress.html) (AWS CLI)
+ [Grant-EC2SecurityGroupIngress](https://docs.aws.amazon.com/powershell/latest/reference/items/Grant-EC2SecurityGroupIngress.html) (AWS Tools for Windows PowerShell)
+ [Revoke-EC2SecurityGroupIngress](https://docs.aws.amazon.com/powershell/latest/reference/items/Revoke-EC2SecurityGroupIngress.html) (AWS Tools for Windows PowerShell)
+ [revoke-security-group-ingress](https://docs.aws.amazon.com/cli/latest/reference/ec2/revoke-security-group-ingress.html) (AWS CLI)
# Identify AWS Transit Gateway referenced security groups
To determine if your security group is being referenced in the rules of a security group in a VPC attached to the same transit gateway, use one of the following commands.
+ [describe-security-group-references](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-security-group-references.html) (AWS CLI)
+ [Get-EC2SecurityGroupReference](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2SecurityGroupReference.html) (AWS Tools for Windows PowerShell)
# Remove stale AWS Transit Gateway security group rules
A stale security group rule is a rule that references a deleted security group in the same VPC or in VPC attached to the same transit gateway. When a security group rule becomes stale, it's not automatically removed from your security group—you must manually remove it.
You can view and delete the stale security group rules for a VPC using the Amazon VPC console.
**To view and delete stale security group rules**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Security groups**.
1. Choose **Actions**, **Manage stale rules**.
1. For **VPC**, choose the VPC with the stale rules.
1. Choose **Edit**.
1. Choose the **Delete** button next to the rule that you want to delete. Choose **Preview changes**, **Save rules**.
**To describe your stale security group rules using the command line**
+ [describe-stale-security-groups](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-stale-security-groups.html) (AWS CLI)
+ [Get-EC2StaleSecurityGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2StaleSecurityGroup.html) (AWS Tools for Windows PowerShell)
After you've identified the stale security group rules, you can delete them using the [revoke-security-group-ingress](https://docs.aws.amazon.com/cli/latest/reference/ec2/revoke-security-group-ingress.html) or [revoke-security-group-egress](https://docs.aws.amazon.com/cli/latest/reference/ec2/revoke-security-group-egress.html) commands.
# Troubleshoot AWS Transit Gateway VPC attachment creation
The following topic can help you troubleshoot problems that you might have when you create a VPC attachment.
**Problem**
The VPC attachment failed.
**Cause**
The cause might be one of the following:
1. The user that is creating the VPC attachment does not have correct permissions to create service-linked role.
1. There is a throttling issue because of too many IAM requests, for example you are using CloudFormation to create permissions and roles.
1. The account has the service-linked role, and the service-linked role has been modified.
1. The transit gateway is not in the `available` state.
**Solution**
Depending on the cause, try the following:
1. Verify that the user has the correct permissions to create service-linked roles. For more information, see [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html#service-linked-role-permissions) in the *IAM User Guide*. After the user has the permissions, create the VPC attachment.
1. Create the VPC attachment manually. For more information, see [Create a VPC attachment in AWS Transit Gateway](create-vpc-attachment.md).
1. Verify that the service-linked role has the correct permissions. For more information, see [Transit gateway service-linked role](service-linked-roles.md#tgw-service-linked-roles).
1. Verify that the transit gateway is in the `available` state. For more information, see [View transit gateway information in AWS Transit Gateway](view-tgws.md).
# AWS Transit Gateway network function attachments
You can create a network function attachment to connect your transit gateway directly to AWS Network Firewall. This eliminates the need to create and manage inspection VPCs.
With a firewall attachment, AWS automatically provisions and manages all the necessary resources behind the scenes. You'll see a new transit gateway attachment rather than individual firewall endpoints. This simplifies the process of implementing centralized network traffic inspection.
Before you can use a firewall attachment, you must first create the attachment in AWS Network Firewall. For the steps to create the attachment, see [Getting Started with AWS Network Firewall Management](https://docs.aws.amazon.com/network-firewall/latest/developerguide/getting-started.html) in the *AWS Network Firewall Developer Guide* After the firewall is created, you can view the attachment in Transit Gateway console under the **Attachments** section. The attachment will be listed with a type of **Network function**.
**Topics**
+ [Accept or reject a transit gateway network function attachment](accept-reject-firewall-attachment.md)
+ [View network function attachments](view-nf-attachment-nm.md)
+ [Route traffic through a transit gateway network function attachment](route-traffic-nf-attachment.md)
# Accept or reject an AWS Transit Gateway network function attachment
You can use either the Amazon VPC console or the AWS Network Firewall CLI or API to accept or reject a transit gateway network function attachment, including Network Firewall attachments. If you are the owner of a transit gateway and someone has created a firewall attachment to your transit gateway from another account, you need to accept or reject the attachment request.
To accept or reject a network function attachment using the Network Firewall CLI, see the `AcceptNetworkFirewallTransitGatewayAttachment` or `RejectNetworkFirewallTransitGatewayAttachment` APIs in the [https://docs.aws.amazon.com/network-firewall/latest/APIReference/Welcome.html](https://docs.aws.amazon.com/network-firewall/latest/APIReference/Welcome.html).
## Accept or reject a network function attachment using the console
Use the Amazon VPC console to accept or reject a transit gateway network function attachment.
**To accept or reject a network function attachment using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Transit Gateways**.
1. Choose **Transit gateway attachments**.
1. Select the attachment with a state of **Pending acceptance** and a type of **Network function**.
1. Choose **Actions**, and then choose either **Accept attachment** or **Reject attachment**.
1. In the confirmation dialog box, choose **Accept** or **Reject**.
If you accept the attachment, it becomes active and the firewall can inspect traffic. If you reject the attachment, it enters a rejected state and will eventually be deleted.
# View AWS Transit Gateway network function attachments
You can view your network function attachments, including your AWS Network Firewall attachments, using either Amazon VPC Console or the Network Manager console to get a visual representation of your network topology.
## View a network function attachment using the Network Manager console
You can view a network function attachments using the Network Manager console.
**To view firewall attachments in Network Manager**
1. Open the Network Manager console at [https://console.aws.amazon.com/networkmanager/home/](https://console.aws.amazon.com/networkmanager/home).
1. Create a global network in Network Manager if you don't already have one.
1. Register your transit gateway with Network Manager.
1. Under **Global Networks**, choose the global network where the attachment is located.
1. In the navigation pane, choose **Transit gateways.**
1. Choose the transit gateway that you want to view attachments for.
1. Choose **Topology tree** view. Network Firewall attachments appear with a network function icon.
1. To view details about a specific firewall attachment, select the transit gateway in the topology view, then select the **Network function** tab.
The Network Manager console provides detailed information about your firewall attachments, including their status, associated transit gateway, and Availability Zones.
## View a network function attachment using the Amazon VPC Console console
Use the VPC console to see a list of your transit gateway attachment types.
**To view transit gateway attachment types using the VPC console**
+ See [View a VPC attachment](view-vpc-attachment.md).
# Route traffic through an AWS Transit Gateway network function attachment
After creating a network function attachment, you need to update your transit gateway route tables to send traffic through the firewall for inspection using either the Amazon VPC Console or by using the CLI. For the steps to update a transit gateway route table association, see [Associate a transit gateway route table](associate-tgw-route-table.md).
## Route traffic through a firewall attachment using the console
Use the Amazon VPC Console console to route traffic through a transit gateway network function attachment.
**To route traffic through a network function attachment using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Transit Gateways**.
1. Choose **Transit gateway route tables**.
1. Select the route table you want to modify.
1. Choose **Actions**, and then choose **Create static route**.
1. For **CIDR**, enter the destination CIDR block for the route.
1. For **Attachment**, select the network function attachment. For example, this might be an AWS Network Firewall attachment.
1. Choose **Create static route**.
**Note**
Only static routes are supported.
Traffic matching the CIDR block in your route table will now be sent to the firewall attachment for inspection before being forwarded to its final destination.
## Route traffic through a network function attachment using the CLI or API
Use the command line or API to route a transit gateway network function attachment.
**To route traffic through a network function attachment using the command line or API**
+ Use [https://docs.aws.amazon.com/cli/latest/reference/create-transit-gateway-route/create-transit-gateway-route.html](https://docs.aws.amazon.com/cli/latest/reference/create-transit-gateway-route/create-transit-gateway-route.html).
For example, the request might be to route a network firewall attachment:
```
aws ec2 create-transit-gateway-route \
--transit-gateway-route-table-id tgw-rtb-0123456789abcdef0 \
--destination-cidr-block 0.0.0.0/0 \
--transit-gateway-attachment-id tgw-attach-0123456789abcdef0
```
The output then returns:
```
{
"Route": {
"DestinationCidrBlock": "0.0.0.0/0",
"TransitGatewayAttachments": [
{
"ResourceId": "network-firewall",
"TransitGatewayAttachmentId": "tgw-attach-0123456789abcdef0",
"ResourceType": "network-function"
}
],
"Type": "static",
"State": "active"
}
}
```
Traffic matching the CIDR block in your route table will now be sent to the firewall attachment for inspection before being forwarded to its final destination.
# AWS Site-to-Site VPN attachments in AWS Transit Gateway
You can connect a Site-to-Site VPN attachment to a transit gateway in AWS Transit Gateway, allowing you to connect your VPCs and on-premises networks. Both dynamic and static routes are supported, as well as IPv4 and IPv6.
**Requirements**
+ Attaching a VPN connection to your transit gateway requires that you specify the VPN customer gateway, which have specific device requirements. Before creating a Site-to-Site VPN attachment, review the customer gateway requirements to ensure that your gateway is set up correctly. For more information about these requirements, including example gateway configuration files, see [Requirements for your Site-to-Site VPN customer gateway device](https://docs.aws.amazon.com/vpn/latest/s2svpn/CGRequirements.html) in the *AWS Site-to-Site VPN User Guide*.
+ For static VPNs, you'll also need to first add the static routes to the transit gateway route table. Static routes in a transit gateway route table that target a VPN attachment are not filtered by the Site-to-Site VPN as this might allow unintended outbound traffic flow when using a BGP-based VPN. For the steps to add a static route to a transit gateway route table, see [Create a static route](tgw-create-static-route.md).
You can create, view, or delete a transit gateway Site-to-Site VPN attachment using either the Amazon VPC console or using the AWS CLI.
**Topics**
+ [Create a transit gateway attachment to a VPN](create-vpn-attachment.md)
+ [View a VPN attachment](view-vpn-attachment.md)
+ [Delete a VPN attachment](delete-vpn-attachment.md)
# Create a transit gateway attachment to a VPN in AWS Transit Gateway
**To create a VPN attachment using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Attachments**.
1. Choose **Create transit gateway attachment**.
1. For **Transit gateway ID**, choose the transit gateway for the attachment. You can choose a transit gateway that you own.
1. For **Attachment type**, choose **VPN**.
1. For **Customer Gateway**, do one of the following:
+ To use an existing customer gateway, choose **Existing**, and then select the gateway to use.
If your customer gateway is behind a network address translation (NAT) device that's enabled for NAT traversal (NAT-T), use the public IP address of your NAT device, and adjust your firewall rules to unblock UDP port 4500.
+ To create a customer gateway, choose **New**, then for **IP Address**, type a static public IP address and **BGP ASN**.
For **Routing options**, choose whether to use **Dynamic** or **Static**. For more information, see [Site-to-Site VPN Routing Options](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNRoutingTypes.html) in the *AWS Site-to-Site VPN User Guide*.
1. For **Tunnel Options**, enter the CIDR ranges and pre-shared keys for your tunnel. For more information, see [Site-to-Site VPN architectures](https://docs.aws.amazon.com/vpn/latest/s2svpn/site-site-architectures.html).
1. Choose **Create transit gateway attachment**.
**To create a VPN attachment using the AWS CLI**
Use the [create-vpn-connection](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-vpn-connection.html) command.
# View a VPN attachment in AWS Transit Gateway
**To view your VPN attachments using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Attachments**.
1. In the **Resource type** column, look for **VPN**. These are the VPN attachments.
1. Choose an attachment to view its details or to add tags.
**To view your VPN attachments using the AWS CLI**
Use the [describe-transit-gateway-attachments](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-transit-gateway-attachments.html) command.
# Delete a VPN attachment in AWS Transit Gateway
**To delete a VPN attachment using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Attachments**.
1. Select the VPN attachment.
1. Choose the resource ID of the VPN connection to navigate to the **VPN Connections** page.
1. Choose **Actions**, **Delete**.
1. When prompted for confirmation, choose **Delete**.
**To delete a VPN attachment using the AWS CLI**
Use the [delete-vpn-connection](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-vpn-connection.html) command.
# VPN Concentrator attachments in AWS Transit Gateway
AWS Site-to-Site VPN Concentrator is a new feature that simplifies multi-site connectivity for distributed enterprises. VPN Concentrator is suitable for customers who need to connect 25\$1 remote sites to AWS, with each site needing low bandwidth (under 100 Mbps).
## How VPN Concentrator works
A VPN Concentrator appears as a single attachment on your transit gateway, but can host multiple Site-to-Site VPN connections.
Traffic from all VPN connections on the Concentrator is routed through the same transit gateway attachment, allowing you to apply consistent routing policies and security rules across all connected sites. The Concentrator integrates seamlessly with transit gateway route tables, enabling you to control traffic flow between your remote sites and other attachments such as VPCs, other VPN connections, and peering connections.
## Benefits of VPN Concentrator
+ **Cost optimization**: Reduce costs by consolidating multiple low-bandwidth VPN connections onto a single transit gateway attachment, especially beneficial when individual sites don't require full VPN attachment capacity.
+ **Simplified management**: Manage multiple remote site connections through a unified attachment while maintaining individual VPN connection control and monitoring.
+ **Consistent routing**: Apply unified routing policies across all connected sites through a single transit gateway route table association.
+ **Scalable architecture**: Connect up to 100 remote sites using a single Concentrator, with support for up to 5 Concentrators per transit gateway.
+ **Standard VPN features**: Each VPN connection supports the same security, monitoring, and routing capabilities as standard Site-to-Site VPN connections.
**Requirements and limitations**
+ **BGP routing only**: VPN Concentrator supports BGP (dynamic) routing only. Static routing is not supported at launch.
+ **Customer gateway requirements**: Each remote site requires a customer gateway that supports BGP routing. Before creating VPN connections on a Concentrator, review the customer gateway requirements in [Requirements for your Site-to-Site VPN customer gateway device](https://docs.aws.amazon.com/vpn/latest/s2svpn/CGRequirements.html) in the *AWS Site-to-Site VPN User Guide*.
+ **Performance considerations**: Each VPN connection on a Concentrator is designed for a maximum of 100 Mbps bandwidth. For higher bandwidth requirements, consider using standard transit gateway VPN attachments.
You can create, view, or delete a VPN Concentrator attachment using either the AWS VPC console or the AWS CLI. Individual VPN connections on the Concentrator are managed through the standard VPN connection APIs and console interfaces.
**Topics**
+ [How VPN Concentrator works](#vpn-concentrator-how-it-works)
+ [Benefits of VPN Concentrator](#vpn-concentrator-benefits)
+ [Create a VPN Concentrator attachment](create-vpn-concentrator-attachment.md)
+ [View a VPN Concentrator attachment](view-vpn-concentrator-attachment.md)
+ [Delete a VPN Concentrator attachment](delete-vpn-concentrator-attachment.md)
# Create a VPN Concentrator attachment in AWS Transit Gateway
**Prerequisites**
+ You must have an existing transit gateway in your account.
**To create a VPN Concentrator attachment using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Site-to-Site VPN Concentrators**.
1. Choose **Create Site-to-Site VPN Concentrator**.
1. (Optional) For **Name tag**, enter a name for your Site-to-Site VPN Concentrator.
1. For **Transit gateway**, select an existing transit gateway.
1. (Optional) To add additional tags, choose **Add new tag** and specify the key and value for each tag.
1. Choose **Create Site-to-Site VPN Concentrator**.
After you create the VPN Concentrator attachment, it appears in the list of attachments with a resource type of **VPN Concentrator** and an initial state of **Pending**. When the attachment is ready, the state changes to **Available**. You can then create Site-to-Site VPN connections on this Concentrator.
**To create a VPN Concentrator attachment using the AWS CLI**
Use the [create-vpn-concentrator](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-vpn-concentrator.html) command.
**To create a VPN connection on a VPN Concentrator using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Site-to-Site VPN Connections**.
1. Choose **Create VPN connection**.
1. For **Target Gateway Type**, choose **Site-to-Site VPN Concentrator**.
1. For **Site-to-Site VPN Concentrator**, choose the VPN Concentrator where you want to create the VPN connection.
1. For **Customer Gateway**, do one of the following:
+ To use an existing customer gateway, choose **Existing**, and then select the gateway to use. Ensure that the customer gateway supports BGP routing.
+ To create a customer gateway, choose **New**. For **IP Address**, enter the static public IP address for your customer gateway device. For **BGP ASN**, enter the Border Gateway Protocol (BGP) Autonomous System Number (ASN) for your customer gateway.
If your customer gateway is behind a network address translation (NAT) device that's enabled for NAT traversal (NAT-T), use the public IP address of your NAT device, and adjust your firewall rules to unblock UDP port 4500.
1. For **Routing options**, **Dynamic (requires BGP)** is automatically selected. VPN Concentrator only supports dynamic routing with BGP.
1. For **Pre-shared key storage**, select either **Standard** or **Secrets Manager**.
1. For **Tunnel bandwidth**, **Standard** is automatically selected. VPN Concentrator only supports standard tunnel bandwidth.
1. For **Tunnel inside IP version**, select either **IPv4** or **IPv6**.
1. (Optional) Select **Enable acceleration** to improve performance of VPN tunnels.
1. (Optional) For **Local IPv4 network CIDR**, provide an IPv4 CIDR range.
1. (Optional) For **Remote IPv4 network CIDR**, provide an IPv4 CIDR range.
1. For **Outside IP Address Type**, you can select either **Public IPv4** or **IPv6** address.
1. (Optional) For **Tunnel Options**, you can configure tunnel settings such as inside tunnel IP addresses and pre-shared keys. For more information, see [Site-to-Site VPN architectures](https://docs.aws.amazon.com/vpn/latest/s2svpn/site-site-architectures.html) in the *AWS Site-to-Site VPN User Guide*.
1. (Optional) To add additional tags, choose **Add new tag** and specify the key and value for each tag.
1. Choose **Create VPN connection**.
The VPN connection appears in the list of VPN connections with the VPN Concentrator ID in the **Transit Gateway ID** column and an initial state of **Pending**. When the VPN connection is ready, the state changes to **Available**.
**To create a VPN connection on a VPN Concentrator using the AWS CLI**
Use the [create-vpn-connection](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-vpn-connection.html) command and specify the VPN Concentrator ID using the `--vpn-concentrator-id` parameter.
# View a VPN Concentrator attachment in AWS Transit Gateway
**To view your VPN Concentrator attachments using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Attachments**.
1. In the **Resource type** column, look for **VPN Concentrator**. These are the VPN Concentrator attachments.
1. Choose an attachment to view its details.
**To view VPN connections on a VPN Concentrator using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Site-to-Site VPN Connections**.
1. In the list of VPN connections, identify connections that show a VPN Concentrator ID in the **Transit Gateway ID** column. These are the VPN connections hosted on VPN Concentrators.
1. Choose a VPN connection to view its details.
**To view your VPN Concentrator attachments using the AWS CLI**
Use the [describe-vpn-concentrator](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-vpn-concentrator.html) command to view VPN Concentrator details, or use the [describe-transit-gateway-attachments](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-transit-gateway-attachments.html) command with a filter for resource type `vpn-concentrator`.
**To view VPN connections on a VPN Concentrator using the AWS CLI**
Use the [describe-vpn-connections](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-vpn-connections.html) command with a filter for `vpn-concentrator-id` to view VPN connections associated with a specific Concentrator.
# Delete a VPN Concentrator attachment in AWS Transit Gateway
**Prerequisites**
+ All VPN connections on the VPN Concentrator must be deleted before you can delete the Concentrator attachment.
+ Ensure that you have updated your routing configurations to account for the removal of the VPN Concentrator and its associated VPN connections.
**To delete VPN connections on a VPN Concentrator using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Site-to-Site VPN Connections**.
1. Identify the VPN connections associated with your VPN Concentrator by looking for the VPN Concentrator ID in the **Transit Gateway ID** column.
1. Select a VPN connection that you want to delete.
1. Choose **Actions**, **Delete**.
1. When prompted for confirmation, choose **Delete**.
1. Repeat steps 4-6 for each VPN connection associated with the VPN Concentrator.
**To delete a VPN Concentrator attachment using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Attachments**.
1. Select the VPN Concentrator attachment that you want to delete. Verify that no VPN connections are associated with this Concentrator.
1. Choose **Actions**, **Delete attachment**.
1. When prompted for confirmation, choose **Delete**.
The VPN Concentrator attachment enters the **Deleting** state and will be removed from your account. This process may take a few minutes to complete.
**To delete VPN connections on a VPN Concentrator using the AWS CLI**
Use the [delete-vpn-connection](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-vpn-connection.html) command for each VPN connection associated with the VPN Concentrator.
**To delete a VPN Concentrator attachment using the AWS CLI**
Use the [delete-vpn-concentrator](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-vpn-concentrator.html) command after all VPN connections have been deleted.
# Client VPN attachments in AWS Transit Gateway
When you associate a Client VPN endpoint with a transit gateway, a Client VPN attachment is automatically created, allowing you to route traffic between your VPCs, on-premises networks, and Client VPN endpoints. AWS Transit Gateway supports cross-account Client VPN attachments, allowing accounts that the transit gateway is shared with to create their own Client VPN attachments.
After the Client VPN endpoint is associated with a transit gateway, you can view the attachment in the Transit Gateway console under **Transit gateway attachments**. The attachment will be listed with a type of **Client VPN**.
**Requirements and limitations**
+ Your transit gateway must have an assigned IPv4 or IPv6 CIDR block before you can create a Client VPN attachment.
+ Route table propagation must be enabled for Client VPN attachments to allow traffic between your Client VPN endpoint and transit gateway. See [Enable route propagation](https://docs.aws.amazon.com/vpc/latest/tgw/enable-tgw-route-propagation.html).
**Topics**
+ [Create a Client VPN attachment](create-client-vpn-attachment.md)
+ [View a Client VPN attachment](view-client-vpn-attachment.md)
+ [Delete a Client VPN attachment](delete-client-vpn-attachment.md)
+ [Accept or reject a Client VPN attachment](accept-reject-client-vpn-attachment.md)
# Create a Client VPN attachment in AWS Transit Gateway
**Prerequisites**
+ You must have an existing transit gateway in your account.
+ Your transit gateway must have an assigned IPv4 or IPv6 CIDR block.
A Client VPN attachment is automatically created when you associate a Client VPN endpoint with a transit gateway.
**To create a Client VPN attachment using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Client VPN endpoints**.
1. Choose **Create Client VPN endpoint**.
1. Select **Transit Gateway** as the association type and enter the Transit Gateway ID to use.
1. Choose **Create Client VPN endpoint**.
After you create the Client VPN attachment, it appears in the list of attachments with a resource type of **Client VPN** and an initial state of **Pending**. When the attachment is ready, the state changes to **Available**. If the transit gateway is in a different account, the attachment state is **Pending acceptance** until the transit gateway owner accepts it.
For more information about creating Client VPN endpoints, see [Getting Started with AWS Client VPN](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/cvpn-getting-started.html).
**To create a Client VPN attachment using the AWS CLI**
Use the [create-client-vpn-endpoint](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-client-vpn-endpoint.html) command.
# View a Client VPN attachment in AWS Transit Gateway
**To view your Client VPN attachments using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit gateways**.
1. Choose **Transit gateway attachments**.
1. In the **Resource type** column, look for **Client VPN**.
1. Choose an attachment to view its details.
**To view your Client VPN attachments using the AWS CLI**
Use the [describe-transit-gateway-attachments](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-transit-gateway-attachments.html) command with a filter for resource type `client-vpn`.
# Delete a Client VPN attachment in AWS Transit Gateway
**To delete a Client VPN attachment using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit gateways**.
1. Choose **Transit gateway attachments**.
1. Select the Client VPN attachment that you want to delete.
1. Choose **Actions**, **Delete transit gateway attachment**.
1. When prompted for confirmation, enter **delete** and choose **Delete**.
The Client VPN attachment enters the **Deleting** state and will be removed from your account. This process may take some time to complete.
**To delete a Client VPN attachment using the AWS CLI**
Use the [delete-transit-gateway-client-vpn-attachment](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-transit-gateway-client-vpn-attachment.html) command.
# Accept or reject a Client VPN attachment in AWS Transit Gateway
If a Client VPN endpoint in another account creates an attachment to your transit gateway, you must accept or reject the attachment request before traffic can flow.
**To accept or reject a Client VPN attachment using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit gateways**.
1. Choose **Transit gateway attachments**.
1. Select the attachment with a state of **Pending acceptance** and a type of **Client VPN**.
1. Choose **Actions**, and then choose either **Accept attachment** or **Reject attachment**.
1. In the confirmation dialog box, choose **Accept** or **Reject**.
If you accept the attachment, it becomes active and AWS Transit Gateway will begin processing traffic to and from the Client VPN endpoint. If you reject the attachment, it enters a rejected state and will eventually be deleted.
**To accept a Client VPN attachment using the AWS CLI**
Use the [accept-transit-gateway-client-vpn-attachment](https://docs.aws.amazon.com/cli/latest/reference/ec2/accept-transit-gateway-client-vpn-attachment.html) command.
**To reject a Client VPN attachment using the AWS CLI**
Use the [reject-transit-gateway-client-vpn-attachment](https://docs.aws.amazon.com/cli/latest/reference/ec2/reject-transit-gateway-client-vpn-attachment.html) command.
# Transit gateway attachments to a Direct Connect gateway in AWS Transit Gateway
Attach a transit gateway to a Direct Connect gateway using a transit virtual interface. This configuration offers the following benefits. You can:
+ Manage a single connection for multiple VPCs or VPNs that are in the same Region.
+ Advertise prefixes from on-premises to AWS and from AWS to on-premises.
The following diagram illustrates how the Direct Connect gateway enables you to create a single connection to your Direct Connect connection that all of your VPCs can use.
![\[Direct Connect Gateway Connected to Transit Gateway\]](http://docs.aws.amazon.com/vpc/latest/tgw/images/direct-connect-tgw.png)
The solution involves the following components:
+ A transit gateway.
+ A Direct Connect gateway.
+ An association between the Direct Connect gateway and the transit gateway.
+ A transit virtual interface that is attached to the Direct Connect gateway.
For information about configuring Direct Connect gateways with transit gateways, see [Transit gateway associations](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-transit-gateways.html) in the *AWS Direct Connect User Guide*.
# Transit gateway peering attachments in AWS Transit Gateway
You can peer both intra-Region and inter-Region transit gateways, and route traffic between them, which includes IPv4 and IPv6 traffic. To do this, create a peering attachment on your transit gateway, and specify a transit gateway. The peer transit gateway can either be in your account or can be from another account. You can also request a peering attachment from your own account to a transit gateway in another account.
After you create a peering attachment request, the owner of the peer transit gateway (also referred to as the *accepter transit gateway*) must accept the request. To route traffic between the transit gateways, add a static route to the transit gateway route table that points to the transit gateway peering attachment.
We recommend using unique ASNs for each peered transit gateway to take advantage of future route propagation capabilities.
Transit gateway peering does not support resolving public or private IPv4 DNS host names to private IPv4 addresses across VPCs on either side of the transit gateway peering attachment using the Amazon Route 53 Resolver in another Region. For more information about the Route 53 Resolver, see [What is Route 53 Resolver?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html) in the *Amazon Route 53 Developer Guide*.
Inter-Region gateway peering uses the same network infrastructure as VPC peering. Therefore traffic is encrypted using AES-256 encryption at the virtual network layer as it travels between Regions. Traffic is also encrypted using AES-256 encryption at the physical layer when it traverses network links that are outside of the physical control of AWS. As a result, traffic is double encrypted on network links outside the physical control of AWS. Within the same Region, traffic is encrypted at the physical layer only when it traverses network links that are outside of the physical control of AWS.
For information about which Regions support transit gateway peering attachments, see [AWS Transit Gateways FAQs](https://aws.amazon.com/transit-gateway/faqs/).
## Opt-in AWS Region considerations
You can peer transit gateways across opt-in Region boundaries. For information about these Regions, and how to opt in, see [Managing AWS Regions](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html). Take the following into consideration when you use transit gateway peering in these Regions:
+ You can peer into an opt-in Region as long as the account that accepts the peering attachment has opted into that Region.
+ Regardless of the Region opt-in status, AWS shares the following account data with the account that accepts the peering attachment:
+ AWS account ID
+ Transit gateway ID
+ Region code
+ When you delete the transit gateway attachment, the above account data is deleted.
+ We recommend that you delete the transit gateway peering attachment before you opt out of the Region. If you do not delete the peering attachment, traffic might continue to go over the attachment and you continue to incur charges. If you do not delete the attachment, you can opt back in, and then delete the attachment.
+ In general, the transit gateway has a sender pays model. By using a transit gateway peering attachment across an opt in boundary, you might incur charges in a Region accepting the attachment, including those Regions you have not opted into. For more information, see [AWS Transit Gateway Pricing](https://aws.amazon.com/transit-gateway/pricing/).
**Topics**
+ [Opt-in AWS Region considerations](#opt-in-considerations)
+ [Create a peering attachment](tgw-peering-create.md)
+ [Accept or reject a peering request](tgw-peering-accept-reject.md)
+ [Add a route to a transit gateway route table](tgw-peering-add-route.md)
+ [Delete a peering attachment](tgw-peering-delete.md)
# Create a peering attachment in AWS Transit Gateway
Before you begin, ensure that you have the ID of the transit gateway that you want to attach. If the transit gateway is in another AWS account, ensure that you have the AWS account ID of the owner of the transit gateway. After you create the peering attachment, the owner of the accepter transit gateway must accept or reject the attachment request.
**To create a peering attachment using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Attachments**.
1. Choose **Create transit gateway attachment**.
1. For **Transit gateway ID**, choose the transit gateway for the attachment. You can choose a transit gateway that you own. Transit gateways that are shared with you are not available for peering.
1. For **Attachment type**, choose **Peering Connection**.
1. Optionally enter a name tag for the attachment.
1. For **Account**, do one of the following:
+ If the transit gateway is in your account, choose **My account**.
+ If the transit gateway is in different AWS account, choose **Other account**. For **Account ID**, enter the AWS account ID.
1. For **Region**, choose the Region that the transit gateway is located in.
1. For **Transit gateway (accepter)**, enter the ID of the transit gateway that you want to attach.
1. Choose **Create transit gateway attachment**.
**To create a peering attachment using the AWS CLI**
Use the [create-transit-gateway-peering-attachment](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-transit-gateway-peering-attachment.html) command.
# Accept or reject a peering attachment request in AWS Transit Gateway
When created, a transit gateway peering attachment is automatically created in a `pendingAcceptance` state and remains in this state indefinitely until it's either accepted or rejected. To activate the peering attachment, the owner of the accepter transit gateway must accept the peering attachment request, even if both transit gateways are in the same account. Accept the peering attachment request from the Region that the accepter transit gateway is located in. Alternatively, if you reject the peering attachment, you must reject the request from the Region that the accepter transit gateway is located in.
**To accept a peering attachment request using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Attachments**.
1. Select the transit gateway peering attachment that's pending acceptance.
1. Choose **Actions**, **Accept transit gateway attachment**.
1. Add the static route to the transit gateway route table. For more information, see [Create a static route in AWS Transit Gateway](tgw-create-static-route.md).
**To reject a peering attachment request using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Attachments**.
1. Select the transit gateway peering attachment that's pending acceptance.
1. Choose **Actions**, **Reject transit gateway attachment**.
**To accept or reject a peering attachment using the AWS CLI**
Use the [accept-transit-gateway-peering-attachment](https://docs.aws.amazon.com/cli/latest/reference/ec2/accept-transit-gateway-peering-attachment.html) and [reject-transit-gateway-peering-attachment](https://docs.aws.amazon.com/cli/latest/reference/ec2/reject-transit-gateway-peering-attachment.html) commands.
# Add a route to a transit gateway route table using AWS Transit Gateway
To route traffic between the peered transit gateways, you must add a static route to the transit gateway route table that points to the transit gateway peering attachment. The owner of the accepter transit gateway must also add a static route to their transit gateway's route table.
**To create a static route using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Route Tables**.
1. Select the route table for which to create a route.
1. Choose **Actions**, **Create static route**.
1. On the **Create static route** page, enter the CIDR block for which to create the route. For example, specify the CIDR block of a VPC that's attached to the peer transit gateway.
1. Choose the peering attachment for the route.
1. Choose **Create static route**.
**To create a static route using the AWS CLI**
Use the [create-transit-gateway-route](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-transit-gateway-route.html) command.
**Important**
After you create the route, the transit gateway peering attachment must already be associated with the transit gateway route table. For more information, see [Associate a transit gateway route table in AWS Transit Gateway](associate-tgw-route-table.md).
# Delete a peering attachment in AWS Transit Gateway
You can delete a transit gateway peering attachment. The owner of either of the transit gateways can delete the attachment.
**To delete a peering attachment using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Attachments**.
1. Select the transit gateway peering attachment.
1. Choose **Actions**, **Delete transit gateway attachment**.
1. Enter **delete** and choose **Delete**.
**To delete a peering attachment using the AWS CLI**
Use the [delete-transit-gateway-peering-attachment](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-transit-gateway-peering-attachment.html) command.
# Connect attachments and Connect peers in AWS Transit Gateway
You can create a *Transit Gateway Connect attachment* to establish a connection between a transit gateway and third-party virtual appliances (such as SD-WAN appliances) running in a VPC. A Connect attachment supports the Generic Routing Encapsulation (GRE) tunnel protocol for high performance, and Border Gateway Protocol (BGP) for dynamic routing. After you create a Connect attachment, you can create one or more GRE tunnels (also referred to as *Transit Gateway Connect peers*) on the Connect attachment to connect the transit gateway and the third-party appliance. You establish two BGP sessions over the GRE tunnel to exchange routing information.
**Important**
A Transit Gateway Connect peer consists of two BGP peering sessions terminating on AWS-managed infrastructure. The two BGP peering sessions provide routing plane redundancy, ensuring that losing one BGP peering session does not impact your routing operation. The routing information received from both BGP sessions is accumulated for the given Connect peer. The two BGP peering sessions also protect against any AWS infrastructure operations such as routine maintenance, patching, hardware upgrades, and replacements. If your Connect peer is operating without the recommended dual BGP peering session configured for redundancy, it might experience a momentary loss of connectivity during AWS infrastructure operations. We strongly recommend that you configure both the BGP peering sessions on your Connect peer. If you have configured multiple Connect peers to support high availability on the appliance side, we recommend that you configure both the BGP peering sessions on each of your Connect peers.
A Connect attachment uses an existing VPC or Direct Connect attachment as the underlying transport mechanism. This is referred to as the *transport attachment*. The transit gateway identifies matched GRE packets from the third-party appliance as traffic from the Connect attachment. It treats any other packets, including GRE packets with incorrect source or destination information, as traffic from the transport attachment.
**Note**
To use a Direct Connect attachment as a transport mechanism, you'll first need to integrate Direct Connect with AWS Transit Gateway. For the steps to create this integration, see [Integrate SD-WAN devices with AWS Transit Gateway and Direct Connect](https://aws.amazon.com/blogs/networking-and-content-delivery/integrate-sd-wan-devices-with-aws-transit-gateway-and-aws-direct-connect/).
## Connect peers
A Connect peer (GRE tunnel) consists of the following components.
**Inside CIDR blocks (BGP addresses)**
The inside IP addresses that are used for BGP peering. You must specify a /29 CIDR block from the `169.254.0.0/16` range for IPv4. You can optionally specify a /125 CIDR block from the `fd00::/8` range for IPv6. The following CIDR blocks are reserved and cannot be used:
+ 169.254.0.0/29
+ 169.254.1.0/29
+ 169.254.2.0/29
+ 169.254.3.0/29
+ 169.254.4.0/29
+ 169.254.5.0/29
+ 169.254.169.248/29
You must configure the first address from the IPv4 range on the appliance as the BGP IP address. When you use IPv6, if your inside CIDR block is fd00::/125, then you must configure the first address in this range (fd00::1) on the tunnel interface of the appliance.
The BGP addresses must be unique across all tunnels on a transit gateway.
**Peer IP address**
The peer IP address (GRE outer IP address) on the appliance side of the Connect peer. This can be any IP address. The IP address can be an IPv4 or IPv6 address, but it must be the same IP address family as the transit gateway address.
**Transit gateway address**
The peer IP address (GRE outer IP address) on the transit gateway side of the Connect peer. The IP address must be specified from the transit gateway CIDR block, and must be unique across Connect attachments on the transit gateway. If you don't specify an IP address, we use the first available address from the transit gateway CIDR block.
You can add a transit gateway CIDR block when you [create](create-tgw.md) or [modify](tgw-modifying.md) a transit gateway.
The IP address can be an IPv4 or IPv6 address, but it must be the same IP address family as the peer IP address.
The peer IP address and transit gateway address are used to uniquely identify the GRE tunnel. You can reuse either address across multiple tunnels, but not both in the same tunnel.
Transit Gateway Connect for the BGP peering only supports Multiprotocol BGP (MP-BGP), where IPv4 Unicast addressing is required to also establish a BGP session for IPv6 Unicast. You can use both IPv4 and IPv6 addresses for the GRE outer IP addresses.
The following example shows a Connect attachment between a transit gateway and an appliance in a VPC.
![\[Transit gateway Connect attachment and Connect peer\]](http://docs.aws.amazon.com/vpc/latest/tgw/images/transit-gateway-connect-peer.png)
| Diagram component | Description |
| --- | --- |
| ![\[Shows how VPC attachments are represented in the example diagram.\]](http://docs.aws.amazon.com/vpc/latest/tgw/images/VPC-attachment.png) | VPC attachment |
| ![\[Shows how Connect attachments are represented in the example diagram.\]](http://docs.aws.amazon.com/vpc/latest/tgw/images/connect-attachment.png) | Connect attachment |
| ![\[Shows how GRE tunnels are represented in the example diagram.\]](http://docs.aws.amazon.com/vpc/latest/tgw/images/GRE-tunnel.png) | GRE tunnel (Connect peer) |
| ![\[Shows how BGP peering sessions are represented in the example diagram.\]](http://docs.aws.amazon.com/vpc/latest/tgw/images/bgp-peering.png) | BGP peering session |
In the preceding example, a Connect attachment is created on an existing VPC attachment (the transport attachment). A Connect peer is created on the Connect attachment to establish a connection to an appliance in the VPC. The transit gateway address is `192.0.2.1`, and the range of BGP addresses is `169.254.6.0/29`. The first IP address in the range (`169.254.6.1`) is configured on the appliance as the peer BGP IP address.
The subnet route table for VPC C has a route that points traffic destined for the transit gateway CIDR block to the transit gateway.
| Destination | Target |
| --- | --- |
| 172.31.0.0/16 | Local |
| 192.0.2.0/24 | tgw-id |
## Requirements and considerations
The following are the requirements and considerations for a Connect attachment.
+ For information about what Regions support Connect attachments, see the [AWS Transit Gateways FAQ](https://aws.amazon.com/transit-gateway/faqs/).
+ The third-party appliance must be configured to send and receive traffic over a GRE tunnel to and from the transit gateway using the Connect attachment.
+ The third-party appliance must be configured to use BGP for dynamic route updates and health checks.
+ The following types of BGP are supported:
+ Exterior BGP (eBGP): Used for connecting to routers that are in a different autonomous system than the transit gateway. If you use eBGP, you must configure ebgp-multihop with a time-to-live (TTL) value of 2.
+ Interior BGP (iBGP): Used for connecting to routers that are in the same autonomous system as the transit gateway. The transit gateway will not install routes from an iBGP peer (third-party appliance), unless the routes are originated from an eBGP peer and should have next-hop-self configured. The routes advertised by third-party appliance over the iBGP peering must have an ASN.
+ MP-BGP (multiprotocol extensions for BGP): Used for supporting multiple protocol types, such as IPv4 and IPv6 address families.
+ The default BGP keep-alive timeout is 10 seconds and the default hold timer is 30 seconds.
+ IPv6 BGP peering is not supported; only IPv4-based BGP peering is supported. IPv6 prefixes are exchanged over IPv4 BGP peering using MP-BGP.
+ Bidirectional Forwarding Detection (BFD) is not supported.
+ BGP graceful restart is not supported.
+ When you create a transit gateway peer, if you do not specify a peer ASN number, we pick the transit gateway ASN number. This means that your appliance and transit gateway will be in the same autonomous system doing iBGP.
+ A Connect peer using the BGP AS-PATH attribute is the preferred route when you have two Connect peers.
To use equal-cost multi-path (ECMP) routing between multiple appliances, you must configure the appliance to advertise the same prefixes to the transit gateway with the same BGP AS-PATH attribute. For the transit gateway to choose all of the available ECMP paths, the AS-PATH and Autonomous System Number (ASN) must match. The transit gateway can use ECMP between Connect peers for the same Connect attachment or between Connect attachments on the same transit gateway. The transit gateway cannot use ECMP between both of the redundant BGP peerings a single peer establishes to it.
+ With a Connect attachment, the routes are propagated to a transit gateway route table by default.
+ Static routes are not supported.
+ Configure the GRE tunnel MTU to be smaller than the external interface MTU by subtracting the GRE header (24 bytes) and outer IP header (20 bytes) overhead. For example, if your external interface MTU is 1500 bytes, set the GRE tunnel MTU to 1456 bytes (1500 - 24 - 20 = 1456) to prevent packet fragmentation.
**Topics**
+ [Connect peers](#tgw-connect-peer)
+ [Requirements and considerations](#tgw-connect-requirements)
+ [Create a Connect attachment](create-tgw-connect-attachment.md)
+ [Create a Connect peer](create-tgw-connect-peer.md)
+ [View Connect attachments and Connect peers](view-tgw-connect-attachments.md)
+ [Modify Connect attachment and Connect peer tags](modify-connect-attachment-tag.md)
+ [Delete a Connect peer](delete-tgw-connect-peer.md)
+ [Delete a Connect attachment](delete-tgw-connect-attachment.md)
# Create a Connect attachment in AWS Transit Gateway
To create a Connect attachment, you must specify an existing attachment as the transport attachment. You can specify a VPC attachment or a Direct Connect attachment as the transport attachment.
**To create a Connect attachment using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Transit gateway attachments**.
1. Choose **Create transit gateway attachment**.
1. (Optional) For **Name tag**, specify a name tag for the attachment.
1. For **Transit gateway ID**, choose the transit gateway for the attachment.
1. For **Attachment type**, choose **Connect**.
1. For **Transport attachment ID**, choose the ID of an existing attachment (the transport attachment).
1. Choose **Create transit gateway attachment**.
**To create a Connect attachment using the AWS CLI**
Use the [create-transit-gateway-connect](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-transit-gateway-connect.html) command.
# Create a Connect peer in AWS Transit Gateway
You can create a Connect peer (GRE tunnel) for an existing Connect attachment. Before you begin, ensure that you have configured a transit gateway CIDR block. You can configure a transit gateway CIDR block when you [create](create-tgw.md) or [modify](tgw-modifying.md) a transit gateway.
When you create the Connect peer, you must specify the GRE outer IP address on the appliance side of the Connect peer.
**To create a Connect peer using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Transit gateway attachments**.
1. Select the Connect attachment, and choose **Actions**, **Create connect peer**.
1. (Optional) For **Name tag**, specify a name tag for the Connect peer.
1. (Optional) For **Transit gateway GRE Address**, specify the GRE outer IP address for the transit gateway. By default, the first available address from the transit gateway CIDR block is used.
1. For **Peer GRE address**, specify the GRE outer IP address for the appliance side of the Connect peer.
1. For **BGP Inside CIDR blocks IPv4**, specify the range of inside IPv4 addresses that are used for BGP peering. Specify a /29 CIDR block from the `169.254.0.0/16` range.
1. (Optional) For **BGP Inside CIDR blocks IPv6**, specify the range of inside IPv6 addresses that are used for BGP peering. Specify a /125 CIDR block from the `fd00::/8` range.
1. (Optional) For **Peer ASN**, specify the Border Gateway Protocol (BGP) Autonomous System Number (ASN) for the appliance. You can use an existing ASN assigned to your network. If you do not have one, you can use a private ASN in the 64512–65534 (16-bit ASN) or 4200000000–4294967294 (32-bit ASN) range.
The default is the same ASN as the transit gateway. If you configure the **Peer ASN** to be different than the transit gateway ASN (eBGP), you must configure ebgp-multihop with a time-to-live (TTL) value of 2.
1. Choose **Create connect peer**.
**To create a Connect peer using the AWS CLI**
Use the [create-transit-gateway-connect-peer](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-transit-gateway-connect-peer.html) command.
# View Connect attachments and Connect peers in AWS Transit Gateway
View your Connect attachments and Connect peers.
**To view your Connect attachments and Connect peers using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Transit gateway attachments**.
1. Select the Connect attachment.
1. To view the Connect peers for the attachment, choose the **Connect Peers** tab.
**To view your Connect attachments and Connect peers using the AWS CLI**
Use the [describe-transit-gateway-connects](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-transit-gateway-connects.html) and [describe-transit-gateway-connect-peers](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-transit-gateway-connect-peers.html) commands.
# Modify Connect attachment and Connect peer tags in AWS Transit Gateway
You can modify the tags for your Connect attachment.
**To modify your Connect attachment tags using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Transit Gateway Attachments**.
1. Select the Connect attachment, and then choose **Actions**, **Manage tags**.
1. To add a tag, choose **Add new tag** and specify the key name and key value.
1. To remove a tag, choose **Remove**.
1. Choose **Save**.
You can modify the tags for your Connect peer.
**To modify your Connect peer tags using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Transit Gateway Attachments**.
1. Select the Connect attachment, and then choose **Connect peers**.
1. Select the Connect peer and then choose **Actions**, **Manage tags**.
1. To add a tag, choose **Add new tag** and specify the key name and key value.
1. To remove a tag, choose **Remove**.
1. Choose **Save**.
**To modify your Connect attachment and Connect peer tags using the AWS CLI**
Use the [create-tags](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-tags.html) and [delete-tags](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-tags.html) commands.
# Delete a Connect peer in AWS Transit Gateway
If you no longer need a Connect peer, you can delete it.
**To delete a Connect peer using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Transit gateway attachments**.
1. Select the Connect attachment.
1. In the **Connect Peers** tab, select the Connect peer and choose **Actions**, **Delete connect peer**.
**To delete a Connect peer using the AWS CLI**
Use the [delete-transit-gateway-connect-peer](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-transit-gateway-connect-peer.html) command.
# Delete a Connect attachment in AWS Transit Gateway
If you no longer need a Connect attachment, you can delete it. You must first delete any Connect peers for the attachment.
**To delete a Connect attachment using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Transit gateway attachments**.
1. Select the Connect attachment, and choose **Actions**, **Delete transit gateway attachment**.
1. Enter **delete** and choose **Delete**.
**To delete a Connect attachment using the AWS CLI**
Use the [delete-transit-gateway-connect](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-transit-gateway-connect.html) command.
# Transit gateway route tables in AWS Transit Gateway
Use transit gateway route tables to configure routing for your transit gateway attachments. A route table is a table that contains rules that direct how your network traffic is routed between your VPCs and VPNs. Each route in the table contains the range of IP addresses for the destinations that you want to send traffic to.
Transit gateway route tables allows you to associate a table with a transit gateway attachment. VPC, VPN, VPN Concentrator, Client VPN, Direct Connect gateway, Peering, and Connect attachments are all supported. When associated, routes for these attachments are propagated from the attachment to the target transit gateway route table. An attachment can be propagated to multiple route tables.
Additionally you can create and manage static routes with a route table. For example, you might have a static route that's used as a backup route in the event of a network disruption that affects any dynamic routes.
**Topics**
+ [Create a transit gateway route table](create-tgw-route-table.md)
+ [View transit gateway route tables](view-tgw-route-tables.md)
+ [Associate a transit gateway route table](associate-tgw-route-table.md)
+ [Disassociate a transit gateway route table](disassociate-tgw-route-table.md)
+ [Enable route propagation](enable-tgw-route-propagation.md)
+ [Disable route propagation](disable-tgw-route-propagation.md)
+ [Create a static route](tgw-create-static-route.md)
+ [Delete a static route](tgw-delete-static-route.md)
+ [Replace a static route](tgw-replace-static-route.md)
+ [Export route tables to Amazon S3](tgw-export-route-tables.md)
+ [Delete a transit gateway route table](delete-tgw-route-table.md)
+ [Create a prefix list reference](create-prefix-list-reference.md)
+ [Modify a prefix list reference](modify-prefix-list-reference.md)
+ [Delete a prefix list reference](delete-prefix-list-reference.md)
# Create a transit gateway route table in AWS Transit Gateway
**To create a transit gateway route table using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Route Tables**.
1. Choose **Create transit gateway route table**.
1. (Optional) For **Name tag**, type a name for the transit gateway route table. This creates a tag with the tag key "Name", where the tag value is the name that you specify.
1. For **Transit gateway ID**, select the transit gateway for the route table.
1. Choose **Create transit gateway route table**.
**To create a transit gateway route table using the AWS CLI**
Use the [create-transit-gateway-route-table](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-transit-gateway-route-table.html) command.
# View transit gateway route tables using AWS Transit Gateway
**To view your transit gateway route tables using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Route Tables**.
1. (Optional) To find a specific route table or set of tables, enter all or part of the name, keyword, or attribute in the filter field.
1. Select the checkbox for a route table, or choose its ID, to display information about its associations, propagations, routes, and tags.
**To view your transit gateway route tables using the AWS CLI**
Use the [describe-transit-gateway-route-tables](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-transit-gateway-route-tables.html) command.
**To view the routes for a transit gateway route table using the AWS CLI**
Use the [search-transit-gateway-routes](https://docs.aws.amazon.com/cli/latest/reference/ec2/search-transit-gateway-routes.html) command.
**To view the route propagations for a transit gateway route table using the AWS CLI**
Use the [get-transit-gateway-route-table-propagations](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-transit-gateway-route-table-propagations.html) command.
**To view the associations for a transit gateway route table using the AWS CLI**
Use the [get-transit-gateway-route-table-associations](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-transit-gateway-route-table-associations.html) command.
# Associate a transit gateway route table in AWS Transit Gateway
You can associate a transit gateway route table with a transit gateway attachment.
**To associate a transit gateway route table using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Route Tables**.
1. Select the route table.
1. In the lower part of the page, choose the **Associations** tab.
1. Choose **Create association**.
1. Choose the attachment to associate and then choose **Create association**.
**To associate a transit gateway route table using the AWS CLI**
Use the [associate-transit-gateway-route-table](https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-transit-gateway-route-table.html) command.
# Delete an association for a transit gateway route table in AWS Transit Gateway
You can disassociate a transit gateway route table from a transit gateway attachment.
**To disassociate a transit gateway route table using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Route Tables**.
1. Select the route table.
1. In the lower part of the page, choose the **Associations** tab.
1. Choose the attachment to disassociate and then choose **Delete association**.
1. When prompted for confirmation, choose **Delete association**.
**To disassociate a transit gateway route table using the AWS CLI**
Use the [disassociate-transit-gateway-route-table](https://docs.aws.amazon.com/cli/latest/reference/ec2/disassociate-transit-gateway-route-table.html) command.
# Enable route propagation to a transit gateway route table in AWS Transit Gateway
Use route propagation to add a route from an attachment to a route table.
**To propagate a route to a transit gateway attachment route table**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Route Tables**.
1. Select the route table for which to create a propagation.
1. Choose **Actions**, **Create propagation**.
1. On the **Create propagation** page, choose the attachment.
1. Choose **Create propagation**.
**To enable route propagation using the AWS CLI**
Use the [enable-transit-gateway-route-table-propagation](https://docs.aws.amazon.com/cli/latest/reference/ec2/enable-transit-gateway-route-table-propagation.html) command.
# Disable route propagation in AWS Transit Gateway
Remove a propagated route from a route table attachment.
**To disable route propagation using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Route Tables**.
1. Select the route table to delete the propagation from.
1. On the lower part of the page, choose the **Propagations** tab.
1. Select the attachment and then choose **Delete propagation**.
1. When prompted for confirmation, choose **Delete propagation**.
**To disable route propagation using the AWS CLI**
Use the [disable-transit-gateway-route-table-propagation](https://docs.aws.amazon.com/cli/latest/reference/ec2/disable-transit-gateway-route-table-propagation.html) command.
# Create a static route in AWS Transit Gateway
Create a static route for a VPC, VPN, or transit gateway peering attachment, or you can create a blackhole route that drops traffic that matches the route.
Static routes in a transit gateway route table that target a VPN attachment are not filtered by the Site-to-Site VPN. This might allow unintended outbound traffic flow when using a BGP-based VPN.
**To create a static route using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Route Tables**.
1. Select the route table for which to create a route.
1. Choose **Actions**, **Create static route**.
1. On the **Create static route** page, enter the CIDR block for which to create the route, and then choose **Active**.
1. Choose the attachment for the route.
1. Choose **Create static route**.
**To create a blackhole route using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Route Tables**.
1. Select the route table for which to create a route.
1. Choose **Actions**, **Create static route**.
1. On the **Create static route** page, enter the CIDR block for which to create the route, and then choose **Blackhole**.
1. Choose **Create static route**.
**To create a static route or blackhole route using the AWS CLI**
Use the [create-transit-gateway-route](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-transit-gateway-route.html) command.
# Delete a static route in AWS Transit Gateway
Delete static routes from a transit gateway route table.
**To delete a static route using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Route Tables**.
1. Select the route table for which to delete the route, and choose **Routes**.
1. Choose the route to delete.
1. Choose **Delete static route**.
1. In the confirmation box, choose **Delete static route**.
**To delete a static route using the AWS CLI**
Use the [delete-transit-gateway-route](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-transit-gateway-route.html) command.
# Replace a static route in AWS Transit Gateway
Replace a static route in a transit gateway route table with a different static route.
**To replace a static route using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Route Tables**.
1. Choose the route that you want to replace in the route table.
1. In the details section, choose the **Routes** tab.
1. Choose **Actions**, **Replace static route**.
1. For the **Type**, choose either **Active** or **Blackhole**.
1. From the **Choose attachment** drop-down, choose the transit gateway that will replace the current one in the route table.
1. Choose **Replace static route**.
**To replace a static route using the AWS CLI**
Use the [replace-transit-gateway-route](https://docs.aws.amazon.com/cli/latest/reference/ec2/replace-transit-gateway-route.html) command.
# Export route tables to Amazon S3 in AWS Transit Gateway
You can export the routes in your transit gateway route tables to an Amazon S3 bucket. The routes are saved to the specified Amazon S3 bucket in a JSON file.
**To export transit gateway route tables using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Route Tables**.
1. Choose the route table that includes the routes to export.
1. Choose **Actions**, **Export routes**.
1. On the **Export routes** page, for **S3 bucket name**, type the name of the S3 bucket.
1. To filter the routes exported, specify filter parameters in the **Filters** section of the page.
1. Choose **Export routes**.
To access the exported routes, open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/), and navigate to the bucket that you specified. The file name includes the AWS account ID, AWS Region, route table ID, and a timestamp. Select the file and choose **Download**. The following is an example of a JSON file that contains information about two propagated routes for VPC attachments.
```
{
"filter": [
{
"name": "route-search.subnet-of-match",
"values": [
"0.0.0.0/0",
"::/0"
]
}
],
"routes": [
{
"destinationCidrBlock": "10.0.0.0/16",
"transitGatewayAttachments": [
{
"resourceId": "vpc-0123456abcd123456",
"transitGatewayAttachmentId": "tgw-attach-1122334455aabbcc1",
"resourceType": "vpc"
}
],
"type": "propagated",
"state": "active"
},
{
"destinationCidrBlock": "10.2.0.0/16",
"transitGatewayAttachments": [
{
"resourceId": "vpc-abcabc123123abca",
"transitGatewayAttachmentId": "tgw-attach-6677889900aabbcc7",
"resourceType": "vpc"
}
],
"type": "propagated",
"state": "active"
}
]
}
```
# Delete a transit gateway route table in AWS Transit Gateway
**To delete a transit gateway route table using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Route Tables**.
1. Select the route table to delete.
1. Choose **Actions**, **Delete transit gateway route table**.
1. Enter **delete** and choose **Delete** to confirm the deletion.
**To delete a transit gateway route table using the AWS CLI**
Use the [delete-transit-gateway-route-table](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-transit-gateway-route-table.html) command.
# Create a route table prefix list reference in AWS Transit Gateway
You can reference a prefix list in your transit gateway route table. A prefix list is a set of one or more CIDR block entries that you define and manage. You can use a prefix list to simplify the management of the IP addresses that you reference in your resources to route network traffic. For example, if you frequently specify the same destination CIDRs across multiple transit gateway route tables, you can manage those CIDRs in a single prefix list, instead of repeatedly referencing the same CIDRs in each route table. If you need to remove a destination CIDR block, you can remove its entry from the prefix list instead of removing the route from every affected route table.
When you create a prefix list reference in your transit gateway route table, each entry in the prefix list is represented as a route in your transit gateway route table.
For more information about prefix lists, see [Prefix lists](https://docs.aws.amazon.com/vpc/latest/userguide/managed-prefix-lists.html) in the *Amazon VPC User Guide*.
**To create a prefix list reference using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Transit Gateway Route Tables**.
1. Select the transit gateway route table.
1. Choose **Actions**, **Create prefix list reference**.
1. For **Prefix list ID**, choose the ID of the prefix list.
1. For **Type**, choose if traffic to this prefix list should be allowed (**Active**) or dropped (**Blackhole**).
1. For **Transit gateway attachment ID**, choose the ID of the attachment to which to route traffic.
1. Choose **Create prefix list reference**.
**To create a prefix list reference using the AWS CLI**
Use the [create-transit-gateway-prefix-list-reference](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-transit-gateway-prefix-list-reference.html) command.
# Modify a prefix list reference in AWS Transit Gateway
You can modify a prefix list reference by changing the attachment that the traffic is routed to, or indicating whether to drop traffic that matches the route.
You cannot modify the individual routes for a prefix list in the **Routes** tab. To modify the entries in the prefix list, use the **Managed Prefix Lists** screen. For more information, see [Modifying a prefix list](https://docs.aws.amazon.com/vpc/latest/userguide/managed-prefix-lists.html#modify-managed-prefix-list) in the *Amazon VPC User Guide*.
**To modify a prefix list reference using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Transit Gateway Route Tables**.
1. Select the transit gateway route table.
1. In the lower pane, choose **Prefix list references**.
1. Choose the prefix list reference, and choose **Modify references**.
1. For **Type**, choose if traffic to this prefix list should be allowed (**Active**) or dropped (**Blackhole**).
1. For **Transit gateway attachment ID**, choose the ID of the attachment to which to route traffic.
1. Choose **Modify prefix list reference**.
**To modify a prefix list reference using the AWS CLI**
Use the [modify-transit-gateway-prefix-list-reference](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-transit-gateway-prefix-list-reference.html) command.
# Delete a prefix list reference in AWS Transit Gateway
If you no longer need a prefix list reference, you can delete it from your transit gateway route table. Deleting the reference does not delete the prefix list.
**To delete a prefix list reference using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Transit Gateway Route Tables**.
1. Select the transit gateway route table.
1. Choose the prefix list reference, and choose **Delete references**.
1. Choose **Delete references**.
**To modify a prefix list reference using the AWS CLI**
Use the [delete-transit-gateway-prefix-list-reference](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-transit-gateway-prefix-list-reference.html) command.
# Transit gateway policy tables in AWS Transit Gateway
Transit gateway dynamic routing uses policy tables to route network traffic for AWS Cloud WAN. The table contains policy rules for matching network traffic by policy attributes, and then maps the traffic that matches the rule to a target route table.
You can use dynamic routing for transit gateways to automatically exchange routing and reachability information with peered transit gateway types. Unlike with a static route, traffic can be routed along a different path based on network conditions, such as path failures or congestion. Dynamic routing also adds an extra layer of security in that it's easier to re-route traffic in the event of a network breach or incursion.
**Note**
Transit gateway policy tables are currently only supported in Cloud WAN when creating a transit gateway peering connection. When creating a peering connection, you can associate that table with the connection. The association then populates the table automatically with the policy rules.
For more information about peering connections in Cloud WAN, see [ Peerings](https://docs.aws.amazon.com/network-manager/latest/cloudwan/cloudwan-peerings.html) in the *AWS Cloud WAN User Guide*.
**Topics**
+ [Create a transit gateway policy table](tgw-policy-tables-create.md)
+ [Delete a transit gateway policy table](tgw-policy-tables-disable.md)
# Create a transit gateway policy table in AWS Transit Gateway
**To create a transit gateway policy table using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit gateway policy table**.
1. Choose **Create transit gateway policy table**.
1. (Optional) For **Name tag**, enter a name for the transit gateway policy table. This creates a tag, where the tag value is the name that you specify.
1. For Transit gateway ID, select the transit gateway for the policy table.
1. Choose **Create transit gateway policy table**.
**To create a transit gateway policy table using the AWS CLI**
Use the [create-transit-gateway-policy-table](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-transit-gateway-policy-table.html) command.
# Delete a transit gateway policy table in AWS Transit Gateway
Delete a transit gateway policy table. When a table is deleted, all policy rules within that table are deleted.
**To delete a transit gateway policy table using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit gateway policy tables**.
1. Choose the transit gateway policy table to delete.
1. Choose **Actions**, and then choose **Delete policy table**.
1. Confirm that you want to delete the table.
**To delete a transit gateway policy table using the AWS CLI**
Use the [delete-transit-gateway-policy-table](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-transit-gateway-policy-table.html) command.
# Multicast in AWS Transit Gateway
Multicast is a communication protocol used for delivering a single stream of data to multiple receiving computers simultaneously. Transit Gateway supports routing multicast traffic between subnets of attached VPCs, and it serves as a multicast router for instances sending traffic destined for multiple receiving instances.
**Topics**
+ [Multicast concepts](#concepts)
+ [Considerations](#limits)
+ [Multicast routing](#how-multicast-works)
+ [Multicast domains](multicast-domains-about.md)
+ [Shared multicast domains](multicast-share-domain.md)
+ [Register sources with a multicast group](add-source-multicast-group.md)
+ [Register members with a multicast group](add-members-multicast-group.md)
+ [Deregister sources from a multicast group](remove-source-multicast-group.md)
+ [Deregister members from a multicast group](remove-members-multicast-group.md)
+ [View multicast groups](view-multicast-group.md)
+ [Set up multicast for Windows Server](multicastwin.md)
+ [Example: Manage IGMP configurations](multicast-configurations-igmp.md)
+ [Example: Manage static source configurations](multicast-configurations-no-igmp.md)
+ [Example: Manage static group member configurations](multicast-configurations-no-igmp-source.md)
## Multicast concepts
The following are the key concepts for multicast:
+ **Multicast domain** — Allows segmentation of a multicast network into different domains, and makes the transit gateway act as multiple multicast routers. You define multicast domain membership at the subnet level.
+ **Multicast group** — Identifies a set of hosts that will send and receive the same multicast traffic. A multicast group is identified by a group IP address. Multicast group membership is defined by individual elastic network interfaces attached to EC2 instances.
+ **Internet Group Management Protocol (IGMP)** — An internet protocol that allows hosts and routers to dynamically manage multicast group membership. An IGMP multicast domain contains hosts that use the IGMP protocol to join, leave, and send messages. AWS supports the IGMPv2 protocol and both IGMP and static (API-based) group membership multicast domains.
+ **Multicast source** — An elastic network interface associated with a supported EC2 instance that is statically configured to send multicast traffic. A multicast source only applies to static source configurations.
A static source multicast domain contains hosts that do not use the IGMP protocol to join, leave, and send messages. You use the AWS CLI to add a source and group members. The statically-added source sends multicast traffic and the members receive multicast traffic.
+ **Multicast group member** — An elastic network interface associated with a supported EC2 instance that receives multicast traffic. A multicast group has multiple group members. In a static source group membership configuration, multicast group members can only receive traffic. In an IGMP group configuration, members can both send and receive traffic.
## Considerations
+ Transit gateway multicast may not be suitable for high-frequency trading or performance-sensitive applications. We strongly recommend that you review the [Multicast quotas](transit-gateway-quotas.md#multicast-quotas) for the limits. Contact your account or Solution Architect team for a detailed review of your performance requirements.
+ For information about supported Regions, see [AWS Transit Gateway FAQs](https://aws.amazon.com/transit-gateway/faqs/).
+ You must create a new transit gateway to support multicast.
+ Multicast group membership is managed using the Amazon Virtual Private Cloud Console or the AWS CLI, or IGMP.
+ A subnet can only be in one multicast domain.
+ If you use a non-Nitro instance, you must disable the **Source/Dest** checkbox. For information about disabling the check, see [Changing the source or destination checking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#change_source_dest_check) in the *Amazon EC2 User Guide*.
+ A non-Nitro instance cannot be a multicast sender.
+ Multicast routing is not supported over Direct Connect, Site-to-Site VPN, peering attachments, or transit gateway Connect attachments.
+ A transit gateway does not support fragmentation of multicast packets. Fragmented multicast packets are dropped. For more information, see [Maximum transmission unit (MTU)](transit-gateway-quotas.md#mtu-quotas).
+ At startup, an IGMP host sends multiple IGMP JOIN messages to join a multicast group (typically 2 to 3 retries). In the unlikely event that all the IGMP JOIN messages get lost, the host will not become part of transit gateway multicast group. In such a scenario you will need to re-trigger the IGMP JOIN message from the host using application specific methods.
+ A group membership starts with the receipt of IGMPv2 JOIN message by the transit gateway and ends with the receipt of the IGMPv2 LEAVE message. The transit gateway keeps track of hosts that successfully joined the group. As a cloud multicast router, transit gateway issues an IGMPv2 QUERY message to all members every two minutes. Each member sends an IGMPv2 JOIN message in response, which is how the members renew their membership. If a member fails to reply to three consecutive queries, the transit gateway removes this membership from all joined groups. However, it continues sending queries to this member for 12 hours before permanently removing the member from its to-be-queried list. An explicit IGMPv2 LEAVE message immediately and permanently removes the host from any further multicast processing.
+ The transit gateway keeps track of hosts that successfully joined the group. In the event of a transit gateway outage, the transit gateway continues to send multicast data to the host for seven minutes (420 seconds) after the last successful IGMP JOIN message. The transit gateway continues to send membership queries to the host for up to 12 hours or until it receives a IGMP LEAVE message from the host.
+ The transit gateway sends membership query packets to all the IGMP members so that it can track multicast group membership. The source IP of these IGMP query packets is 0.0.0.0/32, and the destination IP is 224.0.0.1/32 and the protocol is 2. Your security group configuration on the IGMP hosts (instances), and any ACLs configuration on the host subnets must allow these IGMP protocol messages.
+ When the multicast source and destination are in the same VPC, you cannot use security group referencing to set the destination security group to accept traffic from the source's security group.
+ For static multicast groups and sources, AWS Transit Gateway automatically remove static groups and sources for ENIs that no longer exist. This is performed by periodically assuming the [Transit Gateway service-linked role](service-linked-roles.md#tgw-service-linked-roles) to describe ENIs in the account.
+ Only static multicast supports IPv6. Dynamic multicast does not.
## Multicast routing
When you enable multicast on a transit gateway, it acts as a multicast router. When you add a subnet to a multicast domain, we send all multicast traffic to the transit gateway that is associated with that multicast domain.
### Network ACLs
Network ACL rules operate at the subnet level. They apply to multicast traffic, because transit gateways reside outside of the subnet. For more information, see [Network ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) in the * Amazon VPC User Guide*.
For Internet Group Management Protocol (IGMP) multicast traffic, the following are the minimum inbound rules. The remote host is the host sending the multicast traffic.
| Type | Protocol | Source | Description |
| --- | --- | --- | --- |
| Custom Protocol | IGMP(2) | 0.0.0.0/32 | IGMP query |
| Custom UDP Protocol | UDP | Remote host IP address | Inbound multicast traffic |
The following are the minimum outbound rules for IGMP.
| Type | Protocol | Destination | Description |
| --- | --- | --- | --- |
| Custom Protocol | IGMP(2) | 224.0.0.2/32 | IGMP leave |
| Custom Protocol | IGMP(2) | Multicast group IP address | IGMP join |
| Custom UDP Protocol | UDP | Multicast group IP address | Outbound multicast traffic |
### Security groups
Security group rules operate at the instance level. They can be applied to both inbound and outbound multicast traffic. The behavior is the same as with unicast traffic. For all group member instances, you must allow inbound traffic from the group source. For more information, see [Security groups](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) in the *Amazon VPC User Guide*.
For IGMP multicast traffic, you must have the following inbound rules at a minimum. The remote host is the host sending the multicast traffic. You can't specify a security group as the source of the UDP inbound rule.
| Type | Protocol | Source | Description |
| --- | --- | --- | --- |
| Custom Protocol | 2 | 0.0.0.0/32 | IGMP query |
| Custom UDP Protocol | UDP | Remote host IP address | Inbound multicast traffic |
For IGMP multicast traffic, you must have the following outbound rules at a minimum.
| Type | Protocol | Destination | Description |
| --- | --- | --- | --- |
| Custom Protocol | 2 | 224.0.0.2/32 | IGMP leave |
| Custom Protocol | 2 | Multicast group IP address | IGMP join |
| Custom UDP Protocol | UDP | Multicast group IP address | Outbound multicast traffic |
# Multicast domains in AWS Transit Gateway
A multicast domain allows segmentation of a multicast network into different domains. To begin using multicast with a transit gateway, create a multicast domain, and then associate subnets with the domain.
## Multicast domain attributes
The following table details the multicast domain attributes. You cannot enable both attributes at the same time.
| Attribute | Description |
| --- | --- |
| Igmpv2Support (AWS CLI) **IGMPv2 support** (console) | This attribute determines how group members join or leave a multicast group. When this attribute is disabled, you must add the group members to the domain manually. Enable this attribute if at least one member uses the IGMP protocol. Members join the multicast group in one of the following ways: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/vpc/latest/tgw/multicast-domains-about.html) If you register multicast group members, you must deregister them, too. The transit gateway ignores an IGMP `LEAVE` message sent by a manually added group member. |
| StaticSourcesSupport (AWS CLI) **Static sources support** (console) | This attribute determines whether there are static multicast sources for the group. When this attribute is enabled, you must add sources for a multicast domain using [register-transit-gateway-multicast-group-sources ](https://docs.aws.amazon.com/cli/latest/reference/ec2/register-transit-gateway-multicast-group-sources.html). Only multicast sources can send multicast traffic. When this attribute is disabled, there are no designated multicast sources. Any instances that are in subnets associated with the multicast domain can send multicast traffic, and the group members receive the multicast traffic. |
# Create an IGMP multicast domain in AWS Transit Gateway
If you have not already done so, review the available multicast domain attributes. For more information, see [Multicast domains in AWS Transit Gateway](multicast-domains-about.md).
**To create an IGMP multicast domain using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Multicast**.
1. Choose **Create transit gateway multicast domain**.
1. For **Name tag**, enter a name for the domain.
1. For **Transit gateway ID**, choose the transit gateway that processes the multicast traffic.
1. For **IGMPv2 support**, select the checkbox.
1. For **Static sources support**, clear the checkbox.
1. To automatically accept cross-account subnet associations for this multicast domain, select **Auto accept shared associations**.
1. Choose **Create transit gateway multicast domain**.
**To create an IGMP multicast domain using the AWS CLI**
Use the [create-transit-gateway-multicast-domain](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-transit-gateway-multicast-domain.html) command.
```
aws ec2 create-transit-gateway-multicast-domain --transit-gateway-id tgw-0xexampleid12345 --options StaticSourcesSupport=disable,Igmpv2Support=enable
```
# Create a static source multicast domain in AWS Transit Gateway
If you have not already done so, review the available multicast domain attributes. For more information, see [Multicast domains in AWS Transit Gateway](multicast-domains-about.md).
**To create a static multicast domain using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Multicast**.
1. Choose **Create transit gateway multicast domain**.
1. For **Name tag**, enter a name to identify the domain.
1. For **Transit gateway ID**, choose the transit gateway that processes the multicast traffic.
1. For **IGMPv2 support**, clear the checkbox.
1. For **Static sources support**, select the checkbox.
1. To automatically accept cross-account subnet associations for this multicast domain, select **Auto accept shared associations**.
1. Choose **Create transit gateway multicast domain**.
**To create a static multicast domain using the AWS CLI**
Use the [create-transit-gateway-multicast-domain](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-transit-gateway-multicast-domain.html) command.
```
aws ec2 create-transit-gateway-multicast-domain --transit-gateway-id tgw-0xexampleid12345 --options StaticSourcesSupport=enable,Igmpv2Support=disable
```
# Associating VPC attachments and subnets with a multicast domain in AWS Transit Gateway
Use the following procedure to associate a VPC attachment with a multicast domain. When you create an association, you can then select the subnets to include in the multicast domain.
Before you begin, you must create a VPC attachment on your transit gateway. For more information, see [Amazon VPC attachments in AWS Transit Gateway](tgw-vpc-attachments.md).
**To associate VPC attachments with a multicast domain using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Multicast**.
1. Select the multicast domain, and then choose **Actions**, **Create association**.
1. For **Choose attachment to associate**, select the transit gateway attachment.
1. For **Choose subnets to associate**, select the subnets to include in the multicast domain.
1. Choose **Create association**.
**To associate VPC attachments with a multicast domain using the AWS CLI**
Use the [associate-transit-gateway-multicast-domain](https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-transit-gateway-multicast-domain.html) command.
# Disassociate a subnet from a multicast domain in AWS Transit Gateway
Use the following procedure to disassociate subnets from a multicast domain.
**To disassociate subnets using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Multicast**.
1. Select the multicast domain.
1. Choose the **Associations** tab.
1. Select the subnet, and then choose **Actions**, **Delete association**.
**To disassociate subnets using the AWS CLI**
Use the [disassociate-transit-gateway-multicast-domain](https://docs.aws.amazon.com/cli/latest/reference/ec2/disassociate-transit-gateway-multicast-domain.html) command.
# View multicast domain associations in AWS Transit Gateway
View your multicast domains to verify that they are available, and that they contain the appropriate subnets and attachments.
**To view a multicast domain using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Multicast**.
1. Select the multicast domain.
1. Choose the **Associations** tab.
**To view a multicast domain using the AWS CLI**
Use the [describe-transit-gateway-multicast-domains](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-transit-gateway-multicast-domains.html) command.
# Add tags to a multicast domain in AWS Transit Gateway
Add tags to your resources to help organize and identify them, such as by purpose, owner, or environment. You can add multiple tags to each multicast domain. Tag keys must be unique for each multicast domain. If you add a tag with a key that is already associated with the multicast domain, it updates the value of that tag. For more information, see [Tagging your Amazon EC2 Resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html).
**To add tags to a multicast domain using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Multicast**.
1. Select the multicast domain.
1. Choose **Actions**, **Manage tags**.
1. For each tag, choose **Add new tag** and enter a **Key** and **Value** for the tag.
1. Choose **Save**.
**To add tags to a multicast domain using the AWS CLI**
Use the [create-tags](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-tags.html) command.
# Delete a multicast domain in AWS Transit Gateway
Use the following procedure to delete a multicast domain.
**To delete a multicast domain using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Multicast**.
1. Select the multicast domain, and then choose **Actions**, **Delete multicast domain**.
1. When prompted for confirmation, enter **delete** and then choose **Delete**.
**To delete a multicast domain using the AWS CLI**
Use the [delete-transit-gateway-multicast-domain](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-transit-gateway-multicast-domain.html) command.
# Shared multicast domains in AWS Transit Gateway
With multicast domain sharing, multicast domain owners can share the domain with other AWS accounts inside its organization or across organizations in AWS Organizations. As the multicast domain owner, you can create and manage the multicast domain centrally. Once shared, those users can perform the following operations on a shared multicast domain:
+ Register and deregister group members or group sources in the multicast domain
+ Associate a subnet with the multicast domain, and disassociate subnets from the multicast domain
A multicast domain owner can share a multicast domain with:
+ AWS accounts inside its organization or across organizations in AWS Organizations
+ An organizational unit inside its organization in AWS Organizations
+ Its entire organization in AWS Organizations
+ AWS accounts outside of AWS Organizations.
To share a multicast domain with an AWS account outside of your Organization, you must create a resource share using AWS Resource Access Manager, and then choose **Allow sharing with anyone** when selecting the Principals to share the multicast domain with. For more information on creating a resource share, see [Creating a resource share in AWS RAM](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-create.html) in the *AWS RAM User Guide*
**Topics**
+ [Prerequisites for sharing a multicast domain](#sharing-prereqs)
+ [Related services](#sharing-related)
+ [Shared multicast domain permissions](#sharing-perms)
+ [Billing and metering](#sharing-billing)
+ [Quotas](#sharing-quotas)
+ [Share resources across Availability Zones](sharing-azs.md)
+ [Share a multicast domain](sharing-share.md)
+ [Unshare a shared multicast domain](sharing-unshare.md)
+ [Identify a shared multicast domain](sharing-identify.md)
## Prerequisites for sharing a multicast domain
+ To share a multicast domain, you must own it in your AWS account. You cannot share a multicast domain that has been shared with you.
+ To share a multicast domain with your organization or an organizational unit in AWS Organizations, you must enable sharing with AWS Organizations. For more information, see [ Enable Sharing with AWS Organizations](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs) in the *AWS RAM User Guide*.
## Related services
Multicast domain sharing integrates with AWS Resource Access Manager (AWS RAM). AWS RAM is a service that enables you to share your AWS resources with any AWS account or through AWS Organizations. With AWS RAM, you share resources that you own by creating a *resource share*. A resource share specifies the resources to share, and the users with whom to share them. Consumers can be individual AWS accounts, or organizational units or an entire organization in AWS Organizations.
For more information about AWS RAM, see the *[AWS RAM User Guide](https://docs.aws.amazon.com/ram/latest/userguide/)*.
## Shared multicast domain permissions
### Permissions for owners
Owners are responsible for managing the multicast domain and the members and attachments that they register or associate with the domain. Owners can change or revoke shared access at any time. They can use AWS Organizations to view, modify, and delete resources that consumers create on shared multicast domains.
### Permissions for consumers
Users of the shared multicast domain can perform the following operations on shared multicast domains in the same way that they would on multicast domains that they created:
+ Register and deregister group members or group sources in the multicast domain
+ Associate a subnet with the multicast domain, and disassociate subnets from the multicast domain
Consumers are responsible for managing the resources that they create on the shared multicast domain.
Customers cannot view or modify resources owned by other consumers or by the multicast domain owner, and they cannot modify multicast domains that are shared with them.
## Billing and metering
There are no additional charges for sharing multicast domains for either the owner, or consumers.
## Quotas
A shared multicast domain counts toward the owner's and shared user's multicast domain quotas.
# Share resources across Availability Zones in AWS Transit Gateway
To ensure that resources are distributed across the Availability Zones for a Region, AWS Transit Gateway independently map s Availability Zones to names for each account. This could lead to Availability Zone naming differences across accounts. For example, the Availability Zone `us-east-1a` for your AWS account might not have the same location as `us-east-1a` for another AWS account.
To identify the location of your multicast domain relative to your accounts, you must use the *Availability Zone ID* (AZ ID). The AZ ID is a unique and consistent identifier for an Availability Zone across all AWS accounts. For example, `use1-az1` is an AZ ID for the `us-east-1` Region and it is the same location in every AWS account.
**To view the AZ IDs for the Availability Zones in your account**
1. Open the AWS RAM console at [https://console.aws.amazon.com/ram/home](https://console.aws.amazon.com/ram/home).
1. The AZ IDs for the current Region are displayed in the **Your AZ ID** panel on the right-hand side of the screen.
# Share a multicast domain in AWS Transit Gateway
When an owner shares a multicast domain with you, you can do the following:
+ Register and deregister group members or group sources
+ Associate and disassociate subnets
**Note**
To share a multicast domain, you must add it to a resource share. A resource share is an AWS RAM resource that lets you share your resources across AWS accounts. A resource share specifies the resources to share, and the consumers with whom they are shared. When you share a multicast domain using the Amazon Virtual Private Cloud Console, you add it to an existing resource share. To add the multicast domain to a new resource share, you must first create the resource share using the [AWS RAM console](https://console.aws.amazon.com/ram).
If you are part of an organization in AWS Organizations and sharing within your organization is enabled, consumers in your organization are automatically granted access to the shared multicast domain. Otherwise, consumers receive an invitation to join the resource share and are granted access to the shared multicast domain after accepting the invitation.
You can share a multicast domain that you own using the Amazon Virtual Private Cloud console, AWS RAM console, or the AWS CLI.
**To share a multicast domain that you own using the \$1Amazon Virtual Private Cloud Console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Multicast Domains**.
1. Select your multicast domain, and then choose **Actions**, **Share multicast domain**.
1. Select your resource share and choose **Share multicast domain**.
**To share a multicast domain that you own using the AWS RAM console**
See [Creating a Resource Share](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing.html#working-with-sharing-create) in the *AWS RAM User Guide*.
**To share a multicast domain that you own using the AWS CLI**
Use the [create-resource-share](https://docs.aws.amazon.com/cli/latest/reference/ram/create-resource-share.html) command.
# Unshare a shared multicast domain in AWS Transit Gateway
When a shared multicast domain is unshared, the following happens to consumer multicast domain resources:
+ Consumer subnets are disassociated from the multicast domain. The subnets remain in the consumer account.
+ Consumer group sources and group members are disassociated from the multicast domain, and then deleted from the consumer account.
To unshare a multicast domain, you must remove it from the resource share. You can do this from the AWS RAM console or the AWS CLI.
To unshare a shared multicast domain that you own, you must remove it from the resource share. You can do this using the Amazon Virtual Private Cloud, AWS RAM console, or the AWS CLI.
**To unshare a shared multicast domain that you own using the \$1Amazon Virtual Private Cloud Console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Multicast Domains**.
1. Select your multicast domain, and then choose **Actions**, **Stop sharing**.
**To unshare a shared multicast domain that you own using the AWS RAM console**
See [Updating a Resource Share](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing.html#working-with-sharing-update) in the *AWS RAM User Guide*.
**To unshare a shared multicast domain that you own using the AWS CLI**
Use the [disassociate-resource-share](https://docs.aws.amazon.com/cli/latest/reference/ram/disassociate-resource-share.html) command.
# Identify a shared multicast domain in AWS Transit Gateway
Owners and consumers can identify shared multicast domains using the Amazon Virtual Private Cloud and AWS CLI
**To identify a shared multicast domain using the \$1Amazon Virtual Private Cloud Console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Multicast Domains**.
1. Select your multicast domain.
1. On the **Transit Multicast Domain Details **page, view the **Owner ID** to identify the AWS account ID of the multicast domain.
**To identify a shared multicast domain using the AWS CLI**
Use the [describe-transit-gateway-multicast-domains](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-transit-gateway-multicast-domains.html) command. The command returns the multicast domains that you own and multicast domains that are shared with you. `OwnerId` shows the AWS account ID of the multicast domain owner.
# Register sources with a multicast group in AWS Transit Gateway
**Note**
This procedure is only required when you have set the **Static sources support** attribute to **enable**.
Use the following procedure to register sources with a multicast group. The source is the network interface that sends multicast traffic.
You need the following information before you add a source:
+ The ID of the multicast domain
+ The IDs of the sources' network interfaces
+ The multicast group IP address
**To register sources using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Multicast**.
1. Select the multicast domain, and then choose **Actions**, **Add group sources**.
1. For **Group IP address**, enter either the IPv4 CIDR block or IPv6 CIDR block to assign to the multicast domain.
1. Under **Choose network interfaces**, select the multicast senders' network interfaces.
1. Choose **Add sources**.
**To register sources using the AWS CLI**
Use the [register-transit-gateway-multicast-group-sources](https://docs.aws.amazon.com/cli/latest/reference/ec2/register-transit-gateway-multicast-group-sources.html) command.
# Register members with a multicast group in AWS Transit Gateway
Use the following procedure to register group members with a multicast group.
You need the following information before you add members:
+ The ID of the multicast domain
+ The IDs of the group members' network interfaces
+ The multicast group IP address
**To register members using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Multicast**.
1. Select the multicast domain, and then choose **Actions**, **Add group members**.
1. For **Group IP address**, enter either the IPv4 CIDR block or IPv6 CIDR block to assign to the multicast domain.
1. Under **Choose network interfaces**, select the multicast receivers' network interfaces.
1. Choose **Add members**.
**To register members using the AWS CLI**
Use the [register-transit-gateway-multicast-group-members](https://docs.aws.amazon.com/cli/latest/reference/ec2/register-transit-gateway-multicast-group-members.html) command.
# Deregister sources from a multicast group in AWS Transit Gateway
You don't need to follow this procedure unless you manually added a source to the multicast group.
**To remove a source using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Multicast**.
1. Select the multicast domain.
1. Choose the **Groups** tab.
1. Select the sources, and then choose **Remove source**.
**To remove a source using the AWS CLI**
Use the [deregister-transit-gateway-multicast-group-sources](https://docs.aws.amazon.com/cli/latest/reference/ec2/deregister-transit-gateway-multicast-group-sources.html) command.
# Deregister members from a multicast group in AWS Transit Gateway
You don't need to follow this procedure unless you manually added a member to the multicast group.
**To deregister members using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Multicast**.
1. Select the multicast domain.
1. Choose the **Groups** tab.
1. Select the members, and then choose **Remove member**.
**To deregister members using the AWS CLI**
Use the [deregister-transit-gateway-multicast-group-members](https://docs.aws.amazon.com/cli/latest/reference/ec2/deregister-transit-gateway-multicast-group-members.html) command.
# View multicast groups in AWS Transit Gateway
You can view information about your multicast groups to verify that members were discovered using the IGMPv2 protocol. **Member type** (in the console), or `MemberType` (in the AWS CLI) displays IGMP when AWS discovered members with the protocol.
**To view multicast groups using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateway Multicast**.
1. Select the multicast domain.
1. Choose the **Groups** tab.
**To view multicast groups using the AWS CLI**
Use the [search-transit-gateway-multicast-groups](https://docs.aws.amazon.com/cli/latest/reference/ec2/search-transit-gateway-multicast-groups.html) command.
The following example shows that the IGMP protocol discovered multicast group members.
```
aws ec2 search-transit-gateway-multicast-groups --transit-gateway-multicast-domain tgw-mcast-domain-000fb24d04EXAMPLE
{
"MulticastGroups": [
{
"GroupIpAddress": "224.0.1.0",
"TransitGatewayAttachmentId": "tgw-attach-0372e72386EXAMPLE",
"SubnetId": "subnet-0187aff814EXAMPLE",
"ResourceId": "vpc-0065acced4EXAMPLE",
"ResourceType": "vpc",
"NetworkInterfaceId": "eni-03847706f6EXAMPLE",
"MemberType": "igmp"
}
]
}
```
# Set up multicast for Windows Server in AWS Transit Gateway
You'll need to perform additional steps when setting up multicast to work with transit gateways on Windows Server 2019 or 2022. To set this up you'll need to use PowerShell, and run the following commands:
**To set up multicast for Windows Server using PowerShell**
1. Change Windows Server to use IGMPv2 instead of IGMPv3 for the TCP/IP stack:
`PS C:\> New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters -Name IGMPVersion -PropertyType DWord -Value 3 `
**Note**
`New-ItemProperty` is a property index that specifies the IGMP version. Because IGMP v2 is the supported version for multicast, the property `Value` must be `3`. Instead of editing the Windows registry you can run the following command to set the IGMP version to 2.:
`Set-NetIPv4Protocol -IGMPVersion Version2`
1. Windows Firewall drops most UDP traffic by default. You'll first need to check which connection profile is being used for multicast:
```
PS C:\> Get-NetConnectionProfile | Select-Object NetworkCategory
NetworkCategory
---------------
Public
```
1. Update the connection profile from the previous step to allow access to the required UDP port(s):
`PS C:\> Set-NetFirewallProfile -Profile Public -Enabled False`
1. Reboot the EC2 instance.
1. Test your multicast application to ensure traffic is flowing as expected.
# Example: Manage IGMP configurations using AWS Transit Gateway
This example shows at least one host that uses the IGMP protocol for multicast traffic. AWS automatically creates the multicast group when it receives an IGMP `JOIN` message from an instance, and then adds the instance as a member in this group. You can also statically add non-IGMP hosts as members to a group using the AWS CLI. Any instances that are in subnets associated with the multicast domain can send traffic, and the group members receive the multicast traffic.
Use the following steps to complete the configuration:
1. Create a VPC. For more information, see [Create a VPC](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html) in the *Amazon VPC User Guide*.
1. Create a subnet in the VPC. For more information, see [Create a subnet](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html) in the *Amazon VPC User Guide*.
1. Create a transit gateway configured for multicast traffic. For more information, see [Create a transit gateway in AWS Transit Gateway](create-tgw.md).
1. Create a VPC attachment. For more information, see [Create a VPC attachment in AWS Transit Gateway](create-vpc-attachment.md).
1. Create a multicast domain configured for IGMP support. For more information, see [Create an IGMP multicast domain in AWS Transit Gateway](create-tgw-igmp-domain.md).
Use the following settings:
+ Enable **IGMPv2 support**.
+ Disable **Static sources support**.
1. Create an association between subnets in the transit gateway VPC attachment and the multicast domain. For more information see [Associating VPC attachments and subnets with a multicast domain in AWS Transit Gateway](associate-attachment-to-domain.md).
1. The default IGMP version for EC2 is IGMPv3. You need to change the version for all IGMP group members. You can run the following command:
```
sudo sysctl net.ipv4.conf.eth0.force_igmp_version=2
```
1. Add the members that do not use the IGMP protocol to the multicast group. For more information, see [Register members with a multicast group in AWS Transit Gateway](add-members-multicast-group.md).
# Example: Manage static source configurations in AWS Transit Gateway
This example statically adds multicast sources to a group. Hosts do not use the IGMP protocol to join or leave multicast groups. You need to statically add the group members that receive the multicast traffic.
Use the following steps to complete the configuration:
1. Create a VPC. For more information, see [Create a VPC](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html) in the *Amazon VPC User Guide*.
1. Create a subnet in the VPC. For more information, see [Create a subnet](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html) in the *Amazon VPC User Guide*.
1. Create a transit gateway configured for multicast traffic. For more information, see [Create a transit gateway in AWS Transit Gateway](create-tgw.md).
1. Create a VPC attachment. For more information, see [Create a VPC attachment in AWS Transit Gateway](create-vpc-attachment.md).
1. Create a multicast domain configured for no IGMP support, and support for statically adding sources. For more information, see [Create a static source multicast domain in AWS Transit Gateway](create-tgw-domain.md).
Use the following settings:
+ Disable **IGMPv2 support**.
+ To manually add sources, enable **Static sources support**.
The sources are the only resources that can send multicast traffic when the attribute is enabled. Otherwise, any instances that are in subnets associated with the multicast domain can send multicast traffic, and the group members receive the multicast traffic.
1. Create an association between subnets in the transit gateway VPC attachment and the multicast domain. For more information see [Associating VPC attachments and subnets with a multicast domain in AWS Transit Gateway](associate-attachment-to-domain.md).
1. If you enable **Static sources support**, add the source to the multicast group. For more information, see [Register sources with a multicast group in AWS Transit Gateway](add-source-multicast-group.md).
1. Add the members to the multicast group. For more information, see [Register members with a multicast group in AWS Transit Gateway](add-members-multicast-group.md).
# Example: Manage static group member configurations in AWS Transit Gateway
This example shows statically adding multicast members to a group. Hosts cannot use the IGMP protocol to join or leave multicast groups. Any instances that are in subnets associated with the multicast domain can send multicast traffic, and the group members receive the multicast traffic.
Use the following steps to complete the configuration:
1. Create a VPC. For more information, see [Create a VPC](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html) in the *Amazon VPC User Guide*.
1. Create a subnet in the VPC. For more information, see [Create a subnet](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html) in the *Amazon VPC User Guide*.
1. Create a transit gateway configured for multicast traffic. For more information, see [Create a transit gateway in AWS Transit Gateway](create-tgw.md).
1. Create a VPC attachment. For more information, see [Create a VPC attachment in AWS Transit Gateway](create-vpc-attachment.md).
1. Create a multicast domain configured for no IGMP support, and support for statically adding sources. For more information, see [Create a static source multicast domain in AWS Transit Gateway](create-tgw-domain.md).
Use the following settings:
+ Disable **IGMPv2 support**.
+ Disable **Static sources support**.
1. Create an association between subnets in the transit gateway VPC attachment and the multicast domain. For more information see [Associating VPC attachments and subnets with a multicast domain in AWS Transit Gateway](associate-attachment-to-domain.md).
1. Add the members to the multicast group. For more information, see [Register members with a multicast group in AWS Transit Gateway](add-members-multicast-group.md).
# Flexible cost allocation
By default, transit gateway uses a sender-based cost allocation model where data processing charges are allocated to the account that owns the source attachment. You can create custom metering policies that define which accounts should be charged based on traffic flow properties such as attachment types, specific attachment IDs, or network addresses.
Metering policies consist of ordered rules that are evaluated from lowest to highest rule number. When traffic matches a rule, the specified account is charged according to the rule's configuration. You can specify the account owner for allocating costs from the following options:
+ **Source attachment owner** - Charges are allocated to the account that owns the source attachment (default behavior)
+ **Destination attachment owner** - Charges are allocated to the account that owns the destination attachment
+ **Transit Gateway owner** - Charges are allocated to the account that owns the transit gateway
Flexible Cost Allocation enables better cost management for organizations using centralized network architectures, allowing costs to be allocated to the appropriate business units or application owners regardless of network topology.
**Note**
Flexible Cost Allocation enables flexible allocation of metering usage and in turn costs to account owners of your choice. However, tax implications for AWS accounts can vary significantly based on geographic location, usage patterns and other factors. Please review the billing, tax and cost management implications for accounts in your AWS Organization prior to enabling this feature. Reference: [What is AWS Billing and Cost Management?](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-what-is.html)
## Metering policies
Metering policies allow you to configure cost allocation rules for your transit gateway to control which accounts are charged for data processing and transfer costs based on traffic flow properties. This feature enables better cost management and chargeback capabilities for organizations using centralized network architectures.
A metering policy is composed of the following:
+ **Metering policy** - The overall configuration container that contains the Metering Policy Rules. When created, it contains a single default metering policy entry that is configured to charge all traffic to the source attachment owner. Each transit gateway can have only one metering policy.
+ **Metering policy entry** - Individual rules within a metering policy that define specific matching criteria and the account to meter usage. Each entry includes a rule number for evaluation order, traffic matching conditions (such as source and destination attachment types, attachment IDs, CIDR blocks, ports, and protocols), and which account owner to charge for matching traffic. A policy can contain up to 50 entries, evaluated in order from lowest to highest rule number.
You can allocate metering usage to any of the following:
+ **Source attachment owner**: Allocates metering usage to the account that owns the attachment where traffic originates (default behavior)
+ **Destination attachment owner**: Allocates metering usage to the account that owns the attachment where traffic terminates, and
+ **transit gateway owner**: Allocates metering usage to the account that owns the transit gateway.
+ **Middlebox attachments** - (Optional) Designated transit gateway attachments that route traffic through network appliances for security inspection, load balancing, or other network functions. Data usage for the traffic traversing middlebox attachments is metered to the account owner specified in the metering policy. You can specify a maximum of 10 middlebox attachments. Supported middlebox attachment types are Network Function (AWS Network Firewall), VPC and VPN attachments.
### How metering policies work
By default, transit gateway uses a sender-based cost allocation model where data processing charges are metered to the account that owns the source attachment. With metering policies, you can create custom rules to flexibly meter usage based on the following traffic flow properties:
+ Source and destination attachment types (VPC, VPN, Direct Connect Gateway, Peering, Network Function and VPN Concentrator)
+ Source and destination attachment IDs
+ Source and destination IP addresses, Port ranges and protocols
Metering policies consist of ordered rules that are evaluated from lowest to highest rule number. When traffic matches a rule, the specified account is charged according to the rule's metered account setting. Metering policies address several common organizational scenarios:
+ **Hybrid environment cost allocation**: Allocate costs for data entering AWS from on-premises through Direct Connect Gateway to the destination VPC account owner rather than the central IT admin account owner.
+ **Centralized inspection architecture**: Allocate costs to individual application or VPC account owners rather than the central security team for traffic traversing via inspection VPCs.
+ **Application-based chargeback**: Allocate all data usage costs for a workload to the VPC owner regardless of traffic direction.
+ **Client cost allocation**: Allocate data costs to client accounts when they create attachments to your transit gateway.
### Middlebox attachments
Transit gateway metering policies support Middlebox attachments allowing you to flexibly allocate data processing charges for network traffic routed via middlebox appliances such as network firewalls and load balancers. Examples of middlebox attachments are Network Function attachment to AWS Network Firewall or VPC attachments that route traffic to third-party security appliances in a VPC. Traffic between source and destination transit gateway attachments traverses via these middlebox attachments for typical security inspection use-cases. You can define metering policies to flexibly allocated data processing usage on middlebox attachments to the original source attachment, final destination attachment or transit gateway account owner. For Network Function attachments, the AWS Network Firewall data processing charges are also allocated to the metered account.
### Flexible Cost Allocation - Metering usage types
Flexible cost allocation via metering policies applies to following data usage types:
+ Transit gateway Data Processing Usage on VPC, VPN, VPN Concentrator and Direct Connect attachments
+ Site-to-site VPN Data Transfer Out usage on VPN attachments
+ Direct Connect Data Transfer Out usage on Direct Connect attachments.
+ Data transfer usage on TGW peering attachments
+ Transit gateway Data processing usage on Network Function attachments
+ AWS network firewall (NFW) data processing usage on Network Function attachments.
Flexible cost allocation does not apply to attachments hourly usage and multicast data processing usage. For Transit Gateway Connect attachments, metering policy can be defined for the underlying transport VPC or Direct Connect attachment. For Private IP VPN attachments, metering policy can be defined for the underlying transport Direct Connect attachment.
### Considerations and limitations
Consider the following when implementing metering policies for your transit gateway.
#### Permissions
+ Only the transit gateway owner can create, modify, or delete metering policies.
+ Cost allocation settings apply at the transit gateway level.
+ Attachment owners cannot override cost allocation settings configured by the transit gateway owner.
#### Transit Gateway peering
When traffic traverses transit gateway peering connections:
+ Each transit gateway applies its own metering policy independently.
+ Data charges are allocated separately by each transit gateway based on its local policy.
+ Traffic can be thought of as two separate flows: source attachment to peering, and peering to destination attachment.
#### Cloud WAN integration
When a transit gateway is attached to a Cloud WAN core network:
+ Transit gateway data transfer charges on peering connections are allocated according to the transit gateway metering policy.
+ Metering policies are not supported on Cloud WAN core networks.
#### Performance impact
+ Metering policies do not introduce any additional data-path latency.
+ Metering policies have no impact on maximum bandwidth per attachment.
+ There are no changes to transit gateway resource sharing capabilities.
#### Billing integration
+ Cost allocation tags continue to work with metering policies for organizing costs by business unit.
+ Metering policies define which accounts incur costs, while cost allocation tags help categorize those costs.
+ Changes to metering policies take effect at the end of the next billing hour.
#### IPv6 support
Metering policies are supported for both IPv4 and IPv6 traffic. CIDR block matching in policy entries works with both address families.
#### Middlebox attachment support
+ Middlebox metering policy assumes traffic between the original source and destination attachment is hair-pinned via the specified middle-box attachment (example east-west inspection for VPC-to-VPC traffic). Hence the network 5-tuple (source/destination IPs, source/destination ports and protocol) for flows ingressing and egressing out of middle-box attachments must match. Flows with 5-tuple mis-matches on middle-box attachments (e.g. NAT transformation in inspection VPC) are treated as regular source-destination attachment flows (as opposed to middle-box attachment flows).
+ All egress-only flows on the middlebox attachment (for example north-south traffic to internet via IGW in an inspection VPC) are treated as regular source-destination flows (as opposed to middle-box attachment flows).
+ For Network Function attachments when AWS Network firewall drops packets, all data processing usage is charged back to the sender account regardless of metering policy configuration.
# Create an AWS Transit Gateway metering policy
To enable metering policies, you must create a metering policy for your transit gateway and configure policy entries that define how metering usage is allocated. The metering policy establishes the framework and default settings, while policy entries contain the specific rules that determine which accounts are metered based on traffic characteristics.
Metering policy entries function as ordered rules that are applied sequentially from lowest to highest rule number for traffic flowing through your transit gateway. Each entry defines matching criteria such as source and destination attachment types, CIDR blocks, protocols, and port ranges, along with the account that should be metered for matching traffic. When a traffic flow matches multiple entries, the entry with the lowest rule number takes precedence. If no entries match a particular flow, the default metered account specified in the policy is charged.
After creating a policy, you'll need to add policy entries to implement your cost allocation logic. For the steps to create a metering policy entry, see [Create a metering policy entry](create-metering-policy-entry.md).
## Create a metering policy using the console
Create a policy to define flexible cost allocation rules for transit gateway data usage. By default, all flows are metered to the source attachment owner. Create entries to bill specific network flows to different accounts.
**To create a metering policy**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Metering policies**.
1. Choose **Create metering policy**.
1. For **Transit gateway ID** choose the transit gateway you'd like to create metering policy for.
1. (Optional) For **Middlebox attachment IDs**, choose one or more middlebox attachment. By default, data usage is metered to the middlebox owner. Middlebox attachment support enables metering policy to be applied for traffic traversing middlebox attachments. Additional attachments can be added later.
1. (Optional) In the **Tags** section, add tags to help you identify and organize your metering policy:
1. Choose **Add new tag**.
1. Enter a tag **Key** and optionally a tag **Value**.
1. Choose **Add new tag** to add additional tags, or skip to the next step. You can add up to 50 tags.
1. Choose **Create transit gateway metering policy**.
**Note**
The default metered account is the source attachment owner, and after creating a metering policy, you can add entries that define which account gets charged based on traffic flow properties, noting that the default policy entry (which is the last entry) cannot be modified or deleted like other policy entries.
## Create a metering policy using the AWS CLI
A metering policy defines the default cost allocation behavior and global settings for your transit gateway. Use the [create-transit-gateway-metering-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/create-transit-gateway-metering-policy.html).
Required parameters:
+ `--transit-gateway-id` - The ID of the transit gateway to create the policy for
Optional parameters:
+ `--middle-box-attachment-ids` - Supported transit gateway attachment Ids to add to the policy as middlebox
+ `--tag-specifications` - tags for metering policy
**To create a metering policy using the AWS CLI**
1. Run the **create-transit-gateway-metering-policy** command to create a new metering policy with optional middlebox attachments.
```
aws ec2 create-transit-gateway-metering-policy \
--transit-gateway-id tgw-07a5946195a67dc47 \
--middle-box-attachment-ids \
tgw-attach-0123456789abcdef0 \
tgw-attach-0abc123def456789a \
--tag-specifications \
'[{ "ResourceType": "transit-gateway-metering-policy", \
"Tags": [ { "Key": "Env", "Value": "Prod" } ] }]'
```
This command creates a metering policy for the specified transit gateway with provided middlebox attachments and tags.
1. The command returns the following output when the policy is successfully created:
```
{
"TransitGatewayMeteringPolicy": {
"TransitGatewayMeteringPolicyId": "tgw-mp-042d444564d4b2da7",
"TransitGatewayId": "tgw-07a5946195a67dc47",
"MiddleboxAttachmentIds": ["tgw-attach-0123456789abcdef0",
"tgw-attach-0abc123def456789a"],
"State": "pending",
"UpdateEffectiveAt": "2025-11-05T21:00:00.000Z",
"Tags": [{"Key": "Env","Value": "Prod"}]
}
}
```
Note the metering policy ID returned in the response for use in subsequent commands. **describe-transit-gateway-metering-policies** command can be used to get metering policy associated with transit gateway.
# Manage AWS Transit Gateway metering policies
After creating a metering policy, you can manage it by viewing current settings, modifying configuration options, or deleting the policy when no longer needed. Management operations allow you to add or remove middlebox attachments as your network requirements change. You can only create or delete a policy entry. If you need to modify an existing rule, you can delete the entry and create a new one with the modified configuration. All management operations require transit gateway owner permissions and take effect after two billing hour.
Effective metering policy management is crucial for maintaining accurate cost allocation as your network architecture evolves. Organizations often need to adjust their policies when business units change, new applications are deployed, or network topologies are modified. For example middlebox metering support settings may require updates when firewall security architectures change or when new inspection services are introduced into the traffic path.
Policy modifications support various operational scenarios including seasonal traffic pattern changes, merger and acquisition activities, and compliance requirement updates. When managing policies, consider the impact on existing billing arrangements and communicate changes to affected stakeholders before implementation.
Regular policy reviews help ensure that cost allocation remains aligned with business objectives and organizational structures. Best practices include documenting policy changes, testing modifications in non-production environments when possible, and coordinating with finance teams to understand billing implications. Additionally, consider the timing of policy changes to minimize disruption to monthly billing cycles and financial reporting processes.
**Topics**
+ [Edit a metering policy](metering-policy-edit.md)
+ [Delete a metering policy](metering-policy-delete.md)
# Edit an AWS Transit Gateway metering policy
Edit existing metering policies to modify middlebox attachment configurations. Policy modifications take effect at the next billing hour and apply to all future traffic flows through your transit gateway.
## Edit a metering policy using the console
Use the console to modify existing metering policy settings for your transit gateway.
**To edit an existing metering policy using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Metering policies**.
1. Select the metering policy you want to modify by choosing its policy ID
1. Modify the available policy settings under **Actions**. Console only allow add and remove of Middle box attachments.
1. **Middlebox attachments** - Add or remove transit gateway attachments that should be treated as middleboxes for specialized billing.
## Edit a metering policy using the AWS CLI
Use the **modify-transit-gateway-metering-policy** command to view and modify metering policies.
Required parameters for modify operations:
+ `--transit-gateway-metering-policy-id` - The ID of the metering policy to modify
+ `--add-middle-box-attachment-ids` or `--remove-middle-box-attachment-ids` - Supported transit gateway attachment Ids to add or remove from the policy as middlebox
**To view and edit metering policies using the AWS CLI**
1. (Optional) View existing metering policies using the **describe-transit-gateway-metering-policies** command to see current configuration settings:
```
aws ec2 describe-transit-gateway-metering-policies
```
This command returns all metering policies in your account, showing their current state, and attachments enabled as middlebox for each of the metering policy.
1. Modify a metering policy using the **modify-transit-gateway-metering-policy** command to update configuration options:
```
aws ec2 modify-transit-gateway-metering-policy \
--transit-gateway-metering-policy-id tgw-mp-042d444564d4b2da7 \
--add-middle-box-attachment-ids tgw-attach-0123456789abcdef1 \
--remove-middle-box-attachment-ids tgw-attach-0abc123def456789a
```
This command modifies a metering policy by adding and/or removing middlebox attachments.
1. The command returns the following output when the policy is successfully modified:
```
{
"TransitGatewayMeteringPolicy": {
"TransitGatewayMeteringPolicyId": "tgw-mp-042d444564d4b2da7",
"TransitGatewayId": "tgw-07a5946195a67dc47",
"MiddleboxAttachmentIds": ["tgw-attach-0123456789abcdef0",
"tgw-attach-0123456789abcdef1"],
"State": "modifying",
"UpdateEffectiveAt": "2025-11-05T21:00:00.000Z"
}
}
```
The changes can take up to two billing hours to take effect.
# Delete an AWS Transit Gateway metering policy
Delete metering policies when they are no longer required for your transit gateway cost allocation strategy. Deleting a policy reverts cost allocation to the default sender-based model where data processing and data transfer charges are allocated to the account that owns the source attachment. All policy entries associated with the deleted metering policy are also removed.
## Delete a metering policy using the console
Use the console to remove metering policies that are no longer needed.
**To delete a metering policy using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Metering policies**.
1. Select the policy you want to delete by choosing its policy ID.
1. Choose **Actions**, and then **Delete**.
1. Confirm the deletion by typing **delete** in the confirmation dialog.
1. Choose **Delete**.
**Important**
Deleting a metering policy is irreversible. All policy entries and configuration settings will be permanently removed, and cost allocation will revert to the default sender-based model.
## Delete a metering policy using the AWS CLI
Use the **delete-transit-gateway-metering-policy** command to delete metering policies programmatically.
Requirements:
+ Transit gateway owner permissions
Required parameters:
+ `--transit-gateway-metering-policy-id` - The ID of the metering policy to delete
**To view and delete metering policies using the AWS CLI**
1. (Optional) View existing metering policies using the **describe-transit-gateway-metering-policies** command to see current configuration settings:
```
aws ec2 describe-transit-gateway-metering-policies
```
This command returns all metering policies in your account, showing their current state and configuration.
1. Delete a metering policy using the **delete-transit-gateway-metering-policy** command to permanently remove the policy:
```
aws ec2 delete-transit-gateway-metering-policy \
--transit-gateway-metering-policy-id tgw-mp-042d444564d4b2da7
```
This command permanently removes the specified metering policy and all associated entries. Cost allocation will revert to the default sender-based model for all future traffic flows. This change also takes 2 billing hours to take effect.
1. The command returns the following output when the policy is successfully deleted:
```
{
"TransitGatewayMeteringPolicy": {
"TransitGatewayMeteringPolicyId": "tgw-mp-042d444564d4b2da7",
"TransitGatewayId": "tgw-07a5946195a67dc47",
"MiddleboxAttachmentIds": ["tgw-attach-0123456789abcdef0",
"tgw-attach-0123456789abcdef1"],
"State": "deleting",
"UpdateEffectiveAt": "2025-11-05T21:00:00.000Z"
}
}
```
The response confirms the policy is being deleted with a `deleting` state while the removal is processed across the transit gateway infrastructure.
# Create an AWS Transit Gateway metering policy entry
By default, all flows are metered to the source attachment owner. To meter specific flows to different accounts, create individual policy entries that define which account gets charged based on traffic flow properties.
Metering policy entries function as conditional rules that are evaluated in sequential order based on their rule numbers when traffic flows through your transit gateway. Each entry acts as an "if-then" statement: if the traffic matches the specified criteria (such as source attachment type, destination CIDR block, or protocol), then charge the designated account. The system evaluates entries from lowest to highest rule number, and the first matching entry determines the billing account for that traffic flow.
Entries support a wide range of matching criteria including attachment types (VPC, VPN, Direct Connect Gateway), specific attachment IDs, source and destination CIDR blocks, protocol types, and port ranges. You can combine multiple criteria within a single entry to create precise targeting rules. For example, you might create an entry that matches all HTTPS traffic (port 443) from VPC attachments to a specific destination CIDR range and charges those flows to a security team's account. If no entries match a particular traffic flow, the default metered account specified in the parent metering policy is charged, ensuring all traffic is properly billed. Creating an entry takes 2 billing hours to take effect.
**Important**
Plan rule numbers carefully - Leave gaps (e.g., 10, 20, 30) to allow for future insertions
Test entries with less specific conditions first before adding more restrictive rules
Use specific matching conditions to avoid unintended billing
## Create a metering policy entry using the console
A metering policy defines the default cost allocation behavior and global settings for your transit gateway.
**To create a metering policy entry using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Metering policies**.
1. Select the metering policy ID link to view its details.
1. Choose the **Metering policy entries** tab.
1. Choose **Create metering policy entry**.
1. **Policy rule number** -This should be a unique number (1- 32,766) that determines evaluation order. Lower numbers have higher priority.
1. **Metered account** - Choose one of the following account types to be charged for matching traffic flows:
1. **Source Attachment Owner**
1. **Destination Attachment Owner**
1. **Transit Gateway Attachment Owner**
1. (Optional) Choose **Rule conditions** - These optional conditions define criteria to match specific traffic:
+ **Source attachment type or ID** - Filter by attachment type (VPC, VPN, Direct Connect Gateway, Peering) or ID.
+ **Destination attachment type or ID** - Filter by destination attachment type or ID
+ **Source CIDR block** - Match traffic from specific IP ranges
+ **Destination CIDR block** - Match traffic to specific IP ranges
+ **Source port range** - Match specific source ports
+ **Destination port range** - Match specific destination ports
+ **Protocol** - Filter by protocol for the rule (1, 6, 17, etc.)
1. Choose **Create metering policy entry** to save the configuration.
## Create a metering policy entry using the AWS CLI
Policy entries define specific rules for cost allocation based on traffic characteristics. Rules are evaluated in order from lowest to highest rule number.
Required parameters:
+ `--transit-gateway-metering-policy-id` - The ID of the metering policy to add the entry to
+ `--policy-rule-number` - A unique number (1-32,766) that determines evaluation order
+ `--metered-account` - payer type (source-attachment-owner/ destination-attachment-owner / transit-gateway-owner)
Optional parameters:
These optional parameters that define criteria to match specific traffic:
+ `--source-transit-gateway-attachment-id` - The ID of the source transit gateway attachment.
+ `--source-transit-gateway-attachment-type` - The type of the source transit gateway attachment.
+ `--source-cidr-block` - The source CIDR block for the rule.
+ `--source-port-range` - The source port range for the rule.
+ `--destination-transit-gateway-attachment-id` - The ID of the destination transit gateway attachment.
+ `--destination-transit-gateway-attachment-type` - The type of the destination transit gateway attachment.
+ `--destination-cidr-block` - The destination CIDR block for the rule.
+ `--destination-port-range` - The destination port range for the rule.
+ `--protocol` - The protocol number for the rule
**To create a metering policy entry using the AWS CLI**
1. Use the **create-transit-gateway-metering-policy-entry** command to create a new policy entry that routes VPC traffic to a specific metered account:
```
aws ec2 create-transit-gateway-metering-policy-entry \
--transit-gateway-metering-policy-id tgw-mp-042d444564d4b2da7 \
--policy-rule-number 100 \
--destination-transit-gateway-attachment-type vpc \
--metered-account destination-attachment-owner
```
This command creates a policy entry with rule number 100 that matches traffic destined for VPC attachments and charges the destination attachment owner for those flows.
1. The command returns the following output when the entry is successfully created:
```
{
"TransitGatewayMeteringPolicyEntry": {
"MeteredAccount": "destination-attachment-owner",
"MeteringPolicyRule": {
"DestinationTransitGatewayAttachmentType": "vpc"
},
"PolicyRuleNumber": 100,
"State": "available",
"UpdateEffectiveAt": "2025-11-06T02:00:00.000Z"
}
}
```
The response confirms the entry was created with a "available" state while it's being activated across the transit gateway infrastructure.
# Delete an AWS Transit Gateway metering policy entry
Delete metering policy entries when specific cost allocation rules are no longer required for your network traffic flows. Entry deletion helps simplify policy management by removing outdated or unnecessary rules while maintaining the overall policy structure. When you delete an entry, traffic that previously matched the deleted rule will be evaluated against remaining entries in rule number order, or fall back to the default policy behavior if no other entries match.
Before deleting entries, consider the impact on current billing arrangements and traffic flows. Once deleted, the change takes upto 2 billing hours to get effective and cannot be undone, so coordinate changes with affected account owners and finance teams. Review remaining entries to ensure proper traffic coverage and billing allocation after the deletion. The rule evaluation order for remaining entries stays unchanged, maintaining predictable cost allocation behavior for continuing traffic flows.
**Important**
Deletion is irreversible
Traffic previously matching this entry will be re-evaluated against remaining entries
Review remaining entries to ensure proper traffic coverage
## Delete a metering policy entry using the console
Use the console to remove policy entries through an intuitive interface that provides confirmation dialogs to prevent accidental deletions.
**To delete a policy entry using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Metering policies**.
1. Select the metering policy containing the entry you want to delete.
1. Select the entry you want to remove and choose **Delete**.
1. In the confirmation dialog, review the entry details and type **delete** to confirm the removal.
1. Choose **Delete** to permanently remove the entry.
## Delete a metering policy entry using the AWS CLI
Use the **delete-transit-gateway-metering-policy-entry** command to remove policy entries programmatically.
Requirements:
+ Transit gateway owner permissions
+ Valid metering policy ID and entry rule number
Required parameters:
+ `--transit-gateway-metering-policy-id` - The ID of the metering policy
+ `--policy-rule-number` - The rule number of the entry to delete
**To view and delete policy entries using the AWS CLI**
1. (Optional) View existing policy entries using the **get-transit-gateway-metering-policy-entries** command to see current configuration settings:
```
aws ec2 get-transit-gateway-metering-policy-entries \
--transit-gateway-metering-policy-id tgw-mp-0123456789abcdefg
```
This command returns all entries for the specified policy, showing their rule numbers, matching criteria, and metered accounts.
1. Delete a policy entry using the **delete-transit-gateway-metering-policy-entry** command to permanently remove the entry:
```
aws ec2 delete-transit-gateway-metering-policy-entry \
--transit-gateway-metering-policy-id tgw-mp-0123456789abcdefg \
--policy-rule-number 100
```
This command permanently removes the specified entry from the policy. Traffic that previously matched this entry will be immediately re-evaluated against remaining entries or fall back to the default policy behavior.
1. The command returns the following output when the entry is successfully deleted:
```
{
"TransitGatewayMeteringPolicyEntry": [
{
"PolicyRuleNumber": 100,
"MeteredAccount": "destination-attachment-owner",
"UpdateEffectiveAt": "2024-01-01T01:00:00+00:00",
"state": "deleted",
"MeteringPolicyRule": {
"DestinationTransitGatewayAttachmentType": "vpc"
}
}
}
```
The response confirms the entry is being deleted with a "deleted" state while the removal is processed across the transit gateway infrastructure.
# Manage AWS Transit Gateway metering policy middlebox attachments
transit gateway metering policies support Middlebox attachments allowing you to flexibly allocate data processing charges for network traffic routed via middlebox appliances such as network firewalls and load balancers. Examples of middlebox attachments are Network Function attachment to AWS Network Firewall or VPC attachments that route traffic to third-party security appliances in a VPC. Traffic between source and destination transit gateway attachments traverses via these middlebox attachments for typical security inspection use-cases. You can define metering policies to flexibly allocated data processing usage on middlebox attachments to the original source attachment, final destination attachment or transit gateway account owner. For Network Function attachments, the AWS Network Firewall data processing charges are also allocated to the metered account.
Designated transit gateway attachments that route traffic through network appliances for security inspection, load balancing, or other network functions. Data usage for the traffic traversing middlebox attachments is metered to the account owner specified in the metering policy. You can specify a maximum of 10 middlebox attachments. Supported middlebox attachment types are Network Function (AWS Network Firewall), VPC and VPN attachments.
**Topics**
+ [Add middlebox attachments](create-middlebox-attachment.md)
+ [Remove middlebox attachments](edit-middlebox-attachment.md)
# Add AWS Transit Gateway metering policy middlebox attachments
You can add middlebox attachments to integrate network appliances into your Transit Gateway metering policy. This allows you to route specific traffic through security appliances, load balancers, or other network functions while maintaining granular cost allocation control.
**Important**
Ensure middlebox appliances are properly configured and accessible
Test traffic routing before applying to production workloads
Monitor middlebox performance to avoid introducing latency
Configure appropriate failover behavior for high availability
## Add middlebox attachments using the console
**To add a middlebox attachment entry**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Metering policies**.
1. Select the metering policy ID link to view its details.
1. Choose the **Middlebox attachments** tab.
1. Choose **Add**.
1. When prompted, Select the middlebox attachment IDs that should be treated as middleboxes for specialized billing. You can select up to 10 middlebox attachments.
1. Choose **Add middlebox attachments** to save the configuration.
## Add middlebox attachments using the AWS CLI
Use the **modify-transit-gateway-metering-policy** command to add attachments.
Before you begin, ensure you have the following required parameters:
+ `--transit-gateway-metering-policy-id` - The ID of the existing metering policy
+ `--add-middle-box-attachment-ids` - One or more attachment IDs to add to the policy (for adding attachments)
**To add middlebox attachments to an existing policy using the AWS CLI**
1. In the following example, **modify-transit-gateway-metering-policy** is used to add four middlebox attachments to an existing metering policy. The command adds the specified attachment IDs to the existing list without removing current attachments:
```
aws ec2 modify-transit-gateway-metering-policy \
--transit-gateway-metering-policy-id tgw-mp-0123456789abcdefg \
--add-middle-box-attachment-ids tgw-attach-0bdc681c211bf71f3 tgw-attach-0987654321fedcba0 tgw-attach-0456789012345abcd tgw-attach-0fedcba0987654321
```
1. In the following example response, the JSON output shows the updated policy configuration with all four middlebox attachments now included:
```
{
"TransitGatewayMeteringPolicy": {
"TransitGatewayMeteringPolicyId": "tgw-mp-0123456789abcdefg",
"TransitGatewayId": "tgw-0ecec6433f4bfe55a",
"MiddleBoxAttachmentIds": [
"tgw-attach-0bdc681c211bf71f3",
"tgw-attach-0987654321fedcba0",
"tgw-attach-0456789012345abcd",
"tgw-attach-0fedcba0987654321"
],
"State": "available",
"UpdateEffectiveAt": "2024-09-05T16:00:00.000Z"
}
}
```
# Remove AWS Transit Gateway metering policy middlebox attachments
By default, metering costs are attributed to the middlebox attachment owner. However, you can modify these assignments to ensure costs are properly allocated to the actual source or destination of the traffic. You can add or remove up to 10 total middlebox attachment for a metering policy.
## Remove middlebox attachments using the console
Use the Amazon VPC console to remove middlebox attachments from your metering policy configuration.
**To remove middlebox attachments**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Transit gateways**, **Metering policies**.
1. Select the metering policy that you want to modify.
1. Choose the **Middlebox attachments** tab.
1. Select up to 10 middlebox attachments to remove from the metering policy.
1. Choose **Remove**.
1. When prompted, you can update your chosen middlebox attachments to remove. Traffic through removed attachments will be metered to the middlebox attachment owner.
1. Choose **Remove middlebox attachments**.
## Remove middlebox attachments using the AWS CLI
Use the **modify-transit-gateway-metering-policy** command to remove attachments.
Before you begin, ensure you have the following required parameters:
+ `--transit-gateway-metering-policy-id` - The ID of the existing metering policy
+ `--remove-middle-box-attachment-ids` - One or more attachment IDs to remove from the policy (for removing attachments)
**To remove middlebox attachments from an existing policy using the AWS CLI**
1. In the following example, **modify-transit-gateway-metering-policy** is used to remove two specific middlebox attachments from an existing metering policy. The command removes only the specified attachment IDs while preserving the remaining attachments:
```
aws ec2 modify-transit-gateway-metering-policy \
--transit-gateway-metering-policy-id tgw-mp-0123456789abcdefg \
--remove-middle-box-attachment-ids tgw-attach-0456789012345abcd tgw-attach-0fedcba0987654321
```
1. In the following example response, the JSON output shows the updated policy configuration with the specified attachments removed and the remaining attachments still active:
```
{
"TransitGatewayMeteringPolicy": {
"TransitGatewayMeteringPolicyId": "tgw-mp-0123456789abcdefg",
"TransitGatewayId": "tgw-0ecec6433f4bfe55a",
"MiddleBoxAttachmentIds": [
"tgw-attach-0bdc681c211bf71f3",
"tgw-attach-0987654321fedcba0"
],
"State": "available",
"UpdateEffectiveAt": "2024-09-05T16:00:00.000Z"
}
}
```
**Topics**
+ [Metering policies](#metering-policies-main)
+ [Create a metering policy](metering-policy-create-policy.md)
+ [Manage metering policies](metering-policy-manage-policy.md)
+ [Create a metering policy entry](create-metering-policy-entry.md)
+ [Delete a metering policy entry](metering-policy-entry-delete.md)
+ [Manage metering policy middlebox attachments](metering-policy-middlebox.md)