This content was last updated in April 2025, and represents the status quo asof the time it was written. Google's security policies and systems may changegoing forward, as we continually improve protection for our customers.

At Google, our security controls help protect your data—whether it istraveling over the internet, moving within Google's infrastructure, or stored onour servers. Central to Google's security strategy are authentication,integrity, and encryption, for both data at rest and data in transit. This paperdescribes how we designedGoogle Cloud to encrypt data in transit from the internet and data intransit within Google's networks. This document doesn't apply to data in transitover interconnects between customer data center networks and Google's datacenter networks.

Encryption in transit uses various technologies to help protect data, includingtransport layer security (TLS), BoringSSL, application layer transport security(ALTS), and thePSP securityprotocol.In addition to the default protection that Google provides, you can furtherprotect data by adding encryption options such as IPsec, managed TLScertificates, and Cloud Service Mesh.

This document is aimed at CISOs and security operations teams using orconsidering Google Cloud. This document assumes a basic understanding ofencryption andcryptographicprimitives.

Authentication, integrity, and encryption

Google employs the following security measures to help ensure the authenticity,integrity, and privacy of data in transit:

• Authentication verifies the identity of a peer (either a human or aprocess) in a connection.
• Integrity prevents data that you send from being altered while in transitbetween the source and the destination.
• Encryption uses cryptography to make your data unreadable while in transitand keep it confidential.

Encryption in transit helps protect your data if communications are interceptedwhile data moves between the end user and Google Cloud or between twoservices. Encryption in transit authenticates the endpoints and encrypts thedata before transmission. On arrival, the receiver decrypts the data andverifies that it was not modified during transit.

Encryption is one component of a broader security strategy. Encryption intransit defends your data against potential attackers and removes the need forGoogle, Google Cloud customers, or end users to trust the lower layers ofthe network.

How traffic gets routed

This section describes how requests get from an end user to the appropriateGoogle Cloud service or customer application, and how traffic is routedbetween services.

AGoogle Cloud service is a modular cloud service that we offer to ourcustomers. These services include compute, data storage, data analytics, andmachine learning. For example, Cloud Storage is a Google Cloud service.

Acustomer application is an application hosted on Google Cloud thatyou, as a Google customer, can build and deploy using Google Cloudservices. Customer applications or partner solutions that are hosted onGoogle Cloud are not considered Google Cloud services. For example,an application you build using Cloud Run, Google Kubernetes Engine, or a VMin Compute Engine is a customer application.

The following diagram shows traffic paths from the end user to Google, pathswithin Google's network, and the security for each connection. The following traffic paths are shown:

• End user on the internet to a Google Cloud service (labeled A in thediagram)
• End user on the internet to a customer application that is hosted onGoogle Cloud (labeled B in the diagram)
• Virtual machine to virtual machine (labeled C in the diagram)
• Virtual machine to Google Front End (GFE) (labeled D in the diagram)
• GFE to Google APIs and services (labeled E in the diagram)
• Google Cloud service to Google Cloud service (labeled F in thediagram)

Encryption in transit between the end user and Google

The following sections provide more detail about the end-user routing requeststhat are shown in the preceding diagram.

End user to a Google Cloud service

Google Cloud services such as Cloud Storage orCompute Engine are cloud services that we offer to customers and run inourproductionenvironment.Google Cloud services accept requests from around the world using aglobally distributed system calledGoogle Front End(GFE).GFE terminates traffic for incoming HTTP(S), TCP, and TLS connections; providesDDoS attack countermeasures; and routes and load balances traffic to theGoogle Cloud services themselves. GFE points of presence exist around theglobe with paths that are advertised using unicast orAnycast.

GFE routes traffic from an end user over Google's network to aGoogle Cloud service, and from an end user to a customer application thatis hosted on Google Cloud and usesCloud Load Balancing.

Requests that clients send to a Google Cloud service over HTTPS, HTTP/2,or HTTP/3 are secured with TLS. TLS in the GFE is implemented withBoringSSL, a Google-maintained,open-source implementation of the TLS protocol. BoringCrypto, the core ofBoringSSL, is validated toFIPS 140-3 level1.

The GFE negotiates industry-standard cryptographic parameters with the client,including forward-secure key negotiation. For older, less capable clients, theGFE chooses the strongest legacy cryptographic primitives that the clientoffers.

End user to a customer application hosted on Google Cloud

You can route end user traffic from the internet to your customer applicationsthat are hosted on Google Cloud using a direct connection or through aload balancer. When the traffic is routed directly, the traffic is routed to theexternal IP address of the VM server that hosts the application.

You can use TLS with the external Application Load Balancer or theexternal proxy Network Load Balancer to connect toyour application running on Google Cloud. When you use a Layer 7 loadbalancer, the connection between the end user and the load balancer is encryptedusing TLS by default (provided that the end user's client application supportsTLS). GFE terminates the TLS connections from your end users using TLScertificates that are self-managed or Google-managed. For more information aboutcustomizing your certificate, seeSSL certificatesoverview.To enable encryption between the load balancer and the VM that hosts thecustomer application, seeEncryption from the load balancer to thebackends.

To configure mutual TLS (mTLS), seeMutual TLSoverview. For workloads onGKE and Compute Engine, considerCloud Service Meshso that you can use mTLS for mutual authentication (client and server) andencrypt communications in transit using certificates that you manage.

ForFirebaseHosting andCloud Run customdomains, consider ourfree and automated TLS certificates. With Cloud Run custom domains, youcan alsoprovide your own SSLcertificatesand use an HTTP strict transport security (HSTS) header.

Encryption in transit within Google networks

Google Cloud encrypts customer data in transit within Google'snetworks, unless described otherwise in this section.

Specialized ultra-high performance interconnects that connect TPUs or GPUswithin Google's AI supercomputers are separate from the networks described inthis document. In Google Cloud, these ultra-high performance interconnectsare ICI for TPUs and NVLink for GPUs. For more information, seeTPUarchitecture andGPU machine types.

Traffic over connections to VMs using external IP addresses leaves Google'snetworks. You are responsible for configuring your own encryption for thoseconnections.

Google Cloud virtual network authentication and encryption

Google Cloud's virtual network encrypts, integrity-protects, andauthenticates traffic between VMs.

Encryption of private IP traffic within the same VPC or across peered VPCnetworks within Google Cloud's virtual network is performed at the networklayer.

Each pair of communicating hosts establishes a session key using a controlchannel that is protected byALTSfor authenticated, integrity-protected, and encrypted communications. Thesession key is used to encrypt VM-to-VM communication between those hosts,and session keys are rotated periodically.

VM-to-VM connections within VPC networks and peered VPC networks inside ofGoogle's production network are integrity-protected and encrypted. Theseconnections include connections between customer VMs and between customer andGoogle-managed VMs such as Cloud SQL. The diagram inHow traffic getsrouted shows this interaction (labeled connection C). Note thatbecause Google activates automatic encryption based on the use of internal IPaddresses, connections between VMs using external IP addresses aren'tautomatically encrypted.

Google Cloud's virtual network authenticates alltraffic between VMs. This authentication, achieved using security tokens,prevents a compromised host from spoofing packets on the network.

Security tokens are encapsulated in a tunnel header which containsauthentication information about the sender and receiver. The control plane onthe sending host sets the token, and the receiving host validates the token.Security tokens are pre-generated for every flow, and consist of a token(containing the sender's information) and the host secret.

Connectivity to Google APIs and services

Traffic handling differs depending on where the Google Cloud service ishosted.

Most Google APIs and services are hosted on GFEs. VM to GFEtraffic uses external IP addresses to reach Google Cloud services, but youcan configureprivateaccess to avoid usingexternal IP addresses. The connection from the GFE to the service isauthenticated and encrypted.

Some services, such asCloud SQL, arehosted on Google-managed VM instances. If customer VMs access the serviceshosted on Google-managed VM instances using external IP addresses, trafficremains in Google's production network but isn't automatically encrypted becauseof the use of the external IP addresses. For more information, seeGoogle Cloud virtual network authentication andencryption.

When a user sends a request to a Google Cloud service, we secure the datain transit (providing authentication, integrity, and encryption) using HTTPSwith a certificate from a web (public) certificate authority. Any data the usersends to the GFE is encrypted in transit with TLS or QUIC. GFE negotiates aparticular encryption protocol with the client depending on what the client cansupport. GFE negotiates more modern encryption protocols when possible.

Service-to-service authentication, integrity, and encryption

Google's infrastructure uses ALTS for the authentication, integrity, andencryption of connections from the GFE to a Google Cloud service, and fromone Google Cloud service to another Google Cloud service.

ALTS usesservice-basedidentitiesfor authentication. Services running in Google's production environment areissued credentials asserting their service-based identities. When making orreceiving RPCs from other services, a service uses its credentials toauthenticate. ALTS verifies that these credentials are issued by Google'sinternal CA. Google's internal CA is unrelated and independent of theCertificate Authority Service.

ALTS uses encryption and cryptographic integrity protection for traffic thatcarries Google Cloud data from the GFE to a service and between servicesthat are running in Google's production environment.

ALTS is also used to encapsulate other Layer 7 protocols, such as HTTP, in RPCmechanisms for traffic between GFEs and Google Cloud services. This protectionhelps isolate the application layer and removes any dependency on the networkpath's security.

Encryption in transit methods

The following sections describe some of the technologies that Google uses toencrypt data in transit.

Network encryption using PSP

PSP is a transport-independent protocol that enables per-connection security andsupports offloading of encryption to smart network-interface card (SmartNIC)hardware. Whenever SmartNICs are available, ALTS uses PSP to encrypt data intransit across our network.

PSP is designed to meet the requirements of large-scale data-center traffic.Google infrastructure uses PSP to encrypt traffic within and between our datacenters. PSP also supports non-TCP protocols such as UDP and uses a uniqueencryption key for each connection.

Application layer transport security

ALTS is a mutual authentication and encryption system developed by Google. ALTSprovides authentication, confidentiality, and integrity for data-in-transitbetween services running in Google's production environment. ALTS consists ofthe following protocols:

• Handshake protocol: The client initiates a combined elliptic curve andquantum-safe key exchange. At the end of the handshake, involved servicesauthenticate each other's identities by exchanging and verifying signedcertificates and compute a shared traffic key. Among the algorithms that aresupported for deriving the shared traffic key is the NIST post-quantumalgorithmML-KEM (FIPS 203). Formore information, seePost-quantumcryptography.

• Record protocol: Service-to-service data is encrypted in transit usingthe shared traffic key. By default, ALTS uses AES-128-GCM encryption for alltraffic. Data in transit within Google's lowest-level storage system usesAES-256 encryption, and ALTS provides AES message authentication. Encryptionin ALTS is provided by BoringSSL or PSP. This encryption is validated atFIPS 140-2 level 1 or FIPS 140-3 level 1.

The root signing keys for ALTS certificates are stored in Google's internalCA.

What's next

• For more information about our data center security, seedata centersecurity.
• For information on security configuration options for interconnects betweenGoogle Cloud and customer data center networks, seeChoosing a Network Connectivity product(IPSec) andMACsec forCloud Interconnectoverview.
• For information on Google Cloud compliance and compliancecertifications, see thecompliance resourcecenter, which includes ourSOC3 audit report.
• For best practices on how to secure your data in transit, see theEnterprisefoundationsblueprint,Google Cloud Architecture Framework: Security, privacy, andcompliance, andDecide how to meet regulatory requirements for encryption intransit.