AWS History and Timeline regarding AWS Direct Connect - Overview, Functions, Features, Summary of Updates, and Introduction
First Published:
Last Updated:
This article outlines what features were added to AWS Direct Connect and when, categorized into three areas: the physical layer, the logical layer, and the operational layer. Ultimately, this article aims to answer one key question: what, in this older layer, is now closed to new use?
The answer is that closing happens at three granularities, and only two of them are closed. The service is not closed. One location is no longer accepting new connections. And one of the delivery models that partners use to bring dedicated connections to customers is no longer accepting new integrations. These three are different things, and reading them as one makes the whole article wrong.
This article focuses solely on dates and order of events. The mechanics of Direct Connect, how to choose the right option, and how to configure redundancy belong to other articles, and this article defers to them.

Background and Method of Creating AWS Direct Connect Historical Timeline
A timeline is almost finished the moment its author decides what to count. This section sets out first where the dates come from, and what became a row and what did not. All references were accessed on September 18, 2026.Why This Timeline Is Divided Into Three Lanes
What has been added to Direct Connect falls into three groups of different kinds. Combining them into a single timeline obscures their differences.- Physical Layer: This includes port speeds, locations, link configurations, and link encryption. Arranging any of this takes weeks or months, and once the cable is in, it is hard to move.
- Logical Layer: This concerns how many virtual interfaces stand on a single circuit, and where each of them terminates. This layer changes through console operations alone.
- Operational Layer: This covers what can be done with a circuit once it is in place: seeing it, recording it, building it from a template, and controlling how many routes it accepts.
These three categories have different rates of growth and different underlying reasons. The physical layer has consistently grown since Direct Connect's inception in 2011. The logical layer moved toward separating circuits from what they reach after the introduction of Direct Connect gateways in 2017. The operational layer has only recently become significantly more substantial, starting in 2026.
⚠ The lanes are not a classification the sources use. AWS does not sort Direct Connect updates into these three; this article places them for readability. The placement of an item within a particular lane does not alter the underlying facts, although some items have been placed in only one lane due to their nature.
Primary Sources Used in This Article
This article takes its dates from two sources.The first is the Document history section of the AWS Direct Connect User Guide. From its initial release on 2011-08-03 to the present, a chronological list of releases carries a date for each entry.
⚠ The location of this page cannot be guessed. The
doc-history.html path that many other AWS user guides use redirects, for Direct Connect, to the top of the user guide. The page itself is at AboutThisGuide.html. Attempting to construct the URL without consulting the table of contents will incorrectly lead to the conclusion that this page does not exist.The second source is the announcements on AWS What's New. This article uses the dates listed under
Posted on: for each announcement.In addition, this article draws on the AWS Direct Connect Partners page, the Hybrid Connectivity whitepaper, and the AWS Partner Network blog. These three sources do not contain dates, but they provide information about the status of hosted virtual interfaces, details that are not included in the user guide.
The sources this article used are linked below.
- Document history - AWS Direct Connect User Guide
- What's New with AWS?
- Direct Connect virtual interfaces and hosted virtual interfaces - AWS Direct Connect User Guide
- AWS Direct Connect Partners
- Hybrid Connectivity - AWS Whitepaper
- AWS Partner Network (APN) Blog
What the Document history Is Made Of
The reason for using two systems is that the Document history alone is insufficient. This is not an abstract precaution. It shows in the structure of that page.At the time of retrieval, the Document history contains 45 lines. Of these, 18 lines refer to the addition of locations or Regions. The remaining 27 lines relate to the addition of features, billing, and quotas. ⚠ One of those 18 lines is combined with a line detailing a console refresh.
⚠ The lines pertaining to locations stop at 2021-01-22. No lines have been added regarding locations since then. The only location-related entry after 2021 is an announcement regarding a closure scheduled for 2026-06-30. However, the total number of locations mentioned in the announcement's text exceeds 100 as of 2021, and surpasses 150 by 2026. ⇒ This indicates that the Document history stopped recording the addition of locations at some point. It is impossible to track the evolution of locations using the Document history.
⚠ The period for which records were kept, and the density of those records, is not consistent. Of the 18 lines, 15 fall in the years 2011 to 2016, with between 1 and 3 lines recorded each year during those 6 years. After that, there were no location-related lines in 2017, 2018, or 2019. After a single line appeared in both 2020 and 2021, there is only the 2026 closure announcement.
⇒ The location-related lines listed in the Document history do not reflect the rate at which Direct Connect locations increased; instead, they indicate the period during which the documentation recorded the addition of locations. Misinterpreting this could lead to the incorrect conclusion that locations stopped being added after 2016. In reality, the total the announcements state rose from over 100 to over 150 over that same period.
⚠⚠ Furthermore, there are no entries for the year 2022. The Document history's breakdown by year is missing only the year 2022. However, on 2022-08-08 a real feature was added: slower connections became able to reach a Transit Gateway. ⇒ Therefore, just because the Document history is silent about a particular year does not necessarily mean that nothing happened during that year.
Discrepancies Between Two Primary Sources
This timeline includes a column indicating which source material each entry is derived from. When comparing the two sources, three types of discrepancies emerge.1. The two sources give the same feature different dates.
| Feature | What's New | Document history | Difference | Date Used in This Article |
|---|---|---|---|---|
Native 400 Gbps dedicated connections | 2024-07-01 | 2024-07-18 | 17 days | 2024-07-01 |
Long ASN support | 2025-09-12 | 2025-07-24 | 50 days | 2025-09-12 |
⚠ The direction of the difference is not consistent. For 400 Gbps, the Document history is later than What's New, while for Long ASN, the Document history is earlier. ⇒ No simple relationship in which the Document history trails the announcements explains this. This article uses the Posted on date from the announcement. What's New describes the date the feature became available, while Document history describes the date the documentation was updated, and the latter can vary in either direction.
2. Entries the Document history does not hold. The following five appear only in AWS What's New.
Transit Gateway support at 500 Mbps and lower(2022-08-08)MACsec on partner interconnects(2025-07-28)AWS CloudFormation support(2026-03-31)VIF Rate Limiters(2026-06-01)Inbound prefix controls(2026-08-20)
⚠ Three of the missing entries are from 2026. Read only the Document history, and 2026 appears to hold nothing but BGP route visibility and a billing mode. In reality, there were four feature additions.
3. The two sources describe the same feature with a different scope. Regarding SiteLink, the Document history states:
You can create a private virtual interface that enables connectivity between
two Direct Connect points of presence (PoPs) in the same AWS Region.
For the same feature, the main body of the user guide states:
SiteLink is an optional Direct Connect feature for private virtual interfaces
that enables connectivity between any two Direct Connect points of presence
(PoPs) in the same AWS partition using the shortest available path over the
AWS network.
Inside one Region and inside one partition are not the same scope at all. In the former case, SiteLink only connects locations in the same Region. In the latter case, it creates routes that span continents. The announcement from December 1, 2021 states, "With over 100 Direct Connect locations around the world, you can create networks that span multiple continents." Both the user guide and the announcement are consistent, and only the single line in the Document history is narrower.
⇒ This article takes that line from the Document history as evidence for the date, and not as evidence for the scope of the feature.
The sentence quoted above from the user guide is also not a basis for which virtual interface types SiteLink supports. The beginning of the same section states that SiteLink can be used on a private or a transit virtual interface, and the table in that same section also lists the transit virtual interface as supported. Quoting only the first part of the definition can lead to a narrow and inaccurate understanding of the supported scope. ⛔ Which types are supported is left to the existing article.
The Numbers This Timeline Does Not Carry
This timeline does not contain a list of limits. How many virtual interfaces one connection can carry, and how much can be associated with a Direct Connect gateway, belong to an existing article. On top of that, those numbers do not agree across the primary sources.⚠ There is exactly one exception. Where a change in a limit is itself the event, this article carries the value before and the value after, with the date. Those values mean something as a row. ⛔ No other limit is given as a current value.
For example, the AWS Direct Connect Partners page says a dedicated connection supports
4 transit VIF in one section, and in another section, while describing hosted connections, says a dedicated connection provides 1 transit VIF. ⇒ The two numbers describe the same thing and disagree inside one page. The quotas page gives 4 and records that the allowance went from 1 to 4. ⇒ Writing a limit into a row would leave no record of which page was read on which day. The official quotas page holds the numbers.This timeline does not contain a list of locations. Adding Direct Connect locations generates the highest volume of announcements, and a table that tried to cover them would go stale immediately. Instead, only the evolution of the total numbers as stated in the announcements is included.
This timeline does not contain information on billing models or pricing. The most recent entry in the Document history (2026-09-15) concerns the addition of a billing model for dedicated connections, and for this reason, it has been intentionally excluded from the timeline. The absence of the most recent entry is not an oversight; it is a deliberate exclusion.
This timeline does not carry how to procure the physical circuit for a site. Installing the circuit, selecting a carrier, and arranging the in-building cabling lie outside what this article can verify firsthand.
What This Article Leaves to Other Articles
Direct Connect is one of the densest subjects among the existing articles on this site. To keep them from overlapping, the split is as follows:- Mechanisms, Selection, Redundancy, and Limits — AWS Hybrid Connectivity Decision Guide holds this as its subject. The explanations of the connection types, the three virtual interface types, the Direct Connect gateway, LAG, SiteLink, MACsec, and jumbo frames are all there.
- What AWS Interconnect Consolidates into a Single Object — AWS Interconnect - What One Managed Object Replaces in Multicloud and Last Mile Connectivity.
- Definitions of Terms — AWS Networking Glossary.
- Historical Overview of Hub-Side Features — AWS History and Timeline regarding AWS Transit Gateway. Two rows there write the same events as this article does, from the hub side.
- Evolution of Routing from the VPC Perspective — AWS History and Timeline regarding Amazon VPC.
- What Private Connections Do Not Guarantee — The Boundaries of the AWS Global Network.
- Meaning of Lifecycle States — AWS Service Lifecycle States and AWS Retired Services History and Timeline.
- The Same Distinction Applied at the Service Level — AWS History and Timeline regarding AWS Elastic Beanstalk. This article draws the line between a halt to new integrations and a discontinuation at the level of the connection model. That article applies the same line to a service and to the platform branches under it.
AWS Direct Connect Historical Timeline (Updates from August 3, 2011)
The following three tables form the core of this article, organized by the physical layer, logical layer, and operational layer. TheDated by column in each table indicates how two primary sources handle the information in that row. Both signifies rows with the same date in both sources, Both (differ) indicates rows present in both sources but with different dates, while Document history only and What's New only represent rows found in only one of the sources.Use the following index to navigate:
- The Physical Layer - Port speeds, locations, how links are bundled, and link encryption.
- The Logical Layer - How many virtual interfaces stand on one circuit, and where each of them terminates.
- The Operational Layer - Seeing a circuit, recording it, building it from a template, and controlling how many routes it accepts.
* You can sort the table by clicking on the column name.
The Physical Layer — Port, Location, Link
The day Direct Connect began, only one location was available. The announcement stated:AWS Direct Connect has one location available today, located at Equinix's
Ashburn, Virginia colocation facility.
The advancements made at the physical layer can be most easily understood by measuring the distance from this single location.
| Date | Update | Dated by | Summary |
|---|---|---|---|
| 2011-08-03 | Public release | Both | AWS Direct Connect was launched. The announcement stated that it is a new service that establishes dedicated network connections from data centers, offices, and colocation environments to AWS. ⚠ Initially, it was only available in one location: Ashburn, Virginia, with connectivity only to the US-East Region. Support for San Jose, Los Angeles, London, Tokyo, and Singapore was planned for several months later. ⇒ All other entries in this article can be interpreted as distances from that single location. See: Announcing AWS Direct Connect / Document history |
| 2012-01-10 | Four more locations | Document history only | Four additional locations were added: US West, EU, and two locations in Asia Pacific. The Document history records the addition of locations in US West (Northern California), EU (Ireland), Asia Pacific (Singapore), and Asia Pacific (Tokyo). The same entry also includes the addition of a troubleshooting section. ⇒ This marked an expansion beyond a single continent, just five months after the initial launch. See: Document history |
| 2013-10-22 | Hosted connections | Document history only | Two methods for obtaining connections became available. Previously, customers could only request dedicated ports from AWS; now, connections provided by AWS Direct Connect Partners are an option. ⇒ This was the first time the term "hosted" appeared for Direct Connect. ⚠ This entry refers to "hosted connections," not "hosted virtual interfaces." The two terms are similar, but one refers to the method of obtaining a connection, while the other refers to the allocation of virtual interfaces. See: Document history |
| 2015-04-14 | China (Beijing) Region | Document history only | A location for connectivity to the China (Beijing) Region was added. Subsequently, many Direct Connect announcements carried a proviso excluding the AWS China Regions. That proviso is still in place, and what each feature reaches differs from feature to feature. For example, inbound prefix controls were stated to include the AWS China Regions in an announcement from 2026-08-20, while the Direct Connect gateway announcement of 2017-11-01 stated that they were excluded. See: Document history |
| 2017-02-13 | Link aggregation groups | Document history only | Multiple connections could now be bundled together as a single logical interface. ⇒ A second way to add width appeared in the physical layer, alongside making a single port faster. This option was referenced in an announcement from 2024 regarding 400 Gbps, and was contrasted with the practice of bundling multiple 100 Gbps connections. ⛔ The number of connections that can be bundled, and the conditions, are left to the existing article. See: Document history |
| 2018-10-11 | Jumbo frames | Document history only | Support for sending jumbo frames over Direct Connect was added. The Document history notes an MTU of 9001. ⇒ This was the first update that changed the amount of data that could be carried in a single frame, rather than the connection speed itself. ⚠ That enabling it can require an update to the underlying physical connection, and that every device along the path must agree on the same MTU, are design points the existing article covers. See: Document history |
| 2021-02-12 | 100 Gbps dedicated connections | Document history only | 100 Gbps dedicated connections were added. The Document history carries no speed entry before this one, and 400 Gbps follows three years later. MACsec followed about a month and a half later; these two physical-layer updates came back to back. See: Document history |
| 2021-03-31 | MACsec | Both | Encryption for the physical link itself became available for dedicated connections. The announcement stated that previously, securing data in transit at multi-gigabit speeds required bundling multiple IPsec VPN tunnels, which increased operational complexity and risk. ⇒ This was the first update to reach, from the circuit side, the property of a dedicated line being private but not encrypted. ⚠ Initially, MACsec was only supported for 10 Gbps and 100 Gbps dedicated connections, and only in select locations. The announcement stated that the list of supported locations would be updated periodically. See: AWS Direct Connect Announces MACsec Encryption for Dedicated 10Gbps and 100Gbps Connections at Select Locations / Document history |
| 2024-07-01 | Native 400 Gbps dedicated connections | Both (differ) | Native 400 Gbps dedicated connections were added. The announcement stated that this provides greater bandwidth without the operational overhead of bundling multiple 100 Gbps connections in a link aggregation group. Potential use cases include transferring large datasets for machine learning, large language model training, and autonomous driving support systems. ⚠ The same entry in the Document history is dated 2024-07-18, a difference of 17 days. This article uses the announcement date. ⚠ The announcement itself states that availability is limited to select locations. See: AWS Direct Connect announces native 400 Gbps Dedicated Connections at select locations |
| 2025-07-28 | MACsec on partner interconnects | What's New only | MACsec support was extended to include partner interconnects. This allows partners to encrypt the link between their edge devices and AWS network devices. The announcement stated that it is available at over 100 points of presence globally where MACsec is supported. ⇒ Previously, encryption was only available for customer-owned dedicated connections; this update extends the same capability to a segment of the path when connecting through a partner. ⚠ Only the partner, not the customer, can enable MACsec. This entry does not appear in the Document history. See: AWS Direct Connect extends MACsec functionality to supported Partner Interconnects |
| 2026-06-01 | VIF Rate Limiters | What's New only | The bandwidth of a dedicated connection could now be allocated to individual virtual interfaces. The announcement stated that this addresses the issue of unexpected traffic spikes consuming available bandwidth and impacting other workloads on the same connection. Packets exceeding the configured limit are dropped, and usage statistics and dropped packet counts are sent to CloudWatch. ⇒ This was the first time a customer could control bandwidth allocation on a physical connection. ⚠ The announcement specifies that this feature applies to dedicated connections. This entry does not appear in the Document history. See: AWS Direct Connect now supports VIF Rate Limiters to help prevent network congestion |
The Location Count Can Be Tracked From the Value Each Announcement States
⛔ This article does not carry a list of locations. Instead it places only four data points for the total that Direct Connect announcements state in their own text. Since announcements are released each time a new location is added, the total number presented is always subject to change.| Date | Stated in the announcement | Source |
|---|---|---|
| 2011-08-03 | one location available today | Announcing AWS Direct Connect |
| 2021-12-01 | over 100 Direct Connect locations around the world | Introducing AWS Direct Connect SiteLink |
| 2022-08-08 | over 115 Direct Connect locations (points-of-presence) worldwide | AWS Direct Connect expands AWS Transit Gateway support at more connection speeds |
| 2026-04-02 | over 150 Direct Connect locations worldwide | AWS Direct Connect announces 100G expansion in Auckland, New Zealand |
⚠ This table does not reflect the current number of locations. Each row represents the value stated in the announcement on that particular day. The current number has to be checked on the official AWS Direct Connect locations page.
The Logical Layer — Virtual Interface, Gateway, Route
The announcement in 2011 does not use the term "virtual interface." It uses the term "logical connections" instead.With each AWS Direct Connect connection, you can configure one or more logical
connections that allow you to access public AWS resources (such as S3 buckets)
and/or reach private VPC networks.
⚠ However, the distinction between "public-facing" and "VPC" is already present in this single sentence. What was added to the logical layer later was not this distinction itself, but rather the option of where a virtual interface terminates.
⛔ The Document history holds no row for when the private and public virtual interface types were introduced. ⇒ This article therefore does not assign a date to them either. The following table outlines the order in which the destinations for a virtual interface were added.
| Date | Update | Dated by | Summary |
|---|---|---|---|
| 2013-12-19 | Access to remote AWS Regions | Document history only | Public resources in remote AWS Regions became reachable. The Document history records the addition of a new topic describing how to access public resources in remote Regions. Previously, only Regions connected to a specific circuit could be reached; the Direct Connect gateway performed the same kind of separation for VPCs four years later. See: Document history |
| 2016-12-01 | IPv6 BGP peering | Document history only | The ability was added to establish IPv6 BGP sessions. This meant that traffic was no longer limited to IPv4. This distinction remains relevant through the inbound prefix controls of August 20, 2026, and IPv4 and IPv6 address allocation are handled separately. See: Document history |
| 2017-11-01 | Direct Connect gateway | Both | The location where circuits connect and the VPCs those circuits reach were decoupled. The announcement stated that this new feature allows connections from any Direct Connect location to any VPC deployed in any Region. In the same announcement, the public virtual interface also began reaching the public services of every Region. ⇒ This is the largest change in the logical layer. Previously, a circuit was required for each VPC within its respective Region. ⚠ The announcement states that the AWS China Regions are excluded. ⇒ The object created on this date has since become the place where Transit Gateway was hung in 2019, Cloud WAN in 2024, and AWS Interconnect today. The same announcement also included a change to data transfer pricing, but that is not covered in this document. See: AWS Direct Connect Enables Global Access / Document history |
| 2018-02-06 | Local preference BGP communities | Document history only | Route preference became available for traffic coming into the customer's own network. The Document history states that local preference BGP community tags achieve load balancing and route preference for incoming traffic to your network. This introduced a new lever for controlling traffic routing, separate from how endpoints are configured. The community values used at this time are included in the visibility of routes as of July 30, 2026. See: Document history |
| 2019-03-27 | Transit virtual interface | Document history only | Transit Gateway was added as a destination endpoint. This involved associating a Direct Connect gateway with a Transit Gateway and creating a transit virtual interface directed to that Direct Connect gateway. This marked the introduction of a third type of virtual interface, allowing Direct Connect to be connected to a single hub. A related description from the same period, viewed from the perspective of the hub, can be found in AWS History and Timeline regarding AWS Transit Gateway. This document describes the same event from the endpoint's perspective, while the other describes it from the hub's perspective. See: Document history |
| 2019-09-30 | Transit Gateway across accounts in more Regions | Document history only | Support for Transit Gateway across accounts was expanded to additional Regions. This expanded the functionality introduced in the previous entry to a wider range of Regions. It is common for the date a feature is introduced and the date it becomes available in specific Regions to differ with Direct Connect. See: Document history |
| 2021-12-01 | SiteLink | Both | Traffic is no longer required to pass through AWS Regions. The announcement stated that SiteLink allows on-premises locations to be connected via the shortest path through a Direct Connect location. This transformed Direct Connect, not only as an entry point to AWS, but also as a means of connecting on-premises locations. At this point, the description of Direct Connect as solely an entry point to the cloud became insufficient. The same entry in the Document history refers to connections in the same Region, a narrower scope. The user guide and announcement, however, state that connections can span continents within a partition. See: Introducing AWS Direct Connect SiteLink / Document history |
| 2022-08-08 | Transit Gateway support at 500 Mbps and lower | What's New only | Lower connection speeds are now supported to reach the hub. The announcement stated that connections with speeds of 50, 100, 200, 300, 400, and 500 Mbps can now connect to Transit Gateway. ⇒ What widened was the floor, not the ceiling. While connection speeds were generally increasing, this update lowered the minimum supported speed. This topic is not mentioned in the Document history. Notably, there are no entries for 2022 in the Document history. A related description from the hub's perspective can be found in the Transit Gateway timeline. See: AWS Direct Connect expands AWS Transit Gateway support at more connection speeds |
| 2023-06-15 | SiteLink prefix limit | Document history only | A limit on the number of prefixes supported by SiteLink was documented. The Document history records that a quota topic was added, specifying the maximum number of prefixes supported by SiteLink. Approximately one and a half years after the feature was introduced, the maximum number of prefixes it could handle was documented. This limit is subject to change due to the inbound prefix controls of August 20, 2026. The current limit can be found on the official quota page. See: Document history |
| 2024-11-25 | Direct Connect gateway to Cloud WAN core network | Both | Direct Connect gateways can now be directly connected to the Cloud WAN core network. The announcement stated that this eliminates the need to use Transit Gateway as an intermediary. ⇒ An option that does not pass through the hub was added to the hub connection introduced in 2019. ⇒ The Direct Connect gateway born in 2017 became the place to hang one more thing. Initially, this feature is only available in 11 commercial Regions, as stated in the announcement. See: AWS Cloud WAN simplifies on-premises connectivity via AWS Direct Connect / Document history |
| 2025-09-12 | 4-byte Autonomous System numbers | Both (differ) | BGP sessions can now use 4-byte Autonomous System numbers. The announcement stated that this allows support for the full range of values defined in RFC 6793, addressing complex multi-tenant configurations where 2-byte Autonomous System numbers were insufficient. The announcement explicitly states that this applies to all types of virtual interfaces. While the Document history refers to July 24, 2025, the announcement uses the date September 12, 2025. This document uses the date from the announcement. See: AWS Direct Connect support for 4-byte Autonomous System numbers for Virtual interfaces |
One Change Has No Date
⚠ The quota page details the increase in the number of transit virtual interfaces, but it does not state when that increase occurred. The page indicates that the number of transit virtual interfaces per dedicated connection has increased from one to four since the introduction of Transit Gateway support.⇒ This article does not make that change a row. Assigning a date to something the primary source leaves undated would put the row on weaker evidence than every other row here. The number itself is left to the official quota page.
⚠ For the same reason, there is another item that has not been included in the timeline. This concerns the cessation of new integrations for hosted virtual interfaces. Again, the primary source material lacks a specific date.
The Operational Layer — See, Record, Control
The operational layer differs in its formation compared to the other two. The nine rows this article takes between 2012 and 2020 are spread over 2,851 days, with gaps ranging from 23 to 830 days. After that, no row this article takes appears for 5 years and 10 months. Then, in 2026, three arrive within 142 days.| Date | Update | Dated by | Summary |
|---|---|---|---|
| 2012-08-13 | New console and User Guide | Document history only | The console was updated, and the "Getting Started Guide" was replaced with the "User Guide." This includes a topic on router configuration settings. This represents the oldest update recorded at the operational layer. The Document history itself, which this entry references, belongs to the document that began on this date. See: Document history |
| 2012-12-21 | IAM support | Document history only | Direct Connect operations now leverage IAM. ⇒ Operating a circuit came under the account's permission model. This occurred 1 year and 4 months after the service was launched. See: Document history |
| 2014-04-04 | AWS CloudTrail support | Document history only | Direct Connect API calls are now logged. ⇒ Who changed a circuit's configuration, and when, began to leave a record. This is 1 year and 3 months after IAM support was introduced. See: Document history |
| 2016-06-22 | Self-service LOA-CFA | Document history only | Users can now obtain connection authorization and facility assignment through the console and API. The Document history states that users can download the Letter of Authorization and Connecting Facility Assignment from the console or API. This is the first example of a portion of the circuit provisioning process being moved from manual interaction to an API. This is a Direct Connect-specific update, designed to move physical layer tasks to the operational layer. See: Document history |
| 2016-11-04 | Tagging support | Document history only | Users can now apply tags to Direct Connect resources. ⇒ A circuit became something the same inventory covers as any other AWS resource. See: Document history |
| 2017-06-29 | Amazon CloudWatch metrics | Document history only | Connection metrics are now visible in CloudWatch. ⇒ The state of a circuit became something a dashboard and an alarm can watch. ⚠ At this point only the physical connection is visible, not the virtual interface on it. Visibility at the level of each virtual interface does not arrive for nearly three more years. See: Document history |
| 2019-10-07 | AWS Direct Connect Resiliency Toolkit | Document history only | A wizard for ordering redundant connections has been added. The Document history states that the wizard, which supports multiple resiliency models, helps customers order dedicated connections tailored to their desired SLAs. ⇒ Ordering itself became a tool of the operational layer. ⛔ Which model to choose is left to the existing article. See: Document history |
| 2020-05-11 | CloudWatch metrics for virtual interfaces | Document history only | The scope of metrics has expanded to include not only physical connections but also virtual interfaces. This brings the granularity down to each virtual interface, following the visibility introduced in 2017. See: Document history |
| 2020-06-03 | Resiliency Toolkit failover testing | Document history only | Users can now perform failover testing of redundant configurations. ⇒ Redundancy moved from a drawing to something that can be exercised. ⚠ It took 5 years and 10 months for the next entry in the operational layer to follow this entry. See: Document history |
| 2026-03-31 | AWS CloudFormation support | What's New only | Users can now define Direct Connect configurations using templates. The announcement states that this allows for the automation of creation and management of connections, virtual interfaces, Direct Connect gateways, link aggregation groups, and BGP peering. It also mentions support for drift detection and change management. ⇒ 14 years and 8 months after the service launched, the shape of a Direct Connect deployment became something Infrastructure as Code can hold. ⚠ This entry does not appear in the Document history. See: AWS Direct Connect now supports AWS CloudFormation |
| 2026-07-30 | BGP route visibility | Both | Users can now view the BGP routes being exchanged on a virtual interface. The routes AWS accepted and the routes AWS advertises can be read with their AS path and BGP community values. The API operation is ListVirtualInterfaceRoutes. This continues the trend of increasing visibility, following the introduction of metrics in 2017 and per-virtual-interface metrics in 2020, now extending visibility all the way to the routing table contents. ⚠ The announcement states that this applies to all three types: private, transit, and public. See: AWS Direct Connect now supports BGP route visibility on Virtual Interfaces / Document history |
| 2026-08-20 | Inbound prefix controls | What's New only | Users can now assign a maximum number of routes accepted per virtual interface. Previously, private and transit virtual interfaces were limited to accepting a maximum of 100 routes, forcing customers with larger networks to use design workarounds such as route aggregation or splitting across multiple virtual interfaces. The new system allows a maximum of 1,000 routes per virtual interface, and pools of allocatable prefixes were newly created at the dedicated connection level and at the Direct Connect gateway level. ⇒ The route count stopped being a fixed ceiling of 100 and became a resource handed out per workload. ⚠ This feature does not apply to public virtual interfaces, as stated in the user guide. ⚠ This entry does not appear in the Document history. See: AWS Direct Connect introduces inbound prefix controls and higher prefix scale |
Current Overview, Functions, Features of AWS Direct Connect
The previous three tables outline the additions. This section describes where those additions have left things, and what is closed.The Three Lanes Did Not Fill at the Same Pace
The intervals between the rows this article takes vary across the three lanes.| Lane | Rows | Period | Maximum Interval Between Rows |
|---|---|---|---|
| Physical | 11 | August 3, 2011 — June 1, 2026 | 1,188 days (March 31, 2021 — July 1, 2024) |
| Logical | 11 | December 19, 2013 — September 12, 2025 | 1,078 days (December 19, 2013 — December 1, 2016) |
| Operational | 12 | August 13, 2012 — August 20, 2026 | 2,127 days (June 3, 2020 — March 31, 2026) |
⚠⚠ This table does not mark periods in which nothing happened to the service. The intervals are the time between the rows this article takes, and numerous announcements regarding additional locations were also made during these periods. Therefore, the length of the intervals only suggests that there were no significant structural changes within that layer.
Furthermore, the 2,127-day interval in the operational lane is the longest recorded in this article, and the densest run of additions follows it immediately. Across the three lanes, four additions fall in the 142 days from March 31, 2026 to August 20, 2026.
⇒ What happened to the dedicated-line layer in 2026 was not a new shape of connection. What was added was the range that can be seen, and the range that can be controlled, on circuits that are already in place.
Connection Types and Virtual Interface Types Are Different Axes
Two axes have to be kept apart here. These two can easily be confused, but their growth patterns are entirely different.The first axis concerns how to obtain a connection. The user guide lists two connection types: a physical Ethernet connection dedicated to a single customer, and connections provided by an AWS Direct Connect Partner on behalf of the customer. The former has been available since August 3, 2011, while the latter has been available since October 22, 2013. ⇒ This axis has remained at two options for over twelve years and has not expanded.
The second axis concerns what is built on top of that connection. The user guide lists three virtual interface (VIF) types: those that reach a VPC, those that reach public AWS services, and those that reach a Transit Gateway. ⇒ This axis expanded by one on March 27, 2019.

AWS Direct Connect Partners help you establish network connectivity between
AWS Direct Connect locations and their data center, office, or colocation
environment via the following models: Dedicated Connections, Hosted
Connections, and Hosted Virtual Interfaces.
⇒ The third option, Hosted Virtual Interfaces, is not a connection type. According to the user guide, this is a virtual interface assigned to an account separate from the account that owns the connection. The Hybrid Connectivity whitepaper states this as well.
Hosted Virtual Interface (Hosted VIF) is a type of Private VIF where the VIF
is assigned to a different AWS account than the AWS account which owns the
AWS Direct Connect connection (which can include an AWS Direct Connect
partner).
⇒ The same concept is counted as virtual interface assignment in the user guide, and as a connection delivery model for partners. The closure to new integrations, discussed in the next section, applies only to this third one.
The Path That Is Not Open to New Integrations — The Hosted Virtual Interface Model
⭐ This is the area most likely to be misunderstood.The AWS Direct Connect Partners page states the following regarding hosted virtual interfaces:
It is possible to oversubscribe the shared network link because AWS does not
limit network traffic capacity on each Hosted VIF. As a result, AWS no longer
allows new AWS Direct Connect Partner service integrations using Hosted VIFs.
AWS recommends you use Dedicated Connections or Hosted Connections if you have
workloads sensitive to network congestion.
The AWS Partner Network blog also makes the same point and arrives at the same conclusion. ⇒ This means two separate AWS pages make the same claim.
What this passage can be read for, and what it cannot, have to be kept apart.
What can be read: Three things. First, what is closed is new partner integrations. Second, the reason is oversubscription of bandwidth. Because AWS does not assign capacity to a hosted virtual interface, the shared link can be oversubscribed. Third, AWS is instead recommending dedicated connections or hosted connections.
What cannot be read: Three things, equally. First, it does not state that existing hosted virtual interfaces will stop. Second, it does not specify when this change took effect. This documentation lacks any dates and does not include corresponding entries in the Document history or What's New sections. Third, it does not provide any information about the overall status of the Direct Connect service.
⛔⛔ It therefore cannot be written that the hosted virtual interface has been retired. What the primary sources state is that AWS no longer allows new partner integrations. Nothing more, and nothing less.
⚠ Caution is needed when interpreting the language in the Hybrid Connectivity whitepaper. The whitepaper states, "AWS no longer allows new partners to offer this model." This is a rephrasing of the statement on the Partners page, "new AWS Direct Connect Partner service integrations using Hosted VIFs," and refers to new partner integrations, not new partners themselves. ⇒ This article will adopt the phrasing used on the Partners page.
Closing to New Integrations Is Not the Same as Ending the Feature
New onboarding restrictions and feature termination are separate matters.The hosted virtual interface is still active, and this can be verified through the user guide.
- The user guide includes a section on hosted virtual interfaces, with separate pages detailing the creation process for private, public, and transit configurations.
- ⭐⭐ As of August 20, 2026, the page on inbound prefix control includes a dedicated section titled
Hosted virtual interfaces. This section describes how the account that owns the parent connection manages the allocation for a hosted virtual interface, and how the receiving account accepts the allocation, after which the owner can make adjustments.
⇒ A feature that arrived in 2026 explicitly sets out how the hosted virtual interface is handled. That new partner integrations are not accepted, and that this path is maintained as a feature, hold at the same time.
Closing Happens at Three Granularities
Looking at Direct Connect as of 2026, what is closed and what is not are mixed across three granularities. ⛔ Speaking of all three with the same word breaks both the article and the reader's judgment.
| Granularity | Scope | Status | Justification |
|---|---|---|---|
| Service | AWS Direct Connect itself | Not closed | Not listed in any of the three AWS Service Availability Updates (2025-10-13, 2026-03-31, 2026-06-30). Furthermore, there were four feature additions in 2026. |
| Delivery Model | Partner integrations using hosted virtual interfaces | Not accepting new integrations | The AWS Direct Connect Partners page and the AWS Partner Network blog. ⚠ No specific dates are provided. |
| Location | GDS No. 3 Data Center, Shenzhen | Not accepting new connections | The Document history indicates that no new connections are being accepted after June 30, 2026, and that support will end in July 2027. |
⚠ Two out of the three categories share the same phrasing: "not accepting new [connections/integrations]". However, the scope is different. One refers to the delivery model used by partners, while the other refers to a single physical building. ⇒ In both cases, this does not indicate that the service itself is being shut down.
⚠ The row at the location granularity differs from the other two: it carries a published deadline. The Document history clearly states both the date when accepting new connections will cease and the end of support period. ⇒ Of the three, only this entry allows readers to input their own dates and plan accordingly.
⛔ Defining the terms used to describe a service's lifecycle is outside the scope of this article. The definitions of terms like "maintenance," "sunset," and "end of support," and what each entails within AWS operations, are the subject of AWS Service Lifecycle States. A list of retired services can be found at AWS Retired Services History and Timeline.
What Was Added in 2026
⭐ 2026 is the year the operational layer of Direct Connect grew the most. Three of the four additions below sit in that lane, and the fourth sits in the physical layer.- March 31, 2026 — CloudFormation support. A template now holds connections, virtual interfaces, Direct Connect gateways, LAGs, and BGP peering.
- June 1, 2026 — VIF Rate Limiters. One dedicated connection now divides its bandwidth across its virtual interfaces.
- July 30, 2026 — BGP route visibility.
ListVirtualInterfaceRoutesreturns the routes accepted and the routes advertised. - August 20, 2026 — Inbound prefix controls. Each virtual interface now carries its own allocation of accepted routes.
⇒ What these four have in common is that none of them creates a new shape of connection. Instead, they expand the visibility and the control over circuits already in place. These are not token additions to a settled layer. They pull in one direction: a higher resolution of operation.
⚠ Three of the four do not appear in the Document history. If you only look at the Document history, 2026 might seem like a quiet year for Direct Connect.
The New Entry Point Shares the Same Allocation Pool, Rather Than Replacing Anything
The Direct Connect gateway can also connect to AWS Interconnect. ⛔ AWS Interconnect - What One Managed Object Replaces in Multicloud and Last Mile Connectivity holds what AWS Interconnect folds into a single object.What's significant for this timeline is that the inbound prefix controls page introduced on August 20, 2026, states the following about the Direct Connect gateway allocation:
AWS Interconnect connections consume 2,000 prefixes from the 10,000 per-DXGW
allocation limit. Account for this when planning prefix allocations across VIFs
on a DXGW with an AWS Interconnect connection attached.
⇒ The primary source states that the new entry point hangs off an object in the old layer and shares its allocation. And the 2026 updates built the mechanism that hands that allocation out.
Frequently Asked Questions about AWS Direct Connect History
This section answers the questions that recur about the history of Direct Connect, taking each one back to the primary sources. ⛔ Questions about mechanics and about choosing belong to the existing articles.When did AWS Direct Connect launch?
AWS Direct Connect launched on August 3, 2011. Both the announcement and the User Guide's Document history give the same date. At the time of its initial release, only one Direct Connect location was available, located at an Equinix facility in Ashburn.Has AWS Direct Connect been discontinued or moved to maintenance?
No. AWS Direct Connect does not appear on any of the three AWS Service Availability Updates (dated October 13, 2025; March 31, 2026; and June 30, 2026). Furthermore, four feature additions arrived in 2026 alone: CloudFormation support, VIF Rate Limiters, BGP route visibility, and inbound prefix controls.Has the hosted virtual interface model been retired?
No. What the AWS Direct Connect Partners page states is that AWS no longer allows new partner integrations that use hosted virtual interfaces. It does not state that existing use will stop. In fact, the user guide page for inbound prefix controls, the feature added on August 20, 2026, carries a section dedicated to hosted virtual interfaces that sets out how the allocation is handled.When did AWS stop allowing new hosted virtual interface integrations?
The specific date has not been publicly announced. Both the AWS Direct Connect Partners page and the AWS Partner Network blog mention this restriction, but do not state when it came into effect. There are no corresponding entries in the User Guide's Document history or in AWS What's New. This topic has not been included as an entry in the timeline.Is a hosted connection the same thing as a hosted virtual interface?
No. A hosted connection is a method of acquiring a connection, introduced on October 22, 2013. A hosted virtual interface, on the other hand, is a way to assign a virtual interface to an account other than the one that owns the connection. The names are similar but the things are different, and only the latter is closed to new integrations.How many types of connections and virtual interfaces does Direct Connect have?
Direct Connect offers two types of connections and three types of virtual interfaces. The AWS Direct Connect Partners page lists three models for how partners deliver Direct Connect to customers, including hosted virtual interfaces. The two counts do not contradict each other. They count different things.Why does this timeline use two different primary sources?
This timeline uses two different primary sources because neither one alone provides sufficient information. Of the 45 lines in the Document history, 18 are about locations or Regions, and the record of location additions stops on January 22, 2021. There is no line at all for 2022. Conversely, three of the 2026 feature additions appear only in AWS What's New.Which date does this timeline use when the two sources disagree?
This timeline uses thePosted on: date from AWS What's New. The Posted on: section describes the date the feature became available, while the Document history section describes the date the document was updated. The latter can sometimes be before or after the former. In practice the 400 Gbps entry differs by 17 days and the long ASN entry by 50 days, and the two differ in opposite directions.Why does this timeline not list every Direct Connect location?
The addition of Direct Connect locations generates the highest volume of announcements, and a list that tried to cover them would go stale immediately. This article lists only four data points for the total that the announcements themselves state, and leaves the current number to the official Direct Connect locations page.Why is the most recent Document history entry missing from this timeline?
This entry, which reflects the addition of a dedicated connection billing mode, is not included because this article does not discuss pricing or billing modes. This is an intentional exclusion, not an oversight.Does AWS Interconnect replace AWS Direct Connect?
No. The primary sources do not say so. AWS Interconnect attaches to a Direct Connect gateway and consumes part of that gateway's prefix allocation. ⇒ Therefore, they coexist. AWS Interconnect - What One Managed Object Replaces in Multicloud and Last Mile Connectivity covers what AWS Interconnect itself folds in.Where can I find how Direct Connect actually works?
AWS Hybrid Connectivity Decision Guide holds as its subject the mechanics and the limits of the connection types, the three virtual interface types, the Direct Connect gateway, LAG, SiteLink, MACsec, and jumbo frames. This article covers only dates and order.Summary
AWS Direct Connect began with a single location on August 3, 2011. As of 2026, the announcements state over 150 locations.Measured across the three lanes, the additions did not arrive at the same pace. The physical layer consistently saw increases in speed, locations, and encryption capabilities. The logical layer introduced the Direct Connect gateway on November 1, 2017, separating where a circuit lands from what that circuit reaches, and added a third virtual interface type on March 27, 2019. The operational layer went 2,127 days without a row this article takes, and then received three in the 142 days from March 31, 2026. During that same 142-day period, one addition was also made to the physical layer.
What is closed is not at the granularity of the service. AWS Direct Connect as a service does not appear in any of the three AWS Service Availability Updates. What is closed is new partner integrations that use the hosted virtual interface, and one location. ⛔ Neither of these two is the state of the service. The first carries no date; the second does.
AWS Interconnect, a newer entry point, connects to the Direct Connect gateway and shares its allocation pool. ⇒ The dedicated line is not a layer that was replaced. It is a layer that a new entry point now sits on.
⚠ This article carries only dates and order. Mechanics, choosing, redundancy, and limits are left to the existing articles. All data was obtained as of September 18, 2026, and the number of Direct Connect locations and the limits both move.
References:
Tech Blog with curated related content
Written by Hidekazu Konishi