Follow

Follow
AWS App Runner: The Easy Way to Run Your Containers

AWS App Runner: The Easy Way to Run Your Containers

Alessandro Marino's photo
Alessandro Marino
ยทApr 4, 2023ยท

6 min read

Play this article

Table of contents

App Runner is one of the newest services to run containers on AWS, it offers a fully-managed way of running scalable web applications.

Infographic

Let's start with a quick overview of AWS App Runner:

AWS App Runner Introduction

Where does AWS App Runner fit in the AWS container world?

Running container on AWS

App Runner does not replace container orchestration services like ECS (Elastic Container Service) or EKS (Elastic Kubernetes Service) instead it offers a simplified experience for developers and teams without a strong prior infrastructure and container experience.

App Runner also directly integrates build systems for your application simplifying the workflow between coding and running the service. The service primarily targets containerized web applications so it's particularly useful to build and run API services, backend web services, websites, and more.

Building your containers

App Runner allows you to build a web application from scratch, or run a container from an ECR (Elastic Container Registry) or ECR Public.

AWS App Runner Container Registry source

When you select "Source code repository" as the source for your APP Runner service, you can connect to a specific GitHub repository and configure a build process for your code. The build process can be triggered manually or automatically for every push on the selected git branch.

App Runner Github source

The build process can be configured directly from the App Runner console/SDK/API or you can specify a configuration file to be included in your repository. The service currently supports a lot of common runtimes like NodeJS, Go, Python, Ruby, PHP, .NET, Amazon Corretto (Java), and others.

A custom build command can be used to compile your code and a custom start command can be used to run it when the container is executed.

AppRunner build from source settings

Run your containers

After selecting or building a container image, we can finally take a look at running the service. We don't need a lot of settings to get started with App Runner, using default values we can get started in seconds.

By default our container will start with a public endpoint and outgoing public access, the networking can then be customized to limit outgoing traffic using a VPC connector and one or more security groups. The public endpoint can be removed as well and private connectivity powered by AWS PrivateLink can be set up.

Containers can be sized by selecting vCPU and GB of memory, by default a container starts with 1vCPU and 2 GB of memory.

Environment variables are optional and can be set. Integration with AWS SSM Parameter Store and AWS Secrets Manager exist and we will deep dive into it later on.

Integrations

AWS X-Ray

Observability for your containers can be improved using AWS X-Ray.

X-Ray already integrates well within the AWS ecosystem so you can keep using it even when requests transit on App Runner.

AppRunner AWS X-Ray integration

SSM Parameter Store and Secrets Manager

Environment variables are widely used to provide applications secrets and sensitive values, with the Parameter Store and Secrets Manager integration you can easily store all your secrets in a safe place and allow App Runner to retrieve those at runtime using an IAM Policy.

App Runner AWS SSM Parameter Store integration

AWS WAF

App Runner Web Application Firewall

AWS WAF (Web Application Firewall) already integrates with most of the AWS front-facing services like ELB, CloudFront, and others. App Runner is not an exception and support for WAF was recently added.

With a WAF web ACL, we can set up rules to protect our application from common web attacks, set up rate limits, create a geographical block, block IPs, and more.

AWS KMS

KMS (Key Management Service) integrates with App Runner to allow at-rest encryption of your files.

Pricing

AWS App Runner pricing sits between a standard pay-per-container model (like ECS Fargate) and a more serverless model (like AWS Lambda), pricing can be confusing at a first glance.

With App Runner, your cost is divided into three main parts:

  1. vCPU cost

  2. memory cost

  3. additional costs

vCPU cost is billed to you only when an instance is active, meanwhile, memory is billed continuously. The cost will multiply for the number of instances active if scaling is enabled.

What is an App Runner instance?

Similar to AWS Lambda, App Runner spin up an instance of your container only when requests are made to your endpoint. Instances stay active for some minutes, (1 minute from the AWS Docs).

Additional costs

In addition to vCPU and memory costs, AWS will also bill you for a fixed fee of 1$ for each active App Runner application.

Pipelines for building your app from the source are also billed separately per minute.

Pricing example of a development API

Let's consider an API during the development phase used by a few developers for some hours during the work day, we can assume a traffic of 2 req/s for 2 hours each day. We can also assume the services will not be paused while not used.

  1. 2 hrs x 1 active container instance x [(1 vCPU x $0.064 vCPU-hour) + (2GB x $0.007 GB-hour)] = $0,156 (active hours)

  2. 22 hrs x 1 provisioned container instance x (2GB x $0.007 GB-hour) = $0.336 (inactive hours)

The total daily cost will be $0.492 for a monthly cost of $15.25

Pricing example of a medium-traffic website

Let's consider an e-commerce website with a regional audience where visitors are mainly concentrated during working hours.

On peaks (12 pm - 3 pm), the website can reach 2 req/s or 120 req/m. The max concurrency of the website is 100 req/m so the website will scale to handle peak traffic.

  1. 3 hrs x 2 active container instance x [(1 vCPU x $0.064 vCPU-hour) + (2GB x $0.007 GB-hour)] = $0.468 (peak hours)

  2. 7 hrs x 1 active container instance x [(1 vCPU x $0.064 vCPU-hour) + (2GB x $0.007 GB-hour)] = $0.546 (off-peak hours)

  3. 14 hrs x 1 provisioned container instance x (2GB x $0.007 GB-hour) = $0.196 (inactive hours)

The total daily cost will be $1.21 for a monthly cost of $37.51

Autoscaling

With the concept of App Runner instances fresh, we can also take a look at the Autoscaling feature of App Runner.

To enable Autoscaling we need to set a max concurrency value. This value indicates the number of concurrent requests that an App Runner instance can process. When this quota is exceeded App Runner will scale your service.

You can configure a minimum and a maximum number of instances for your autoscaling.

AppRunner autoscaling feature

Limitations

App Runner is still a young product and aims to simplify the workflow so a few limitations are to be expected, most of the major roadblocks have already been removed, for example, the VPC connection.

Some limitations are still here and hopefully will be removed soon, looking at the public roadmap you can have an idea of what blocks people the most:

  • External private container registries are currently not supported, you can only use public registries or ECR.

  • Incoming traffic is limited to HTTP requests, you can't use other protocols. For example, WebSockets are not supported.

  • GitHub is the only source repository currently supported.

  • App Runner does not scale to zero currently.

  • No AWS Saving Plan support

Summary

With this post, we introduce the main concepts of AWS App Runner and we take a look at the main features and limitations.

Get your hands dirty, try it yourself, and let us know what you think about this service.

ย 
Share this