- Clients using the endpoint must support Server Name Identification (SNI), and send the appropriate
Host
request header. SNI was first implemented in 2004 and has been nearly universally supported by clients since 2014 so only obscure or legacy clients will have issues connecting. - Wildcard DNS records are not supported. Shared endpoints require a fully qualified domain name. A wildcard certificate can be used in conjunction with providing a domain (see Configuration for details).
- Some attributes of how Endpoints handle requests are set at the load balancer level, and changing these attributes will migrate your Endpoint to a different load balancer. This comes with some implications for open connections to your endpoint, which are detailed below in the Configuration section.
Creating Shared Endpoints
Shared endpoints can be created:- By checking the “Shared” box when creating an HTTP(S) endpoint using the Aptible Dashboard.
- By using the
--shared
flag when creating an HTTP(S) endpoint using theaptible endpoints:https:create
CLI command.
- By checking the “Shared” box when updating a HTTP(S) endpoint using the Aptible Dashboard.
- By using the
--shared
flag when updating an HTTP(S) endpoint using theaptible endpoints:https:modify
CLI command.
Converting to a Dedicated Endpoint
Shared endpoints cannot be converted back to dedicated. To go back to using a dedicated endpoint, create a new dedicated endpoint with the same configuration then delate the shared endpoint when it’s no longer needed.Configuration
Shared endpoints support the same configuration options as dedicated HTTP(S) endpoints. The only exceptions of note are:- Shared endpoints using a Custom Certificate must specify a fully qualified domain when creating or migrating to a shared endpoint. This is the
--managed-tls-domain
option for CLI commands. - Shared endpoints do not support managed wildcard domains, a fully qualified domain name must be used with Managed TLS.
- Wait for DNS changes to propegate
- Wait for the HTTP client keep-alive timeout to elapse
- Wait for the TCP idle timeout to elapse
- Wait up to 15 seconds for in-flight response to to finish sending
IDLE_TIMEOUT
is set to 10 minutes or less, the process will complete without any disruption to a properly functioning client connection. For customers with an IDLE_TIMEOUT
configured above 10 minutes, we recommend using a dedicated endpoint to avoid interruptions, or reaching out to Aptible Support for guidance.
Converting an endpoint from dedicated to shared has the same behavior descibed above.