AWS History and Timeline regarding AWS Transit Gateway - Overview, Functions, Features, Summary of Updates, and Introduction

First Published:
Last Updated:

A Transit Gateway configuration set up several years ago is now yours to run. Then, the name AWS Cloud WAN enters the picture. The initial question that typically arises is whether to retire Transit Gateway. To answer this question, it's necessary to have a timeline outlining what Transit Gateway has become capable of over the past few years.

This article presents a historical timeline of AWS Transit Gateway feature additions. What it follows is not a list of features. It is a record of when this one hub became able to take on each new thing. The growing number of attachment types is itself the record of how far the hub's reach has widened.

What a Transit Gateway Can Have Attached to It
What a Transit Gateway Can Have Attached to It
This timeline differs from historical records of other AWS services in one key aspect: the newer layers have not replaced this hub. AWS Cloud WAN became generally available on July 12, 2022. Over the subsequent four years, three new attachment types and one new routing method have been added to Transit Gateway. This article documents these facts, citing dates and links to official AWS resources.

This article does not offer recommendations on which option to choose. It does not address which services to use – Transit Gateway, Cloud WAN, VPC peering, or PrivateLink – nor does it discuss migration strategies or order. It also avoids discussing pricing and billing details. Furthermore, it will not include construction procedures or examples of CLI commands. Instead, it focuses solely on documenting what became available on which date, and what its state is as of the verification date. Where AWS has not stated a reason, this article does not supply one.

All information presented in this article was verified as of September 11, 2026.

Related articles on hidekazu-konishi.com:

Background and Method of Creating AWS Transit Gateway Historical Timeline

What Counts as a Turning Point Here

This timeline is not exhaustive. Transit Gateway has been an active service since 2018, and listing every announcement would leave Region expansions as the majority. Only the following five types of rows are included:

  1. Additions to Supported Attachment Types: Entries indicating the addition of new attachment types. This is the primary focus of this article.
  2. Changes to Routing Decisions: Entries describing changes to how the next destination is determined, such as updates to route tables, prefix lists, appliance mode, and Policy-Based Routing.
  3. Increased Options for Connecting Hubs: Entries related to increased options for connecting hubs, including inter-Region peering, intra-Region peering, and connections to Cloud WAN.
  4. Expanded Visibility into Hub Operations: Entries describing new tools for seeing what happens inside the hub, such as CloudWatch metrics, flow logs, and Network Manager.
  5. Changes to Limits and Operational Agreements: Entries related to changes in quotas and service level agreements.

The Primary Sources This Article Used

Each row includes the URL for the corresponding primary source material. Three groups of sources were used:

  • AWS What's New — Official announcements. This article prioritizes this source as the definitive record of dates. Collection used the whats-new-v2 AWS Transit Gateway tag and then took a difference against the tags of related services.
  • Amazon VPC Transit Gateway User Guide, Document history — The update history of the guide itself. As of the verification date, this section contains 22 entries. Changes not reflected in the What's New announcements can only be found here.
  • AWS Networking and Content Delivery blog, and individual service user guides — Information on functionality and limitations not included in the official announcements.

⛔ Secondary media and summary articles are not considered primary source material.

⚠ Data collection based solely on tags may result in missing entries. As of the verification date, the AWS Transit Gateway tag contains information for 68 announcements. This article's timeline includes three announcements that are not included in this tag. The row for prefix lists and the row for Network Manager's support for multiple accounts inside an organization both carried the Amazon VPC tag, and the row for AWS Direct Connect's expanded connection speeds carried the AWS Cloud WAN tag. Conversely, there are several changes recorded in the Document history that do not have corresponding announcements in What's New. ⇒ Each row therefore carries the URL of the source that row was taken from.

Where the Two Primary Sources Disagree on the Date

⛔ What's New and Document history sometimes assign different dates to the same change. The discrepancies found as of the verification date are listed below:

ChangeWhat's NewDocument historyDifference (Days)Date Used in This Article
AWS Direct Connect Support2019-04-302019-03-27342019-03-27
Flexible Cost Allocation2025-11-212025-11-2012025-11-21
Client VPN Attachment2026-04-232026-04-2032026-04-23
Policy-Based Routing2026-07-302026-07-2822026-07-30

⇒ This article uses the publication date from What's New when that information is available for a particular entry; otherwise, it uses the date from the Document history. You can determine which date was used by checking the URL referenced in each row. ⛔ Dates are not invented to make the precision uniform.

⛔ There is a specific reason why the first row is an exception. The What's New page announcing AWS Direct Connect support redirects to the What's New index when accessed, and the original content is no longer available. ⇒ While a record of the announcement still exists, only the Document history provides a primary source a reader can open. Therefore, this row uses the date from the Document history.

⚠ Old announcement pages becoming unreadable is not something that has happened across this timeline. On the verification date, announcement pages from 2018 and from December 2019 both returned their full content. ⇒ Individual pages have been withdrawn.

⚠ These date discrepancies are not errors. AWS timeline articles cite three sources as the basis for dates: What's New, the AWS blog, and the Document history in the AWS user guides. A date that matches any one of those three has a basis.

The Track Column and the Type Column

Each row in the timeline has two labels.

Track names what the row widened in the hub. This column is the axis of this article, turned into a column.

  • Launch — Rows indicating the introduction of a service.
  • Attachment — Rows indicating the expansion of what can be attached to the hub. This includes both the addition of a new attachment type and the broadening of an existing one. ⛔ Counting the rows in this column does not equate to counting the number of attachment types.
  • Routing — Rows indicating an expansion in routing options.
  • Peering — Rows indicating advancements in methods for connecting hubs.
  • Multicast — Rows related to one-to-many distribution.
  • Observability — Rows indicating an increase in methods for monitoring and understanding system behavior.
  • Security — Rows related to communication control and protection.
  • Operations — Rows concerning limits, operational commitments, and cost allocation methods.

Type indicates the nature of the date. This distinction is used to avoid using the same terminology for announcements and entries found in documentation.

  • GA — Rows indicating announcements made in AWS What's New as generally available.
  • Docs — Rows that are not associated with a corresponding What's New announcement but are only listed in the user guide's Document history.
  • Preview — Rows indicating announcements made as previews.
  • Quota increase — Rows indicating an increase in established quotas.
  • SLA update — Rows indicating changes to the service level agreement.

What This Timeline Does Not Include

What is left out, and why, is listed first.

  • Rows for Region expansions. As of the verification date, approximately half of the 68 announcements carrying the AWS Transit Gateway tag were Region expansions. Listing them one by one does not show what the hub came to take on. ⛔ Instead, for features whose availability depends on the Region, they are named in the text of the relevant row.
  • Pricing and billing information. Transit Gateway has charges based on the number of attachments and the volume of traffic processed. This article focuses on entries that reflect changes in how costs are allocated, but does not include any comparisons of specific prices or rates.
  • Changes to the console interface and updates to SDK versions.
  • Announcements related to services that utilize Transit Gateway. There are numerous announcements indicating that other AWS services became able to reach resources through Transit Gateway, but this does not represent an expansion of Transit Gateway's own capabilities. ⇒ The only exception is when an announcement introduces a new type of attachment. As of the verification date, there were three such cases, and the other service announced each of them.
  • The history of feature additions to AWS Cloud WAN itself. This article includes only two entries related to Cloud WAN: the announcement of the preview and the general availability release. These two entries are included because Cloud WAN is often the starting point for readers' questions, not because this article is building a complete timeline of Cloud WAN.

What This Article Leaves to Other Articles

This article focuses solely on detailing what features and updates were added to Transit Gateway and when. Design and selection are held by previously published articles.

  • The complete timeline for VPC is available in the previously published AWS History and Timeline regarding Amazon VPC. This article picks up three lines from that article, focusing on Transit Gateway with greater detail. ⛔ It does not include any lines related to other VPC features.
  • The previously published AWS VPC Connectivity Decision Guide provides information on choosing between Transit Gateway, VPC peering, PrivateLink, VPC Lattice, and Cloud WAN. That article also covers the relationship between Cloud WAN and Transit Gateway, as well as the steps involved in migrating between them. ⛔ This article does not provide selection criteria or migration procedures.
  • The previously published AWS Hybrid Connectivity Decision Guide details the choice between AWS Direct Connect and AWS Site-to-Site VPN for connecting to on-premises environments.
  • The history of feature additions for AWS Network Firewall is documented in the previously published AWS History and Timeline regarding AWS Network Firewall. This article includes a single line indicating an increase in attachment types available on the Transit Gateway side.
  • The previously published VPC Encryption Controls outlines what VPC Encryption Controls guarantee and to what extent. That article covers the boundaries where guarantees are no longer in effect when using Transit Gateway. ⛔ This article includes a single line indicating a feature addition, but does not detail the scope of those guarantees.
  • Definitions for various terms are available in the previously published AWS Networking Glossary. ⚠ That article uses the term VPN concentrator as a general term to describe Virtual Private Gateways. When this article uses VPN Concentrator in uppercase, it refers to the attachment type added in 2025.
  • The previously published AWS Hybrid Connectivity Decision Guide provides guidance on how to incorporate VPN Concentrator into your designs. That article details which features it can be combined with and which it cannot. ⛔ This article includes only a single line indicating a date.
  • The previously published AWS Retired Services History and Timeline lists services that have moved to a maintenance phase. This article notes only one point: that, as of the verification date, Transit Gateway is not listed in that service retirement list.
  • The other two articles published alongside this one address the same principle – that a new layer does not erase the previous layer – but cover different topics. Information on calling conventions can be found in API Design Paradigms History and Timeline, while details on directories and IDs are in Microsoft Identity History and Timeline. This article focuses on routing.

AWS Transit Gateway Historical Timeline (Updates from November 26, 2018)

The following is a historical timeline for AWS Transit Gateway. Entries are listed in chronological order, with links to original source materials provided for each entry.

Use the following index to navigate by year:

  • 2018 - The hub arrives. At this point only a VPC and a VPN connection can be attached.
  • 2019 - Direct Connect can be attached, and inter-Region peering and one-to-many distribution arrive.
  • 2020 - Additional routing options are introduced, and support is added for integrating with SD-WAN devices.
  • 2021 - Transit gateways in the same Region can be peered with each other.
  • 2022 - Cloud WAN becomes generally available, and the hub side moves in the same week.
  • 2023 - Bandwidth limits are documented.
  • 2024 - Security group references can now extend beyond VPCs.
  • 2025 - Two more attachment types are added.
  • 2026 - One further addition is made, and routing capabilities expand beyond simple destination-based routing.

2018-2020 - The Hub Takes Shape

During the period from 2018 to 2020, the core framework of what is now known as Transit Gateway was largely completed. ⚠ However, it's important to note that the types of attachments added during this time all directly carry network traffic. As of the end of 2020, five types of attachments were supported: VPCs, VPN connections, Direct Connect gateways, hub-to-hub peering, and Transit Gateway Connect. Security control and cost allocation were not yet the hub's job.

DateTrackTypeSummary
2018-11-26LaunchGAAWS Transit Gateway was launched. The announcement was titled Introducing AWS Transit Gateway. ⇒ This marked the beginning of a new way to connect VPCs, offering an alternative to using VPC peering. Previously, when you had N VPCs, you needed N×(N-1)/2 peering connections, each requiring individual route configuration. ⚠ At this point, only VPC and VPN connections were supported. What this article follows is how the set of attachment types grew from here. References: Introducing AWS Transit Gateway
2019-03-27AttachmentDocsIt became possible to attach AWS Direct Connect gateways. The Document history states, You can use an Direct Connect gateway to connect your Direct Connect connection over a transit virtual interface to the VPCs or VPNs attached to your transit gateway. ⇒ This allowed traffic originating from a dedicated connection to reach multiple VPCs connected to the hub. ⛔ A corresponding What's New announcement could not be found as of the verification date. While the announcement was published on April 30, 2019, and this article confirms that record, the page redirects to a What's New index without the original content. ⇒ Therefore, this article uses the Document history as the primary source, aligning the date accordingly. References: Document history for transit gateways
2019-12-03PeeringGAInter-Region peering became available. This allowed you to connect hubs and exchange routes between them. ⇒ For the first time, it became possible to build a single network spanning multiple Regions using only hubs. ⚠ The word peering carries two meanings in this article. It refers to both VPC peering (between VPCs) and transit gateway peering attachments (between hubs). This article consistently uses descriptive terms to differentiate between the two. References: AWS Transit Gateway now supports Inter-Region Peering
2019-12-03MulticastGAThe hub gained the ability to relay one-to-many traffic. The announcement stated, AWS Transit Gateway now supports routing internet protocol (IP) multicast traffic between attached Amazon Virtual Private Cloud (VPC) connections. ⇒ This enabled the distribution of the same data to multiple recipients simultaneously, across VPCs. ⚠ At this stage, registering recipients still required using AWS APIs. Support for a standard protocol was still a year away. References: Run IP Multicast Workloads in the Cloud Using AWS Transit Gateway
2019-12-03ObservabilityGAAWS Transit Gateway Network Manager was launched. This tool provides a single point of visibility for networks spanning multiple Regions and sites. ⇒ As the number of hubs grows, it becomes necessary to have a way to understand how each hub is connected. This tool provides that capability. ⛔ The name of this feature is retained as it was at the time of the announcement. While the documentation for this feature is now titled AWS Global Networks for Transit Gateways, changing the name would effectively erase the historical record of this feature's introduction. ⚠ This feature later became a standalone document (see the row for 2021-12-02). References: Amazon Web Services Announces AWS Transit Gateway Network Manager to Centrally Monitor Your Global Network
2020-05-04ObservabilityGARoute Analyzer was added. This allows you to analyze how traffic is routed from a specified source to a destination within a hub's route table. ⇒ You can now verify whether your routing configuration is working as intended, without actually sending traffic. References: Announcing Route Analyzer in AWS Transit Gateway Network Manager
2020-07-06ObservabilityGACloudWatch metrics became available on a per-attachment basis. Previously, only aggregate metrics for the entire hub were available. ⇒ You can now see how much traffic is flowing through each individual attachment. References: AWS Transit Gateway now supports more granular CloudWatch Metrics for improved network monitoring
2020-08-24RoutingGAHub route tables could now reference prefix lists. You can create named lists of CIDR blocks, and then specify those lists as destinations in your routes. ⇒ Adding and removing routes can now be done by editing the prefix list, rather than directly editing the route table. ⚠ This announcement does not appear in the AWS Transit Gateway tag list. It is associated with the Amazon VPC tag list. The article notes that relying solely on tag-based collection can lead to omissions like this. References: AWS Transit Gateway customers can now use their own Prefix Lists to simplify IP management
2020-08-24OperationsDocsIt became possible to modify existing hubs. The Document history records this as Modify transit gateway, stating You can modify the configuration options for your transit gateway. ⇒ Previously, you had to recreate a hub to change its configuration. ⛔ A corresponding What's New announcement could not be found. This article uses the date from the Document history. References: Document history for transit gateways
2020-10-29RoutingDocsAppliance mode could now be enabled on VPC attachments. The user guide explains that enabling this mode ensures that traffic between the source and destination uses the same availability zone for the attachment's entire duration. ⇒ This resolves an issue where stateful appliances on the hub's downstream side might receive traffic on different zones for the return flow. Stateful appliances require seeing both the incoming and outgoing traffic to validate communication. ⛔ A corresponding What's New announcement could not be found. References: Document history for transit gateways
2020-12-10AttachmentGATransit Gateway Connect was launched. This introduces a new attachment type that allows you to directly connect SD-WAN appliances or third-party virtual appliances running within a VPC to the hub. ⇒ Counting only the types added after launch, this is the third. ⛔ This article always writes the full name Transit Gateway Connect. Using Connect alone is ambiguous, potentially referring to other services. References: Introducing AWS Transit Gateway Connect to simplify SD-WAN branch connectivity
2020-12-10MulticastGARecipients could now register using standard protocols. This refers to support for the Internet Group Management Protocol (IGMP). ⇒ This brings one-to-many distribution, introduced a year ago, into a form that existing applications can use without modification. Previously, registering recipients required using AWS APIs. References: AWS customers can now use industry standard Internet Group Management Protocol (IGMP) to easily deploy, manage and scale their multicast applications in AWS cloud

2021-2023 - The Neighbors Arrive, and the Limits Get Written Down

Over these three years, the origin of the question this article's readers are carrying becomes visible. That origin is AWS Cloud WAN. ⚠ It's important to note that on the very day after Cloud WAN became generally available, changes were also implemented on the hub side.

DateTrackTypeSummary
2021-03-30RoutingQuota increaseThe default limit on the number of dynamic routes Transit Gateway Connect can handle went up. The announcement stated that the number of dynamic routes that can be advertised from on-premises devices or virtual routers in a VPC to the hub has increased from 100 to 1,000. ⇒ This represents an expansion of the attachment type added a little over three months earlier, to better suit real-world usage. References: AWS Transit Gateway Connect increases service quotas for route limits
2021-06-03OperationsSLA updateThe Service Level Agreement (SLA) has been changed from 99.95% to 99.99%. ⇒ Since the hub serves as a single point of aggregation for routes, any disruption to it can have a significant impact. This change, while not a feature addition, represents a shift in the criteria for determining what can be directed to the hub. References: AWS Transit Gateway Updates Service Level Agreement to 99.99%
2021-11-01ObservabilityGANetwork Manager now includes APIs to automate network analysis. It can aggregate network resources, analyze routes, and extract telemetry data across multiple Regions. ⇒ This functionality, previously accessible only through the interface, is now available through programmable APIs. References: AWS Transit Gateway Network Manager launches new APIs to simplify network and route analysis in your global network
2021-12-01PeeringGATransit gateways in the same Region can now be peered with each other. The announcement stated that organizations can now connect their own hubs, allowing departments to interconnect. ⇒ Intra-Region peering arrived two years after inter-Region peering. ⚠ The order is counterintuitive: the peering that spans the greater distance arrived first. References: AWS Transit Gateway introduces intra-region peering for simplified cloud operations and network connectivity
2021-12-02PeeringPreviewAWS Cloud WAN was announced in preview. This is a service that allows you to build and operate a wide area network across multiple Regions and sites, based on a central policy document. ⇒ This is where the questions that the reader may have begin. ⛔ This article is not a timeline for Cloud WAN. Only two entries relate to Cloud WAN: this preview announcement and the general availability announcement. Feature additions are not tracked. References: Introducing AWS Cloud WAN (Preview)
2021-12-02ObservabilityDocsThe documentation for Network Manager has been separated from the AWS Transit Gateway User Guide. The Document history notes that Network Manager was created as a standalone guide, and is no longer included as part of the AWS Transit Gateway User Guide. ⇒ This means the tool for viewing the network is no longer an add-on to the hub. References: Document history for transit gateways
2022-05-24ObservabilityGANetwork Manager now supports multiple AWS accounts. ⛔ This functionality is specifically for accounts within an organization created using AWS Organizations. The announcement explicitly states this limitation: across multiple AWS accounts within an organization, created using AWS Organizations. ⇒ This means you can now view a single network across multiple accounts within an organization. References: Announcing Multi-Account Support for AWS Transit Gateway Network Manager
2022-07-12PeeringGAAWS Cloud WAN is now generally available. ⇒ This date serves as a key reference point for this article. Subsequent entries relate to features introduced after Cloud WAN. ⛔ This row is not a change to Transit Gateway itself. This entry is included to establish a date for the reader's initial questions about Cloud WAN. References: Announcing the general availability of AWS Cloud WAN
2022-07-13RoutingDocsPolicy tables have been added. The Document history notes that Use policy tables to set up dynamic routing for transit gateways for automatically exchanging routing and reachability information with peered transit gateway types. ⇒ This feature, allowing hubs to connect, was introduced the day after Cloud WAN became generally available. ⚠ This policy table returns for a different purpose four years later (see the row for 2026-07-30). ⛔ No corresponding What's New announcement could be found. References: Document history for transit gateways
2022-07-14ObservabilityGAAmazon VPC Flow Logs now support Transit Gateway. This allows you to output source and destination addresses, ports, protocol, counters, timestamps, various metadata, and more for all flows passing through the hub. ⇒ Previously, you had to correlate network interface logs from individual VPCs. ⚠ The previously published Amazon VPC timeline also carries this row. This entry focuses on the hub's perspective, providing a more granular view. References: Amazon VPC Flow Logs adds Transit Gateway support for improved visibility and monitoring
2022-08-08AttachmentGAAWS Direct Connect can now connect to Transit Gateway with slower connection speeds. The announcement stated that connections with speeds of 50, 100, 200, 300, 400, and 500 Mbps can now connect to the hub. ⇒ What widened is the floor, not the ceiling. Previously, a minimum connection speed was required to connect to the hub. ⚠ This is not an addition of a new attachment type. Direct Connect gateways were already supported; what this expands is the set of connection speeds that can reach the hub. The heading more connection speeds refers to that expansion, not to an increase in the maximum speed. References: AWS Direct Connect expands AWS Transit Gateway support at more connection speeds
2023-08-14OperationsDocsBandwidth limits are now documented in the Quotas section of the user guide. The Document history states: AWS Transit Gateway Quotas Bandwidth limits were added. ⇒ This provides a documented estimate of the amount of bandwidth that can be aggregated to the hub. ⚠ This article does not copy the limit values themselves. Refer to the official Quotas page for the latest information. ⛔ No corresponding What's New announcement could be found. References: Document history for transit gateways

2024-2026 - What Arrived After Cloud WAN

This is the core of this article: ⇒ Since the general availability of AWS Cloud WAN and up to the verification date, three new types of attachments have been added to Transit Gateway, along with one additional routing option.

DateTrackTypeSummary
2024-08-12OperationsGAYou can now apply cost allocation tags to resources within Transit Gateway. This allows you to categorize costs by units such as teams, departments, or applications. ⇒ This marks the beginning of features designed with the assumption that a single hub will be shared across multiple departments. References: AWS announces support for Cost Allocation Tags on AWS Transit Gateway
2024-09-25SecurityGASecurity group referencing became available between VPCs connected by the hub. You can now specify the security group on the receiving end in inbound rules. ⇒ Previously, this was only possible through VPC peering; now, it's achievable through the hub. ⚠ The previously published Amazon VPC timeline also carries this row. That article records the change as one that makes migration from VPC peering to the hub easier. References: AWS announces general availability for Security Group Referencing on AWS Transit Gateway
2024-11-14ObservabilityGASupport has been added for zone-specific metrics and Path Maximum Transmission Unit (MTU) discovery. The announcement states that both Transit Gateway and Cloud WAN can now send zone-specific metrics to CloudWatch, and both support Path MTU discovery. ⇒ This allows you to detect MTU mismatches along the path. ⚠ This feature is available for both Transit Gateway and Cloud WAN. The documentation records the fact of this shared availability, but does not attempt to interpret AWS's intentions. References: AWS Transit Gateway and AWS Cloud WAN enhance visibility metrics and Path MTU support
2025-06-16AttachmentGANetwork function attachment has been added. You can now directly attach AWS Network Firewall to the hub, eliminating the need to manually configure inspection VPCs. ⇒ This is the first new attachment type added after the general availability of Cloud WAN. ⛔ Only five Regions were supported at the time of the announcement. The set of supported Regions can change, so consult the official list. ⚠ The history of feature additions to AWS Network Firewall itself is held by a previously published article. This article records only that the hub gained this attachment type. References: AWS Network Firewall now supports AWS Transit Gateway native integration
2025-11-19AttachmentGAVPN Concentrator has been added. This allows you to connect numerous sites with limited bandwidth by grouping them under a single attachment to the hub. The announcement states that a single VPN Concentrator can connect up to 100 sites. ⇒ This is the second new attachment type added after the general availability of Cloud WAN. ⛔ This functionality was initially announced by AWS Site-to-Site VPN. There is no corresponding row in the Transit Gateway user guide's Document history. This article cross-references the tags and the Document history because omissions of this kind occur. ⚠ The name may vary depending on the documentation. While referred to as Site-to-Site VPN Concentrator by AWS Site-to-Site VPN, it is listed as VPN Concentrator when referring to attachment types. References: AWS Site-to-Site VPN announces VPN Concentrator
2025-11-20SecurityDocsYou can now configure encryption control on the hub. The user guide explains that enabling this feature enforces traffic encryption for all traffic associated with VPCs attached to the hub. ⇒ The hub is now not only routing traffic but also enforcing its characteristics. ⛔ What this feature guarantees, and how far, is held by the previously published VPC Encryption Controls. That documentation delves into scenarios where encryption guarantees may be cut off before reaching the hub. This article delegates that ground to the previously published article. References: Document history for transit gateways
2025-11-21OperationsGAFlexible Cost Allocation has been introduced. Previously, costs associated with the hub were only allocated to the sending account; now, you can allocate them to the sending account, the receiving account, or the account that owns the hub. This can be configured at the attachment level or the flow level. ⇒ This further aligns cost management with the assumption that a single hub is shared across multiple departments. ⛔ This article does not give amounts or unit prices. It only records the structural change of having more options for cost allocation. References: AWS announces Flexible Cost Allocation on AWS Transit Gateway
2026-04-23AttachmentGAClient VPN attachment has been added. You can now directly associate Client VPN endpoints to the hub, eliminating the need to route traffic through a VPC. ⇒ This is the third new attachment type added after the general availability of Cloud WAN. ⚠ The announcement states one more thing. Removing the intermediary VPC means the user's source address is now preserved, whereas previously, address translation was applied. ⛔ This feature was also announced by AWS Client VPN. References: AWS Client VPN now supports native AWS Transit Gateway integration
2026-07-30RoutingGAPolicy-Based Routing is now generally available. In addition to source and destination addresses, you can now use port and protocol combinations to determine the routing path. ⇒ The criteria for the hub to determine the next hop now extend beyond just the destination address. When configuring, use policy tables, and an attachment can be associated with either a policy table or a route table, but not both. ⚠ Policy tables were introduced for a different purpose on 2022-07-13. They are now used to determine the routing path itself. ⛔ The user guide also includes limitations. When an attachment has a policy table associated with it, the hub will no longer advertise routes via BGP. This applies to Site-to-Site VPN and Transit Gateway Connect attachments. ⛔ This article uses 2026-07-30. The document history lists the date as 2026-07-28. References: AWS announces general availability of Policy-Based Routing on AWS Transit Gateway

Current Overview, Functions, Features of AWS Transit Gateway

What Can Be Attached, and Why the Count Depends on Where You Look

⛔ As of the verification date, the primary sources give three different counts for the types of things that can be attached. To state the number in the form there are N attachment types, it is necessary to name the source the number came from.

SourceCountDescription
Section Transit gateway concepts in the user guide8VPC, Transit Gateway Connect, Direct Connect gateway, hub-to-hub peering, VPN connection, VPN Concentrator, Client VPN endpoint, network function attachment
Section Resource attachments in the user guide6All items from the above 8, excluding Client VPN endpoint and network function attachment
Amazon EC2 API TransitGatewayAttachmentResourceType enumeration9VPC, VPN, VPN_CONCENTRATOR, DIRECT_CONNECT_GATEWAY, CONNECT, PEERING, TGW_PEERING, NETWORK_FUNCTION, CLIENT_VPN. The difference from the concepts list is that there are two values corresponding to peering.

⇒ This article does not state a single number of attachment types. The number differs by section inside one user guide, and the API enumeration uses a different categorization. ⚠ For tasks requiring a specific count, refer to the API enumeration rather than the user guide. The user guide is a document that describes functionality and therefore simplifies categorization.

⛔ In the enumeration, the specific meaning of PEERING and TGW_PEERING is not confirmed in this article. What can be confirmed is only that two of the values correspond to peering. ⚠ In addition to the enumeration above, the value UNKNOWN_TO_SDK_VERSION may also appear. This value indicates that the SDK has received an unrecognized value and is not a type of attachment. The number 9 above excludes this value.

⚠ The values in this table are as of the verification date. As indicated in the timeline in this article, this list has been continuously expanding since 2018.

References: What is AWS Transit Gateway for Amazon VPC? / How AWS Transit Gateway works / TransitGatewayAttachmentResourceType

The Two Layers of Route Tables

⛔ Even when using a Transit Gateway, VPC route tables do not disappear. This is a common point of confusion.

The Two Layers of Route Tables a Packet Passes Through
The Two Layers of Route Tables a Packet Passes Through
The user guide clearly states that when a VPC is attached to a transit gateway, you need to add a route to the subnet's route table to send traffic through the hub. ⇒ Packets are first evaluated by the VPC's route table, and only when that table picks the hub as the next destination does the hub's route table get consulted. Both layers remain in place.

These two layers are evaluated differently.

  • The VPC's route table prioritizes the local route that points inside the VPC. Subsequently, more specific routes are prioritized.
  • The hub's route table does not have an equivalent to local routes. The most specific route wins. When several routes point to the same range, the tie breaks in one of two ways. Routes that come from different attachment types are ranked by the type itself, in a fixed order. Routes of the same type are ranked by their BGP attributes. ⛔ And the user guide states plainly that it cannot guarantee a consistent order for BGP-derived routes that share the same range, attachment type, and BGP attributes.

⇒ This distinction is the core focus of this article. The hub is not overriding the VPC's routing decisions. Instead, the hub adds a second layer of routing decisions behind the VPC's own.

⚠ The transfer unit also varies depending on the layer. The user guide states that the transfer unit is 8500 bytes between VPCs, Direct Connect, Transit Gateway Connect, and peering attachments. However, it is 1500 bytes over VPN connections. ⛔ The term peering attachments covers three types: intra-Region, inter-Region, and Cloud WAN peering attachments. The user guide states that limitation in parentheses. ⛔ These values are as of the verification date.

References: How AWS Transit Gateway works / What is AWS Transit Gateway for Amazon VPC? / Transit gateway policy tables in AWS Transit Gateway

Where Transit Gateway Sits Next to AWS Cloud WAN

AWS itself clarifies the distinction between the two. The AWS Cloud WAN FAQ states:

Both Transit Gateway and Cloud WAN allow centralized connectivity between VPCs and
on-premises locations. Transit Gateway is a Regional network connectivity hub and is
optimal if you operate in a few AWS Regions, want to manage your own peering and routing
configuration, or prefer to use your own automation.

The AWS Networking and Content Delivery blog puts the question of migrating this way:

Of course, you don’t have to migrate from Transit Gateway to Cloud WAN unless you want to.
If you are happy with your current architecture, great!

⛔ The first sentence of the second quote above uses a right single quotation mark as its apostrophe. The source is reproduced without character substitution.

⇒ The primary source simply states that the two should be used differently; it does not state that one replaces the other.

⚠ Furthermore, the timeline also includes a line indicating that there is no replacement. Cloud WAN became generally available on 2022-07-12. Between that date and the verification date, three new types of attachments were added to Transit Gateway: the network function attachment on 2025-06-16, the VPN Concentrator on 2025-11-19, and the Client VPN attachment on 2026-04-23. Additionally, on 2026-07-30, the routing capabilities themselves were expanded.

⚠ The same situation is occurring with the documentation. Network Manager, which was introduced on 2019-12-03, is now split into two separate documents. The document for using a core network is the AWS Cloud WAN User Guide, while the document for creating a global network without a core network is the AWS Global Networks for Transit Gateways User Guide. The Cloud WAN User Guide specifically directs users to the latter in certain scenarios. ⇒ The documentation was therefore not replaced. It was divided into two.

⛔ However, the naming conventions are not consistent across AWS documentation. As of the verification date, the AWS Transit Gateway FAQ still describes a global network as an object of the AWS Transit Gateway Network Manager service. ⇒ When researching current names, it is best to consult the user guide rather than the product FAQ.

References: AWS Cloud WAN FAQs / AWS Cloud WAN and AWS Transit Gateway migration and interoperability patterns / What is AWS Cloud WAN? / What is AWS Global Networks for Transit Gateways? / AWS Transit Gateway FAQs

⛔ This article concludes here. Decisions on which option to choose and the order in which to migrate are covered in the previously published AWS VPC Connectivity Decision Guide.

Whether This Service Is in Maintenance

As of the verification date, AWS Transit Gateway does not appear on the list of services currently in maintenance. AWS lists services and features that are no longer accepting new users on the Services in Maintenance page. ⇒ That page was opened on the verification date, and Transit Gateway was not on it.

⚠ That check reflects the verification date only. Service lifecycle announcements move, so open the same page again when a decision depends on it. ⇒ AWS Retired Services History and Timeline provides information on when specific services were added to this list.

References: Services in Maintenance

Frequently Asked Questions about AWS Transit Gateway History

Does AWS Cloud WAN replace AWS Transit Gateway?

No. The frequently asked questions for AWS Cloud WAN describe the differences between the two, positioning Transit Gateway as a hub for regional connections. AWS's blog also states that migration is not necessary unless desired. ⇒ This is also true from the timeline's perspective. Since July 12, 2022, when Cloud WAN became generally available, three new types of attachments have been added to Transit Gateway.

Is AWS Transit Gateway in maintenance mode?

No. The AWS Services in Maintenance page was checked on September 11, 2026, and Transit Gateway was not on it. ⚠ The lifecycle announcements on that page move. Open it again when a decision depends on it.

How many kinds of attachments can a transit gateway have?

The number a transit gateway reports depends on which source you read. The user guide's Transit gateway concepts section lists 8, while the same user guide's Resource attachments section lists 6. The Amazon EC2 API enumeration lists 9. ⇒ When performing tasks that require a specific number, refer to the API enumeration.

Do I still need VPC route tables after introducing a transit gateway?

Yes. The user guide clearly states that when a VPC is attached to a transit gateway, you need to add a route to the subnet route table to send traffic through the hub. ⇒ Both VPC route tables and hub route tables will remain in place, functioning as two separate layers.

When did transit gateway peering become available?

Inter-Region peering between transit gateways became available on December 3, 2019, while intra-Region peering became available on December 1, 2021. ⚠ The order is counterintuitive: the peering that spans the greater distance arrived first.

What is appliance mode for?

Appliance mode keeps the forward and return traffic of a stateful appliance in the same Availability Zone. The user guide explains that enabling this feature means a single flow will continue to use the same zone. The date recorded in the Document history is 2020-10-29.

How is Transit Gateway Connect different from a VPN attachment?

Transit Gateway Connect is a type of attachment used to connect appliances running in a VPC, such as SD-WAN devices or third-party virtual appliances, to a central hub. It was introduced on December 10, 2020. ⇒ A VPN attachment handles the connection to equipment at the remote site, while Transit Gateway Connect handles appliances running in a VPC on the AWS side.

When did multicast become available, and when did IGMP support arrive?

Multicast became available on December 3, 2019, and support for the Internet Group Management Protocol (IGMP) was added on December 10, 2020. ⇒ This latter addition enabled clients to register their participation using a standard protocol, rather than through AWS APIs.

When could AWS Network Firewall be attached to a transit gateway directly?

June 16, 2025. From that date a firewall can be attached to a transit gateway directly, as a network function attachment, without an inspection VPC in between. ⛔ At the time of the announcement, it was available in only five Regions. The set of supported Regions can change, so consult the official list.

What are the dates in this timeline based on?

The dates in this timeline are based on two sources: the publication date of the AWS What's New updates and the Document history in the Amazon VPC Transit Gateway User Guide. ⇒ This article uses the publication date from AWS What's New for rows where that information is available, and uses the dates from the Document history when that record is not available. As of the verification date, there are four rows where these two sources conflict. A list of these discrepancies is provided in the first half of this article.

Summary

AWS Transit Gateway was introduced on November 26, 2018. Initially, it only supported VPC and VPN connections. Since then, the types of attachments it supports have kept growing. Direct Connect gateway, hub-to-hub peering, Transit Gateway Connect, network function attachment, VPN Concentrator, and Client VPN endpoint were subsequently added.

The increasing variety of attachment types reflects the expanding scope of this hub. Initially, it simply routed traffic. Now, it can enforce encryption during traffic forwarding for connected VPCs, allow users to select cost allocation targets, and determine the destination based on factors beyond the destination address.

AWS Cloud WAN did not replace Transit Gateway. AWS itself provides guidance on differentiating between the two in its frequently asked questions, stating that migration is optional. The timeline provides further evidence of this. Cloud WAN became generally available on July 12, 2022. Since then, three new types of attachments and one new routing method have been added to Transit Gateway.

The underlying layers have not been removed. VPC route tables still exist. Packets are evaluated at the VPC layer first, and only when the hub is selected do they undergo evaluation within the hub layer. Transit Gateway did not replace the VPC's routing decisions; instead, it added another layer of evaluation behind it.

This timeline will be updated as AWS Transit Gateway continues to evolve.


References:
Tech Blog with curated related content

Written by Hidekazu Konishi