Module 2: AWS App Runner Fundamentals
LEARNING MODULE
Learning Objectives
In this module, you will:
- Learn the fundamentals of AWS App Runner, including its benefits, use cases, features, and pricing model.
- Understand where to find documentation and other resources.
- Get acquainted with AWS App Runner in the AWS management console and learn how to create, manage, and delete a service.
AWS App Runner is a fully managed service that makes it easy for developers to quickly deploy containerized web applications and APIs, at scale and with no prior infrastructure experience required. Start with your source code or a container image. App Runner builds and deploys your web application automatically, load balances traffic with encryption, scales to meet your traffic needs, and makes it easy for your services to communicate with other AWS services and applications that run in a private Amazon VPC. With App Runner, rather than thinking about servers or scaling, you have more time to focus on your applications.
Time to Complete
60 minutes
Introduction to AWS App Runner
AWS App Runner (hereafter “App Runner”) is a fully-managed service that makes it easy for developers to quickly deploy containerized web applications and APIs, at scale and with no prior infrastructure experience required. If you've got a web application or web service, such as a web site, API, or microservice, it's a candidate for App Runner.
App Runner is limousine service for containerized web apps. When AWS describes App Runner as "fully managed", they aren't kidding: if you want every last detail handled for you, App Runner is your service. Like AWS Lambda, your only responsibility is to supply your code. Like AWS Lambda, you won't have (or need) visibility into the underlying EC2 instances and infrastructure that your service runs on.
If you're not container-savvy, that's nothing to worry about: the deployment process can create a container for your code automatically. If you already use containers, you can bring your existing containers. App Runner will do everything else, managing TLS, a load balancer, health checks, and auto-scaling for you. Under the hood, App Runner is running your container with AWS Fargate on Amazon ECS, but you won't ever interact with those services directly.
Benefits
App Runner is easy to use, scales automatically, saves time, and provides a compliant environment.
Easy to use
You can build and run secure web-scale application in just a few clicks with AWS App Runner. You don’t need experience with containers, infrastructure, server configuration, networking, load balancing, or deployment pipelines.
Scales with Traffic
App Runner seamless scales up and down resources in response to web traffic. You can configure a minimum number of container instances to eliminate cold starts and ensure low latency.
Saves time
You won’t need to spend time allocating, configuring, or managing resources and infrastructure with App Runner. Resources and infrastructure components are fully managed by AWS, and benefit from security and operational best practices. You can stay completely focused on your application
Ensure a compliant environment
Your App Runner application can connect to AWS services, such as database, cache, and message queue services, through Amazon VPC. No public subnets are required, helping you protect your resources.
Use Cases
Use cases for AWS App Runner include front-end and back-end web applications, Microservices, Web APIs, and rapid deployment.
Front-end and Back-end Web Applications
You can host websites, web services, and APIs in App Runner.
Microservices and APIs
You can run thousands of microservices simultaneously on App Runner. This gives you loose-coupling and each microservice can scale independently.
Rapid Deployment
App Runner leverages AWS best practices and technologies for deploying and running your containers at scale. This reduces your time-to-market for new applications and features.
Features
Let’s review the features of the AWS App Runner service:
VPC Connector
App Runner services can communicate with other AWS services running in a private Amazon Virtual Private Cloud (VPC) via a VPC Connectors. This enables you to add support for other services under the control of an Amazon VPC.
Auto Scaling
App Runner automatically scales container instances up or down to meet traffic, with the constraints you configure.
Automatic Deployments
App Runner can automatically build and deploy your application when it changes. You can connect App Runner to your code repository, or to a container image registry such as ECR.
Certificate Management
App Runner includes Transport Layer Security (TLS) automatically. There is no setup required, and certificates are automatically renewed.
Cost Management
You can control costs by easily pausing or resuming applications through the AWS management console, AWS CLI, or AWS SDK.
Load Balancing
App Runner load balances traffic automatically, providing reliability and high availability.
Logs and Metrics
To enable monitoring and optimization of your containerized applications, App Runner provides detailed build, deployment, and runtime logs. A full set of compute metrics is also provided through built-in integration to Amazon CloudWatch.
Limitations
App Runner is only available in select regions, which you can check on the AWS App Runner endpoints and quotas page. If you will be using App Runner with other AWS services, such as a database or storage service, you’ll want to use regions that support all of your target services so they can be co-located for efficiency. You should also consider AWS recommendations for choosing a region, such as compliance with local regulations, and proximity to your user base location.
Not available in all regions
AWS App Runner is not available in all AWS regions. You can find the currently supported regions on the AWS App Runner endpoints and quotas page.
One container per service
In App Runner, a service is associated with one container, and one container only. You can run multiple instances of that container in accordance with traffic, but there’s no way to compose a service from multiple containers, the way you can with ECS or EKS.
Regional quotas
By default, you can create a maximum of 10 auto scaling configurations, 10 connections to third-party resources, 10 observability configurations, 10 services, and 10 VPC connectors per region. All of these quotas are adjustable. You can request a service quota increase using the AWS Service Quotes and AWS Support Center.
Pricing Model
App Runner charges for compute and memory resources. In addition, you can be charged for automated deployment and building from source code, if you opt to use those features. Note: the rates and pricing examples described here are based on US rates as of May 2022. Be sure to check the pricing page to confirm rates and other pricing model details. Note that rates may differ depending on region.
When you create your application in App Runner, you configure the amount of memory and virtual CPU required. A virtual CPU (vCPU) is a unit of CPU equal to one thread of one CPU core. You also specify concurrency, which determines the maximum number of simultaneous requests your active container instances need to support. When your application is idle, you only pay for the provisioned container instance memory which keeps your application warm and ready to respond quickly to the next request. When requests come in, you pay for vCPU and memory consumed by active container instances as your application processes requests. You are only billed when your application is running, and you can pause and resume your application through the AWS console.
Provisioned Container Instances
Once you deploy an application, you are charged for the memory provisioned in each container instance. By keeping memory provisioned even where there is no traffic, App Runner ensures it can respond to the next request with low latency.
At the time of this writing, provisioned container instances cost $0.007/GB-hour in US and European regions.
Pricing example: Imagine you have deployed a provisioned container instance that requires 2GB of memory, and as yet no traffic. That one 2GB provisioned container instance costs 1 x 2GB x $0.007 = $0.34 per day.
Active Container Instances
When your application is processing requests, your charges switch from provisioned container instances to active container instances. Active container instances charge you for compute resources and any memory beyond what is covered by provisioned container instances.
Active container instances are charged at the rate of $0.064/vCPU-hour. Container instance charges are billed per second, with a one-minute minimum for vCPU resources once a provisioned container instance starts processing requests.
Automatic deployments
If you opt-in to automatic deployments, source code changes to a deployment branch build container images and trigger a deployment. Automatic deployments are billed at $1/per application per month.
Build fee
You pay a build fee when App Runner builds your application from source code. The rate is $0.005/build-minute.
Pricing example 1: App Testing
You are testing your application for 2 hours each day. While active, your app gets 2 requests per second for a 2-hour period. Your app requires 2GB of memory per container instance. You pause the service for 22 hours of each day.
Your daily provisioned container instance fee is 2 hrs x 1 provisioned container instance x (2 GB x $0.007 GB-hour), or $0.03. You are only charged 2 hours per day because you are pausing the app for the other 22 hours of each day.
Your daily active container instance fee is 2 hrs x 1 active container instance x [(1 vCPU x $0.064 vCPU-hour)] – 2 hrs x 1 provisioned container instance x (2 GB x $0.007) = $0.13. Your total daily cost is $0.16, or $4.80/month.
Pricing example 2: Lightweight API
You have deployed a lightweight latency-sensitive web API to 1 provisioned container instance with 2GB of memory. Each day, you receive 80 sporadic requests during an 8-hour period.
App Runner maintains the provisioned container instance (memory) 24 hours/day, charged at 2GB x $0.007 GB-hour, or $0.34/day.
App Runners scales to 1 active container instance for 8 hours a day when requests are coming in. Active container instances are charged for compute and memory, minus the provisioned container instance memory charges. The formula is below, and comes out to $0.51/day.
8 hrs × 1 active container instance × [(1 vCPU × $0.064 vCPU-hour) + (2 GB × $0.007 GB-hour)] - 8 hrs x 1 provisioned container instance x (2 GB × $0.007 GB-hour) = $0.51
Total daily charges are $0.51 (active container instances) + $0.34 (provisioned container instances) = $0.85, or $25.50/month.
Pricing example 3: High-Volume Production
You have a web application in production. Each container instance requires 2GB of memory and can process 80 requests/second. The site is busy during the day with requests that peak at 800 requests/second for 3 hours. During 12 non-peak hours, there are 60 requests/second. App Runner scales the app to 10 active container instances for peak hours, and down to 1 active container instance for non-peak hours. Provisioned container instance memory is charged 24 hours each day.
The provisioned container instance (memory) is charged 24 hours/day at 2GB x $0.007 GB-hour, or $0.34/day.
During peak hours, 10 active container instances are needed to serve 800 requests/second for 3 hours. That’s 10 active container instances × 3 hrs × [(1 vCPU × $0.064 vCPU-hour) + (2 GB x $0.007 GB-hour)] - 1 provisioned container instance x 3 hrs x (2 GB x $0.007 GB-hour) = $2.30.
During non-peak (12 hours), 1 active container instance handles the 60 requests/second. That’s 12 hrs × 1 active container instance × [(1 vCPU × $0.064 vCPU-hour) + (2 GB x $0.007 GB-hour)] - 12 hrs × 1 provisioned container instance x (2 GB x $0.007 GB-hour) = $0.77.
Putting that all together, $2.30 (peak active container instances) + $0.77 (non-peak active container instances) + $0.45 (daily provisioned container instances) = $3.40/day, or $102/month.
Reference: AWS App Runner | Pricing, EC2 Virtual CPU
Developer Workflow
In this section, you’ll learn how developers work with App Runner. You follow the flow shown below to create an App Runner service for your application.
1. Add a Source
In this step, you connect to a container image or your source code and select deployment settings. When you create an App Runner service, you connect it to a source. The source can be a container image or a source code repository (shown below). For a source code repository, such as a GitHub repo, you’ll need to provide connection details.
Even if your application is not containerized, App Runner supports automatically building a container image. When you associate your existing source code repository and optionally provide App Runner with your runtime build and start commands, App Runner automatically containerizes your web application and provides a running web application. Automatic containerization is available for curated App Runner platforms that contain supported runtimes and frameworks.
Reference: AWS App Runner | FAQs
In deployment settings, you can choose to trigger update deployments of your application manually or automatically. If you enable automatic deployment, App Runner will automatically build and deploy your application whenever you update your source code or container image.
2. Configure build and service settings
In this step, you configure your container's vCPU and memory, and select auto scaling and health check options. If you chose to deploy from a source code repository rather than a container registry, you will also configure build settings. Although App Runner will default these settings for you, you’ll want to understand them and know your options for customizing your configuration.
You can choose to configure the settings in the console, or provide a YAML configuration file in your source code repository.
In service settings, you’ll give your service a name and set your container’s CPU and memory size. These settings affect your costs. You can also set any environment variables needed by your application here.
You can configure auto-scaling behavior. The default is just one instance of your container. App Runner can scale your service to more instances when it receives more than 80 concurrent requests. You can configure the maximum number of instances, which gives you cost control.
Health check settings allow you to identify a web path where App Runner can send health check requests. By default, if there are 5 consecutive health check failures, the instance is considered unhealthy and App Runner will replace it. You can configure the number of health checks that must fail before App Runner decides that the service is unhealthy, from 1 to 20.
Security settings allow you to choose an IAM role the instance will use. If your application needs to communicate with other AWS service, you authorize that in the IAM role. These settings also let you optionally provide a customer-managed key (CMK) for encrypting source code.
3.Review and Create
In this step, you review and verify all of your settings. Once you click Create and Deploy, App Runner creates your service and deploys your application.
4. Receive a Secure URL
Lastly, you receive a secure URL of your running production-ready service from AWS App Runner. HTTPS is configured automatically for you.
Finally, you may associate your application with a custom domain if you have one. You’ll be guided through proving you own the domain.
Managing App Runner Services
You can create, deploy, and manage an App Runner service in several ways.
AWS Management Console
From the AWS management console, you can create, deploy, configure, monitor, and terminate App Runner services. You navigate to the AWS App Runner console to perform these operations.
Once a service has been created and deployed, you can select a service and view service details in these areas:
Service Overview
In the Service overview section, you see your app's status (such as Running), the default domain URL, the Amazon Resource Name (ARN) of the service, and a "Source" URL. That last one takes you to the container in Amazon Elastic Container Registry (ECR) or your source code repository.
Logs
This tab shows your deployment logs and application execution log. App Runner collects your applications output and streams it to CloudWatch Logs. You can include any output you deem useful, such as the detail of requests to a web service.
Activity
The Activity tab shows the history of your service. App Runner uses a list of operations to keep track of activity in your App Runner service. An operation represents an asynchronous call to an API action, such as creating a service, updating a configuration, and deploying a service.
Metrics
The Metrics tab reveals your service metrics, including requests, responses, latency, and number of active instances.
Configuration
The Configuration tab displays your service configuration details, including number of virtual CPUs and memory, auto-scaling, health check, and security. Click Edit to modify your configuration. If you need to, you can exercise control over the number of virtual CPUs and memory per instance, set environment variables, customize auto-scaling, configure health checks, use a custom IAM role, or use a custom encryption key.
Monitoring and Logging
Monitoring your App Runner application is essential for maintaining reliability, availability, and performance. Collecting monitoring data from all parts of your AWS solution makes debugging a failure easier. App Runner collects application logs from your code. It also integrates with several AWS services for monitoring and responding to service incidents.
Amazon CloudWatch Alarms
You can use Amazon CloudWatch Alarms to monitor a service metric and send you a notification if conditions you specify are met. You can watch a service metric over a time period, and set a threshold to receive a notification if the metric exceeds the threshold for a given number of time periods. For example, you could be alerted when CPU utilization exceeds 60%.
Reference: Viewing App Runner service metrics reported to CloudWatch
Application Logs
App Runner collects the output of your application code and streams it to Amazon CloudWatch Logs. You decide what to log in your application, such as request details to a web service. You can view these logs in the App Runner console. If you use Visual Studio, you can view CloudWatch logs from the IDE if you have the AWS Toolkit for Visual Studio installed.
AWS CloudTrail Action Logs
AWS CloudTrail keeps a record of API calls against AWS services and tracks them as events. You can view events in the AWS console, and can optionally configure events to be continually written to an Amazon S3 bucket.
Reference: CloudWatch Logs, CloudWatch Metrics, CloudTrail API Actions
AWS Deployment Tool for .NET
The AWS Deploy Tool for .NET is interactive tooling for the .NET CLI and the AWS Toolkit for Visual Studio that helps deploy .NET applications with minimum AWS knowledge, and with the fewest clicks or commands. The tool guides you through deployment. You can create and publish .NET web applications to AWS App Runner using this tool with a single command, dotnet aws deploy.
If you use Visual Studio as your IDE and have the AWS Toolkit for Visual Studio installed, you can get this same guided deployment functionality in Visual Studio. In Solution Explorer, right-click your project and select Publish to AWS. Wizard pages will guide you through deployment
AWS Copilot
AWS Copilot is an open source command line interface (CLI) that can deploy to AWS App Runner as well as Amazon ECS and AWS Fargate with managed build pipelines. Copilot uses Amazon CloudFormation behind the scenes. Copilot can be used with .NET as well as Python and Node.js applications.
As a .NET developer, you’ll most likely want to use AWS Deployment for .NET CLI to deploy to AWS App Runner from the command line, but you might choose AWS Copilot if you also have non-.NET applications to deploy.
Here’s what it looks like when you deploy App Runner using Copilot:
AWS CLI
The AWS Command Line Interface contains commands for viewing and managing your AWS App Runner services. You can create, list, and describe services and related artifacts like VPC connectors and custom domains. You can view and set configuration settings. You can start deployments. You can pause, or resume applications. You can delete services.
Connecting to other AWS Services
By default, an App Runner service can only send messages to public endpoints, such as public websites and web services. If your application needs to integrate with other AWS services without going over the Internet, such as an Amazon RDS database, Amazon DynamoDB database, or Amazon ElastiCache, you can use a VPC Connector. Although you don’t generally need to understand AWS infrastructure in order to use App Runner, you will need a high-level understanding of Amazon Virtual Private Cloud (VPC), subnets, and security in order to use VPC Connectors. You can get a basic understanding of terms by reading What is Amazon VPC? and How Amazon VPC works.
VPC Connectors
A VPC Connector associates your App Runner service with a VPC. The VPC connector is only half of the connection. To reach another AWS service, that other service must also have a connection to the VPC. One way to arrange that is with a VPC endpoint, a private connection that doesn’t require Internet access. For example, the diagram below shows a connection between an App Runner service and a DynamoDB database. A VPC connector for App Runner and a VPC endpoint for DynamoDB are the two links to the VPC that enable communication.
You can configure a VPC Connector when you create an App Runner service. To configure a VPC Connector, you will need to specify the following:
- The VPC you wish to connect to, such as your default VPC
- .The subnets to select. For high availability, you should select subnets across at least 3 availability zones.
- Your default security group.
You should consult your organization’s security expert when configuring VPC connectors or VPC endpoints.
VPC Endpoints
A VPC endpoint enables you to privately connect your VPC to supported AWS services without requiring an Internet gateway, NAT device, or VPN connection. Instances in your VPC do not require public IP addresses to communicate with resources in the service. Traffic between your VPC and the other service does not leave the Amazon network.
You can learn more about VPC endpoints in the AWS Well-Architected Framework guide and AWS PrivateLink concepts.
You can create a VPC endpoint in the AWS console by navigating to VPC > Endpoints and clicking Create endpoint. To create an endpoint for an AWS service, select category AWS services, and search for and select the service you wish to connect to.
Documentation and Resources
Bookmark these resources, which you’ll want to use for reference and learning:
The AWS App Runner product detail pages provide a service overview, features, pricing, resources, and FAQs.
The AWS App Runner Documentation page has links to developer resources including the App Runner Developer Guide, AWS CLI reference, tutorials, videos, and blogs.
The AWS App Runner Developer Guide describes architecture, deployment, and observability.
The AWS CLI apprunner command reference. From the AWS CLI, you can create services, perform manual deployments, and list service status.
The Build and Deploy a Microsoft .NET Core Web API application to AWS App Runner using CloudFormation workshop shows how to build a Microsoft .NET Web API application with Amazon Aurora database with App Runner.
The AWS App Runner: Deep Dive webinar video is a tech talk and demo.
AWS App Runner: From Code to a Scalable, Secure Web Application in Minutes is a walk-through blog from Martin Beeby.
Key Take-Aways
You should now be able to articulate the benefits, use cases, features, and pricing model of AWS App Runner.
You learned the 4 steps of the developer workflow.
You learned how to manage App Runner instances in the AWS console, monitoring and logging options, and various command line tools.
You learned how VPC Connectors and VPC endpoints work together to connect AWS App Runner with other AWS services.
For .NET workloads, the easiest way to use App Runner is to use container images as a source. When you use code repository sources, extra work is required to install .NET on instances.
Conclusion
In this module, you learned the fundamentals of AWS App Runner. In the introduction to the service you reviewed App Runner’s benefits, use cases, features, limitations, and pricing model. You learned about the developer workflow and what you can configure. You learned about managing an App Runner service from the AWS management console and a variety of tools.