HTTP(S) Endpoints are available in two flavors:
ALB Endpoints are next-generation endpoints on Aptible. All customers are encouraged to upgrade legacy ELB Endpoints to ALB Endpoints.
You can check whether an Endpoint is an ALB or ELB Endpoint in the Aptible dashboard by selecting your app, then choosing the "Endpoints" tab to view all endpoints associated with that app. ALB vs. ELB is listed under the "Platform" section.
ALB Endpoints are more robust than ELB Endpoints and provide additional features, including:
- Connection Draining: Unlike ELB Endpoints, ALB Endpoints will drain connections to existing instances over 30 seconds when you redeploy your app, which ensures that even long running requests aren't interrupted by a deploy.
- DNS-Level Failover: via Brickwall.
- HTTP/2 Support: ALBs let you better utilize high-latency network connections via HTTP/2. Of course, HTTP/1 clients are still supported, and your app continues to receive traffic over HTTP/1.
Requests are balanced round-robin style.
ELB Endpoints are legacy. There's no reason to keep using ELB Endpoints today. Review the upgrade checklist below to migrate to ALB Endpoints.
When planning an upgrade from an ELB Endpoint to an ALB Endpoint, be aware of a few key differences between the platforms:
If you pointed your DNS records directly at the AWS DNS name for your ELB, DNS will break when you upgrade, because the underlying AWS ELB will be deleted.
If you pointed your DNS records at the Aptible portable name (
elb-XXX-NNN.aptible.in), you will not need to modify your DNS, as the Aptible record will automatically update. This means you will not need to change your DNS records if:
- You created a
CNAMErecord in your DNS provider from your domain name to this this portable name, or
- You are using DNSimple and created an ALIAS record to the Aptible portable name, or if you're using CloudFlare and are relying on CNAME flattening.
However, if you created a CNAME to the underlying ELB name (ending with
.elb.amazonaws.com), or if you are using an
ALIAS record in AWS Route 53, then you must update your DNS records to use the Aptible portable name before upgrading.
The main difference between ELB and ALB Endpoints is that SSLv3 is supported (and enabled by default) on ELB Endpoints, whereas it is not available on ALB Endpoints. For an overwhelming majority of apps, not supporting SSLv3 is desirable.
For more information, review HTTPS Protocols.
Unlike ELB Endpoints, ALB Endpoints perform SSL/TLS termination at the load balancer level. Traffic is then re-encrypted, delivered to a reverse proxy on the same instance as your app container, and forwarded over HTTP to your app.
Both the ALB and the local reverse proxy will add an IP address to the
X-Forwarded-For header. As a result, the X-Forwarded-For proxy will typically contain two IP addresses when using an ALB (whereas it would only contain one when using an ELB):
- The IP address of the client that connected to the ALB
- The IP address of the ALB itself
If you are using another proxy in front of your app (e.g. a CDN), there might more IP addresses in the list. If your app contains logic that depends on this header (e.g., IP address filtering, or matching header entries to proxies) you will want to account for the additional proxy.
This option is recommended for production apps.
- Provision a new Endpoint, choosing ALB as the platform
- Once the new ALB Endpoint is provisioned, verify that your app is behaving properly when using the new ALB's Aptible portable name (
- Update all DNS records pointing to the old ELB Endpoint to use the new ALB Endpoint instead
- Deprovision the old ELB Endpoint
This option is recommended for staging apps.
In the Aptible dashboard, locate the ELB Endpoint you want to upgrade. Select "Upgrade" under the "Platform" entry. Custom upgrade instructions for that specific endpoint will appear.
Updated 9 months ago