Load balancers cost $10/month, billed hourly at $0.015. There is no additional cost to use Let’s Encrypt with load balancers.
There are no bandwidth charges for DigitalOcean Load Balancers because they are bandwidth neutral. In other words, load balancers themselves don’t change the amount of data transferred by Droplets. Bandwidth costs are based on the data transfer of the Droplets included in the load balancer’s backend, taking into consideration their own transfer limits.
Load balancers and Let’s Encrypt certificates are supported in every region.
The Droplets you choose for your backend pool must be in the same region as your load balancer.
A DigitalOcean Load Balancer monitors backend Droplets to ensure that each service is operating healthy. Users can define health check endpoints and set the parameters around what constitutes a healthy response. The load balancer will automatically remove machines from rotation that fail health checks until those health checks indicate that service has been restored.
DigitalOcean Load Balancers are configured with automatic failover in order to maintain availability even when failures occur at the balancing layer. Internally, the active balancing component is monitored and fails over to a standby if necessary, meaning your load balancer is never a single point of failure. To achieve the same outcome and avoid a single point of failure using Droplets, it would take at least two Droplets and a Floating IP.
There are two different ways to define backend Droplets for a load balancer:
Tags are custom labels you can apply to Droplets. If you use a tag to define the backend Droplets for your load balancer, it will automatically adjust the routing whenever you add or remove that tag from a Droplet.
The load balancer will connect to Droplets over the private network if it is enabled on the Droplets in question when they are added to the load balancer. If private networking is disabled, the load balancer will contact the Droplet using its public IP address.
Load balancers support two balancing algorithms: round robin and least connections.
A single DigitalOcean Load Balancer can be configured to handle multiple protocols and ports. You can control traffic routing with configurable rules that specify the ports and protocols that the load balancer should listen on, as well as the way that it should select and forward requests to the backend servers.
Because DigitalOcean Load Balancers are network load balancers, not application load balancers, they do not support directing traffic to specific backends based on URLs, cookies, HTTP headers, etc.
Standard HTTP balancing directs requests based on standard HTTP mechanisms. The load balancer sets the
X-Forwarded-Port headers to give the backend servers information about the original request.
If user sessions depend on the client always connecting to the same backend, a cookie can be sent to the client to enable sticky sessions.
You can balance secure traffic using either HTTPS or HTTP/2. Both protocols can be configured with:
You can configure load balancers to redirect HTTP traffic on port 80 to HTTPS or HTTP/2 on port 443. This way, the load balancer can listen for traffic on both ports but redirect unencrypted traffic for better security.
TCP balancing is available for applications that do not speak HTTP. For example, deploying a load balancer in front of a database cluster like Galera would allow you spread requests across all available machines.
DigitalOcean Load Balancer Let’s Encrypt certificates are fully managed and automatically renewed on your behalf every 60 days. You can use SSL certificates with HTTPS and HTTP/2.
Load balancers currently do not support IPv6.
When using SSL passthrough (port 443 to 443), load balancers will not inject
x-forwarded-port, and other
x-forwarded-for parameters. Load balancers will inject those parameters for HTTPS when using SSL termination (port 443 to 80) or HTTP connection (port 80 to 80).
Sticky sessions are only visible at the load balancer layer; the cookies used for sticky sessions are both set and stripped at the load balancer. Because those cookies are not present in the request sent to the backend Droplets, backend applications cannot use them.
Load balancers use
keep-alive headers are not honored.
The default number of load balancers an account can have is 10. This is also affected by the Droplet limit on the account.
Load balancer connections have a keep-alive time of 60 seconds.
HTTP health checks are sent using HTTP 1.0. If your web server uses a version other than HTTP 1.0 the headers in the health check may not be compatible and you’ll need to use a TCP check.
You cannot assign a floating IP address to a DigitalOcean Load Balancer.
Sticky sessions will not work with SSL passthrough (port 443 to 443). They will work with SSL termination (port 443 to 80) and HTTP requests (port 80 to 80).
You must manage your DNS records on DigitalOcean in order for us to manage Let’s Encrypt on load balancers on your behalf.
You can only use SSL termination with Let’s Encrypt on DigitalOcean. SSL passthrough requires certificates on the Droplets themselves, and DigitalOcean does not install or maintain certificates on unmanaged services like Droplets.
Load balancers do not support Let’s Encrypt wildcard certificates. Let’s Encrypt added wildcard certificate support in March of 2018 but continues to recommend non-wildcard certificates for most use cases.
If your certificate isn’t issued on the first try, we will automatically retry at 20 minute intervals up to 3 times. After that, we’ll send email to your account’s address letting you know that the certificate creation failed.
Let’s Encrypt SSL keys are limited to 2048 bits.