Overview

Application Load balancer is an entry-point to your application. Load balancer routes traffic to your application and integrates easily with workloads of your stack: functions, batch-jobs or container-workloads.

• Application load balancers are used to communicate with your workloads 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.

When to use

An application load balancer is a good fit for many cloud applications. Whether your backend is running on 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 container-workloads, the load balancer periodically checks the health of target containers. It only sends requests to healthy ones and automatically notifies 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.
• Ease of use - Integrate with workloads 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

The following example shows a simple application-load-balancer with a single listener exposed.

resources:
  myLoadBalancer:
    Type: 'application-load-balancer'
    Properties:
      listeners:
        - port: 443
          protocol: HTTPS

Configure listeners

Listeners provide a way to expose ports of application-load-balancer. They makes application-load-balancer accessible from the outside and forward traffic to workloads (functions, container-workloads, batch-jobs) of your stack.

Following example shows application-load-balancer with one listeners. HTTPS listener at port 443.

resources:
  myLoadBalancer:
    Type: 'application-load-balancer'
    Properties:
      listeners:
        - port: 443
          protocol: 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 workloads).

Redirect

The following example extends the previous one and 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.

resources:
  myLoadBalancer:
    Type: 'application-load-balancer'
    Properties:
      listeners:
        - port: 443
          protocol: HTTPS
        - port: 80
          protocol: HTTP
          defaultAction:
            type: redirect
            properties:
              statusCode: HTTP_301
              protocol: HTTPS
              port: 443

Integrating with workloads

To integrate, add an event integration to the workload.

The following example extends the previous one and shows:

• container-workload mySingleContainer with event integration which delivers all requests incoming to myLoadBalancer's listener on port 443 to the container.

resources:
  myLoadBalancer:
    Type: 'application-load-balancer'
    Properties:
      listeners:
        - port: 443
          protocol: HTTPS
        - port: 80
          protocol: HTTP
          defaultAction:
            type: redirect
            properties:
              statusCode: HTTP_301
              protocol: HTTPS
              port: 443

  mySingleContainer:
    Type: 'container-workload'
    Properties:
      containers:
        - name: myCont
          imageConfig:
            filePath: containers/ts-container.ts
          environment:
            - name: port
              value: '80'
          events:
            - type: application-load-balancer
              properties:
                loadBalancerName: myLoadBalancer
                listenerPort: 443
                containerPort: 80
                priority: 2
                paths:
                  - '*'

More information on integrating workloads with application load balancer can be found:

• integrate functions with application load balancer.
• integrate container-workload with application load balancer.
• integrate batch-job with application load balancer.

Domain names

Domains can be easily controlled by Stacktape.

If your domain DNS records are controlled by AWS Route 53, Stacktape automatically generates correct TLS certifiates for your domain and assign them to listeners.

If your domain DNS records are NOT controlled by AWS:

1. migrate domain with a help of domain-add command (if you are migrating domain which is currently in use, please readAWS docs).
2. you can provision certificate by specifying customCertificateArns for your listener.

resources:
  myLoadBalancer:
    Type: 'application-load-balancer'
    Properties:
      domainNames:
        - my-app.mydomain.com
      listeners:
        - port: 443
          protocol: HTTPS

Cdn

resources:
  myLoadBalancer:
    Type: 'application-load-balancer'
    Properties:
      listeners:
        - port: 443
          protocol: HTTPS
      cdn:
        enabled: true
        listenerPort: 443

Cdn domain names

Domains can be easily controlled by Stacktape.

If your domain DNS records are controlled by AWS Route 53, Stacktape automatically generates correct TLS certificates for your domain.

If your domain DNS records are NOT controlled by AWS:

1. migrate domain with a help of domain-add command (if you are migrating domain which is currently in use, please readAWS docs).
2. you can provision certificate by specifying customCertificateArn and specifyingdisableDnsProvision

resources:
  myLoadBalancer:
    Type: 'application-load-balancer'
    Properties:
      listeners:
        - port: 443
          protocol: HTTPS
      cdn:
        enabled: true
        listenerPort: 443
        domainNames:
          - domainName: something.mydomain.com

Route rewrites

Route rewrites can be used to route incoming requests to different origins: I.e., instead of forwarding a request to the application-load-balancer, the request can be forwarded to another origin (http-api-gateway, bucket or application-load-balancer).

Routing to a bucket

In the following example we are routing all request with url path starting with /static to the bucket myBucket which contains our static content. All other requests are routed to the application-load-balancer myLoadBalancer.

resources:
  myLoadBalancer:
    Type: 'application-load-balancer'
    Properties:
      listeners:
        - port: 443
          protocol: HTTPS
      cdn:
        enabled: true
        listenerPort: 443
        routeRewrites:
          - path: /static/*
            routeTo:
              type: bucket
              properties:
                bucketName: myBucket
                disableUrlNormalization: true

  myBucket:
    Type: 'bucket'

Routing to application-load-balancer

In the following example we are routing all request with url path starting with /app2 to the application-load-balancer myLoadBalancer2. All other requests are routed to the application-load-balancer myLoadBalancer.

resources:
  myLoadBalancer:
    Type: 'application-load-balancer'
    Properties:
      listeners:
        - port: 443
          protocol: HTTPS
      cdn:
        enabled: true
        listenerPort: 443
        routeRewrites:
          - path: /app2/*
            routeTo:
              type: 'application-load-balancer'
              properties:
                loadBalancerName: myLoadBalancer
                listenerPort: 443

  myLoadBalancer2:
    Type: 'application-load-balancer'
    Properties:
      listeners:
        - port: 443
          protocol: HTTPS

Routing to http-api-gateway

In the following example we are routing all request with url path starting with /app2 to the http-api-gateway appApiGateway. All other requests are routed to the application-load-balancer myLoadBalancer.

resources:
  myLoadBalancer:
    Type: 'application-load-balancer'
    Properties:
      listeners:
        - port: 443
          protocol: HTTPS
      cdn:
        enabled: true
        listenerPort: 443
        routeRewrites:
          - path: /app2/*
            routeTo:
              type: 'http-api-gateway'
              properties:
                httpApiGatewayName: appApiGateway

  appApiGateway:
    Type: 'http-api-gateway'

Caching options

Caching options enable you to specify caching settings for your CDN.

You can specify different cache options for each route rewrite. This gives you the ability to cache different types of content differently.

If you do not specify caching options, Stacktape uses default caching options.

The following example shows:

• CDN configuration in which we are setting default TTL for the default route to 60 seconds (1 minute).
• every request, with URL path starting with /static, will be cached for 604800 seconds (1 week).

resources:
  myLoadBalancer:
    Type: 'application-load-balancer'
    Properties:
      listeners:
        - port: 443
          protocol: HTTPS
      cdn:
        enabled: true
        listenerPort: 443
        cachingOptions:
          defaultTTL: 60
        routeRewrites:
          - path: /static/*
            cachingOptions:
              defaultTTL: 604800

Specify cache key

The cache key section specifies which parts of a request are included in the cache key.

By default, requests are cached only based on the path.

A cache key can be configured to include headers, cookies, or query params.

Cache key headers

Cache key cookies

Cache key query string

Forwarding options

Forwarding options specify which parts of a request get forwarded to the origin.

Different forwarding options can be specified for each route rewrite.

If no forwarding options are specified, Stacktape uses default forwarding options.

In the following example we are configuring CDN to only forward requests with methods GET and

resources:
  myLoadBalancer:
    Type: 'application-load-balancer'
    Properties:
      listeners:
        - port: 443
          protocol: HTTPS
      cdn:
        enabled: true
        listenerPort: 443
        forwardingOptions:
          allowedMethods:
            - 'GET'
            - 'POST'