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

YAML
TypeScript
Copy
serviceName: posts-api-pg

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: customLb
            priority: 5
            paths:
              - '*'

Using HTTPS(TLS)

• In order to use HTTPS(TLS) with your load balancers you can use property useHttps.
• To use this property, your load balancer must have custom domain name specified. Stacktape will attach correct TLS certificate to the load balancer during deployment. See section Custom domain names to see how to use custom domain names with load balancer.
• If you are using custom listeners you cannot use useHttps property (see section Configure custom listeners) .

YAML
TypeScript
Copy
resources:
  myLoadBalancer:
    type: 'application-load-balancer'
    properties:
      customDomains:
        - my-app.mydomain.com
      useHttps: true

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 (and listenerPort if your load balancer uses custom listeners) that will forward requests to the integration
• priority
  • 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

YAML
TypeScript
Copy
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/*'

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

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

Custom domain names

YAML
TypeScript
Copy
resources:
  myLoadBalancer:
    type: 'application-load-balancer'
    properties:
      customDomains:
        - my-app.mydomain.com
      useHttps: true

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).

YAML
TypeScript
Copy
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:
              - '*'

Using HTTPS with custom listeners

If you are using custom listeners, you can configure listener to use HTTPS. In order to do that you can either:

1. Have custom domain name specified. Stacktape will attach correct TLS certificates (for the domain) to the listener during deployment. See section Custom domain names to see how to use custom domain names with load balancer.

YAML
TypeScript
Copy
resources:
  myLoadBalancer:
    type: 'application-load-balancer'
    properties:
      customDomains:
        - my-app.mydomain.com
      listeners:
        - protocol: HTTPS
          port: 443

2. 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 to the load balancer (if you use custom domains Stacktape can handle DNS records for you).

YAML
TypeScript
Copy
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

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.

YAML
TypeScript
Copy
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 configure AWS Cloudfront CDN (Content Delivery Network) to be in front of your application-load-balancer.

For information about using CDN refer to our CDN docs.

Using firewall

To lean more, check web-app-firewall documentation.

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

Referenceable parameters