Media Access Control security (MACsec) provides Layer 2 point-to-point encryption for physical links connecting on-premises edge routers directly to Google Cloud edge routers over Dedicated Interconnect. By encrypting data at the Ethernet frame level, MACsec ensures data confidentiality, authentication, and integrity for all network traffic before it traverses the physical demarcations. Network traffic transiting between the customer router and Google's edge router remains protected against eavesdropping and physical interception without requiring encapsulation overhead at the IP layer.
MACsec capability on Dedicated Interconnect depends directly on the circuit capacity and the underlying hardware port provisioning at the colocation facility. All 100-Gbps Ethernet links are MACsec capable by default, as are all Cross-Site Interconnect connections. In contrast, 10-Gbps Ethernet links are not MACsec capable by default and require the selection of a MACsec-capable port during circuit ordering or project allow-listing. If an existing 10-Gbps connection does not reside on a MACsec-capable port, administrators must request a new connection or schedule a physical port migration with Google Cloud. The availableFeatures field in the interconnect description indicates MACsec capability, showing IF_MACSEC for 10-Gbps links that support the feature.
The security model of MACsec relies on pre-shared keys and the MACsec Key Agreement (MKA) protocol to establish authenticated, encrypted sessions between router endpoints. Administrators configure a pre-shared key consisting of a Connectivity Association Key Name (CKN) and a Connectivity Association Key (CAK), each assigned a specific start time with infinite validity. When multiple pre-shared keys are configured on a link, Google edge routers automatically select the key with the latest start time as the active key and reject connection sessions attempting to use older keys. Managing and retrieving these cryptographic keys requires the Compute Network Admin IAM role or a custom role with the compute.interconnects.getMacsecConfig permission. Keys can be rotated by creating new pre-shared keys with future start times, and all configured keys have infinite validity once active.
MACsec fail-mode policies define how a Cloud Interconnect circuit handles data transmission if an MKA session fails to negotiate between the customer router and Google's edge router. By default, Cloud Interconnect operates in a fail closed configuration, which causes the connection to drop all traffic immediately if encryption cannot be established. This ensures no unencrypted data leaves the network. Alternatively, a fail open configuration allows the connection to pass unencrypted traffic if the MKA session fails, which is recommended strictly for testing or troubleshooting. The fail-open setting is controlled by the macsec.failOpen parameter. Modifying the fail-open state requires temporarily disabling MACsec via the Google Cloud CLI, which causes packet loss unless VLAN attachments are drained beforehand, so organizations must schedule maintenance windows for this change.
Monitoring MACsec health requires distinguishing between administrative enablement, pre-shared key configuration, and real-time operational status on physical circuits. Administrative state and key associations appear through configuration inspection commands, but actual session health must be validated via connection diagnostic outputs. A healthy MACsec deployment displays an active Link Aggregation Control Protocol (LACP) state, a circuit bundle status of BUNDLE_OPERATIONAL_STATUS_UP, and a MACsec operational status of true associated with the active CKN. In addition to encryption session states, diagnostic checks report receiving and transmitting optical power levels in decibel-milliwatts to help isolate physical layer degradation from key mismatches or protocol failures.
Encryption strategies for hybrid and multi-cloud connectivity involve selecting the appropriate protection mechanism based on the network path, data sensitivity, performance needs, and operational capabilities. Google Cloud provides two primary encryption approaches for interconnecting on-premises networks with Google Cloud: MACsec for Layer 2 frame-level encryption over Cloud Interconnect, and Cloud VPN using IPsec for Layer 3 network-level encryption. Each approach addresses different segments of the connectivity stack and offers distinct tradeoffs in deployment complexity, cost, and performance characteristics that must be evaluated against specific business requirements.
MACsec is a Layer 2 encryption protocol that secures traffic at the Ethernet frame level between on-premises routers and Google's edge routers. MACsec operates below the IP layer, meaning it encrypts all traffic flowing across the physical link regardless of protocol, providing comprehensive protection for any data that traverses the interconnect. This makes MACsec particularly valuable for organizations with strict data sovereignty requirements or those that need to protect non-IP traffic that might not work with higher-layer encryption solutions.
MACsec for Cloud Interconnect is available on both 10-Gbps and 100-Gbps Dedicated Interconnect connections, though the availability model differs: all 100-Gbps connections include MACsec capability by default, while 10-Gbps connections require requesting MACsec-capable ports specifically at the time of ordering. Cross-Site Interconnect connections also include MACsec capability by default. The encryption uses pre-shared keys configured through the MACsec Key Agreement protocol, where the on-premises router and Google's edge router mutually authenticate using shared keys before establishing an encrypted session. Each MACsec configuration includes a connectivity association key name that identifies the active key.
MACsec supports two fail-over behaviors that significantly impact availability: the default fail-closed mode drops all traffic if the MKA session cannot be established, ensuring no unencrypted data leaves the network, while fail-open mode allows traffic to pass unencrypted if encryption fails. The fail-open setting should only be used for testing and troubleshooting, not for production traffic, because enabling it risks exposing sensitive data.
For Google Distributed Cloud connected deployments, MACsec provides Layer 2 encryption between internal rack components in multi-rack configurations, specifically securing the Ethernet links between aggregator switches in the base rack and top-of-rack switches in standalone racks. This internal MACsec deployment is distinct from Cloud Interconnect MACsec in that it protects traffic within the customer's premises infrastructure rather than traffic crossing the public internet or carrier networks.
The Distributed Cloud connected MACsec implementation enforces several non-negotiable policies: unencrypted packets are never allowed on internal Ethernet links, and if a MACsec session cannot be negotiated, the affected link automatically goes down rather than falling back to plaintext. All MACsec configuration, including encryption keys, is managed entirely by Google rather than the customer, simplifying operational burden but reducing customer control over key management processes. Key management follows a structured rotation schedule: each internal Ethernet link has a unique keychain holding four primary keys, each valid for 25% of the total key lifetime, plus a fallback key that never expires. When primary keys expire, the aggregator and ToR switches rotate to the next key immediately, with a 5-day overlap between the previous and next key to ensure continuous operation during transition. The actual session encryption uses a randomly generated MACsec Secure Association Key that is regenerated every 6 hours using volume-based rekeying with Extended Packet Numbering, providing frequent key refresh without session interruption.
Cloud VPN provides IPsec ESP Tunnel Mode encryption for traffic flowing between on-premises networks and Google Cloud VPC networks, operating at Layer 3 to protect IP packets regardless of the underlying physical infrastructure. Cloud VPN supports both Classic VPN and HA VPN topologies, with HA VPN providing higher availability through redundant tunnels across multiple interfaces and regions. Unlike MACsec, which requires dedicated physical interconnect infrastructure, Cloud VPN works over any IP connectivity, including existing site-to-site VPN tunnels, making it suitable for organizations that have not deployed Dedicated Interconnect.
Cloud VPN uses Internet Key Exchange protocols to negotiate encryption parameters with peer VPN devices, supporting IKEv1 and IKEv2 with a defined set of cipher algorithms. When establishing connections, Cloud VPN can act as either initiator or responder depending on which side originates the traffic requiring a new security association. The cipher proposal order matters because the initiator proposes ciphers while the responder selects from those proposals; if both sides initiate simultaneously, different ciphers might be selected, potentially causing instability. Best practice is to configure both the Cloud VPN tunnel and the peer VPN gateway to propose and accept only a single cipher for each role to ensure consistent selection. Cloud VPN also supports IKE fragmentation, which helps handle situations where IKE packets exceed the gateway MTU.
The choice between MACsec over Cloud Interconnect and Cloud VPN depends on several technical and business factors that must be evaluated together. MACsec provides Layer 2 encryption that protects all traffic on the physical link, making it ideal for organizations that need comprehensive protection without managing IP-level policies, but it requires Dedicated Interconnect infrastructure and MACsec-capable routers, adding deployment complexity and cost. Cloud VPN offers greater flexibility since it works over any IP connectivity and can be deployed quickly without physical infrastructure changes, though it only protects IP traffic and requires proper IKE cipher configuration on both ends.
Performance considerations also differ: MACsec operates at line rate on the physical interface with minimal overhead since it encrypts at the Ethernet layer, while IPsec encryption in Cloud VPN adds processing overhead that can impact throughput depending on the chosen ciphers and the capabilities of the peer VPN device. For latency-sensitive applications, MACsec over Cloud Interconnect typically provides lower latency than Cloud VPN because the traffic does not need to traverse additional encapsulation and decryption steps, and the dedicated physical path avoids internet congestion variability.
From a reliability perspective, Cloud Interconnect with MACsec supports the same redundancy options as standard Cloud Interconnect, including connection groups that define critical production (99.99% SLA), non-critical production (99.9% SLA), or no SLA configurations. Achieving 99.99% availability requires at least four Dedicated Interconnect connections across two different metropolitan areas with connections in different edge availability domains. Cloud VPN's availability depends on the HA VPN topology design, which provides redundant tunnels but relies on underlying IP connectivity that may have different availability characteristics than dedicated interconnect.
For disaster recovery and multi-cloud scenarios, organizations often combine both approaches: MACsec over Cloud Interconnect provides high-bandwidth, low-latency encryption for primary workloads, while Cloud VPN can serve as a backup path or support connectivity to other cloud providers where dedicated interconnect is not available. The composite availability calculation must account for dependencies between these components—if the primary MACsec path fails and the backup Cloud VPN path also fails, the combined availability is the product of both paths' availability rather than the sum.
High Availability VPN (HA VPN) is a Google Cloud service that provides encrypted IPsec tunnels over the public internet or carrier connections, serving as a secure alternative for scenarios where Dedicated or Partner Interconnect is not feasible. HA VPN establishes two redundant VPN tunnels between a Google Cloud HA VPN gateway and an on-premises or another cloud's peer VPN gateway, creating a highly available, encrypted connection without requiring physical co-location. This makes it suitable for hybrid and multi-cloud network connectivity where direct, private fiber links are unavailable or cost-prohibitive.
HA VPN functions as an encrypted overlay for connectivity by creating IPsec tunnels that carry traffic between networks. The service uses Internet Key Exchange v2 and IPsec to negotiate and establish secure tunnels, providing encryption, integrity, and authentication for data in transit. Unlike MACsec, which encrypts traffic at Layer 2 on a physical Dedicated Interconnect link, HA VPN's IPsec encryption operates at Layer 3 over any IP transport, including the public internet. This fundamental difference means HA VPN does not require a physical port in a Google colocation facility, making it a viable option for locations where Partner Interconnect is unavailable or for direct cross-cloud connections where no physical interconnect exists.
The choice between HA VPN and MACsec involves evaluating performance, cost, and operational requirements. MACsec provides hardware-accelerated, low-latency Layer 2 encryption on Dedicated Interconnect, but it depends on physical fiber availability and specific port capabilities. In contrast, HA VPN offers flexible, software-based encryption over any IP path, trading some potential latency for greater geographic reach and simpler provisioning. For Partner Interconnect, a service provider delivers the physical connection, but encryption is not inherently provided; HA VPN can be layered on top for security or used instead when a service provider link is not an option. Therefore, evaluate HA VPN when the primary requirements are encryption and reachability, while Dedicated Interconnect with MACsec is preferable when the highest performance and lowest latency on a private link are critical.
Configuring HA VPN involves creating an HA VPN gateway in a Google Cloud region and defining tunnels with specific IKE and IPsec cipher suites, such as AES-GCM for encryption. Each tunnel's configuration must match the peer gateway's settings, including pre-shared keys and IKE fragmentation settings to handle large packets. The operational model is software-driven and API-managed, differing from the physical provisioning and MACsec key management required for Dedicated Interconnect. Choose HA VPN for encrypted connectivity when facing constraints like distant locations, cross-cloud workloads, temporary environments, or budget limits that make dedicated fiber impractical. The tradeoff accepts the variability of internet or carrier network performance for the benefits of encryption, redundancy, and rapid deployment without physical dependencies.
MACsec encrypts traffic at Layer 2 (the Ethernet frame level) on physical Dedicated Interconnect links, providing comprehensive protection for all traffic regardless of protocol. Cloud VPN uses IPsec at Layer 3 to protect only IP packets, but it works over any IP connectivity including the public internet rather than requiring dedicated physical infrastructure.
Choose HA VPN when you need encrypted connectivity but cannot deploy Dedicated Interconnect due to geographic constraints, cost limitations, or cross-cloud requirements. Choose MACsec over Dedicated Interconnect when you need the highest performance and lowest latency on a private link with hardware-accelerated encryption.
By default, MACsec operates in fail-closed mode, which drops all traffic immediately if the encryption session cannot be established. This ensures no unencrypted data leaves your network. You can optionally enable fail-open mode to allow unencrypted traffic to pass, but this should only be used for testing and troubleshooting, not production traffic.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts