An Application Load Balancer (ALB) serves as a single point of contact for clients and distributes incoming application traffic across multiple targets, such as containers and Lambda functions. It operates at the application layer (layer 7) and is ideal for load balancing HTTP and HTTPS traffic.

ALBs can be integrated with various compute resources, offload SSL/TLS termination, and be configured with custom domain names or fronted by a CDN.

Under the hood, Stacktape uses AWS Application Load Balancer.

When to use them

ALBs are a good fit for most modern cloud applications. They offer high throughput and low latency, making them suitable for demanding workloads.

Advantages

• Predictable pricing: ALBs have a predictable pricing model, which can be more cost-effective than HTTP API Gateways for high-traffic applications.
• Scalability: ALBs can handle millions of requests per second and scale automatically as traffic grows.
• Health checks: When used with container workloads, an ALB periodically checks the health of each container and only routes traffic to healthy ones.
• Content-based routing: ALBs can route requests to different services based on the content of the request, such as the URL path, HTTP header, or query string.
• Security: You can offload SSL/TLS termination to the load balancer, encrypting traffic between the client and the ALB.

Disadvantages

• Fixed cost: ALBs have a fixed monthly cost (around $20/month), even if they are idle. For low-traffic applications, an HTTP API Gateway might be a more cost-effective choice.

Basic usage

resources:
  myLoadBalancer:
    type: 'application-load-balancer'

  basicLambda:
    type: function
    properties:
      packaging:
        type: stacktape-lambda-buildpack
        properties:
          entryfilePath: 'lambdas/js-lambda.js'
      events:
        - type: application-load-balancer
          properties:
            loadBalancerName: myLoadBalancer
            priority: 5
            paths:
              - '*'

Integrating with compute resources

You can forward requests from an ALB to your compute resources by creating an event integration on a multi-container workload, function, or batch job.

Each integration must specify:

• loadBalancerName: The name of the ALB that will forward requests.
• priority: A number that determines the order in which the integration rules are evaluated (from lowest to highest).
• condition: A set of rules that determine which requests are forwarded to the resource. Conditions can be based on the URL path, query string, headers, and other request properties.

The following example shows two integrations:

• The first integration forwards all requests (*) to a multi-container workload.
• The second integration, which has a lower priority and is evaluated first, forwards any requests with a URL path prefixed with /lambda-service/ to a Lambda function.

resources:
  myLoadBalancer:
    type: 'application-load-balancer'

  mySingleContainer:
    type: 'multi-container-workload'
    properties:
      containers:
        - name: myCont
          packaging:
            type: stacktape-image-buildpack
            properties:
              entryfilePath: containers/ts-container.ts
          environment:
            - name: PORT
              value: '80'
          events:
            - type: application-load-balancer
              properties:
                loadBalancerName: myLoadBalancer
                containerPort: 80
                priority: 3
                paths:
                  - '*'
      resources:
        cpu: 0.25
        memory: 512

  myFunction:
    type: function
    properties:
      packaging:
        type: stacktape-lambda-buildpack
        properties:
          entryfilePath: my-lambda.js
      events:
        - type: application-load-balancer
          properties:
            loadBalancerName: myLoadBalancer
            priority: 2
            paths:
              - '/lambda-service/*'

For more information, see the documentation on integrating ALBs with functions, multi-container workloads, and batch jobs.

Custom domain names

You can use a custom domain for your ALB. If you don't have one, you can register one through Stacktape.

If you already have a domain, you can either let Stacktape manage it (if you use AWS Route 53 for DNS) or use a third-party DNS provider.

For more details, see the Domains and Certificates page.

Using Stacktape to manage domains and certs

resources:
  myLoadBalancer:
    type: 'application-load-balancer'
    properties:
      customDomains:
        - my-app.mydomain.com

Using a 3rd-party DNS

To use a domain from a provider like GoDaddy or Cloudflare:

1. Create or import a TLS certificate for your domain in the AWS Certificate Manager console and copy its ARN.
2. Configure a listener on your load balancer to use the custom certificate.
3. After deploying, find the ALB's domain name in the Stacktape Console.
4. In your DNS provider's dashboard, create a CNAME or ALIAS record pointing to the ALB's domain name.

resources:
  myLoadBalancer:
    type: 'application-load-balancer'
    properties:
      listeners:
        - port: 443
          protocol: HTTPS
          customCertificateArns:
            - arn:aws:acm:eu-west-1:999999999999:certificate/8ab817b5-c4fa-4b1d-8b72-d6082cb40351
        - port: 80
          protocol: HTTP
          defaultAction:
            type: redirect
            properties:
              statusCode: HTTP_301
              protocol: HTTPS

Custom listeners

Listeners check for connection requests from clients, using the protocol and port that you configure. You can define rules for a listener that determine how the load balancer routes requests to its registered targets.

resources:
  myLoadBalancer:
    type: 'application-load-balancer'
    properties:
      listeners:
        - port: 80
          protocol: HTTP

  myFunction:
    type: function
    properties:
      packaging:
        type: stacktape-lambda-buildpack
        properties:
          entryfilePath: my-lambda.js
      events:
        - type: application-load-balancer
          properties:
            loadBalancerName: myLoadBalancer
            # you need to specify listener port when referencing load balancer with custom listeners
            listenerPort: 80
            priority: 5
            paths:
              - '*'

Default listener action

The default action for a listener determines what to do with a request that doesn't match any of the listener's rules.

Redirect

You can configure a listener to redirect incoming requests to a different URL. For example, you can redirect all HTTP requests on port 80 to an HTTPS listener on port 443.

resources:
  myLoadBalancer:
    type: 'application-load-balancer'
    properties:
      customDomains:
        - my-app.mydomain.com
      listeners:
        - port: 443
          protocol: HTTPS
        - port: 80
          protocol: HTTP
          defaultAction:
            type: redirect
            properties:
              statusCode: HTTP_301
              protocol: HTTPS
              port: 443

CDN

You can place an AWS CloudFront CDN in front of your ALB to cache content and reduce latency.

For more information, see the CDN documentation.

Using a firewall

You can protect your ALB with a web application firewall (WAF).

To learn more, see the Web Application Firewall documentation.

resources:
  myFirewall:
    type: web-app-firewall
    properties:
      scope: regional
  myLoadBalancer:
    type: 'application-load-balancer'
    properties:
      useFirewall: myFirewall

Referenceable parameters