Amazon CloudFront is a content delivery network (CDN) that securely delivers static and dynamic web content with low latency and high transfer speeds using a global network of edge locations. When you request content that is served via CloudFront, you are routed to the nearest edge location in order to minimize network latency and maximize performance benefits.

CloudFront supports HTTPS and custom domain names, and integrates with AWS Certificate Manager (ACM) to help you to easily serve content over HTTPS using your own domain and SSL/TLS certificate. In addition to accelerated static content delivery, CloudFront offers a number of advanced features that help you to build powerful, feature-rich applications. For example, CloudFront offers content customization with Lambda@Edge, live or on-demand video streaming, private content support, and more. (For more information about how CloudFront can be useful in your web application, check out Amazon CloudFront Use Cases and Amazon CloudFront Key Features.)

CloudFront uses one of two methods to serve content via HTTPS when using custom domain names:

• Server Name Indication (SNI) (Default option, recommended for most users): Clients indicate which hostname they are attempting to reach in the “Client Hello” message at the beginning of the SSL/TLS handshake process.  CloudFront uses the hostname to return the corresponding certificate.
• Dedicated IP Addresses: CloudFront maps SSL/TLS certificates to dedicated IP addresses. When a request is sent to a dedicated IP address, CloudFront returns the certificate mapped to that IP address.

These methods refer to the process that CloudFront uses to establish an SSL/TLS connection with a client. In CloudFront, using dedicated IP addresses is also referred to as “Legacy Clients Support.” (Refer to Custom Client SSL Support for more details on CloudFront settings and configurations.)

In this post, we explore the differences between SNI-based SSL and dedicated IP SSL, how these protocols are used in CloudFront, and the use cases for each protocol.

Overview: SNI-Based SSL vs. Dedicated IP SSL

When you exchange messages with a server over HTTPS, you first establish an SSL/TLS connection with the server, then use this SSL/TLS connection to exchange encrypted HTTP messages.  To establish the SSL/TLS connection necessary for the secure exchange of data over HTTPS, your HTTP client must request and receive an SSL/TLS certificate from the server.  After your HTTP client has validated the legitimacy of the certificate, and that the certificate corresponds to the hostname you were trying to reach, it uses the public key in the certificate to negotiate encryption conditions with the server and form an encrypted communication channel. But, if the server has multiple SSL/TLS certificates corresponding to multiple hostnames, how does the server know which certificate to return in response to your request?

Consider a server that has two certificates corresponding to the hostnames example-1.com and example-2.com.  The server must know which hostname a request is addressed to in order to return the appropriate certificate and establish an SSL/TLS connection. This is a paradox because the hostname is specified in the HTTP Host header, and the server cannot read HTTP headers until after a secure SSL/TLS connection is formed.  Before SNI, the requesting client was unable to specify the hostname it was trying to connect to until after it received the certificate from the server and established an SSL/TLS connection.  If a server does not initially know which hostname you are trying to reach, then it is restricted to being able to present a single, default certificate on a given IP address and port number.

Without SNI, an IP address and port combination is only capable of presenting a single certificate and hostname. Assuming all HTTP clients want to use the standard HTTPS port (443), you can dedicate a unique IP address to each hostname on a server—but this increases the cost of serving content.

Serving content from multiple domains without SNI

To address this problem, SNI was created as an extension of the SSL/TLS protocols and was designed to allow HTTP clients to specify the hostname they are attempting to reach at the beginning of the SSL/TLS handshake process.  Because you specify a hostname (example-1.com) at the beginning of the handshake process before the SSL/TLS connection is established, the server can use this information in order to determine which certificate to return.

Serving content from multiple domains with SNI

SNI allows the server (CloudFront) to present multiple certificates using the same IP address and port number.  SNI-based SSL refers to SSL/TLS connections that are established when SNI is used to specify the hostname and retrieve the appropriate certificate as part of the SSL/TLS handshake.  Dedicated IP SSL refers to SSL/TLS connections that are established when the server returns its default certificate without considering SNI.

SNI-Based SSL connections

The following diagram illustrates how SNI is used to establish an SSL/TLS connection with a CloudFront edge location that is serving content from multiple customers.

Using SNI to establish an SSL/TLS connection with CloudFront

In this example, you are attempting to reach content stored under the custom domain name example-1.com.  The owner of example-1.com has configured this content to be served over HTTPS with CloudFront using SNI, and has uploaded their custom certificate to ACM and referenced the certificate in CloudFront.

When you issue the request to example-1.com, the DNS query is resolved to the public IP address of the nearest CloudFront edge location.  For more information on this process, check out how Amazon CloudFront delivers content.  In this example, the edge location contains certificates from three separate customers, each configured to use a custom domain name.

To establish the SSL/TLS connection, your HTTP client (commonly a web browser) inserts the example-1.com hostname into the “Client Hello” message of the TLS handshake.  The CloudFront edge location receives this message and uses the hostname in the “Client Hello” message to retrieve the certificate corresponding with the requested hostname, return it your HTTP client, and establish an SSL/TLS connection in order to serve content over HTTPS.

Dedicated IP SSL connections

The following diagram illustrates how you can use dedicated IP SSL to establish an SSL/TLS connection with a CloudFront edge location that is serving content from multiple customers.

Using dedicated IP addresses to establish an SSL/TLS connection with CloudFront

In this example, you are again attempting to reach content stored under the custom domain name example-1.com.  The owner of example-1.com has configured this content to be served over HTTPS with CloudFront and dedicated IP addresses, and has uploaded their custom certificate to ACM and referenced the certificate in CloudFront.

Because the owner of example-1.com has chosen to serve content over HTTPS using dedicated IP addresses rather than SNI, CloudFront associates example-1.com with a dedicated IP address at each edge location.  In this example, example-1.com is associated with the IP address x.x.x.1 at the pictured edge location.  This edge location contains content from three separate customers, each configured to use a dedicated IP address to serve content via HTTPS.

Each edge location uses a different dedicated IP address to serve the example-1.com content.  When you issue a request for example-1.com, the DNS query resolves to the IP address x.x.x.1 (or another IP address belonging to example-1.com).

You connect to CloudFront at x.x.x.1, and may or may not include the desired hostname (example-1.com) in the “Client Hello” message.  Since the owner of example-1.com has configured dedicated IP SSL for this content, CloudFront will consider an SNI from your HTTP client if it’s available, otherwise it will use your dedicated IP to route to your distribution. CloudFront recognizes the request is addressed to x.x.x.1 and uses this IP address to identify the correct SSL/TLS certificate.  CloudFront then returns the SSL/TLS certificate to your HTTP client and establishes an SSL/TLS connection.

Use cases: SNI-Based SSL vs. Dedicated IP SSL

When using CloudFront to serve content via HTTPS, SNI-based SSL is the recommended approach in order to minimize costs.  Using dedicated IP addresses incurs additional costs, see Amazon CloudFront Pricing for more details.

Most modern web browsers support SNI by default. However, if you have users who use web browsers that do not support SNI and cannot upgrade, using dedicated IP addresses allows you to serve HTTPS content with CloudFront.  Analyzing Amazon CloudFront Access Logs for SNI-incompatible user agents can determine if dedicated IP SSL is required for your application.  If your web application has minimum browser requirements, this can also determine whether support for dedicated IP SSL is required.

Globally, 98% of web browsers support SNI, and 97% of web browsers within the US support SNI.[1] Additionally, over 98% of certificates used with CloudFront rely on SNI, with less than 2% of certificates relying on dedicated IP addresses.  Use cases for continued support of SNI-incompatible browsers are expected to decline as multiple popular web browsers have announced plans to deprecate earlier TLS versions (TLS 1.0/1.1).[2] Web browsers relying on TLS 1.2+ are likely SNI-compatible.

Conclusion

In this post, we reviewed the ways in which CloudFront can establish SSL/TLS connections with users in order to serve content using HTTPS and custom domain names.

In general, SNI-based SSL is preferred over dedicated IP SSL to minimize costs. However, if you have a significant number of users operating with browsers or web clients that do not support SNI, CloudFront can serve HTTPS content using dedicated IP addresses.

For more information about how SNI specifies the hostname in the handshake process, check out its definition in TLS Extensions Definitions.

April 18, 2024: This post was corrected to change the sentence “CloudFront does not consider SNI from your HTTP client, even if you provide this information” to “CloudFront will consider an SNI from your HTTP client if it’s available, otherwise it will use your dedicated IP to route to your distribution.”