Overview

Application Load balancer is an entry-point to your application. Load balancer can route 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 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

Application load balancer is a good fit for many cloud applications. Whether your backend is ran on container-workloads or functions thanks to high throughput and low latency, load balancer is ideal for high load fast performing applications.

Advantages

• Predictible pricing - Application load balancers have predictable pricing model which can be found here. Eventhough application-load-balancers have fixed base price per month (as oposed 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 application load balancer is used with container-workloads load balancer periodically checks 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

Usage

➡️ Simple usage

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

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

➡️ 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 request that does not match any event integration that are associated with this listener (see integrating with workloads).

Redirect

Following example extens 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 with workload, you can simply add an event integration to deliver requests to the chosen workkload.

This example is only an extension of the previous one. We have added 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 certifiates 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 request coming to different origins: I.e instead of forwarding request to the application-load-balancer, you can choose other resource to route to (http-api-gateway, bucket or load-balancer).

Routing to 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 application-load-balancer

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 ability to cache different types of content differently.

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

In the following example we are setting default TTL for the default route to 60 seconds. However, 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

Cache key specifies which parts of request are included in the cache key.

By default requests are cached only based on path.

You can configure cache key to include headers, cookies or query params.

Cache key headers

Cache key cookies

Cache key query string

Forwarding options

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

You can specify different forwarding options for each route rewrite. This gives you ability to forward parts of request only when needed.

If you do not specify forwarding options, 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'