Application Load Balancers
Overview
- Application Load balancer is an entry-point to your application. Load balancer routes traffic to your application and integrates easily with compute resources of your stack: functions, batch-jobs or multi-container-workloads.
- Application load balancers are used to communicate with your compute resources using the HTTP protocol.
- You can offload SSL/TLS (HTTPS) termination to the load-balancer instead of handling it as a part of your application.
- You can easily configure custom domain names or put CDN in front of your application-load-balancer.
Under the hood
Application load balancer is an abstraction which under the hood uses AWS Application Load Balancer. By default Stacktape takes care of which ports(listeners) are open on the load balancer, but you are free to configure your own custom listeners.
When to use
An application load balancer is a good fit for many cloud applications. Whether your backend is running on multi-container-workloads or functions thanks to high throughput and low latency, an application load balancer is ideal for high load fast performing applications.
Advantages
- Predictable pricing - Application load balancers have a predictable pricing model which can be found here. Even though application-load-balancers have fixed base price per month (as opposed to http-api-gateways, where you only pay for requests), when traffic is high application-load-balancer can be cheaper.
- Scaling - Application load balancer is designed to handle traffic as it grows and can load balance millions of requests/sec.
- Health checks - When an application load balancer is used with multi-container-workloads, the load balancer periodically checks the health of target containers. It only sends requests to healthy ones and automatically notifies multi-container-workload to replace unhealthy containers.
- Content based routing - If your application is composed of several individual services, application-load-balancer can route a request to a service based on the content of the request such as Host field, Path URL, HTTP header, HTTP method, Query string or Source IP address (see section Integrating with compute resources).
- Ease of use - Integrate with compute resources of your stack with few lines of config
- Security - You can offload SSL/TLS (HTTPS) termination to the load-balancer instead of handling it as a part of your application. This means that any communication between load-balancer and client can be encrypted.
Disadvantages
- Fixed price base - You are paying ~20$/month for application-load-balancer even if it is sitting idle. When you have low traffic application or do NOT need the advantages that application-load-balancer offers, you might try using http-api-gateway
Simple usage
Copy
resources:myLoadBalancer:type: 'application-load-balancer'basicLambda:type: functionproperties:packaging:type: stacktape-lambda-buildpackproperties:entryfilePath: 'lambdas/js-lambda.js'events:- type: application-load-balancerproperties:loadBalancerName: customLbpriority: 5paths:- '*'
Application load balancer with function integration
Integrating with compute resources
By creating event integration on a workload(multi-container-workload, function, batch-job), you are telling application load balancer to forward requests to the workload.
Each integration must specify:
loadBalancerName
(andlistenerPort
if your load balancer uses custom listeners) that will forward requests to the integrationpriority
- priority determines order in which the integrations are evaluated by load balancer.
- load balancer evaluates integrations from lowest value to highest value.
- load balancer forwards the request to the first integration whose condition matches the request.
- condition
- condition determines which requests can be forwarded to the integration.
- condition can be composed of
path
,queryString
,headers
and other parts of request.
Following example shows two integrations:
- integration attached to mySingleContainer which forwards all requests (wildcard path
*
) to the multi-container-workload. - integration attached to myFunction which forwards requests with URL prefixed with
/lambda-service/
to the function. - since integration on myFunction has lower priority it is evaluated before integration on mySingleContainer
Copy
resources:myLoadBalancer:type: 'application-load-balancer'mySingleContainer:type: 'multi-container-workload'properties:containers:- name: myContpackaging:type: stacktape-image-buildpackproperties:entryfilePath: containers/ts-container.tsenvironment:- name: PORTvalue: '80'events:- type: application-load-balancerproperties:loadBalancerName: myLoadBalancercontainerPort: 80priority: 3paths:- '*'resources:cpu: 0.25memory: 512myFunction:type: functionproperties:packaging:type: stacktape-lambda-buildpackproperties:entryfilePath: my-lambda.jsevents:- type: application-load-balancerproperties:loadBalancerName: myLoadBalancerpriority: 2paths:- '/lambda-service/*'
Application load balancer with function and multi-container-workload integrations.
More information on integrating compute resources with application load balancer can be found:
Custom domain names
If you do not have a custom domain and want one, read the section Registering domain on the Domains and TLS certificates page.
If you already have an existing domain and you wish to use it with your app, there are two approaches:
- Using Stacktape to manage domains and certs - you must use Route53 in your AWS account as your DNS.
- Using 3rd party DNS provider - such as GoDaddy, Cloudflare etc. You must handle domains and generate certificates yourself.
For more information about domain management options, refer to Domains and TLS certificates page.
Using Stacktape to manage domains and certs
Stacktape allows you to connect your custom domain names to some of your resources (Web Service, HTTP API Gateways, Application Load Balancers and Buckets with CDNs).
Connecting a custom domain to the resource does 2 things:
- Creates DNS records:
- If you use your custom domain with a resource, Stacktape automatically creates a DNS record (during deploy) pointing the specified domain name to the resource.
- Adds TLS certificates
- If the origin resource (HTTP API Gateway, Application Load Balancer or CDN) uses HTTPS protocol, Stacktape takes care of issuing and attaching correct (free, AWS-managed) certificate to the resource. This means, you do not have to deal with TLS termination as it is handled by the connected resource.
- If you want to use your own certificates, you can configure
customCertificateArns
.
To manage a custom domain, it first needs to be added to your AWS account. This means that a hosted zone (collection of records managed together for a given domain) for your domain exists in your AWS account and your domain registrar's name servers are pointing to it. To learn more, refer to Adding a domain guide.
Copy
resources:myLoadBalancer:type: 'application-load-balancer'properties:customDomains:- my-app.mydomain.com
Using 3rd party DNS
To use 3rd party DNS provider you must:
- Create/import a custom TLS certificate for your domain in AWS console. Copy certificate ARN; you will need it in the next step.
- Configure listener (more info on listeners here) on your load balancer with your custom certificate using the copied ARN.
Copy
resources:myLoadBalancer:type: 'application-load-balancer'properties:listeners:- port: 443protocol: HTTPScustomCertificateArns:- arn:aws:acm:eu-west-1:999999999999:certificate/8ab817b5-c4fa-4b1d-8b72-d6082cb40351- port: 80protocol: HTTPdefaultAction:type: redirectproperties:statusCode: HTTP_301protocol: HTTPS
Custom HTTPS listener with custom certificate with automatic HTTP to HTTPS redirect
After you deploy your load balancer, you can find the domain name in Stacktape console in:
Your project and stage > Click on your Application Load Balancer resource to see its domain
Once you have the domain name, you can point DNS record to this domain using your DNS provider:
- Use ALIAS record type for root domains (i.e mydomain.com)
- Use CNAME record type for subdomains (i.e www.mydomain.com or staging.mydomain.com
Configure custom listeners
Listeners provide a way to expose ports of application-load-balancer. They makes application-load-balancer accessible from the outside.
Listeners are listening on specified ports and forward traffic to compute resources through event integrations(functions, multi-container-workloads or batch-jobs).
- Listeners are used to expose specific ports of the Load balancer.
- If you do not specify any listeners, by default, two listeners are created:
- HTTPS listener (port 443) - all traffic is routed to this listener
- HTTP listener (port 80) - automatically redirects to HTTPS listener
Copy
resources:myLoadBalancer:type: 'application-load-balancer'properties:listeners:- port: 80protocol: HTTPmyFunction:type: functionproperties:packaging:type: stacktape-lambda-buildpackproperties:entryfilePath: my-lambda.jsevents:- type: application-load-balancerproperties:loadBalancerName: myLoadBalancer# you need to specify listener port when referencing load balancer with custom listenerslistenerPort: 80priority: 5paths:- '*'
Application load balancer with single listener and function integration.
Using custom TLS certificates
If you are using custom listeners, you can configure listener to use your custom TLS certificate. In order to do that you can:
- Set
customCertificateArns
property to make the listener use custom certificate of your choice (you can create certificate in AWS console). In this case you also need to handle DNS records for your domain, i.e point correct domain name relevant for the certificate to the load balancer.
Copy
resources:myLoadBalancer:type: 'application-load-balancer'properties:listeners:- port: 443protocol: HTTPScustomCertificateArns:- arn:aws:acm:eu-west-1:999999999999:certificate/8ab817b5-c4fa-4b1d-8b72-d6082cb40351- port: 80protocol: HTTPdefaultAction:type: redirectproperties:statusCode: HTTP_301protocol: HTTPS
Default listener action
Default listener action determines what to do with a request that does not match any event integration associated with this listener (see Integrating with compute resources).
Redirect
The following example shows application-load-balancer with two listeners:
- HTTPS listener at port 443
- HTTP listener at port 80. HTTP listener has default redirect action configured. This means that any HTTP request is automatically redirected to its HTTPS version.
Copy
resources:myLoadBalancer:type: 'application-load-balancer'properties:customDomains:- my-app.mydomain.comlisteners:- port: 443protocol: HTTPS- port: 80protocol: HTTPdefaultAction:type: redirectproperties:statusCode: HTTP_301protocol: HTTPSport: 443
CDN
You can configure AWS Cloudfront CDN (Content Delivery Network) to be in front of your application-load-balancer.
- CDN is a globally distributed network that can cache responses from your Application Load Balancer at the edge - close to your users.
- AWS Cloudfront has 205 edge locations on 6 continents.
- The CDN is used to:
- reduce latency & improve load times
- reduce bandwidth costs
- reduce the amount of traffic coming to the origin
- improve security
- The "origin" is the resource (Application Load Balancer) to which CDN is attached. CDN caches responses from the origin at the edge for specified amount of time.
- If the content requested by the client is in the CDN cache, the CDN immediately returns it to the client without making a request to the origin.
- If the content is NOT in the cache, the CDN makes a request to the Origin. The response from the origin is then forwarded to the client, and cached at the edge.
- The CDN has its own URL endpoint.
For information about using CDN refer to our CDN docs.
Using firewall
- You can use
web-app-firewall
to protect your resources from common web exploits that could affect application availability, compromise security, or consume excessive resources. - Web app firewall protects your application by filtering dangerous requests coming to your app. You can read more about the firewall in our docs.
To lean more, check web-app-firewall documentation.
Copy
resources:myFirewall:type: web-app-firewallproperties:scope: regionalmyLoadBalancer:type: 'application-load-balancer'properties:useFirewall: myFirewall
Referenceable parameters
The following parameters can be easily referenced using $ResourceParam directive directive.
To learn more about referencing parameters, refer to referencing parameters.
default domain name of load balancer
- Usage:
$ResourceParam('<<resource-name>>', 'domain')
Comma-separated list of custom domain names assigned to the Load balancer (only available if you use custom domain names)
- Usage:
$ResourceParam('<<resource-name>>', 'customDomains')
Default domain of the CDN distribution (only available if you DO NOT configure custom domain names for the CDN).
- Usage:
$ResourceParam('<<resource-name>>', 'cdnDomain')
Default url of the CDN distribution (only available if you DO NOT configure custom domain names for the CDN).
- Usage:
$ResourceParam('<<resource-name>>', 'cdnUrl')
Comma-separated list of custom domain names assigned to the CDN (only available if you configure custom domain names for the CDN).
- Usage:
$ResourceParam('<<resource-name>>', 'cdnCustomDomains')
Comma-separated list of custom domain name URLs of the CDN (only available if you configure custom domain names for the CDN).
- Usage:
$ResourceParam('<<resource-name>>', 'cdnCustomDomainUrls')