VPN, Direct Connect, and MACsec
Lesson 1 of 3 in Hybrid and Private Connectivity.
Two ways to connect a data centre to AWS, and one sentence that decides most exam questions about them: a VPN is encrypted by default and Direct Connect is not.
AWS Site-to-Site VPN builds an IPsec connection between your customer gateway device and either a virtual private gateway or a transit gateway. Every VPN connection comes with two tunnels, terminating on endpoints in different Availability Zones, because a single tunnel is a single point of failure — and AWS will take one down for maintenance, which is why a design that only configures one tunnel is a design that will have an outage. Routing is static (you declare the prefixes) or dynamic over BGP (the gateways exchange them, and failover between tunnels happens on its own). Traffic is encrypted in transit over the public internet, which is the entire point: cheap, quick to stand up, encrypted, and subject to whatever the internet is doing today.
AWS Direct Connect is a physical circuit into an AWS location, giving you consistent latency, high and predictable bandwidth, and lower data-transfer costs. You carve it into virtual interfaces: a private VIF reaches a VPC (through a virtual private gateway or a Direct Connect gateway), a transit VIF reaches a transit gateway through a Direct Connect gateway, and a public VIF reaches AWS public service endpoints. What you do not get is confidentiality. The circuit is private in the sense that it is not shared routing on the internet; the packets on it are not cryptographically protected. If a requirement says "data in transit must be encrypted" and the answer options include a bare Direct Connect connection, that option is wrong.
Two ways to fix that, and C03 names the second explicitly: run an IPsec VPN over the Direct Connect connection, or enable MACsec on the connection itself.
A four-layer stack of hybrid-path encryption options, bottom to top. Layer one, the physical path: an internet transit path or a Direct Connect cross-connect, which by itself provides no cryptographic protection. Layer two, MACsec at layer two: available on 10, 100 and 400 Gbps dedicated Direct Connect connections at selected points of presence, encrypting the link between your router and the AWS Direct Connect device with 256-bit keys. Layer three, IPsec at layers three and four: AWS Site-to-Site VPN, encrypted by default, the only option over the internet and the usual way to encrypt traffic that rides a Direct Connect connection all the way to the VPC. Layer four, emphasized, TLS at the application layer: end-to-end encryption between client and service that holds regardless of which lower layers are present, and the control that most compliance requirements actually describe.
| Site-to-Site VPN | Direct Connect alone | VPN over Direct Connect | Direct Connect + MACsec | |
|---|---|---|---|---|
Encrypted in transit | yes — IPsec, by default | no — private routing, no cryptography | yes — IPsec over the private circuit | yes — at layer 2, on the connection itself |
What span is protected | customer gateway to AWS gateway, across the internet | nothing | customer gateway to the AWS gateway, over the circuit | your router to the AWS Direct Connect device — the cross-connect only |
Performance | internet-dependent; about 1.25 Gbps per tunnel, more with ECMP on a transit gateway | dedicated and predictable, up to 100 or 400 Gbps | the circuit’s bandwidth minus IPsec overhead and the VPN’s own limits | line rate — encryption happens in the hardware |
Time to deploy | hours | weeks to months — a physical cross-connect | weeks, then hours | weeks, and only at supported locations |
Requirements | a routable customer gateway device | a Direct Connect location or partner | both of the above | a 10, 100 or 400 Gbps dedicated connection at a MACsec-capable point of presence, MACsec-capable customer hardware, 256-bit CKN/CAK keys |
Typical exam phrasing | “quickly, encrypted, over the internet” | “consistent bandwidth and lower egress cost” | “dedicated bandwidth and encryption in transit” | “layer 2 encryption on the Direct Connect link” |
Precision on MACsec, because C03 names it and the details are the question. MACsec is an IEEE 802.1AE standard that encrypts Ethernet frames, and on AWS it applies to dedicated Direct Connect connections of 10, 100 or 400 Gbps at selected points of presence. You create a CKN/CAK key pair, associate it with the connection or link aggregation group — AWS keeps it in Secrets Manager — and configure the matching key on your own router, which must support MACsec. Only 256-bit keys are accepted, and for 100 and 400 Gbps connections extended packet numbering is required, because the original 32-bit numbering space would otherwise force key rotation every few minutes.
The limitation to state out loud: MACsec protects the link, from your router to the AWS Direct Connect device. It does not encrypt the traffic beyond that point, and it is unavailable on hosted connections. So "data must be encrypted end-to-end from on-premises to the application" is not a MACsec answer — that is IPsec, or TLS, or both.
Two more facts worth carrying. Redundancy: a single VPN connection's two tunnels protect against a tunnel failure, not a device or site failure; a serious design uses two customer gateway devices, and a serious Direct Connect design uses two connections at two locations — frequently with a VPN as the backup path, which is also the cheapest way to satisfy "what if the circuit is cut". And scope: C03 removed cross-Region private and public VIF design from the skill list, so do not spend study time on cross-Region VIF topologies; spend it on which option satisfies an encryption requirement, and on getting the MACsec prerequisites right.
BGP or static routing?
BGP is the default answer for anything that must fail over on its own: the gateways exchange prefixes, both tunnels are usable, and a tunnel going down reconverges without a human. Static routing exists for customer devices that do not speak BGP, and it means you maintain prefix lists by hand and failover is your problem. With a transit gateway, BGP also lets you use ECMP across tunnels to exceed a single tunnel’s throughput.
Site-to-Site VPN over Direct Connect — where does the VPN run?
The classic pattern terminates an IPsec VPN over a public VIF, so the encrypted tunnel rides the private circuit instead of the internet. With a transit gateway and a transit VIF, Site-to-Site VPN over private IP is also available, which keeps the tunnel on private addressing. Either way, the result is the combination the exam likes: dedicated bandwidth from Direct Connect plus encryption from IPsec.
Hosted connections and partner circuits
A hosted connection comes from a Direct Connect partner and is provisioned on their port, typically at sub-1 Gbps capacities. It behaves like a dedicated connection for routing purposes but cannot run MACsec — MACsec is a property of a dedicated port you own. If a question gives you a hosted 500 Mbps connection and asks for layer 2 encryption, the answer is "not available here; use IPsec".
Multi-cloud, in the same frame
The task statement says hybrid and multi-cloud, and nothing changes structurally: a Site-to-Site VPN to another cloud provider’s gateway is the common path, with BGP for routing and the usual two tunnels; a transit gateway becomes the hub so one attachment serves many VPCs. The security questions are identical — is it encrypted, is the routing deliberate, is the far side authenticated, and which segments can reach it.
Key terms: AWS Site-to-Site VPN, AWS Direct Connect, MACsec (MAC Security)
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.