.NET and AWS App Runner
Tags: aws, dotnet, containers
Published: 2022-06-21 13:30:03

The newest entry into AWS container management is designed to help remove the amount of configuration and management that you must use when working with containers. [App Runner](https://aws.amazon.com/apprunner/) is a fully managed service that automatically builds and deploys the application as well creating the load balancer. App Runner also manages the scaling up and down based upon traffic. What do you, as a developer, have to do to get your container running in App Runner? Let’s take a look.

First, log into AWS and go to the App Runner console home. If you click on the _Services_ link you will find App Runner under the **Compute** section rather than the Containers section, even though its purpose is to easily run containers. Click on the _Create an App Runner Service_ button to get the Step 1 page as shown in Figure 1.

![Figure 1. Creating an App Runner service](https://billthevestguy.com/wp-content/uploads/2021/11/figure0519.png)_Figure 1. Creating an App Runner service_

The first section, **Source**, requires you to identify where the container image that you want to deploy is stored. You currently, at the time of this writing, can choose either a container registry, [Amazon ECR](https://aws.amazon.com/ecr/), or a source code repository. Since we have already loaded an image in ECR in the last post, let us move forward with this option by ensuring _Container registry_ and _Amazon ECR_ are selected, and then clicking the Browse button to bring up the image selection screen as shown in Figure 2.

![Figure 2 – Selecting a container image from ECR](https://billthevestguy.com/wp-content/uploads/2021/11/figure0520.png)_Figure 2 – Selecting a container image from ECR_

In this screen we selected the “prodotnetonaws” image repository that we created in the last post and the container image with the tag of “latest”.

Once you have completed the **Source** section, the next step is to determine the **Deployment settings** for your container. Here, your choices are to use the _Deployment trigger_ of **Manual**, which means that you must fire off each deployment yourself using the App Runner console or the AWS CLI, or **Automatic**, where App Runner watches your repository, deploying the new version of the container every time the image changes. In this case, we will choose _Manual_ so that we have full control of the deployment.

_**Warning**: When you have your deployment settings set to Automatic, every time the image is updated App Runner will trigger a deployment. This may be appropriate in a development or even test environment, but it is unlikely that you will want to use this in a production setting._

The last data that you need to enter on this page is to give App Runner an _ECR access role_ that App Runner will use to access ECR. In this case, we will select **Create new service** role and App Runner will pre-select a _Service name role_. Click the Next button when completed.

The next step is entitled **Configure service** and is designed to, surprisingly enough, help you configure the service. There are 5 sections on this page, _Service settings_, _Auto scaling_, _Health check_, _Security_, and _Tags_. The only section that is expanded is the first, all of the other sections need to be expanded before you see the options.

The first section, Service settings, with default settings can be seen in Figure 3.

![Figure 3 – Service settings in App Runner](https://billthevestguy.com/wp-content/uploads/2021/11/figure0521.png)_Figure 3 – Service settings in App Runner_

Here you set the _Service name_, select the _Virtual CPU & memory_, configure any optional _Environmental variables_ that you may need, and determine the TCP _Port_ that your service will use. If you are using the sample application that we loaded into ECR in the previous post you will need to change the port value from the default 8080 to port 80 so that it will serve the application we configured in the container. You also have the ability, under _Additional configuration_, to add a Start command which will be run on launch. This is generally left blank if you have configured the entry point within the container image. We gave the service the name “ProDotNetOnAWS-AR” and let all the rest of the settings in this section remain as default.

The next section is **Auto scaling**, and there are two major options, _Default configuration_ and _Custom configuration_, each of which provide the ability to set the auto scaling values as shown in Figure 4.

![Figure 4 – Setting the Auto scaling settings in App Runner](https://billthevestguy.com/wp-content/uploads/2021/11/figure0522.png)_Figure 4 – Setting the Auto scaling settings in App Runner_

The first of these auto scaling values is _Concurrency_. This value represents the maximum number of concurrent requests that an instance can process before App Runner scales up the service. The default configuration has this set at 100 requests that you can customize if using the _Custom configuration_ setting.

The next value is _Minimum size_, or the number of instances that App Runner provisions for your service, regardless of concurrent usage. This means that there may be times where some of these provisioned instances are not being used. You will be charged for the memory usage of all provisioned instances, but only for the CPU of those instances that are actually handling traffic. The default configuration for minimum size is set to 1 instance.

The last value is _Maximum size_. This value represents the maximum number of instances to which your service will scale; once your service reaches the maximum size there will be no additional scaling no matter the number of concurrent requests. The default configuration for maximum size is 25 instances.

If any of the default values do not match your need, you will need to create a custom configuration, which will give you control over each of these configuration values. To do this, select _Custom configuration_. This will display a drop-down that contains all of the App Runner configurations you have available (currently it will only have “DefaultConfiguration” because we have yet to define a different configuration) and an **Add new** button. Clicking this button will bring up the entry screen as shown in Figure 5.

![Figure 5 – Customizing auto scaling in App Runner](https://billthevestguy.com/wp-content/uploads/2021/11/figure0523.png)_Figure 5 – Customizing auto scaling in App Runner_

The next section after you configure auto scaling is **Health check**. The first value you set in this section is the _Timeout_, which describes the amount of time, in seconds, that the load balancer will wait for a health check response. The default timeout is 5 seconds. You also can set the _Interval_, which is the number of seconds between health checks of each instance and is defaulted to 10 seconds. You can also set the _Unhealthy_ and _Health_ thresholds, where the unhealthy threshold is the number of consecutive health check failures that means that an instance is unhealthy and needs to be recycled and the health threshold is the number of consecutive successful health checks necessary for an instance to be determined to be healthy. The default for these values is 5 requests for unhealthy and 1 request for healthy.

You next can assign an IAM role to the instance in the **Security** section. This IAM role will be used by the running application if it needs to communicate to other AWS services, such as S3 or a database server. The last section is **Tags**, where you can enter one or more tags to the App Runner service.

Once you have finished configuring the service, clicking the **Next** button will bring you to the review screen. Clicking the **Create and deploy** button on this screen will give the approval for App Runner to create the service, deploy the container image, and run it so that the application is available. You will be presented with the service details page and a banner that informs you that “Create service is in progress.” This process will take several minutes, and when completed will take you to the properties page as shown in Figure 6.

![Figure 6 – After App Runner is completed](https://billthevestguy.com/wp-content/uploads/2021/11/figure0524.png)_Figure 6 – After App Runner is completed_

Once the service is created and the status is displayed as _Running_, you will see a value for a _Default domain_ which represents the external-facing URL. Clicking on it will bring up the home page for your containerized sample application.

There are five tabs displayed under the domain, _Logs_, _Activity_, _Metrics_, _Configuration_, and _Custom Domain_. The Logs section displays the _Event_, _Deployment_, and _Application_ logs for this App Runner service. This is where you will be able to look for any problems during deployment or running of the container itself. You should be able, under the _Event log_ section, to see the listing of events from the service creation. The _Activity_ tab is very similar, in that it displays a list of activities taken by your service, such as creation and deployment.

The next tab, _Metrics_, tracks metrics related to the entire App Runner service. This where you will be able to see information on HTTP connections and requests, as well as being able to track the changes in the number of used and unused instances. By going into the sample application (at the default domain) and clicking around the site, you should see these values change and a graph become available that provides insight into these various activities.

The _Configuration_ tab allows you to view and edit many of the settings that we set in the original service creation. There are two different sections where you can make edits. The first is at the _Source and deployment_ level, where you can change the container source and whether the deployment will be manual or automatically happen when the repository is updated. The second section where you can make changes is at the _Configure service_ level where you are able to change your current settings for autoscaling, health check, and security.

The last tab on the details page is _Custom domain_. The default domain will always be available for your application; however, it is likely that you will want to have other domain names pointed to it – we certainly wouldn’t want to use https://SomeRandomValue.us-east-2.awsapprunner.com for our company’s web address. Linking domains is straightforward from the App Runner side. Simply click the **Link domain** button and input the custom domain that you would like to link, we of course used “prodotnetonaws.com”. Note that this does not include “www”, because this usage is currently not supported through the App Runner console. Once you enter the customer domain name, you will be presented the _Configure DNS_ page as shown in Figure 7.

![Figure 7 – Configuring a custom domain in App Runner](https://billthevestguy.com/wp-content/uploads/2021/11/figure0525.png)_Figure 7 – Configuring a custom domain in App Runner_
 
This page contains a set of certificate validation records that you need to add to your Domain Name System (DNS) so that App Runner can validate that you own or control the domain. You will also need to add CNAME records to your DNS to target the App Runner domain; you will need to add one record for the custom domain and another for the www subdomain if so desired. Once the certificate validation records are added to your DNS, the customer domain status will become _Active_ and traffic will be directed to your App Runner instance. This evaluation can take anywhere from minutes to up to 48 hours, depending upon your DNS provider.

Once your App Runner instance is up and running this first time, there are several actions that you can take on it as shown in the upper right corner of Figure 7. The first is the orange **Deploy** button. This will deploy the container from either the container or source code repository depending upon your configuration. You also can **Delete** the service, which is straightforward, as well as **Pause** the service. There are some things to consider when you pause your App Runner service. The first is that your application will lose all state – much as if you were deploying a new service. The second consideration is that if you are pausing your service because of a code defect, you will not be able to redeploy a new (presumably fixed) container without first resuming the service.