Most SAP-C02 candidates can recite the Direct Connect basics: a dedicated or hosted connection lands in a Direct Connect location, you create a virtual interface, and BGP carries routes between your router and AWS. Our SAP-C02 networking deep dive covers that layer, together with the three resiliency models and the Direct Connect plus VPN backup pattern. The exam, however, increasingly tests the layer underneath: which gateway a VIF may terminate on, why a Transit Gateway association advertises something different from a virtual private gateway association, how AWS picks between two paths that both advertise the same prefix, and what you reach for when a regulator demands encryption on a private circuit.
This guide is a practitioner’s walk through that layer, written for the AWS Certified Solutions Architect - Professional exam and verified against the current Direct Connect documentation. It assumes you already know what a VIF is and focuses on the rules, quotas and BGP behaviours that turn into distractors.
Connections: Dedicated vs Hosted, and What Each Can Carry
A Direct Connect connection is the physical or partner-provisioned Ethernet circuit. Everything else hangs off it.
| Dedicated connection | Hosted connection | |
|---|---|---|
| Who provisions it | You, through the console, CLI or API | An AWS Direct Connect Partner, on your behalf; you must accept it |
| Port speeds | 1, 10, 100 and 400 Gbps | 50, 100, 200, 300, 400, 500 Mbps and 1, 2, 5, 10, 25 Gbps |
| Virtual interfaces | Up to 50 private or public VIFs plus up to 4 transit VIFs (51 total) | Exactly 1 VIF of any type |
| Speed changes | New connection | Partner can upgrade or downgrade in place if they support it |
| Bursting | Line rate | Traffic policing: excess above the configured rate is dropped |
| MACsec | Yes, on 10, 100 and 400 Gbps at supported locations | No |
| LAG membership | Yes | No |
| Jumbo frames | Yes | Only if enabled on the partner’s parent connection |
Three details in that table do exam work. First, a hosted connection carries one VIF, so a design that needs a private VIF and a public VIF over a single 500 Mbps hosted connection is wrong by definition: you need two hosted connections or a dedicated port. Second, 1 Gbps and faster hosted connections may only be created by partners who have met additional requirements, and 25 Gbps hosted connections exist only at locations with 100 Gbps ports. Third, a hosted connection is not a hosted virtual interface. A hosted VIF is a VIF you create on your own connection but assign to a different AWS account; the other account accepts it and attaches it to their gateway. For private and transit hosted VIFs the receiving account owns both the VIF and the gateway side; for a public hosted VIF the chosen account is simply billed for it.
Dedicated ports use single-mode fibre: 1000BASE-LX for 1 Gbps, 10GBASE-LR for 10 Gbps, 100GBASE-LR4 for 100 Gbps and 400GBASE-LR4 for 400 Gbps. Your device must support 802.1Q VLAN tagging end to end, BGP and BGP MD5 authentication. After you order a dedicated connection AWS issues a Letter of Authorization and Connecting Facility Assignment (LOA-CFA) that the colocation provider uses to run the cross-connect.
Billing has two elements: port hours (by capacity and connection type) and data transfer out. Data transfer out over private and transit VIFs is charged to the account that owns the resource sending the traffic, at the Direct Connect rate, and there is no additional charge for using a multi-account Direct Connect gateway. Data transfer in is free.
The Three Virtual Interfaces and Where They Terminate
| VIF type | Reaches | Terminates on | Typical SAP-C02 cue |
|---|---|---|---|
| Private | One VPC, or many VPCs via a Direct Connect gateway, by private IP | A virtual private gateway in the connection’s associated Region, or a Direct Connect gateway (any Region except China) | “Private IP access to VPCs” |
| Public | Every AWS public service and public IP globally (S3, DynamoDB endpoints, EC2 public IPs, Amazon.com) | AWS’s public routing; you advertise public prefixes you own | ”S3 without traversing the internet”, “VPN endpoints over Direct Connect” |
| Transit | One or more Transit Gateways (or a Cloud WAN core network) via a Direct Connect gateway | A Direct Connect gateway only | ”Many VPCs in many Regions through one connection” |
A private VIF attached directly to a virtual private gateway reaches one VPC and that VPC must be in the connection’s associated Region. A private VIF attached to a Direct Connect gateway reaches virtual private gateways in any account and any Region except China. A transit VIF can only attach to a Direct Connect gateway, and works on any dedicated or hosted connection of any speed. Public VIFs reach all public Regions from any location in a public Region or GovCloud (US), but the China Regions are isolated: their prefixes are only advertised within China.
What you need to create a VIF
The prerequisites table in the documentation is exam gold because every row is a potential “why did the BGP session not come up” question:
- VLAN 1 to 4094, unique on the connection, cannot be changed after creation. On a hosted connection the partner supplies it.
- Your BGP ASN: a public ASN you own, or a private ASN. For 16-bit private ASNs the range is 64512 to 65534; 32-bit values from 1 to 2147483647 are also accepted. You cannot use the same ASN on both sides of a VIF, but you can reuse your ASN across VIFs.
- Amazon’s ASN: on a private VIF attached directly to a VGW it is the ASN configured on the VGW; attached to a Direct Connect gateway it is the gateway’s ASN (private, 64512 to 65534 or 4200000000 to 4294967294, default 64512). On a public VIF Amazon always peers as ASN 7224.
- Peer IPs: one BGP session per address family per VIF (IPv4, IPv6 or dual-stack). For IPv6 Amazon allocates a /125 and you cannot bring your own. 31-bit IPv4 prefixes are allowed. Do not use Elastic IPs or BYOIP from the Amazon pool as public VIF peer addresses.
- MD5 is always on; you can supply the key or let Amazon generate it.
- Public VIF only: the public prefixes you intend to advertise, which you must own and have registered. At least one, at most 1,000, any length from /1 to /32 (IPv4) or /1 to /64 (IPv6). AWS reviews them. Adding prefixes later goes through Support.
- Private and transit VIF only: the MTU, 1500 by default (see jumbo frames below).
VIF quotas that cannot be increased
| Quota | Value |
|---|---|
| Private or public VIFs per dedicated connection | 50 |
| Transit VIFs per dedicated connection | 4 |
| Total VIFs per dedicated connection or per LAG | 51 |
| VIFs per hosted connection | 1 |
| VIFs (private or transit) per Direct Connect gateway | 30 |
| Virtual private gateways per Direct Connect gateway | 20 |
| Transit Gateways per Direct Connect gateway | 6 |
| Direct Connect gateways associated to one Transit Gateway | 20 |
| Routes per BGP session on a public VIF | 1,000 |
| Direct Connect gateways per account | 200 (adjustable) |
| Active connections per location per Region per account | 10 (adjustable) |
| LAGs per Region | 10 (adjustable) |
Routes from on-premises to AWS on a private or transit VIF default to 100 per address family and can be raised to 1,000 with inbound prefix controls, covered later.
Direct Connect Gateway: Rules the Exam Hides in Scenarios
A Direct Connect gateway is a global resource. The documentation describes it as a distributed set of BGP route reflectors that sits outside the data path, which is why one gateway is already highly available and why you never deploy two “for redundancy”. It accepts three kinds of association: a virtual private gateway, a Transit Gateway, or a Cloud WAN core network. It also lets a VPC in a Local Zone reach your data centre through the Local Zone’s VGW.
Rule 1: no transitive routing between associations
A Direct Connect gateway does not forward traffic between the gateways associated with it. Two VGWs on the same Direct Connect gateway cannot talk through it, and that is the canonical SAP-C02 distractor (“use the Direct Connect gateway to connect the two VPCs” is wrong; use VPC peering, a Transit Gateway or Cloud WAN).
There is one documented exception, introduced in November 2021: if your on-premises router advertises a supernet that covers two or more VPC CIDRs whose VGWs are on the same Direct Connect gateway and the same VIF, the VPCs can reach each other via the Direct Connect endpoint. For example, advertising 10.0.0.0/8 or 0.0.0.0/0 towards VPCs 10.0.0.0/24 and 10.0.1.0/24 lets them communicate. To prevent that, advertise more specific routes that do not overlap your VPCs, use security groups, or give each VPC its own Direct Connect gateway. With Transit Gateway associations the equivalent leak is stopped by associating the VPC attachments with a route table that blackholes the other VPCs.
Rule 2: VGW and TGW associations do not mix
You cannot associate a Direct Connect gateway with a Transit Gateway if that gateway is already associated with a virtual private gateway or already has a private VIF attached. Migrating from VGW associations to a Transit Gateway therefore means a new Direct Connect gateway with a transit VIF, not a flip of a switch.
Rule 3: cross-account works through association proposals
The gateway can live in one account (call it the network account) while the VGWs or Transit Gateways live in others. The owner of the VGW or TGW sends an association proposal; the Direct Connect gateway owner accepts it and may edit the allowed prefixes on the way in. The gateway owner “owns the routing to the customer”, so the network account controls what the data centre learns regardless of what the workload accounts attach. This is the Direct Connect half of the shared-services design in our multi-account architecture guide.
Rule 4: allowed prefixes mean two different things
This is the single most under-studied Direct Connect fact and it reads like a trick until you see the mechanism.
| Association type | What the allowed prefix list does | What on-premises receives |
|---|---|---|
| Virtual private gateway | A filter. Entries must be the same as, or wider than, the VPC CIDR | Only the VPC’s actual CIDR, and only if the filter allows it |
| Transit Gateway | A provisioned advertisement. The exact prefixes you list | Exactly the listed prefixes, originated by the Direct Connect gateway’s ASN, regardless of which VPCs are attached |
The documentation’s worked example: a VPC with 10.0.0.0/16.
- VGW association, allowed prefix 10.0.0.0/24: you receive nothing, because /24 is narrower than the VPC.
- VGW association, allowed prefix 10.0.0.0/15: you receive 10.0.0.0/16, because the filter is wider than the VPC.
- TGW association, allowed prefix 10.0.0.0/24: you receive 10.0.0.0/24 (and not the /16), because AWS advertises what you provision.
- TGW association, allowed prefix 10.0.0.0/8: you receive 10.0.0.0/8, one summary route for every VPC behind the Transit Gateway, including VPCs in a second Region reached by TGW peering.
Two consequences. For Transit Gateway associations you must enter allowed prefixes (there is no VPC CIDR to inherit), and AWS to on-premises advertisement is capped at 200 prefixes per Transit Gateway on a transit VIF (IPv4 and IPv6 combined), which is why summarisation into a handful of supernets is the expected design. And when several Transit Gateways are associated with one Direct Connect gateway, their allowed prefix lists may not overlap, which means 0.0.0.0/0 is impossible with more than one TGW association. Changing an existing prefix moves the association to updating and can delay or drop only the traffic that uses that prefix.
Inbound prefix controls
The reverse direction, on-premises to AWS, was historically a flat 100 routes per BGP session. Prefix controls now expose it as a pool: each dedicated connection has a pool of 5,000 prefixes per address family at 1 and 10 Gbps, 30,000 at 100 Gbps and 50,000 at 400 Gbps; each private or transit VIF gets a default allocation of 100 per family that you can raise to 1,000; and each Direct Connect gateway caps total allocations across its VIFs at 10,000 (IPv4 plus IPv6) alongside its 30-VIF limit. Advertising more prefixes than the allocation drops the BGP session to idle (reported as DOWN), so “the session flaps whenever the WAN team adds branches” is a prefix allocation problem, not a timer problem. Public VIFs are not part of this scheme and keep their fixed 1,000. Remember too that propagated routes into a VPC route table are still bounded by the VPC route table quota, which a larger VIF allocation does not raise.
BGP on Direct Connect: How AWS Picks a Path
Direct Connect is BGP, so questions that say “prefer the 10 Gbps circuit and fail over to the 1 Gbps circuit” are asking you to manipulate BGP attributes that AWS honours. The order differs by VIF type.
Private and transit VIFs: AWS to on-premises
For traffic leaving AWS towards your network, the evaluation order is:
- Longest prefix match. Advertise more specific prefixes on the preferred VIF if you want active/passive without touching communities.
- Local preference, set by community tags you attach to the prefixes you advertise. This is the recommended knob when prefix lengths are equal.
- AS_PATH length, when prefix length and local preference tie.
- MED, last and explicitly not recommended by AWS.
The local preference communities are:
| Community | Meaning |
|---|---|
7224:7100 | Low preference |
7224:7200 | Medium preference (also the default AWS applies to a location in the same associated Region when you tag nothing) |
7224:7300 | High preference |
They are mutually exclusive per prefix and are evaluated before AS_PATH. Active/passive: tag the primary VIF’s prefixes 7224:7300 and the backup’s 7224:7100. Active/active across two connections, even in different home Regions: tag both 7224:7200, and AWS load-balances with ECMP; if one fails the remaining paths carry traffic regardless of Region association. With no tags, an AWS Region prefers Direct Connect locations in its own associated Region, and ECMP applies across VIFs that have the same AS_PATH length and attributes when the paths are either all from locations in the same associated Region or all from locations outside it. The ASNs inside the AS_PATH do not need to match; only the length counts.
A subtle SiteLink interaction: with SiteLink enabled on a VIF, an AWS Region prefers the lower AS_PATH length from any location, ignoring the associated-Region preference it would otherwise apply.
For the on-premises to AWS direction, you choose on your router as usual. Because a Transit Gateway evaluates Direct Connect gateway propagated routes before VPN propagated routes for an identical CIDR, the “Direct Connect primary, VPN backup” pattern works without extra configuration on the AWS side; our Transit Gateway internals guide walks through that evaluation order.
Public VIFs: scope communities and NO_EXPORT
A public VIF is a peering with Amazon’s network as AS 7224, and you must advertise public prefixes you own. AWS filters inbound packets to confirm they originate from your advertised prefixes and never re-advertises your prefixes to other customers, peers or transit providers; all prefixes AWS sends you carry the well-known NO_EXPORT community and a minimum AS_PATH length of 3.
Scope communities decide how far your prefixes propagate inside AWS:
| Community | Scope of your advertisement |
|---|---|
7224:9100 | The local AWS Region only |
7224:9200 | All Regions on the continent (North America, Asia Pacific, or Europe/Middle East/Africa) |
7224:9300 | Global, all public Regions (the default when you tag nothing) |
And AWS tags what it sends you so you can filter:
| Community on AWS routes | Origin |
|---|---|
7224:8100 | Same Region as the Direct Connect location |
7224:8200 | Same continent |
| none | Another continent |
Two more public-VIF rules appear in distractors. If you advertise the same prefix from two Regions over two public VIFs with identical attributes, AWS sends outbound traffic via the home Region. And if you peer with a private ASN on a public VIF, AWS replaces it with 7224 when re-advertising, so AS_PATH prepending is stripped and has no effect outside AWS; prepending only works with a public ASN you own. Prefixes with the same communities and identical AS_PATH are multipath candidates, which is how you load-share inbound traffic across multiple public VIFs (all of which must be in the same Region).
BFD and timers
Asynchronous BFD is enabled on the AWS side of every VIF but only takes effect once you configure it on your router; AWS recommends a 300 ms minimum interval with a multiplier of 3 for sub-second failure detection. Without BFD you wait for the BGP hold timer (90 seconds by default on the AWS side) before a dead peer is withdrawn, which is the difference between a blip and a 90-second outage in a failover question.
Link Aggregation Groups
A LAG is one logical LACP bundle at a single Direct Connect endpoint:
- Members must be dedicated connections of 1, 10, 100 or 400 Gbps, all the same speed, all terminating on the same endpoint. Hosted connections cannot join.
- Maximum four connections below 100 Gbps, two at 100 or 400 Gbps. Each member counts against your per-Region connection quota.
- All members run active/active. Multi-chassis LAG is not supported.
minimumLinksdefaults to 0; set it so the whole LAG goes down when too few members are up, which forces failover rather than overloading the survivors.- All VIF types are supported, up to 51 per LAG. You can build a LAG from existing connections (their VIFs move with them) or order new ones. MACsec on a LAG uses one key across all members, and joining a LAG replaces a connection’s MACsec keys with the LAG’s.
- With prefix controls, a LAG’s inbound prefix pool is the per-connection pool times the number of billable members, and you cannot remove a member if that would shrink the pool below what the LAG’s VIFs have allocated.
The exam trap: a LAG increases bandwidth and survives a single port failure, but every member is in one location on one device, so it does not satisfy a “resilient to location failure” requirement. That needs connections at two locations.
Resiliency Models and the Failover Test
The Resiliency Toolkit’s connection wizard orders dedicated connections in the shape each SLA requires:
| Model | Shape | Protects against | SLA target |
|---|---|---|---|
| Maximum resiliency | Two connections in each of two locations, on separate devices | Device, link and whole-location failure | 99.99% |
| High resiliency | One connection in each of two locations | Fibre cut, device failure, location failure | 99.9% |
| Development and test | Two connections on separate devices in one location | Device failure only | n/a |
| Classic | Whatever you order manually | Your problem | n/a |
The wizard refuses to terminate redundant connections on the same device and builds LAGs automatically when you choose a speed that is not a native port speed.
Once built, the failover test proves the design. You pick a VIF, a BGP peering session and a duration; AWS takes that peering session down for the duration (or until you stop it) and then restores it. If traffic does not move to the redundant VIF, your resiliency model is fiction. Only the account that owns the VIF can run the test, CloudTrail records it, history is kept for 365 days with statuses In progress, Completed, Cancelled and Failed, and AWS warns not to run it during a Direct Connect maintenance window because the session may be restored early. A scenario that says “validate failover without unplugging fibre” is pointing at this feature.
Jumbo Frames and MTU
Direct Connect supports Ethernet frames of 1522 or 9023 bytes. At the VIF level:
| VIF | MTU options |
|---|---|
| Private | 1500 or 9001 |
| Transit | 1500 or 8500 (Transit Gateway jumbo frames are 8500 bytes) |
| Public | 1500 |
Enabling jumbo frames on a VIF may update the underlying connection and disrupt all VIFs on it for up to 30 seconds. Once a VIF is jumbo, it can only be associated with a jumbo-capable connection or LAG. If two private VIFs advertise the same route with different MTUs, or a Site-to-Site VPN advertises the same route, 1500 is used. On hosted connections jumbo frames are available only if enabled on the partner’s parent connection. Jumbo frames apply only to propagated routes via Direct Connect and static routes via Transit Gateways, and EC2 instance types C1, CC1, T1 and M1 drop them.
Encryption Over Direct Connect: Three Mechanisms
Direct Connect is a private circuit, not an encrypted one. AWS encrypts traffic at the physical layer between Direct Connect locations and Regions, but the cross-connect from your router to the AWS device is in the clear unless you add one of these:
| Mechanism | Layer | Where it runs | Requirements | Trade-offs |
|---|---|---|---|---|
| MACsec | 2 | Between your edge device and the Direct Connect device over the cross-connect | Dedicated 10, 100 or 400 Gbps at a MACsec-capable location; MACsec-capable device; LAG supported | Line-rate, no extra charge, but point-to-point only (not end to end) and not on hosted connections |
| Site-to-Site VPN over a public VIF | 3 (IPsec) | From your customer gateway to VGW or TGW public endpoints | Public VIF, public IPs on both ends | Exposes public endpoints and opens access to all public services; 1.25 Gbps per tunnel |
| Private IP VPN over Direct Connect | 3 (IPsec) | From your customer gateway to a Transit Gateway over a transit VIF using private IPs | Transit Gateway with a private CIDR block, Direct Connect gateway, transit VIF, TGW association whose allowed prefixes include the TGW CIDR | No public IPs, no third-party VPN gear, higher route scale; still 1.25 Gbps per tunnel (use ECMP) |
MACsec details that get tested
MACsec on Direct Connect is static CAK mode only. You generate a Connectivity Association Key Name and Connectivity Association Key pair (the CAK is exactly 64 hexadecimal characters, AES-256), associate it with the connection or LAG, and configure the same pair on your device; the session key is derived automatically and rotates on its own. A connection stores up to three CKN/CAK pairs so you can rotate without downtime; the AWS device tries the newest key and falls back to the previous working one. Cipher suites are GCM-AES-256 and GCM-AES-XPN-256 at 10 Gbps and XPN-256 only at 100 and 400 Gbps, because 32-bit packet numbering exhausts in minutes at those speeds. The Secure Channel Identifier must be on, and moving the VLAN tag outside the encrypted payload is not supported.
The encryption mode is the exam hook: should_encrypt (the default) attempts MACsec and falls back to clear traffic if negotiation fails; must_encrypt refuses to pass any traffic without encryption. A compliance scenario wants must_encrypt; an availability scenario during initial rollout wants should_encrypt. AWS stores your keys in Secrets Manager under an AWS managed key, and if you schedule that secret for deletion AWS eventually disassociates the key and, if it was the last one on a must_encrypt connection, drops the mode to should_encrypt to avoid sudden packet loss.
Private IP VPN details that get tested
Private IP VPN exists so regulated customers can encrypt over Direct Connect without a public VIF. You give the Transit Gateway a private CIDR block (RFC 1918 or RFC 6598) that does not overlap any attachment, include that CIDR in the Direct Connect gateway association’s allowed prefixes, and the IPsec tunnels terminate on private IPs at both ends. The VPN attachment can use the same or a different TGW route table from the underlying Direct Connect attachment, so encrypted and unencrypted flows can run side by side. Route scale is higher than Direct Connect alone: 5,000 outbound and 1,000 inbound. It requires a Transit Gateway; a virtual private gateway cannot terminate a private IP VPN.
SiteLink: Site-to-Site Over the AWS Backbone
SiteLink connects two of your own locations through their Direct Connect points of presence over the AWS global network without routing through a Region. You enable it per VIF, and the VIFs must hang off the same Direct Connect gateway; AWS then exchanges the BGP routes learned from each site with the others.
| VIF | SiteLink |
|---|---|
| Transit VIF | Supported |
| Private VIF on a Direct Connect gateway (with or without a VGW association) | Supported |
| Private VIF attached directly to a VGW | Not supported |
| Public VIF | Not supported |
There is a separate hourly SiteLink fee per VIF plus data transfer. It is not available in GovCloud (US) or China. It does not work if your router advertises the same route on multiple VIFs, and SiteLink prefixes are bounded by the same 1,000-per-family prefix controls. Jumbo frames work at 8500 or 9001 depending on VIF type. When a scenario describes data centres in two countries that already have Direct Connect and need low-latency private connectivity to each other without a Transit Gateway in the middle, SiteLink is the answer; when the sites need to reach each other and VPCs with centralised inspection, Transit Gateway peering or Cloud WAN is.
The Associated Region Is Control Plane, Not Data Plane
Every Direct Connect device belongs to one AWS Region, and a connection inherits that associated Region. The associated Region decides where the connection and its VIFs are managed (console, API calls, CloudWatch metrics) and influences default local preference, but it does not restrict where your traffic goes: a public VIF reaches all public Regions, and private or transit VIFs through a Direct Connect gateway reach any Region. The one exception is a private VIF attached directly to a virtual private gateway, where the VGW must be in the associated Region. One physical location can host devices for two different Regions with different port speeds and MACsec support, so “the location is in Mumbai, therefore the connection is managed in Mumbai” is not necessarily true.
Hybrid DNS, Outposts and the edge services that sit on top of this connectivity are covered in our hybrid and edge architectures guide, and the Region-failover designs that ride on Direct Connect are in the disaster recovery guide.
Scenario Drill
| Scenario | Answer | Why |
|---|---|---|
| Single 1 Gbps hosted connection must reach VPCs privately and S3 via public IPs | Add a second hosted connection or move to a dedicated port | One VIF per hosted connection |
| Two VPCs on VGWs associated with the same Direct Connect gateway must communicate | VPC peering, Transit Gateway or Cloud WAN | No transitive routing through a Direct Connect gateway |
| Transit VIF receives 22.0.0.0/24 but not the VPC’s 10.0.0.0/16 | Allowed prefixes on a TGW association are provisioned, not filtered | Enter the prefixes you want advertised |
| VGW association with allowed prefix 10.0.0.0/24 for a 10.0.0.0/16 VPC: no routes | Filter must be same or wider than the VPC CIDR | Use 10.0.0.0/16 or wider |
| 2 TGWs on one Direct Connect gateway; second TGW needs 0.0.0.0/0 | Not possible | Allowed prefixes may not overlap across TGW associations |
| Prefer 10 Gbps path, fail to 1 Gbps path, same prefixes | Tag 7224:7300 on primary, 7224:7100 on backup | Local preference beats AS_PATH |
| Load-share inbound across two connections in different Regions | Tag both 7224:7200 | Equal local preference enables ECMP regardless of home Region |
| AS_PATH prepending on a public VIF with private ASN has no effect | Expected | AWS replaces private ASNs with 7224 and strips prepends |
| Prefixes must only be reachable from eu-west-1 over a public VIF | 7224:9100 | Local-Region scope community |
| BGP drops to idle after advertising 150 routes | Raise the VIF prefix allocation (default 100, max 1,000) | Prefix controls |
| 40 Gbps needed, survive a port failure | LAG of 4 × 10 Gbps, minimumLinks set | LAG rules; location failure still unprotected |
| 99.99% SLA for on-premises connectivity | Maximum resiliency: 2 connections × 2 locations, separate devices | Resiliency Toolkit |
| Prove failover without physical disruption | Direct Connect failover test on the VIF | Brings BGP session down for a chosen duration |
| Encrypt a 10 Gbps dedicated connection at line rate, no extra cost | MACsec with must_encrypt | L2 encryption on dedicated 10/100/400 Gbps |
| Encrypt over Direct Connect, regulator forbids public IPs, no appliances | Private IP VPN over a transit VIF to a Transit Gateway | No public VIF or public endpoints |
| Two data centres with Direct Connect need private connectivity to each other, no Region transit | SiteLink on both VIFs, same Direct Connect gateway | Backbone site-to-site |
| Jumbo frames enabled on one private VIF, 1500 on the other, same route | 1500 used | Mixed-MTU rule |
Common Mistakes
- Treating a hosted connection like a dedicated one. One VIF, partner-controlled speed, traffic policing, no MACsec, no LAG.
- Expecting the Direct Connect gateway to route VPC to VPC. It is a route reflector for on-premises to AWS traffic; use peering, Transit Gateway or Cloud WAN.
- Confusing allowed-prefix semantics. Filter for VGW associations, provisioned advertisement for Transit Gateway associations.
- Reaching for MED or AS_PATH first. AWS evaluates longest prefix, then local preference communities, then AS_PATH, then MED. Communities are the recommended tool.
- Believing a LAG is multi-site resilience. It is multi-port resilience in one location.
- Assuming Direct Connect is encrypted. It is private, not encrypted. Pick MACsec, VPN over public VIF, or Private IP VPN based on the constraints.
- Mixing VGW and TGW associations on one gateway. Not allowed; plan a second Direct Connect gateway for the migration.
- Ignoring the 200-prefix advertisement cap from a Transit Gateway to on-premises; summarise.
- Forgetting that AWS strips private ASNs on public VIFs. Prepending needs a public ASN you own.
- Running the failover test during a maintenance window or from an account that does not own the VIF.
Frequently Asked Questions
Can a transit VIF be created on a hosted connection?
Yes. Transit VIFs work on any dedicated or hosted connection of any speed, but a hosted connection still carries only one VIF in total.
How many Transit Gateways can one Direct Connect gateway reach, and how many Direct Connect gateways can one Transit Gateway have?
Six Transit Gateways per Direct Connect gateway and 20 Direct Connect gateways per Transit Gateway. Both are fixed quotas. A Direct Connect gateway can hold 20 virtual private gateway associations instead, but never both VGW and TGW associations at once.
Why does the exam care about 7224?
It is Amazon’s ASN on public VIFs and the prefix of every Direct Connect BGP community. The local preference set (7224:7100, 7224:7200, 7224:7300) controls AWS to on-premises path choice on private and transit VIFs; the scope set (7224:9100, 7224:9200, 7224:9300) controls how far your public prefixes propagate; and 7224:8100 / 7224:8200 mark the origin of routes AWS sends you.
What is the difference between SiteLink and Transit Gateway peering?
SiteLink joins your on-premises sites to each other across Direct Connect locations over the AWS backbone without entering a Region. Transit Gateway peering joins Transit Gateways in different Regions so VPCs and attached on-premises networks can route through them. SiteLink is for site-to-site; Transit Gateway peering (or Cloud WAN) is for cloud-centric hub routing with inspection.
Does MACsec replace an IPsec VPN?
No. MACsec encrypts the single Ethernet hop between your router and the Direct Connect device at line rate with no extra charge, but it is point-to-point and only on 10, 100 and 400 Gbps dedicated connections at supported locations. IPsec (public VIF or Private IP VPN) encrypts end to end between your customer gateway and the AWS gateway but is limited to 1.25 Gbps per tunnel.
If I attach a private VIF directly to a VGW, which Regions can I reach?
Only the VPC whose VGW is in the connection’s associated Region. Put a Direct Connect gateway in between to reach VPCs in any Region.
Conclusion
The SAP-C02 exam rarely asks “what is Direct Connect”. It asks you to spot that a hosted connection cannot carry a second VIF, that a Direct Connect gateway will not route between the VPCs hanging off it, that a Transit Gateway association advertises what you provision while a VGW association advertises what the filter lets through, and that path preference is settled by prefix length and 7224:7x00 communities before AS_PATH ever matters. Layer on the LAG and resiliency-model shapes, the MTU rules, and the three encryption options with their speed and public-IP constraints, and most Direct Connect questions collapse to one or two eliminations.
The fastest way to make those eliminations automatic is to practise them against realistic distractors. Sailor.sh’s AWS Certified Solutions Architect - Professional (SAP-C02) Mock Exam Bundle includes eight full-length, 75-question exams whose explanations spell out why the LAG answer, the VPN-over-public-VIF answer or the single-gateway answer loses to the one the scenario actually demands. Pair this guide with the SAP-C02 study plan and the first-attempt pass guide, then test yourself on the SAP-C02 practice questions before booking the real thing.