Stay organized with collections
Save and categorize content based on your preferences.
Encryption in all Google Cloud regions
All VM-to-VM traffic within a VPC network and peered
VPC networks is encrypted.
Encryption between proxy load balancers and backends
For some proxy load balancers (see table 1), Google automatically encrypts
traffic to the backends that reside within Google Cloud VPC
networks. This is called automatic network-level encryption.
Automatic network-level encryption is only applicable to communications with
these types of backends:
Some Google Cloud load balancers use Google Front Ends
(GFEs) as the
client to the backends whereas others use the open source Envoy
proxy.
In all cases, the load balancer supports the cipher suites listed in
RFC 8446, section 9.1
for TLS 1.3. For TLS 1.2 and earlier, the load balancer supports the cipher suites
associated with the COMPATIBLE
SSL policy profile.
The following table provides a summary of the proxy load balancers that encrypt traffic to the backends.
Table 1. Communications between load balancers and backends
Proxy load balancer
Proxy (client to the backend)
Automatic network-level encryption
Backend service protocol options
Global external Application Load Balancer
GFE (with Envoy software for advanced routing features)
HTTP, HTTPS, and HTTP/2
Choose HTTPS or HTTP/2 if you require auditable encryption in transit to
the backends.
Classic Application Load Balancer
GFE
HTTP, HTTPS, and HTTP/2
Choose HTTPS or HTTP/2 if you require auditable encryption in transit to
the backends.
Regional external Application Load Balancer
Envoy proxy
HTTP, HTTPS, and HTTP/2
Choose HTTPS or HTTP/2 if you require auditable encryption in transit to
the backends.
Regional internal Application Load Balancer
Envoy proxy
HTTP, HTTPS, and HTTP/2
Choose HTTPS or HTTP/2 if you require auditable encryption in transit to
the backends.
Cross-region internal Application Load Balancer
Envoy proxy
HTTP, HTTPS, and HTTP/2
Choose HTTPS or HTTP/2 if you require auditable encryption in transit to
the backends.
Global external proxy Network Load Balancer
GFE (with Envoy software for advanced routing features)
SSL or TCP
Choose SSL for the backend service protocol if you require auditable
encryption in transit to the backends.
Classic proxy Network Load Balancer
GFE
SSL or TCP
Choose SSL for the backend service protocol if you require auditable
encryption in transit to the backends.
Regional external proxy Network Load Balancer
Envoy proxy
TCP
Regional internal proxy Network Load Balancer
Envoy proxy
TCP
Cross-region internal proxy Network Load Balancer
Envoy proxy
TCP
Cloud Service Mesh
Client-side proxy
HTTPS and HTTP/2
Secure backend protocol use cases
A secure protocol to connect to backend instances is recommended in the
following cases:
When you require an auditable, encrypted connection from the load balancer (or
Cloud Service Mesh) to the backend instances.
When the load balancer connects to a backend instance that is outside of
Google Cloud (with an internet
NEG). Communication
to an internet NEG backend might transit the public internet. When the load
balancer connects to an internet NEG, the public CA-signed certificate must
meet the validation
requirements.
Secure backend protocol considerations
When using a secure backend service protocol, keep the following in mind:
Your load balancer's backend instances or endpoints must serve using the same
protocol as the backend service. For example, if the backend service protocol
is HTTPS, the backends must be HTTPS servers.
If the backend service protocol is HTTP/2, your backends must use TLS. For
configuration instructions, see the documentation for the software running
on your backend instances or endpoints.
You must install private keys and certificates on your backend instances or
endpoints in order for them to function as HTTPS or SSL servers. These
certificates don't need to match the load balancer's frontend SSL
certificates. For installation instructions, see the documentation for the
software running on your backend instances or endpoints.
With the exception of HTTPS load balancers with internet NEG
backends, load balancers
don't use the Server Name Indication (SNI) extension for connections to the
backend.
When a load balancer connects to backends that are within Google Cloud,
the load balancer accepts any certificate your backends present. In this case,
the load balancer performs only minimum certificate validation.
For example, certificates are treated as valid even in the following
circumstances:
The certificate is self-signed.
The certificate is signed by an unknown certificate authority (CA).
The certificate has expired or is not yet valid.
The CN and subjectAlternativeName attributes don't match a
Host header or DNS PTR record.
For RSA certificates, starting April 28, 2025, the load balancer will only
accept RSA certificates that have the X509v3 Key Usage extension present and
include both the Digital Signature and Key Encipherment parameters. For more
information, see the associated release note on January 24,
2025.
Secure frontend protocols
When you use a target HTTPS or target SSL proxy as part of your configuration,
Google Cloud uses a secure frontend protocol.
Internal Application Load Balancers use Google's BoringSSL library. For FIPS 140-2
details, see the Envoy documentation.
Google builds Envoy proxies for internal Application Load Balancers in FIPS compliant
mode.
Cloud Service Mesh supports Envoy proxies that are built in FIPS-compliant
mode.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-25 UTC."],[],[],null,["# Encryption from the load balancer to the backends\n\nEncryption in all Google Cloud regions\n--------------------------------------\n\nAll VM-to-VM traffic within a VPC network and peered\nVPC networks is encrypted.\n\nEncryption between proxy load balancers and backends\n----------------------------------------------------\n\nFor some proxy load balancers (see table 1), Google automatically encrypts\ntraffic to the backends that reside within Google Cloud VPC\nnetworks. This is called *automatic network-level encryption*.\nAutomatic network-level encryption is only applicable to communications with\nthese types of backends:\n\n- Instance groups\n- Zonal NEGs (`GCE_VM_IP_PORT` endpoints)\n\nIn addition, Google Cloud provides [secure protocol options to\nencrypt communication with the backend\nservice](/load-balancing/docs/backend-service#protocol_to_the_backends).\n\nSome Google Cloud load balancers use [Google Front Ends\n(GFEs)](/security/infrastructure/design#google_front_end_service) as the\nclient to the backends whereas others use the open source [Envoy\nproxy](https://www.envoyproxy.io/).\nIn all cases, the load balancer supports the cipher suites listed in\n[RFC 8446, section 9.1](https://datatracker.ietf.org/doc/html/rfc8446#section-9.1)\nfor TLS 1.3. For TLS 1.2 and earlier, the load balancer supports the cipher suites\nassociated with the COMPATIBLE\n[SSL policy profile](/load-balancing/docs/ssl-policies-concepts#defining_an_ssl_policy).\n\nThe following table provides a summary of the proxy load balancers that encrypt traffic to the backends.\n\n### Secure backend protocol use cases\n\nA secure protocol to connect to backend instances is recommended in the\nfollowing cases:\n\n- When you require an auditable, encrypted connection from the load balancer (or\n Cloud Service Mesh) to the backend instances.\n\n- When the load balancer connects to a backend instance that is outside of\n Google Cloud (with an [internet\n NEG](/load-balancing/docs/negs/internet-neg-concepts)). Communication\n to an internet NEG backend might transit the public internet. When the load\n balancer connects to an internet NEG, the public CA-signed certificate must\n [meet the validation\n requirements](/load-balancing/docs/negs/internet-neg-concepts#ssl_server_certification_validation_and_san_validation).\n\n### Secure backend protocol considerations\n\nWhen using a secure backend service protocol, keep the following in mind:\n\n- Your load balancer's backend instances or endpoints must serve using the same\n protocol as the backend service. For example, if the backend service protocol\n is HTTPS, the backends must be HTTPS servers.\n\n- If the backend service protocol is HTTP/2, your backends must use TLS. For\n configuration instructions, see the documentation for the software running\n on your backend instances or endpoints.\n\n- You must install private keys and certificates on your backend instances or\n endpoints in order for them to function as HTTPS or SSL servers. These\n certificates don't need to match the load balancer's frontend SSL\n certificates. For installation instructions, see the documentation for the\n software running on your backend instances or endpoints.\n\n- With the exception of HTTPS load balancers with [internet NEG\n backends](/load-balancing/docs/negs/internet-neg-concepts), load balancers\n don't use the Server Name Indication (SNI) extension for connections to the\n backend.\n\n- When a load balancer connects to backends that are within Google Cloud,\n the load balancer accepts any certificate your backends present. In this case,\n the load balancer performs only minimum certificate validation.\n\n For example, certificates are treated as valid even in the following\n circumstances:\n - The certificate is self-signed.\n - The certificate is signed by an unknown certificate authority (CA).\n - The certificate has expired or is not yet valid.\n - The `CN` and `subjectAlternativeName` attributes don't match a `Host` header or DNS PTR record.\n\n For RSA certificates, starting April 28, 2025, the load balancer will only\n accept RSA certificates that have the X509v3 Key Usage extension present and\n include both the Digital Signature and Key Encipherment parameters. For more\n information, see the associated [release note on January 24,\n 2025](/load-balancing/docs/release-notes#January_24_2025).\n\nSecure frontend protocols\n-------------------------\n\nWhen you use a target HTTPS or target SSL proxy as part of your configuration,\nGoogle Cloud uses a secure frontend protocol.\n\nExternal Application Load Balancers and external proxy Network Load Balancers use Google's\nBoringCrypto library. For FIPS 140-2 details, see [NIST Cryptographic Module\nValidation Program Certificate #3678](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/3678).\n\nInternal Application Load Balancers use Google's BoringSSL library. For FIPS 140-2\ndetails, see the [Envoy documentation](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ssl).\nGoogle builds Envoy proxies for internal Application Load Balancers in FIPS compliant\nmode.\nCloud Service Mesh supports Envoy proxies that are built in FIPS-compliant mode."]]
