Dedicated Cloud Connectivity Security Guide: Encrypting, Routing and Governing Private Cloud Circuits

Private circuits into AWS Direct Connect, Azure ExpressRoute and Google Cloud Interconnect are often treated as trusted because they avoid the internet, yet none of them encrypts traffic by default and each one is a BGP session that can carry the wrong routes into your network. This guide covers the security of the circuit itself: link encryption with MACsec, IPsec over the circuit, BGP route controls and prefix limits, cross-account and partner attachments, key handling, resilience and monitoring. It is written for network and cloud architects, network engineers and security reviewers who run or approve hybrid connectivity. It does not repeat VPC and VNet controls inside the cloud; see the Cloud Network Security Guide for those. Product behaviour was checked against AWS, Microsoft and Google documentation on 11 November 2026.

Key takeaways

• Private is not encrypted. AWS states that Direct Connect "does not encrypt your traffic that is in transit by default", and the same is true of ExpressRoute and Cloud Interconnect: you must add MACsec, IPsec or application TLS yourself.
• MACsec protects one hop. It encrypts the cross-connect between your router and the provider edge at line rate, but traffic is decrypted at the provider edge, so sensitive flows still need IPsec or TLS for end-to-end protection.
• The BGP session is the real trust boundary. Filter what you accept and what you advertise, set prefix limits on your side, and remember that exceeding the provider's prefix quota takes the session down.
• Attachments are access grants. Hosted connections, partner pairing keys and cross-account gateway associations decide which accounts and networks can reach your on-premises estate; treat them like privileged access and review them.
• Keys need an owner and a rotation plan. MACsec CAK/CKN pairs and IPsec pre-shared keys sit in a secrets store and on your routers; plan hitless rotation before go-live, not after an incident.

What dedicated connectivity is, and what it is not

All three major providers sell a physical cross-connect at a colocation facility (a dedicated port you own end to end) and a partner model where a carrier or exchange provisions a slice of its own port for you. Each then runs one or more logical interfaces with eBGP over 802.1Q VLANs. The table compares the building blocks that matter for security.

The circuit gives you predictable latency and avoids internet exposure of the transport, but it extends your routing domain into the provider's edge and, through partners, into a third party's network. The fibre, the meet-me room and the partner's switches are all places where traffic can be observed if it is not encrypted. For the carrier side of the path, see the MPLS and Carrier WAN Security Guide.

Threats to the circuit

Encrypting the link with MACsec

MACsec (IEEE 802.1AE with MKA key agreement) encrypts Ethernet frames between your router and the provider edge. The three implementations differ in detail, and those details decide whether a link comes up.

• Use the strict mode once stable: AWS's default should_encrypt silently carries clear traffic if negotiation fails. Move to must_encrypt after a burn-in period, accepting that a key fault becomes an outage, and route around it with a second encrypted link.
• Know what MACsec does not cover: AWS and Google both note it is point to point on the Ethernet link. Google adds that it does not encrypt traffic inside Google's network and recommends IPsec on top for layer 3 protection.
• Protect the vault that feeds the port: on Azure the Key Vault holding the CAK is a dependency of the circuit. Restrict who can write those secrets, keep soft delete on, and monitor secret changes. See the Azure Key Vault Security Guide.

For the protocol itself, cipher choice and MKA, see the MACsec guide.

IPsec over the circuit

IPsec gives end-to-end protection from your router to a cloud VPN gateway or network virtual appliance, and it works on hosted or partner circuits where MACsec is not available. AWS describes combining Direct Connect with Site-to-Site VPN to get an IPsec-encrypted private connection. Microsoft documents a site-to-site VPN over ExpressRoute Microsoft peering in which route exchange happens inside the tunnels, so it is not exposed to the underlying peering. Google offers HA VPN over Cloud Interconnect.

• Cryptography: use IKEv2 with AES-GCM or AES-256 and SHA-256 or stronger, and Diffie-Hellman group 14 as a floor (Microsoft's worked example uses DH group 14 with AES-CBC-256 and SHA-256; prefer elliptic curve or larger groups where both ends support them). See the IPsec Security Guide.
• Throughput: a single tunnel rarely fills a 10 Gbps or larger circuit. Plan multiple tunnels with ECMP, and measure before committing a migration to it.
• Microsoft peering scope: when you run VPN over Microsoft peering, apply a route filter so only the public prefixes you need are advertised. Microsoft's example allows only the West US 2 regional community 12076:51026, and terminates Microsoft peering in the DMZ.
• Choosing: MACsec when you own a dedicated port and need line-rate protection of the cross-connect; IPsec when you need end-to-end protection, use a partner circuit, or must satisfy a policy that requires encryption to the cloud network boundary. Many regulated designs run both.

BGP route controls and prefix limits

Every circuit is an eBGP session. The provider controls what it accepts, but only you control what you accept, and a mistake can attract traffic for prefixes you never meant to route through the cloud.

• Filter what you advertise: send only the specific on-premises prefixes the cloud needs. Never advertise a default route or RFC 1918 space over Microsoft peering; Microsoft requires these to be filtered.
• Filter what you accept: accept only the cloud CIDRs you expect, and drop a default route from the cloud unless it is designed. Use a max-prefix setting on your router with a warning threshold below the provider limit.
• Avoid loops and leaks: AWS treats an AS path containing 7224 twice as a loop and drops it, and requires that Direct Connect learned prefixes are not advertised beyond your network boundary. Filter routes learned from one provider out of advertisements to another and to the internet.
• Remember public VIF scope: an untagged public VIF advertisement is global by default. Tag with 7224:9100 where only the local Region should reach you.
• Authenticate sessions: configure the MD5 key on every BGP session (Microsoft makes it optional, Google supports it on Cloud Router). Keep the key out of shared tickets.

For RPKI, max-prefix design and route leak prevention generally, see the BGP and Routing Security Guide.

Attachments, partners and cloud permissions

The circuit connects to cloud networks through gateways: the Direct Connect gateway and transit gateways on AWS, the ExpressRoute gateway and Global Reach on Azure, Cloud Router and VLAN attachments on Google. Each attachment widens reachability.

• Cross-account associations: on AWS a virtual private gateway owner in any account can propose an association to your Direct Connect gateway, and the gateway owner must accept it. The owner can override the requested allowed prefixes, which act as a filter on what is advertised. Accept proposals only through change control and record who approved them.
• Hosted and partner connections: a hosted connection or a Partner Interconnect pairing key gives a third party the ability to provision into your account. Treat pairing keys and authorisation keys as secrets, scope them to one use, and remove unused hosted connections.
• Cloud roles: the API actions that create virtual interfaces, accept associations, change allowed prefixes or replace MACsec keys are network-admin privileges. Limit them to a small role, require approval for production changes, and alert on use. See the Cloud IAM Review Checklist.
• Inspection point: decide where traffic from on premises is inspected. A common pattern lands the circuit in a hub or transit network with firewalls, so new spokes cannot receive on-premises routes without passing the hub.

Where identity fits

Two machine identities sit inside this design. On Azure, the user-assigned managed identity that ExpressRoute uses to read the MACsec secrets from Key Vault must have get on secrets and nothing more, and the vault cannot sit behind a private endpoint. On AWS, the CKN/CAK pair lives as a Secrets Manager secret that AWS creates; scheduling its deletion can disassociate the key and, if it was the last key in must_encrypt mode, AWS changes the mode to should_encrypt. Infrastructure-as-code pipelines that manage circuits hold credentials able to change routing for the whole company, so scope and monitor them like any other privileged NHI. See the AWS Secrets Manager guide.

Resilience and choosing a design

Use BFD for fast failure detection, keep the VPN backup path at a lower BGP preference (for example AWS local preference communities 7224:7300 on the primary and 7224:7100 on the backup), and test failover quarterly. A backup VPN that has never carried production traffic is not a backup.

Implementation steps

1. Inventory: list every circuit, port, VIF, peering, VLAN attachment, hosted connection and gateway association across all accounts and subscriptions, with owner and purpose.
2. Set the policy: decide which flows need MACsec, which need IPsec or TLS, and the accepted and advertised prefix lists per circuit.
3. Prepare keys: generate CAK/CKN pairs in the provider workflow or your key system, store them in the secrets store, and load them on routers through a controlled change. Never paste them into tickets.
4. Enable on one link first: on a redundant pair, enable MACsec on one port, confirm MKA and BGP, then the second (Microsoft documents enabling one port at a time for this reason). Start AWS links in should_encrypt, check MACsec status, then move to must_encrypt.
5. Apply route filters and max-prefix: stage prefix lists in a maintenance window, compare received and advertised routes before and after, and keep the previous configuration ready to restore.
6. Lock attachments: remove stale hosted connections and associations, restrict the IAM or RBAC roles that can create them, and add alerts.
7. Test failover and rotation: fail each circuit, rotate one key with the keychain or multi-key feature, and record the outcome.
8. Rollback: for MACsec, revert to should_encrypt or clear the key identifiers on one link while the other carries traffic; for routing, reapply the saved prefix lists.

Detection and measurement

• Control plane: log cloud API calls that create or delete virtual interfaces, accept gateway associations, change allowed prefixes, or associate or remove MACsec keys (CloudTrail, Azure Activity Log, Google Cloud Audit Logs), and alert outside change windows.
• BGP state: alert on session down, flaps, received prefix count crossing a warning threshold, and any unexpected prefix or default route.
• MACsec state: monitor MKA session state and encryption status on your routers and in the provider console; alert when a link runs unencrypted.
• Traffic: collect flow logs on both sides to confirm the circuit carries only expected source and destination ranges.

Metrics that show the programme works:

• Percentage of circuits carrying regulated data that are encrypted end to end or at the link (target 100 per cent).
• Percentage of MACsec links in strict mode.
• Number of circuits and attachments without a named owner (target zero).
• Days since last successful failover test per circuit.
• Age of MACsec and IPsec keys against the rotation policy.

Common failure patterns

• Assuming private means encrypted: sensitive replication runs in clear over a partner circuit because "it never touches the internet".
• Fail-open forever: AWS links left in should_encrypt after a key mismatch quietly carry clear traffic for months.
• No inbound filter: the router accepts everything the cloud advertises, so a new VPC with an overlapping range attracts on-premises traffic.
• Prefix overflow outage: a summarisation change pushes more than 100 routes into an AWS private VIF and the session goes idle.
• Orphaned attachments: associations from closed projects or acquired companies still reach the data centre.
• Keys in configs and tickets: CAKs and pre-shared keys found in router backups and change records, readable by far more people than the circuit's owners.

Framework mapping

Practitioner checklist

• Every circuit, VIF, peering and attachment is inventoried with an owner.
• Regulated flows are encrypted with IPsec or TLS end to end; MACsec protects dedicated cross-connects.
• MACsec links run in strict mode after burn-in, with XPN ciphers on high-speed ports.
• CAK, CKN and pre-shared keys live only in a secrets store and router configs, with a tested rotation.
• Inbound and outbound prefix lists and max-prefix are set on every session, below provider limits.
• BGP sessions use MD5 authentication and BFD.
• Cross-account associations, hosted connections and pairing keys go through change control and are reviewed quarterly.
• Cloud roles that change circuits are restricted and their use alerts.
• Failover to a backup path is tested at least quarterly.

Standards and references

• AWS: MAC Security in Direct Connect
• AWS: Encryption in transit in Direct Connect
• AWS: Direct Connect routing policies and BGP communities
• Microsoft Learn: Configure MACsec on ExpressRoute Direct ports
• Microsoft Learn: ExpressRoute routing requirements
• Microsoft Learn: Site-to-site VPN over ExpressRoute Microsoft peering
• Google Cloud: MACsec for Cloud Interconnect overview
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Cloud Network Security Guide · Hybrid Cloud Security · MACsec · BGP and Routing Security Guide · Security Requirements for Selecting a Colocation or Data Centre Provider