

# Deploying .NET Windows applications with Elastic Beanstalk
<a name="create_deploy_NET"></a>

**Check out the *.NET on AWS Developer Center***  
  
Have you stopped by our *.Net Developer Center*? It's our one stop shop for all things .NET on AWS.  
For more information see the [.NET on AWS Developer Center](https://aws.amazon.com/developer/language/net).

This chapter provides instructions for configuring and deploying your ASP.NET and .NET Core Windows web applications to AWS Elastic Beanstalk. Elastic Beanstalk makes it easy to deploy, manage, and scale your .NET (Windows) web applications using Amazon Web Services.

You can deploy your application in just a few minutes using the Elastic Beanstalk Command Line Interface (EB CLI) or by using the Elastic Beanstalk console. After you deploy your Elastic Beanstalk application, you can continue to use the EB CLI to manage your application and environment, or you can use the Elastic Beanstalk console, AWS CLI, or the APIs.

This chapter provides the following tutorials:
+ [QuickStart for .NET Core on Windows](dotnet-quickstart.md) — Step-by-step instructions to create and deploy a *Hello World* .NET Core Windows application using the EB CLI.
+ [QuickStart for ASP.NET](aspnet-quickstart.md) — Step-by-step instructions to create and deploy a *Hello World* ASP.NET application using the AWS Toolkit for Visual Studio.

If you need help with Windows .NET Core application development, there are several places you can go:
+  [.NET Development Forum](https://forums.aws.amazon.com/forum.jspa?forumID=61) — Post your questions and get feedback.
+ [.NET Developer Center](https://aws.amazon.com/net/) — One-stop shop for sample code, documentation, tools, and additional resources.
+ [AWS SDK for .NET Documentation](https://aws.amazon.com/documentation/sdk-for-net/) — Read about setting up the SDK and running code samples, features of the SDK, and detailed information about the API operations for the SDK.

**Note**  
This platform does not support worker environments. For details, see [Elastic Beanstalk worker environments](using-features-managing-env-tiers.md). 

**Topics**
+ [

# QuickStart: Deploy a .NET Core on Windows application to Elastic Beanstalk
](dotnet-quickstart.md)
+ [

# QuickStart: Deploy an ASP.NET application to Elastic Beanstalk
](aspnet-quickstart.md)
+ [

# Setting up your .NET development environment
](dotnet-devenv.md)
+ [

# Using the Elastic Beanstalk .NET Windows platform
](create_deploy_NET.container.console.md)
+ [

# Adding an Amazon RDS DB instance to your .NET application environment
](create_deploy_NET.rds.md)
+ [

# The AWS Toolkit for Visual Studio
](dotnet-toolkit.md)
+ [

# Migrating your on-premises .NET application to Elastic Beanstalk
](dotnet-onpremmigration.md)
+ [

# Recommendations for Windows Server retired components on Elastic Beanstalk
](dotnet-deprecation-recommendations.md)

# QuickStart: Deploy a .NET Core on Windows application to Elastic Beanstalk
<a name="dotnet-quickstart"></a>

This QuickStart tutorial walks you through the process of creating a .NET Core on Windows application and deploying it to an AWS Elastic Beanstalk environment.

**Not for production use**  
Examples are intended for demonstration only. Do not use example applications in production.

**Topics**
+ [

## Your AWS account
](#dotnet-quickstart-aws-account)
+ [

## Prerequisites
](#dotnet-quickstart-prereq)
+ [

## Step 1: Create a .NET Core on Windows application
](#dotnet-quickstart-create-app)
+ [

## Step 2: Run your application locally
](#dotnet-quickstart-run-local)
+ [

## Step 3: Deploy your .NET Core on Windows application with the EB CLI
](#dotnet-quickstart-deploy)
+ [

## Step 4: Run your application on Elastic Beanstalk
](#dotnet-quickstart-run-eb-ap)
+ [

## Step 5: Clean up
](#go-tutorial-cleanup)
+ [

## AWS resources for your application
](#dotnet-quickstart-eb-resources)
+ [

## Next steps
](#dotnet-quickstart-next-steps)
+ [

## Deploy with the Elastic Beanstalk console
](#dotnet-quickstart-console)

## Your AWS account
<a name="dotnet-quickstart-aws-account"></a>

If you're not already an AWS customer, you need to create an AWS account. Signing up enables you to access Elastic Beanstalk and other AWS services that you need.

If you already have an AWS account, you can move on to [Prerequisites](#dotnet-quickstart-prereq).

### Create an AWS account
<a name="dotnet-quickstart-aws-account-procedure"></a>

#### Sign up for an AWS account
<a name="sign-up-for-aws"></a>

If you do not have an AWS account, complete the following steps to create one.

**To sign up for an AWS account**

1. Open [https://portal.aws.amazon.com/billing/signup](https://portal.aws.amazon.com/billing/signup).

1. Follow the online instructions.

   Part of the sign-up procedure involves receiving a phone call or text message and entering a verification code on the phone keypad.

   When you sign up for an AWS account, an *AWS account root user* is created. The root user has access to all AWS services and resources in the account. As a security best practice, assign administrative access to a user, and use only the root user to perform [tasks that require root user access](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks).

AWS sends you a confirmation email after the sign-up process is complete. At any time, you can view your current account activity and manage your account by going to [https://aws.amazon.com/](https://aws.amazon.com/) and choosing **My Account**.

#### Create a user with administrative access
<a name="create-an-admin"></a>

After you sign up for an AWS account, secure your AWS account root user, enable AWS IAM Identity Center, and create an administrative user so that you don't use the root user for everyday tasks.

**Secure your AWS account root user**

1.  Sign in to the [AWS Management Console](https://console.aws.amazon.com/) as the account owner by choosing **Root user** and entering your AWS account email address. On the next page, enter your password.

   For help signing in by using root user, see [Signing in as the root user](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) in the *AWS Sign-In User Guide*.

1. Turn on multi-factor authentication (MFA) for your root user.

   For instructions, see [Enable a virtual MFA device for your AWS account root user (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) in the *IAM User Guide*.

**Create a user with administrative access**

1. Enable IAM Identity Center.

   For instructions, see [Enabling AWS IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) in the *AWS IAM Identity Center User Guide*.

1. In IAM Identity Center, grant administrative access to a user.

   For a tutorial about using the IAM Identity Center directory as your identity source, see [ Configure user access with the default IAM Identity Center directory](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html) in the *AWS IAM Identity Center User Guide*.

**Sign in as the user with administrative access**
+ To sign in with your IAM Identity Center user, use the sign-in URL that was sent to your email address when you created the IAM Identity Center user.

  For help signing in using an IAM Identity Center user, see [Signing in to the AWS access portal](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html) in the *AWS Sign-In User Guide*.

**Assign access to additional users**

1. In IAM Identity Center, create a permission set that follows the best practice of applying least-privilege permissions.

   For instructions, see [ Create a permission set](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) in the *AWS IAM Identity Center User Guide*.

1. Assign users to a group, and then assign single sign-on access to the group.

   For instructions, see [ Add groups](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) in the *AWS IAM Identity Center User Guide*.

## Prerequisites
<a name="dotnet-quickstart-prereq"></a>

To follow the procedures in this guide, you will need a command line terminal or shell to run commands. Commands are shown in listings preceded by a prompt symbol (>) and the name of the current directory, when appropriate.

```
C:\eb-project> this is a command
this is output
```

### EB CLI
<a name="dotnet-quickstart-prereq.ebcli"></a>

This tutorial uses the Elastic Beanstalk Command Line Interface (EB CLI). For details on installing and configuring the EB CLI, see [Install EB CLI with setup script (recommended)](eb-cli3.md#eb-cli3-install) and [Configure the EB CLI](eb-cli3-configuration.md).

### .NET Core on Windows
<a name="dotnet-quickstart-prereq.runtime"></a>

If you don't have the .NET SDK installed on your local machine, you can install it by following the [Download .NET](https://dotnet.microsoft.com/en-us/download) link on the [.NET documentation](https://learn.microsoft.com/en-us/dotnet/) website.

Verify your .NET SDK installation by running the following command.

```
C:\> dotnet --info
```

## Step 1: Create a .NET Core on Windows application
<a name="dotnet-quickstart-create-app"></a>

Create a project directory.

```
C:\> mkdir eb-dotnetcore
C:\> cd eb-dotnetcore
```

Next, create a sample Hello World RESTful web service application by running the following commands.

```
C:\eb-dotnetcore> dotnet new web --name HelloElasticBeanstalk
C:\eb-dotnetcore> cd HelloElasticBeanstalk
```

## Step 2: Run your application locally
<a name="dotnet-quickstart-run-local"></a>

Run the following command to run your application locally.

```
C:\eb-dotnetcore\HelloElasticBeasntalk> dotnet run
```

The output should look something like the following text.

```
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: https://localhost:7222
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:5228
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
      Content root path: C:\Users\Administrator\eb-dotnetcore\HelloElasticBeanstalk
```

**Note**  
The `dotnet` command selects a port at random when running the application locally. In this example the port is 5228. When you deploy the application to your Elastic Beanstalk environment, the application will run on port 5000.

Enter the URL address `http://localhost:port` in your web browser. For this specific example, the command is `http://localhost:5228`. The web browser should display “Hello World\$1”.

## Step 3: Deploy your .NET Core on Windows application with the EB CLI
<a name="dotnet-quickstart-deploy"></a>

Run the following commands to create an Elastic Beanstalk environment for this application.

 

**To create an environment and deploy your .NET Core on Windows application**

1. Run the following commands in the `HelloElasticBeanstalk` directory to publish and zip your application.

   ```
   C:\eb-dotnetcore\HelloElasticBeasntalk> dotnet publish -o site
   C:\eb-dotnetcore\HelloElasticBeasntalk> cd site
   C:\eb-dotnetcore\HelloElasticBeasntalk\site> Compress-Archive -Path * -DestinationPath ../site.zip
   C:\eb-dotnetcore\HelloElasticBeasntalk\site> cd ..
   ```

1. Create a new file in the `HelloElasticBeanstalk` called `aws-windows-deployment-manifest.json` with the following contents: 

   ```
   {
       "manifestVersion": 1,
       "deployments": {
           "aspNetCoreWeb": [
           {
               "name": "test-dotnet-core",
               "parameters": {
                   "appBundle": "site.zip",
                   "iisPath": "/",
                   "iisWebSite": "Default Web Site"
               }
           }
           ]
       }
   }
   ```

1. Initialize your EB CLI repository with the **eb init** command.

   ```
   C:\eb-dotnetcore\HelloElasticBeasntalk> eb init -p iis dotnet-windows-server-tutorial --region us-east-2
   ```

   This command creates an application named `dotnet-windows-server-tutorial` and configures your local repository to create environments with the latest Windows server platform version.

1. Create an environment and deploy your application to it with **eb create**. Elastic Beanstalk automatically builds a zip file for your application and starts it on port 5000.

   ```
   C:\eb-dotnetcore\HelloElasticBeasntalk> eb create dotnet-windows-server-env
   ```

   It takes about five minutes for Elastic Beanstalk to create your environment.

## Step 4: Run your application on Elastic Beanstalk
<a name="dotnet-quickstart-run-eb-ap"></a>

When the process to create your environment completes, open your website with **eb open**.

```
C:\eb-dotnetcore\HelloElasticBeasntalk> eb open
```

Congratulations\$1 You've deployed a .NET Core on Windows application with Elastic Beanstalk\$1 This opens a browser window using the domain name created for your application.

## Step 5: Clean up
<a name="go-tutorial-cleanup"></a>

You can terminate your environment when you finish working with your application. Elastic Beanstalk terminates all AWS resources associated with your environment.

To terminate your Elastic Beanstalk environment with the EB CLI run the following command.

```
C:\eb-dotnetcore\HelloElasticBeasntalk> eb terminate
```

## AWS resources for your application
<a name="dotnet-quickstart-eb-resources"></a>

You just created a single instance application. It serves as a straightforward sample application with a single EC2 instance, so it doesn't require load balancing or auto scaling. For single instance applications Elastic Beanstalk creates the following AWS resources:
+ **EC2 instance** – An Amazon EC2 virtual machine configured to run web apps on the platform you choose.

  Each platform runs a different set of software, configuration files, and scripts to support a specific language version, framework, web container, or combination thereof. Most platforms use either Apache or nginx as a reverse proxy that processes web traffic in front of your web app, forwards requests to it, serves static assets, and generates access and error logs.
+ **Instance security group** – An Amazon EC2 security group configured to allow incoming traffic on port 80. This resource lets HTTP traffic from the load balancer reach the EC2 instance running your web app. By default, traffic is not allowed on other ports.
+ **Amazon S3 bucket** – A storage location for your source code, logs, and other artifacts that are created when you use Elastic Beanstalk.
+ **Amazon CloudWatch alarms** – Two CloudWatch alarms that monitor the load on the instances in your environment and are triggered if the load is too high or too low. When an alarm is triggered, your Auto Scaling group scales up or down in response.
+ **CloudFormation stack** – Elastic Beanstalk uses CloudFormation to launch the resources in your environment and propagate configuration changes. The resources are defined in a template that you can view in the [CloudFormation console](https://console.aws.amazon.com/cloudformation).
+  **Domain name** – A domain name that routes to your web app in the form **subdomain*.*region*.elasticbeanstalk.com*. 

Elastic Beanstalk manages all of these resources. When you terminate your environment, Elastic Beanstalk terminates all the resources that it contains.

## Next steps
<a name="dotnet-quickstart-next-steps"></a>

After you have an environment running an application, you can deploy a new version of the application or a different application at any time. Deploying a new application version is very quick because it doesn't require provisioning or restarting EC2 instances. You can also explore your new environment using the Elastic Beanstalk console. For detailed steps, see [Explore your environment](GettingStarted.md#GettingStarted.Explore) in the *Getting started* chapter of this guide.

**Try more tutorials**  
If you'd like to try other tutorials with different example applications, see [QuickStart for ASP.NET](aspnet-quickstart.md).

After you deploy a sample application or two and are ready to start developing and running .NET Core on Windows applications locally, see [Setting up your .NET development environment](dotnet-devenv.md) 

## Deploy with the Elastic Beanstalk console
<a name="dotnet-quickstart-console"></a>

You can also use the Elastic Beanstalk console to launch the sample application. For detailed steps, see [Create an example application](GettingStarted.md#GettingStarted.CreateApp) in the *Getting started* chapter of this guide.

# QuickStart: Deploy an ASP.NET application to Elastic Beanstalk
<a name="aspnet-quickstart"></a>

This QuickStart tutorial walks you through the process of creating a ASP.NET application and deploying it to an AWS Elastic Beanstalk environment.

**Not for production use**  
Examples are intended for demonstration only. Do not use example applications in production.

**Topics**
+ [

## Your AWS account
](#aspnet-quickstart-aws-account)
+ [

## Prerequisites
](#aspnet-quickstart-prereq)
+ [

## Step 1: Create a ASP.NET application
](#aspnet-quickstart-create-app)
+ [

## Step 2: Run your application locally
](#aspnet-quickstart-run-local)
+ [

## Step 3: Deploy your ASP.NET application with the AWS Toolkit for Visual Studio
](#aspnet-quickstart-deploy)
+ [

## Step 4: Run your application on Elastic Beanstalk
](#aspnet-quickstart-run-eb-ap)
+ [

## Step 5: Clean up
](#aspnet-quickstart-cleanup)
+ [

## AWS resources for your application
](#aspnet-quickstart-eb-resources)
+ [

## Next steps
](#aspnet-quickstart-next-steps)
+ [

## Deploy with the Elastic Beanstalk console
](#aspnet-quickstart-console)

## Your AWS account
<a name="aspnet-quickstart-aws-account"></a>

If you're not already an AWS customer, you need to create an AWS account. Signing up enables you to access Elastic Beanstalk and other AWS services that you need.

If you already have an AWS account, you can move on to [Prerequisites](#aspnet-quickstart-prereq).

### Create an AWS account
<a name="aspnet-quickstart-aws-account-procedure"></a>

#### Sign up for an AWS account
<a name="sign-up-for-aws"></a>

If you do not have an AWS account, complete the following steps to create one.

**To sign up for an AWS account**

1. Open [https://portal.aws.amazon.com/billing/signup](https://portal.aws.amazon.com/billing/signup).

1. Follow the online instructions.

   Part of the sign-up procedure involves receiving a phone call or text message and entering a verification code on the phone keypad.

   When you sign up for an AWS account, an *AWS account root user* is created. The root user has access to all AWS services and resources in the account. As a security best practice, assign administrative access to a user, and use only the root user to perform [tasks that require root user access](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks).

AWS sends you a confirmation email after the sign-up process is complete. At any time, you can view your current account activity and manage your account by going to [https://aws.amazon.com/](https://aws.amazon.com/) and choosing **My Account**.

#### Create a user with administrative access
<a name="create-an-admin"></a>

After you sign up for an AWS account, secure your AWS account root user, enable AWS IAM Identity Center, and create an administrative user so that you don't use the root user for everyday tasks.

**Secure your AWS account root user**

1.  Sign in to the [AWS Management Console](https://console.aws.amazon.com/) as the account owner by choosing **Root user** and entering your AWS account email address. On the next page, enter your password.

   For help signing in by using root user, see [Signing in as the root user](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) in the *AWS Sign-In User Guide*.

1. Turn on multi-factor authentication (MFA) for your root user.

   For instructions, see [Enable a virtual MFA device for your AWS account root user (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) in the *IAM User Guide*.

**Create a user with administrative access**

1. Enable IAM Identity Center.

   For instructions, see [Enabling AWS IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) in the *AWS IAM Identity Center User Guide*.

1. In IAM Identity Center, grant administrative access to a user.

   For a tutorial about using the IAM Identity Center directory as your identity source, see [ Configure user access with the default IAM Identity Center directory](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html) in the *AWS IAM Identity Center User Guide*.

**Sign in as the user with administrative access**
+ To sign in with your IAM Identity Center user, use the sign-in URL that was sent to your email address when you created the IAM Identity Center user.

  For help signing in using an IAM Identity Center user, see [Signing in to the AWS access portal](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html) in the *AWS Sign-In User Guide*.

**Assign access to additional users**

1. In IAM Identity Center, create a permission set that follows the best practice of applying least-privilege permissions.

   For instructions, see [ Create a permission set](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) in the *AWS IAM Identity Center User Guide*.

1. Assign users to a group, and then assign single sign-on access to the group.

   For instructions, see [ Add groups](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) in the *AWS IAM Identity Center User Guide*.

## Prerequisites
<a name="aspnet-quickstart-prereq"></a>

This QuickStart tutorial walks you through creating a "Hello World" application and deploying it to an Elastic Beanstalk environment with Visual Studio and the AWS Toolkit for Visual Studio.

### Visual Studio
<a name="aspnet-quickstart-prereq.vs"></a>

To download and install Visual Studio follow the instructions on the Visual Studio [download page](https://visualstudio.microsoft.com/downloads/). This example uses Visual Studio 2022. During the Visual Studio installation select these specific items:
+ On the **Workloads** tab — select **ASP.NET and web development**.
+ On the **Individual components** tab — select **.NET Framework 4.8 development tools** and **.NET Framework project and item templates**.

### AWS Toolkit for Visual Studio
<a name="aspnet-quickstart-prereq.aws-vs-tk"></a>

To download and set up AWS Toolkit for Visual Studio follow the instructions in the [Getting started](https://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/getting-set-up.html) topic of the AWS Toolkit for Visual Studio User Guide. 

## Step 1: Create a ASP.NET application
<a name="aspnet-quickstart-create-app"></a>

Next, create an application that you'll deploy to an Elastic Beanstalk environment. We'll create a "Hello World" ASP.NET web application.

**To create an ASP.NET application**

1. Launch Visual Studio. In the **File** menu, select **New**, then **Project**.

1. The **Create a new project** dialog box displays. Select **ASP.NET web application (.NET Framework)**, then select **Next**.

1. On the **Configure your new project** dialog, enter `eb-aspnet` for your **Project name**. From the **Framework** dropdown menu select **.NET Framework 4.8**, then select **Create**.

   Note the project directory. In this example, the project directory is `C:\Users\Administrator\source\repos\eb-aspnet\eb-aspnet`.

1. The **Create a new ASP.NET Web Application** dialogue displays. Select the **Empty** template. Next select **Create**.

   At this point, you have created an empty ASP.NET web application project using Visual Studio. Next, we'll create a web form that will serve as the entry point for the ASP.NET web application.

1. From the **Project** menu, select **Add New Item**. On the **Add New Item** page, select **Web Form** and name it `Default.aspx`. Next select **Add**.

1. Add the following to `Default.aspx:`

   ```
   <%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="eb_aspnet.Default" %>
   
   <!DOCTYPE html>
   
   <html xmlns="https://www.w3.org/1999/xhtml">
   <head runat="server">
       <title>Hello Elastic Beanstalk!</title>
   </head>
   <body>
       <form id="body" runat="server">
           <div>
               Hello Elastic Beanstalk! This is an ASP.NET on Windows Server application.
           </div>
       </form>
   </body>
   </html>
   ```

## Step 2: Run your application locally
<a name="aspnet-quickstart-run-local"></a>

In Visual Studio, from the **Debug** menu select **Start Debugging** to run your application locally. The page should display "Hello Elastic Beanstalk\$1 This is an ASP.NET on Windows Server application."

## Step 3: Deploy your ASP.NET application with the AWS Toolkit for Visual Studio
<a name="aspnet-quickstart-deploy"></a>

Follow these steps to create an Elastic Beanstalk environment and deploy your new application to it.

**To create an environment and deploy your ASP.NET application**

1. In **Solution Explorer**, right-click your application, then select **Publish to AWS Elastic Beanstalk**.

1. Choose a name for your new Elastic Beanstalk application and environment.

1. Beyond this point, you may proceed with the defaults provided by Elastic Beanstalk or modify any of the options and settings to your liking.

1. On the **Review** page, select **Deploy**. This will package your ASP.NET web application and deploy it to Elastic Beanstalk.

   It takes about five minutes for Elastic Beanstalk to create your environment. The Elastic Beanstalk deployment feature will monitor your environment until it becomes available with the newly deployed code. On the **Env:<**environment name**>** tab, you'll see the status for your environment.

## Step 4: Run your application on Elastic Beanstalk
<a name="aspnet-quickstart-run-eb-ap"></a>

When the process to create your environment completes, the **Env:<**environment name**>** tab, displays information about your environment and application, including the domain URL to launch your application. Select this URL on this tab or copy and paste it into your web browser.

Congratulations\$1 You've deployed a ASP.NET application with Elastic Beanstalk\$1

## Step 5: Clean up
<a name="aspnet-quickstart-cleanup"></a>

When you finish working with your application, you can terminate your environment in the AWS Toolkit for Visual Studio.

**To terminate your environment**

1. Expand the Elastic Beanstalk node and the application node in **AWS Explorer**. Right-click your application environment and select **Terminate Environment**.

1. When prompted, select **Yes** to confirm that you want to terminate the environment. It will take a few minutes for Elastic Beanstalk to terminate the AWS resources running in the environment.

## AWS resources for your application
<a name="aspnet-quickstart-eb-resources"></a>

You just created a single instance application. It serves as a straightforward sample application with a single EC2 instance, so it doesn't require load balancing or auto scaling. For single instance applications Elastic Beanstalk creates the following AWS resources:
+ **EC2 instance** – An Amazon EC2 virtual machine configured to run web apps on the platform you choose.

  Each platform runs a different set of software, configuration files, and scripts to support a specific language version, framework, web container, or combination thereof. Most platforms use either Apache or nginx as a reverse proxy that processes web traffic in front of your web app, forwards requests to it, serves static assets, and generates access and error logs.
+ **Instance security group** – An Amazon EC2 security group configured to allow incoming traffic on port 80. This resource lets HTTP traffic from the load balancer reach the EC2 instance running your web app. By default, traffic is not allowed on other ports.
+ **Amazon S3 bucket** – A storage location for your source code, logs, and other artifacts that are created when you use Elastic Beanstalk.
+ **Amazon CloudWatch alarms** – Two CloudWatch alarms that monitor the load on the instances in your environment and are triggered if the load is too high or too low. When an alarm is triggered, your Auto Scaling group scales up or down in response.
+ **CloudFormation stack** – Elastic Beanstalk uses CloudFormation to launch the resources in your environment and propagate configuration changes. The resources are defined in a template that you can view in the [CloudFormation console](https://console.aws.amazon.com/cloudformation).
+  **Domain name** – A domain name that routes to your web app in the form **subdomain*.*region*.elasticbeanstalk.com*. 

Elastic Beanstalk manages all of these resources. When you terminate your environment, Elastic Beanstalk terminates all the resources that it contains.

## Next steps
<a name="aspnet-quickstart-next-steps"></a>

After you have an environment running an application, you can deploy a new version of the application or a different application at any time. Deploying a new application version is very quick because it doesn't require provisioning or restarting EC2 instances. You can also explore your new environment using the Elastic Beanstalk console. For detailed steps, see [Explore your environment](GettingStarted.md#GettingStarted.Explore) in the *Getting started* chapter of this guide.

**Try more tutorials**  
If you'd like to try other tutorials with different example applications, see [QuickStart for .NET Core on Windows](dotnet-quickstart.md).

After you deploy a sample application or two and are ready to start developing and running ASP.NET applications locally, see [Setting up your .NET development environment](dotnet-devenv.md) 

## Deploy with the Elastic Beanstalk console
<a name="aspnet-quickstart-console"></a>

You can also use the Elastic Beanstalk console to launch the sample application. For detailed steps, see [Create an example application](GettingStarted.md#GettingStarted.CreateApp) in the *Getting started* chapter of this guide.

# Setting up your .NET development environment
<a name="dotnet-devenv"></a>

This topic provides instructions to set up a .NET Windows development environment to test your application locally prior to deploying it to AWS Elastic Beanstalk. It also references websites that provide installation instructions for useful tools.

**Topics**
+ [

## Installing an IDE
](#dotnet-devenv-ide)
+ [

## Installing the AWS Toolkit for Visual Studio
](#dotnet-devenv-toolkit)

If you need to manage AWS resources from within your application, install the AWS SDK for .NET. For example, you can use Amazon S3 to store and retrieve data.

With the AWS SDK for .NET, you can get started in minutes with a single, downloadable package complete with Visual Studio project templates, the AWS .NET library, C\$1 code samples, and documentation. Practical examples are provided in C\$1 for how to use the libraries to build applications. Online video tutorials and reference documentation are provided to help you learn how to use the libraries and code samples.

Visit the [AWS SDK for .NET homepage](https://aws.amazon.com/sdk-for-net/) for more information and installation instructions.

## Installing an IDE
<a name="dotnet-devenv-ide"></a>

Integrated development environments (IDEs) provide a wide range of features that facilitate application development. If you haven't used an IDE for .NET development, try Visual Studio Community to get started.

Visit the [Visual Studio Community](https://www.visualstudio.com/vs/community/) page to download and install Visual Studio Community.

## Installing the AWS Toolkit for Visual Studio
<a name="dotnet-devenv-toolkit"></a>

The [AWS Toolkit for Visual Studio](dotnet-toolkit.md) is an open source plug-in for the Visual Studio IDE that makes it easier for developers to develop, debug, and deploy .NET applications using AWS. Visit the [Toolkit for Visual Studio homepage](https://aws.amazon.com/visualstudio/) for installation instructions.

# Using the Elastic Beanstalk .NET Windows platform
<a name="create_deploy_NET.container.console"></a>

This topic describes how to configure, build, and run your ASP.NET and .NET Core Windows web applications on Elastic Beanstalk.

AWS Elastic Beanstalk supports a number of platforms for different versions of the .NET programming framework and Windows Server. See [.NET on Windows Server with IIS](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net) in the *AWS Elastic Beanstalk Platforms* document for a full list.

Elastic Beanstalk provides [configuration options](command-options.md) that you can use to customize the software that runs on the EC2 instances in your Elastic Beanstalk environment. You can configure environment variables needed by your application, enable log rotation to Amazon S3, and set .NET framework settings.

Configuration options are available in the Elastic Beanstalk console for [modifying the configuration of a running environment](environment-configuration-methods-after.md). To avoid losing your environment's configuration when you terminate it, you can use [saved configurations](environment-configuration-savedconfig.md) to save your settings and later apply them to another environment.

To save settings in your source code, you can include [configuration files](ebextensions.md). Settings in configuration files are applied every time you create an environment or deploy your application. You can also use configuration files to install packages, run scripts, and perform other instance customization operations during deployments.

Settings applied in the Elastic Beanstalk console override the same settings in configuration files, if they exist. This lets you have default settings in configuration files, and override them with environment-specific settings in the console. For more information about precedence, and other methods of changing settings, see [Configuration options](command-options.md).

## Configuring your .NET environment in the Elastic Beanstalk console
<a name="dotnet-console"></a>

You can use the Elastic Beanstalk console to enable log rotation to Amazon S3, configure variables that your application can read from the environment, and change .NET framework settings.

**To configure your .NET environment in the Elastic Beanstalk console**

1. Open the [Elastic Beanstalk console](https://console.aws.amazon.com/elasticbeanstalk), and in the **Regions** list, select your AWS Region.

1. In the navigation pane, choose **Environments**, and then choose the name of your environment from the list.

1. In the navigation pane, choose **Configuration**.

1. In the **Updates, monitoring, and logging** configuration category, choose **Edit**.

### Container options
<a name="dotnet-console-framework"></a>
+ **Target .NET runtime** – Set to `2.0` to run CLR v2.
+ **Enable 32-bit applications** – Set to `True` to run 32-bit applications.

### Log options
<a name="dotnet-console-logs"></a>

The Log Options section has two settings:
+ **Instance profile** – Specifies the instance profile that has permission to access the Amazon S3 bucket associated with your application.
+ **Enable log file rotation to Amazon S3** – Specifies whether log files for your application's Amazon EC2 instances are copied to the Amazon S3 bucket associated with your application.

### Environment properties
<a name="dotnet-console-properties"></a>

The **Environment Properties** section lets you specify environment configuration settings on the Amazon EC2 instances that are running your application. These settings are passed in as key-value pairs to the application. Use `System.GetEnvironmentVariable` to read them. Identical keys can exist in both `web.config` and as environment properties. Use the `System.Configuration` namespace to read values from `web.config`.

```
NameValueCollection appConfig = ConfigurationManager.AppSettings;
string endpoint = appConfig["API_ENDPOINT"];
```

See [Environment variables and other software settings](environments-cfg-softwaresettings.md) for more information.

## The aws:elasticbeanstalk:container:dotnet:apppool namespace
<a name="dotnet-namespaces"></a>

You can use a [configuration file](ebextensions.md) to set configuration options and perform other instance configuration tasks during deployments. Configuration options can be [platform specific](command-options-specific.md) or apply to [all platforms](command-options-general.md) in the Elastic Beanstalk service as a whole. Configuration options are organized into *namespaces*.

The .NET platform defines options in the `aws:elasticbeanstalk:container:dotnet:apppool` namespace that you can use to configure the .NET runtime.

The following example configuration file shows settings for each of the options available in this namespace:

**Example .ebextensions/dotnet-settings.config**  

```
option_settings:
  aws:elasticbeanstalk:container:dotnet:apppool:
    Target Runtime: 2.0
    Enable 32-bit Applications: True
```

Elastic Beanstalk provides many configuration options for customizing your environment. In addition to configuration files, you can also set configuration options using the console, saved configurations, the EB CLI, or the AWS CLI. See [Configuration options](command-options.md) for more information.

# Migrating across major versions of the Elastic Beanstalk Windows server platform
<a name="dotnet-v2migration"></a>

AWS Elastic Beanstalk has had several major versions of its Windows Server platform. This page covers the main improvements for each major version, and what to consider before you migrate to a later version.

The Windows Server platform is currently at version 2 (v2). If your application uses any Windows Server platform version earlier than v2, we recommend that you migrate to v2.

## What's new in major versions of the Windows server platform
<a name="dotnet-v2migration.diffs"></a>

### Windows server platform V2
<a name="dotnet-v2migration.diffs.v2"></a>

Version 2 (v2) of the Elastic Beanstalk Windows Server platform was [released in February 2019](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2019-02-21-windows-v2.html). V2 brings the behavior of the Windows Server platform closer to that of the Elastic Beanstalk Linux-based platforms in several important ways. V2 is fully backward compatible with v1, making migration from v1 easy.

The Windows Server platform now supports the following:
+ *Versioning* – Each release gets a new version number, and you can refer to past versions (that are still available to you) when creating and managing environments.
+ *Enhanced health* – For details, see [Enhanced health reporting and monitoring in Elastic Beanstalk](health-enhanced.md).
+ *Immutable* and *Rolling with an Additional Batch* deployments – For details about deployment policies, see [Deploying applications to Elastic Beanstalk environments](using-features.deploy-existing-version.md).
+ *Immutable updates* – For details about update types, see [Configuration changes](environments-updating.md).
+ *Managed platform updates* – For details, see [Managed platform updates](environment-platform-update-managed.md).

**Note**  
The new deployment and update features depend on enhanced health. Enable enhanced health to use them. For details, see [Enabling Elastic Beanstalk enhanced health reporting](health-enhanced-enable.md).

### Windows server platform V1
<a name="dotnet-v2migration.diffs.v1"></a>

Version 1.0.0 (v1) of the Elastic Beanstalk Windows Server platform was released in October 2015. This version changes the order in which Elastic Beanstalk processes commands in [configuration files](ebextensions.md) during environment creation and updates.

Previous platform versions don't have a version number in the solution stack name:
+ 64bit Windows Server 2012 R2 running IIS 8.5
+ 64bit Windows Server Core 2012 R2 running IIS 8.5
+ 64bit Windows Server 2012 running IIS 8
+ 64bit Windows Server 2008 R2 running IIS 7.5

In earlier versions, the processing order for configuration files is inconsistent. During environment creation, `Container Commands` run after the application source is deployed to IIS. During a deployment to a running environment, container commands run before the new version is deployed. During a scale up, configuration files are not processed at all.

In addition to this, IIS starts up before container commands run. This behavior has led some customers to implement workarounds in container commands, pausing the IIS server before commands run, and starting it again after they complete.

Version 1 fixes the inconsistency and brings the behavior of the Windows Server platform closer to that of the Elastic Beanstalk Linux-based platforms. In the v1 platform, Elastic Beanstalk always runs container commands before starting the IIS server.

The v1 platform solution stacks have a `v1` after the Windows Server version:
+ 64bit Windows Server 2012 R2 v1.1.0 running IIS 8.5
+ 64bit Windows Server Core 2012 R2 v1.1.0 running IIS 8.5
+ 64bit Windows Server 2012 v1.1.0 running IIS 8
+ 64bit Windows Server 2008 R2 v1.1.0 running IIS 7.5

Additionally, the v1 platform extracts the contents of your application source bundle to `C:\staging\` before running container commands. After container commands complete, the contents of this folder are compressed into a .zip file and deployed to IIS. This workflow allows you to modify the contents of your application source bundle with commands or a script before deployment.

## Migrating from earlier major versions of the Windows server platform
<a name="dotnet-v2migration.migration"></a>

Read this section for migration considerations before you update your environment. To update your environment's platform to a newer version, see [Updating your Elastic Beanstalk environment's platform version](using-features.platform.upgrade.md).

### From V1 to V2
<a name="dotnet-v2migration.migration.fromv1"></a>

The Windows Server platform v2 doesn't support .NET Core 1.x and 2.0. If you're migrating your application from Windows Server v1 to v2, and your application uses one of these .NET Core versions, update your application to a .NET Core version that v2 supports. For a list of supported versions, see [.NET on Windows Server with IIS](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net) in the *AWS Elastic Beanstalk Platforms*.

If your application uses a custom Amazon Machine Image (AMI), create a new custom AMI based on a Windows Server platform v2 AMI. To learn more, see [Using a custom Amazon machine image (AMI) in your Elastic Beanstalk environment](using-features.customenv.md).

**Note**  
The deployment and update features that are new to Windows Server v2 depend on enhanced health. When you migrate an environment to v2, enhanced health is disabled. Enable it to use these features. For details, see [Enabling Elastic Beanstalk enhanced health reporting](health-enhanced-enable.md).

### From pre-V1
<a name="dotnet-v2migration.migration.fromv0"></a>

In addition to considerations for migrating from v1, if you're migrating your application from a Windows Server solution stack that's earlier than v1, and you currently use container commands, remove any commands that you added to work around the processing inconsistencies when you migrate to a newer version. Starting with v1, container commands are guaranteed to run completely before the application source that is deployed and before IIS starts. This enables you to make any changes to the source in `C:\staging` and modify IIS configuration files during this step without issue.

For example, you can use the AWS CLI to download a DLL file to your application source from Amazon S3:

`.ebextensions\copy-dll.config`

```
container_commands:
  copy-dll:
    command: aws s3 cp s3://amzn-s3-demo-bucket/dlls/large-dll.dll .\lib\
```

For more information on using configuration files, see [Advanced environment customization with configuration files (`.ebextensions`)](ebextensions.md).

# Running multiple applications and ASP.NET core applications with a deployment manifest
<a name="dotnet-manifest"></a>

You can use a deployment manifest to tell Elastic Beanstalk how to deploy your application. By using this method, you don't need to use `MSDeploy` to generate a source bundle for a single ASP.NET application that runs at the root path of your website. Rather, you can use a manifest file to run multiple applications at different paths. Or, alternatively, you can tell Elastic Beanstalk to deploy and run the app with ASP.NET Core. You can also use a deployment manifest to configure an application pool where to run your applications.

Deployment manifests add support for [.NET Core applications](#dotnet-manifest-dotnetcore) to Elastic Beanstalk. You can deploy a .NET Framework application without a deployment manifest. However, .NET Core applications require a deployment manifest to run on Elastic Beanstalk. When you use a deployment manifest, you create a site archive for each application, and then bundle the site archives in a second ZIP archive that contains the deployment manifest.

Deployment manifests also add the ability to [run multiple applications at different paths](#dotnet-manifest-multiapp). A deployment manifest defines an array of deployment targets, each with a site archive and a path at which IIS should run it. For example, you could run a web API at the `/api` path to serve asynchronous requests, and a web app at the root path that consumes the API.

You can use a deployment manifest to [configure IIS websites with custom bindings and physical paths](#dotnet-manifest-websites). This allows you to set up websites that listen on specific ports or host names before deploying your applications.

You can also use a deployment manifest to [run multiple applications using application pools in IIS or Kestrel](#dotnet-manifest-apppool). You can configure an application pool to restart your applications periodically, run 32-bit applications, or use a specific version of the .NET Framework runtime.

For full customization, you can [write your own deployment scripts](#dotnet-manifest-custom) in Windows PowerShell and tell Elastic Beanstalk which scripts to run to install, uninstall, and restart your application.

Deployment manifests and related features require a Windows Server platform [version 1.2.0 or newer](dotnet-v2migration.md).

For detailed information about all available configuration options, properties, and advanced features like skipping IIS resets, see the [deployment manifest schema reference](dotnet-manifest-schema.md).

**Topics**
+ [

## .NET core apps
](#dotnet-manifest-dotnetcore)
+ [

## Run multiple applications
](#dotnet-manifest-multiapp)
+ [

## Configure IIS websites
](#dotnet-manifest-websites)
+ [

## Using Application Request Routing (ARR)
](#dotnet-manifest-arr)
+ [

## Configure application pools
](#dotnet-manifest-apppool)
+ [

## Define custom deployments
](#dotnet-manifest-custom)
+ [

# Deployment manifest schema reference
](dotnet-manifest-schema.md)

## .NET core apps
<a name="dotnet-manifest-dotnetcore"></a>

You can use a deployment manifest to run .NET Core applications on Elastic Beanstalk. .NET Core is a cross-platform version of .NET that comes with a command line tool (`dotnet`). You can use it to generate an application, run it locally, and prepare it for publishing.

To run a .NET Core application on Elastic Beanstalk, you can run `dotnet publish` and package the output in a ZIP archive, not including any containing directories. Place the site archive in a source bundle with a deployment manifest with a deployment target of type `aspNetCoreWeb`.

The following deployment manifest runs a .NET Core application from a site archive named `dotnet-core-app.zip` at the root path.

**Example aws-windows-deployment-manifest.json - .NET core**  

```
{
  "manifestVersion": 1,
  "deployments": {
    "aspNetCoreWeb": [
      {
        "name": "my-dotnet-core-app",
        "parameters": {
          "archive": "dotnet-core-app.zip",
          "iisPath": "/"
        }
      }
    ]
  }
}
```

Bundle the manifest and site archive in a ZIP archive to create a source bundle.

**Example dotnet-core-bundle.zip**  

```
.
|-- aws-windows-deployment-manifest.json
`-- dotnet-core-app.zip
```

The site archive contains the compiled application code, dependencies, and `web.config` file.

**Example dotnet-core-app.zip**  

```
.
|-- Microsoft.AspNetCore.Hosting.Abstractions.dll
|-- Microsoft.AspNetCore.Hosting.Server.Abstractions.dll
|-- Microsoft.AspNetCore.Hosting.dll
|-- Microsoft.AspNetCore.Http.Abstractions.dll
|-- Microsoft.AspNetCore.Http.Extensions.dll
|-- Microsoft.AspNetCore.Http.Features.dll
|-- Microsoft.AspNetCore.Http.dll
|-- Microsoft.AspNetCore.HttpOverrides.dll
|-- Microsoft.AspNetCore.Server.IISIntegration.dll
|-- Microsoft.AspNetCore.Server.Kestrel.dll
|-- Microsoft.AspNetCore.WebUtilities.dll
|-- Microsoft.Extensions.Configuration.Abstractions.dll
|-- Microsoft.Extensions.Configuration.EnvironmentVariables.dll
|-- Microsoft.Extensions.Configuration.dll
|-- Microsoft.Extensions.DependencyInjection.Abstractions.dll
|-- Microsoft.Extensions.DependencyInjection.dll
|-- Microsoft.Extensions.FileProviders.Abstractions.dll
|-- Microsoft.Extensions.FileProviders.Physical.dll
|-- Microsoft.Extensions.FileSystemGlobbing.dll
|-- Microsoft.Extensions.Logging.Abstractions.dll
|-- Microsoft.Extensions.Logging.dll
|-- Microsoft.Extensions.ObjectPool.dll
|-- Microsoft.Extensions.Options.dll
|-- Microsoft.Extensions.PlatformAbstractions.dll
|-- Microsoft.Extensions.Primitives.dll
|-- Microsoft.Net.Http.Headers.dll
|-- System.Diagnostics.Contracts.dll
|-- System.Net.WebSockets.dll
|-- System.Text.Encodings.Web.dll
|-- dotnet-core-app.deps.json
|-- dotnet-core-app.dll
|-- dotnet-core-app.pdb
|-- dotnet-core-app.runtimeconfig.json
`-- web.config
```

## Run multiple applications
<a name="dotnet-manifest-multiapp"></a>

You can run multiple applications with a deployment manifest by defining multiple deployment targets.

The following deployment manifest configures two .NET Core applications. The `WebApiSampleApp` application implements a simple web API and serves asynchronous requests at the `/api` path. The `DotNetSampleApp` application is a web application that serves requests at the root path.

**Example aws-windows-deployment-manifest.json - multiple apps**  

```
{
  "manifestVersion": 1,
  "deployments": {
    "aspNetCoreWeb": [
      {
        "name": "WebAPISample",
        "parameters": {
          "appBundle": "WebApiSampleApp.zip",
          "iisPath": "/api"
        }
      },
      {
        "name": "DotNetSample",
        "parameters": {
          "appBundle": "DotNetSampleApp.zip",
          "iisPath": "/"
        }
      }
    ]
  }
}
```

A sample application with multiple applications is available here:
+ **Deployable source bundle** - [dotnet-multiapp-sample-bundle-v2.zip](samples/dotnet-multiapp-sample-bundle-v2.zip)
+ **Source code** - [dotnet-multiapp-sample-source-v2.zip](samples/dotnet-multiapp-sample-source-v2.zip)

## Configure IIS websites
<a name="dotnet-manifest-websites"></a>

You can configure IIS websites with custom bindings and physical paths using the deployment manifest. This is useful when you need to set up websites that listen on specific ports, use custom host names, or serve content from specific directories.

The following deployment manifest configures a custom IIS website that listens on HTTP with a specific port number and a custom physical path:

**Example aws-windows-deployment-manifest.json - IIS website configuration**  

```
{
  "manifestVersion": 1,
  "iisConfig": {
    "websites": [
      {
        "name": "MyCustomSite",
        "physicalPath": "C:\inetpub\wwwroot\mysite",
        "bindings": [
          {
            "protocol": "http",
            "port": 8080,
            "hostName": "mysite.local"
          }
        ]
      }
    ]
  },
  "deployments": {
    "aspNetCoreWeb": [
      {
        "name": "my-dotnet-core-app",
        "parameters": {
          "appBundle": "dotnet-core-app.zip",
          "iisWebSite": "MyCustomSite",
          "iisPath": "/"
        }
      }
    ]
  }
}
```

In this example:
+ A website named "MyCustomSite" is created with a custom physical path
+ The website has an HTTP binding on port 8080 with a specific host name
+ The ASP.NET Core application is deployed to this custom website using the `iisWebSite` parameter

## Using Application Request Routing (ARR)
<a name="dotnet-manifest-arr"></a>

Application Request Routing (ARR) and URL Rewrite modules are pre-installed and available in Elastic Beanstalk Windows AMIs. These modules enable advanced routing scenarios and URL manipulation through IIS configuration using ebextensions or application configuration.

The following example shows a simple deployment manifest that configures a website with a custom port, combined with an ebextensions configuration that sets up basic ARR routing:

**Example aws-windows-deployment-manifest.json - Simple ARR setup**  

```
{
  "manifestVersion": 1,
  "iisConfig": {
    "websites": [
      {
        "name": "ARRSite",
        "physicalPath": "C:\\inetpub\\wwwroot\\arrsite",
        "bindings": [
          {
            "protocol": "http",
            "port": 8080,
            "hostName": "localhost"
          }
        ]
      }
    ]
  },
  "deployments": {
    "aspNetCoreWeb": [
      {
        "name": "BackendApp",
        "parameters": {
          "appBundle": "backend-app.zip",
          "iisWebSite": "ARRSite",
          "iisPath": "/backend"
        }
      }
    ]
  }
}
```

ARR configuration is done through ebextensions. The following configuration sets up basic ARR routing rules:

**Example .ebextensions/arr-config.config - Basic ARR configuration**  

```
files:
  "C:\\temp\\configure-arr.ps1":
    content: |
      # Enable ARR proxy at server level
      Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter 'system.webServer/proxy' -Name 'enabled' -Value 'True'
      
      # Clear any existing global rules to avoid conflicts
      Clear-WebConfiguration -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter 'system.webServer/rewrite/globalRules'

      # Add global rule to route all requests to backend
      Add-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' `
        -Filter 'system.webServer/rewrite/globalRules' `
        -Name '.' `
        -Value @{
          name = 'Route_to_Backend'
          stopProcessing = 'True'
          match = @{ url = '^(?!backend/)(.*)' }
          action = @{
            type = 'Rewrite'
            url = 'http://localhost:8080/backend/{R:1}'
          }
        }

container_commands:
  01_configure_arr:
    command: powershell -ExecutionPolicy Bypass -File "C:\\temp\\configure-arr.ps1"
    waitAfterCompletion: 0
```

This configuration creates a website on port 8080 and sets up ARR to route all incoming requests to the backend application running on that site.

## Configure application pools
<a name="dotnet-manifest-apppool"></a>

You can support multiple applications in your Windows environment. Two approaches are available:
+ You can use the out-of-process hosting model with the Kestrel web server. With this model, you configure multiple applications to run in one application pool.
+ You can use the in-process hosting model.With this model, you use multiple application pools to run multiple applications with only one application in each pool. If you're using IIS server and need to run multiple applications, you must use this approach.

To configure Kestrel to run multiple applications in one application pool, add `hostingModel="OutofProcess"` in the `web.config` file. Consider the following examples.

**Example web.config - for Kestrel out-of-process hosting model**  

```
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add 
    name="aspNetCore" 
    path="*" verb="*" 
    modules="AspNetCoreModuleV2" 
    resourceType="Unspecified" />
</handlers>
<aspNetCore 
    processPath="dotnet" 
    arguments=".\CoreWebApp-5-0.dll" 
    stdoutLogEnabled="false" 
    stdoutLogFile=".\logs\stdout" 
    hostingModel="OutofProcess" />
</system.webServer>
</location>
</configuration>
```

**Example aws-windows-deployment-manifest.json - multiple applications**  

```
{
"manifestVersion": 1,
  "deployments": {"msDeploy": [
      {"name": "Web-app1",
        "parameters": {"archive": "site1.zip",
          "iisPath": "/"
        }
      },
      {"name": "Web-app2",
        "parameters": {"archive": "site2.zip",
          "iisPath": "/app2"
        }
      }
    ]
  }
}
```

IIS doesn't support multiple applications in one application pool because it uses the in-process hosting model. Therefore, you need to configure multiple applications by assigning each application to one application pool. In other words, assign only one application to one application pool.

You can configure IIS to use different application pools in the `aws-windows-deployment-manifest.json` file. Make the following updates as you refer to the next example file:
+ Add an `iisConfig` section that includes a subsection called `appPools`.
+ In the `appPools` block, list the application pools. 
+ In the `deployments` section, define a `parameters` section for each application.
+ For each application the `parameters` section specifies an archive, a path to run it, and an `appPool` in which to run.

The following deployment manifest configures two application pools that restart their application every 10 minutes. They also attach their applications to a .NET Framework web application that runs at the path specified.

**Example aws-windows-deployment-manifest.json - one application per application pool**  

```
{
"manifestVersion": 1,
  "iisConfig": {"appPools": [
      {"name": "MyFirstPool",
       "recycling": {"regularTimeInterval": 10}
      },
      {"name": "MySecondPool",
       "recycling": {"regularTimeInterval": 10}
      }
     ]
    },
  "deployments": {"msDeploy": [
      {"name": "Web-app1",
        "parameters": {
           "archive": "site1.zip",
           "iisPath": "/",
           "appPool": "MyFirstPool"
           }
      },
      {"name": "Web-app2",
        "parameters": {
           "archive": "site2.zip",
           "iisPath": "/app2",
           "appPool": "MySecondPool"
          }
      }
     ]
    }
}
```

## Define custom deployments
<a name="dotnet-manifest-custom"></a>

For even more control, you can completely customize an application deployment by defining a *custom deployment*.

This deployment manifest instructs Elastic Beanstalk to execute PowerShell scripts in 32-bit mode. It specifies three scripts: an `install` script (`siteInstall.ps1`) that runs during instance launch and deployments, an `uninstall` script (`siteUninstall.ps1`) that executes before installing new versions during deployments, and a `restart` script (`siteRestart.ps1`) that runs when you select [Restart App Server](environments-dashboard-actions.md) in the AWS management console.

**Example aws-windows-deployment-manifest.json - custom deployment**  

```
{
  "manifestVersion": 1,
  "deployments": {
    "custom": [
      {
        "name": "Custom site",
        "architecture" : 32,
        "scripts": {
          "install": {
            "file": "siteInstall.ps1"
          },
          "restart": {
            "file": "siteRestart.ps1"
          },
          "uninstall": {
            "file": "siteUninstall.ps1"
          }
        }
      }
    ]
  }
}
```

Include any artifacts required to run the application in your source bundle with the manifest and scripts.

**Example Custom-site-bundle.zip**  

```
.
|-- aws-windows-deployment-manifest.json
|-- siteInstall.ps1
|-- siteRestart.ps1
|-- siteUninstall.ps1
`-- site-contents.zip
```

# Deployment manifest schema reference
<a name="dotnet-manifest-schema"></a>

The deployment manifest is a JSON file that defines how Elastic Beanstalk should deploy and configure your Windows applications. This section provides a comprehensive reference for all supported properties and configuration options in the manifest schema.

## Manifest structure
<a name="dotnet-manifest-schema-structure"></a>

The deployment manifest follows a specific JSON schema with the following top-level structure:

**Example Basic manifest structure**  

```
{
  "manifestVersion": 1,
  "skipIISReset": false,
  "iisConfig": {
    "websites": [...],
    "appPools": [...]
  },
  "deployments": {
    "msDeploy": [...],
    "aspNetCoreWeb": [...],
    "custom": [...]
  }
}
```

### Top-level properties
<a name="dotnet-manifest-schema-top-level"></a>

`manifestVersion` (required)  
*Type:* Number  
*Default:* 1  
*Valid values:* 1  
Specifies the version of the manifest schema. Currently, only version 1 is supported.

`skipIISReset` (optional)  
*Type:* Boolean  
*Default:* false  
Controls whether IIS is reset during application deployments. This flag affects both `msDeploy` and `aspNetCoreWeb` deployment types.  
*Behavior:*  
+ *Not specified or `false` (default):* IIS resets are performed during install, uninstall, and update operations. This is the traditional behavior.
+ *`true`:* IIS resets are skipped during deployment operations.
*Benefits:*  
+ *Reduced downtime* – Applications experience shorter service interruptions during deployments.
+ *Faster deployments* – Eliminates the time required for IIS to fully restart and reinitialize.
When using `skipIISReset`, the [RestartAppServer](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RestartAppServer.html) operation performs an IIS reset regardless of this flag setting.
*Example:*  

```
{
  "manifestVersion": 1,
  "skipIISReset": true,
  "deployments": {
    "aspNetCoreWeb": [
      {
        "name": "my-dotnet-core-app",
        "parameters": {
          "archive": "dotnet-core-app.zip",
          "iisPath": "/"
        }
      }
    ]
  }
}
```

`deployments` (required)  
*Type:* Object  
Contains the deployment configurations for your applications. This object can include `msDeploy`, `aspNetCoreWeb`, and `custom` deployment types.

`iisConfig` (optional)  
*Type:* Object  
Defines IIS configuration settings to apply before deploying applications. Supports both website and application pool configuration.

## IIS configuration
<a name="dotnet-manifest-schema-iis-config"></a>

The `iisConfig` section allows you to configure IIS settings before deploying your applications. This includes setting up application pools with specific configurations and configuring IIS websites with custom bindings.

### IIS websites
<a name="dotnet-manifest-schema-websites"></a>

IIS websites allow you to configure custom website settings including physical paths and network bindings before deploying your applications.

**Important considerations for creating different IIS websites**  
*Website setup order:* Websites are configured sequentially in the order they appear in the `websites` array. The platform processes each website configuration in sequence, so ensure proper ordering if you have dependencies between websites.
*Firewall and port access:* Only port 80 is automatically exposed through the default Elastic Beanstalk Windows firewall configuration. If you configure websites to use non-standard ports, you must define custom firewall rules through ebextensions or custom deployment scripts to allow external access to these ports.

**Example Website configuration**  

```
{
  "iisConfig": {
    "websites": [
      {
        "name": "MyCustomSite",
        "physicalPath": "C:\inetpub\wwwroot\mysite",
        "bindings": [
          {
            "protocol": "http",
            "port": 8080,
            "hostName": "mysite.local"
          },
          {
            "protocol": "https",
            "port": 8443
          }
        ]
      }
    ]
  }
}
```Website properties

`name` (required)  
*Type:* String  
The name of the IIS website. This name is used to identify the website in IIS Manager and must be unique within the IIS configuration.

`physicalPath` (required)  
*Type:* String  
The physical path on the server where the website files are stored. This path must be accessible to the IIS worker process.

`bindings` (required)  
*Type:* Array  
*Minimum items:* 1  
An array of binding configurations that define how the website responds to network requests. Each binding specifies a protocol, port, and optional host name.

#### Website bindings
<a name="dotnet-manifest-schema-bindings"></a>

Website bindings define the network endpoints where your IIS website will listen for incoming requests.

`protocol` (required)  
*Type:* String  
*Valid values:* "http", "https"  
The protocol used for the binding.

`port` (required)  
*Type:* Integer  
*Valid range:* 1-65535  
The port number on which the website will listen for requests.

`hostName` (optional)  
*Type:* String  
The host name (domain name) for the binding.

### Application pools
<a name="dotnet-manifest-schema-app-pools"></a>

Application pools provide isolation between applications and allow you to configure runtime settings for groups of applications.

**Example Application pool configuration**  

```
{
  "iisConfig": {
    "appPools": [
      {
        "name": "MyAppPool",
        "enable32Bit": false,
        "managedPipelineMode": "Integrated",
        "managedRuntimeVersion": "v4.0",
        "queueLength": 1000,
        "cpu": {
          "limitPercentage": 80,
          "limitAction": "Throttle",
          "limitMonitoringInterval": 5
        },
        "recycling": {
          "regularTimeInterval": 1440,
          "requestLimit": 10000,
          "memory": 1048576,
          "privateMemory": 524288
        }
      }
    ]
  }
}
```Application pool properties

`name` (required)  
*Type:* String  
The name of the application pool. This name is used to reference the pool in deployment configurations.

`enable32Bit` (optional)  
*Type:* Boolean  
Enables a 32-bit application to run on a 64-bit version of Windows. Set to `true` for legacy applications that require 32-bit compatibility.

`managedPipelineMode` (optional)  
*Type:* String  
*Valid values:* "Integrated", "Classic"  
Specifies the request-processing mode for the application pool.

`managedRuntimeVersion` (optional)  
*Type:* String  
*Valid values:* "No Managed Code", "v2.0", "v4.0"  
Specifies the .NET Framework version for the application pool.

`queueLength` (optional)  
*Type:* Integer  
Maximum number of requests that HTTP.sys queues for the application pool before rejecting additional requests.

#### CPU configuration
<a name="dotnet-manifest-schema-cpu-config"></a>

The `cpu` object configures CPU usage limits and monitoring for the application pool.

`limitPercentage` (optional)  
*Type:* Number  
Maximum percentage of CPU time that worker processes in the application pool can consume.

`limitAction` (optional)  
*Type:* String  
*Valid values:* "NoAction", "KillW3wp", "Throttle", "ThrottleUnderLoad"  
Action to take when the CPU limit is reached.

`limitMonitoringInterval` (optional)  
*Type:* Number  
Reset period (in minutes) for CPU monitoring and throttling limits.

#### Recycling configuration
<a name="dotnet-manifest-schema-recycling-config"></a>

The `recycling` object configures when and how application pool worker processes are recycled.

`regularTimeInterval` (optional)  
*Type:* Integer  
Time interval (in minutes) after which the application pool recycles. Set to 0 to disable time-based recycling.

`requestLimit` (optional)  
*Type:* Integer  
Maximum number of requests the application pool processes before recycling.

`memory` (optional)  
*Type:* Integer  
Amount of virtual memory (in kilobytes) that triggers worker process recycling.

`privateMemory` (optional)  
*Type:* Integer  
Amount of private memory (in kilobytes) that triggers worker process recycling.

## Deployment types
<a name="dotnet-manifest-schema-deployments"></a>

The `deployments` object contains arrays of deployment configurations for different application types. Each deployment type has specific properties and use cases.

### MSDeploy deployments
<a name="dotnet-manifest-schema-msdeploy"></a>

MSDeploy deployments are used for traditional .NET Framework applications that can be deployed using Web Deploy (MSDeploy).

**Example MSDeploy deployment configuration**  

```
{
  "deployments": {
    "msDeploy": [
      {
        "name": "WebApp",
        "description": "Main web application",
        "parameters": {
          "appBundle": "webapp.zip",
          "iisPath": "/",
          "appPool": "DefaultAppPool"
        }
      }
    ]
  }
}
```MSDeploy deployment properties

`name` (required)  
*Type:* String  
Unique name for the deployment. This name must be unique across all deployments in the manifest.

`description` (optional)  
*Type:* String  
Human-readable description of the deployment.

`parameters` (required)  
*Type:* Object  
Configuration parameters for the MSDeploy operation.

`scripts` (optional)  
*Type:* Object  
PowerShell scripts to run at various stages of the deployment lifecycle.

#### MSDeploy parameters
<a name="dotnet-manifest-schema-msdeploy-parameters"></a>

`appBundle` (required)  
*Type:* String  
Path to the application bundle (ZIP file) relative to the manifest file. This bundle contains the application files to deploy.

`iisWebSite` (optional)  
*Type:* String  
*Default:* "Default Web Site"  
The IIS website to deploy the application to. By default, applications are deployed to the "Default Web Site". Optionally, you can specify a different website name, such as one configured in the `iisConfig.websites` section.

`iisPath` (optional)  
*Type:* String  
*Default:* "/"  
Virtual directory path in IIS where the application will be deployed. Use "/" for the root path or "/api" for a subdirectory.

`appPool` (optional)  
*Type:* String  
Name of the application pool to run this application.

### ASP.NET Core deployments
<a name="dotnet-manifest-schema-aspnetcore"></a>

ASP.NET Core deployments are specifically designed for .NET Core and .NET 5\$1 applications.

**Example ASP.NET Core deployment configuration**  

```
{
  "deployments": {
    "aspNetCoreWeb": [
      {
        "name": "CoreAPI",
        "description": "ASP.NET Core Web API",
        "parameters": {
          "appBundle": "coreapi.zip",
          "iisPath": "/api",
          "appPool": "CoreAppPool"
        }
      }
    ]
  }
}
```

ASP.NET Core deployments use the same property structure as MSDeploy deployments, with the key difference being the runtime environment and hosting model used for the application.ASP.NET Core deployment parameters

`appBundle` (required)  
*Type:* String  
Path to the application bundle relative to the manifest file. This can be either a ZIP archive or a directory path containing the published ASP.NET Core application.

`iisWebSite` (optional)  
*Type:* String  
*Default:* "Default Web Site"  
The IIS website to deploy the ASP.NET Core application to. By default, applications are deployed to the "Default Web Site". Optionally, you can specify a different website name, such as one configured in the `iisConfig.websites` section.

`iisPath` (optional)  
*Type:* String  
*Default:* "/"  
Virtual directory path in IIS for the ASP.NET Core application.

`appPool` (optional)  
*Type:* String  
Application pool for the ASP.NET Core application. The pool will be configured appropriately for ASP.NET Core hosting.

### Custom deployments
<a name="dotnet-manifest-schema-custom"></a>

Custom deployments provide complete control over the deployment process through PowerShell scripts. This deployment type is useful for complex scenarios that require custom installation, configuration, or deployment logic.

**Example Custom deployment configuration**  

```
{
  "deployments": {
    "custom": [
      {
        "name": "CustomService",
        "description": "Custom Windows service deployment",
        "architecture": 32,
        "scripts": {
          "install": {
            "file": "install-service.ps1"
          },
          "restart": {
            "file": "restart-service.ps1"
          },
          "uninstall": {
            "file": "uninstall-service.ps1",
            "ignoreErrors": true
          }
        }
      }
    ]
  }
}
```Custom deployment properties

`name` (required)  
*Type:* String  
Unique name for the custom deployment.

`description` (optional)  
*Type:* String  
Description of the custom deployment.

`architecture` (optional)  
*Type:* Integer  
*Default:* 32  
*Valid values:* 32, 64  
The architecture specification for execution mode of powershell scripts

`scripts` (required)  
*Type:* Object  
PowerShell scripts that define the deployment behavior. Custom deployments support additional script types compared to other deployment types.

## Deployment scripts
<a name="dotnet-manifest-schema-scripts"></a>

Deployment scripts are PowerShell scripts that run at specific points during the deployment lifecycle. Different deployment types support different sets of script events.

### Script events
<a name="dotnet-manifest-schema-script-events"></a>

The following script events are available depending on the deployment type:Standard deployment scripts (msDeploy and aspNetCoreWeb)

`preInstall`  
Runs before the application is installed or updated.

`postInstall`  
Runs after the application is installed or updated.

`preRestart`  
Runs before the application is restarted.

`postRestart`  
Runs after the application is restarted.

`preUninstall`  
Runs before the application is uninstalled.

`postUninstall`  
Runs after the application is uninstalled.Custom deployment scripts (custom deployments only)

`install`  
Primary installation script for custom deployments. This script is responsible for installing the application or service.

`restart`  
Script to restart the application or service. Called when the environment is restarted.

`uninstall`  
Script to uninstall the application or service. Called during environment termination or application removal.

### Script properties
<a name="dotnet-manifest-schema-script-properties"></a>

Each script is defined as an object with the following properties:

`file` (required)  
*Type:* String  
Path to the PowerShell script file relative to the manifest file. The script should have a `.ps1` extension.

`ignoreErrors` (optional)  
*Type:* Boolean  
*Default:* false  
When set to `true`, deployment continues even if the script fails. Use this for non-critical scripts or cleanup operations.

**Example Script configuration example**  

```
{
  "scripts": {
    "preInstall": {
      "file": "backup-config.ps1",
      "ignoreErrors": true
    },
    "postInstall": {
      "file": "configure-app.ps1"
    }
  }
}
```

# Using EC2 Fast Launch with Windows platform branches
<a name="dotnet-ec2fastlaunch"></a>

The EC2 Fast Launch feature reduces Windows instance launch times in your Elastic Beanstalk environments. The purpose of this topic is to guide you on using this feature with your Elastic Beanstalk environments. Starting with Windows platform version 2.16.2, released on [January 22, 2025](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2025-01-22-windows.html), Elastic Beanstalk platform releases include base AMIs with EC2 Fast Launch enabled.

## Default EC2 Fast Launch availability
<a name="dotnet-ec2fastlaunch-default"></a>

The latest Elastic Beanstalk Windows platform versions include base AMIs with EC2 Fast Launch automatically enabled, with no additional costs. However, when newer platform versions are released, EC2 Fast Launch may not remain automatically enabled on base AMIs from older platform versions.

We recommend upgrading to the latest Windows platform version to use base AMIs with EC2 Fast Launch automatically enabled. However, if you need to continue using your existing platform version, you can manually enable EC2 Fast Launch on your environment's base AMI. For instructions, see [Manually configuring EC2 Fast Launch](#dotnet-ec2fastlaunch-manual).

## Manually configuring EC2 Fast Launch
<a name="dotnet-ec2fastlaunch-manual"></a>

**Note**  
Manually enabling EC2 Fast Launch may incur additional costs compared to using platform versions with EC2 Fast Launch automatically enabled. For more information about EC2 Fast Launch costs, see the [Manage costs for EC2 Fast Launch underlying resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/win-fast-launch-manage-costs.html) page in the *Amazon EC2 User Guide*.

Follow these steps to enable EC2 Fast Launch on a Windows base AMI used by your Elastic Beanstalk environment:

**To manually enable EC2 Fast Launch for your Elastic Beanstalk environment**

1. Identify your environment's base AMI:

   Follow the steps in [Creating a Custom AMI](using-features.customenv.md) to identify your environment's base AMI ID. Note that you don't need to create a custom AMI - you only need to follow the steps to locate your current base AMI ID.

1. Enable EC2 Fast Launch on the AMI:

   Use the instructions in [Enable EC2 Fast Launch](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/win-fast-launch-configure.html) in the *Amazon EC2 User Guide* to configure EC2 Fast Launch for your AMI.

# Adding an Amazon RDS DB instance to your .NET application environment
<a name="create_deploy_NET.rds"></a>

This topic provides instructions to create an Amazon RDS using the Elastic Beanstalk console. You can use an Amazon Relational Database Service (Amazon RDS) DB instance to store data gathered and modified by your application. The database can be coupled to your environment and managed by Elastic Beanstalk, or it can be created as decoupled and managed externally by another service. In these instructions the database is coupled to your environment and managed by Elastic Beanstalk. For more information about integrating an Amazon RDS with Elastic Beanstalk, see [Adding a database to your Elastic Beanstalk environment](using-features.managing.db.md).

**Topics**
+ [

## Adding a DB instance to your environment
](#dotnet-rds-create)
+ [

## Downloading a driver
](#dotnet-rds-drivers)
+ [

## Connecting to a database
](#dotnet-rds-connect)

## Adding a DB instance to your environment
<a name="dotnet-rds-create"></a>

**To add a DB instance to your environment**

1. Open the [Elastic Beanstalk console](https://console.aws.amazon.com/elasticbeanstalk), and in the **Regions** list, select your AWS Region.

1. In the navigation pane, choose **Environments**, and then choose the name of your environment from the list.

1. In the navigation pane, choose **Configuration**.

1. In the **Database** configuration category, choose **Edit**.

1. Choose a DB engine, and enter a user name and password.

1. To save the changes choose **Apply** at the bottom of the page.

Adding a DB instance takes about 10 minutes. When the environment update is complete, the DB instance's hostname and other connection information are available to your application through the following environment properties:


| Property name | Description | Property value | 
| --- | --- | --- | 
|  `RDS_HOSTNAME`  |  The hostname of the DB instance.  |  On the **Connectivity & security** tab on the Amazon RDS console: **Endpoint**.  | 
|  `RDS_PORT`  |  The port where the DB instance accepts connections. The default value varies among DB engines.  |  On the **Connectivity & security** tab on the Amazon RDS console: **Port**.  | 
|  `RDS_DB_NAME`  |  The database name, **ebdb**.  |  On the **Configuration** tab on the Amazon RDS console: **DB Name**.  | 
|  `RDS_USERNAME`  |  The username that you configured for your database.  |  On the **Configuration** tab on the Amazon RDS console: **Master username**.  | 
|  `RDS_PASSWORD`  |  The password that you configured for your database.  |  Not available for reference in the Amazon RDS console.  | 

For more information about configuring a database instance coupled with an Elastic Beanstalk environment, see [Adding a database to your Elastic Beanstalk environment](using-features.managing.db.md).

## Downloading a driver
<a name="dotnet-rds-drivers"></a>

Download and install the `EntityFramework` package and a database driver for your development environment with `NuGet`.

**Common entity framework database providers for .NET**
+ **SQL Server** – `Microsoft.EntityFrameworkCore.SqlServer`
+ **MySQL** – `Pomelo.EntityFrameworkCore.MySql`
+ **PostgreSQL** – `Npgsql.EntityFrameworkCore.PostgreSQL`

## Connecting to a database
<a name="dotnet-rds-connect"></a>

Elastic Beanstalk provides connection information for attached DB instances in environment properties. Use `ConfigurationManager.AppSettings` to read the properties and configure a database connection.

**Example Helpers.cs - connection string method**  

```
using System;
using System.Collections.Generic;
using System.Configuration;
using System.Linq;
using System.Web;

namespace MVC5App.Models
{
  public class Helpers
  {
    public static string GetRDSConnectionString()
    {
      var appConfig = ConfigurationManager.AppSettings;

      string dbname = appConfig["RDS_DB_NAME"];

      if (string.IsNullOrEmpty(dbname)) return null;

      string username = appConfig["RDS_USERNAME"];
      string password = appConfig["RDS_PASSWORD"];
      string hostname = appConfig["RDS_HOSTNAME"];
      string port = appConfig["RDS_PORT"];

      return "Data Source=" + hostname + ";Initial Catalog=" + dbname + ";User ID=" + username + ";Password=" + password + ";";
    }
  }
}
```

Use the connection string to initialize your database context.

**Example DBContext.cs**  

```
using System.Data.Entity;
using System.Security.Claims;
using System.Threading.Tasks;
using Microsoft.AspNet.Identity;
using Microsoft.AspNet.Identity.EntityFramework;

namespace MVC5App.Models
{
  public class RDSContext : DbContext
  { 
    public RDSContext()
      : base(GetRDSConnectionString())
    {
    }

    public static RDSContext Create()
    {
      return new RDSContext();
    }
  }
}
```

# The AWS Toolkit for Visual Studio
<a name="dotnet-toolkit"></a>

Visual Studio provides templates for different programming languages and application types. You can start with any of these templates. The AWS Toolkit for Visual Studio also provides three project templates that bootstrap development of your application: AWS Console Project, AWS Web Project, and AWS Empty Project. For this example, you'll create a new ASP.NET Web Application.

**To create a new ASP.NET web application project**

1. In Visual Studio, on the **File** menu, click **New** and then click **Project**.

1. In the **New Project** dialog box, click **Installed Templates**, click **Visual C\$1**, and then click **Web**. Click **ASP.NET Empty Web Application**, type a project name, and then click **OK**. 

**To run a project**

Do one of the following:

1. Press **F5**.

1. Select **Start Debugging** from the **Debug** menu.

## Test locally
<a name="create_deploy_NET.sdlc.testlocal"></a>

Visual Studio makes it easy for you to test your application locally. To test or run ASP.NET web applications, you need a web server. Visual Studio offers several options, such as Internet Information Services (IIS), IIS Express, or the built-in Visual Studio Development Server. To learn about each of these options and to decide which one is best for you, see [Web Servers in Visual Studio for ASP.NET Web Projects](http://msdn.microsoft.com/en-us/library/58wxa9w5.aspx).

## Create an Elastic Beanstalk environment
<a name="create_deploy_NET.sdlc.deploy"></a>

After testing your application, you are ready to deploy it to Elastic Beanstalk.

**Note**  
[Configuration file](ebextensions.md) needs to be part of the project to be included in the archive. Alternatively, instead of including the configuration files in the project, you can use Visual Studio to deploy all files in the project folder. In **Solution Explorer**, right-click the project name, and then click **Properties**. Click the **Package/Publish Web** tab. In the **Items to deploy** section, select **All Files in the Project Folder** in the drop-down list.

**To deploy your application to Elastic Beanstalk using the AWS toolkit for Visual Studio**

1. In **Solution Explorer**, right-click your application and then select **Publish to AWS**.

1. In the **Publish to AWS** wizard, enter your account information.

   1. For **AWS account to use for deployment**, select your account or select **Other** to enter new account information. 

   1. For **Region**, select the region where you want to deploy your application. For information about available AWS Regions, see [AWS Elastic Beanstalk Endpoints and Quotas](https://docs.aws.amazon.com/general/latest/gr/elasticbeanstalk.html) in the *AWS General Reference*. If you select a region that is not supported by Elastic Beanstalk, then the option to deploy to Elastic Beanstalk will become unavailable.

   1.  Click **Deploy new application with template** and select **Elastic Beanstalk**. Then click **Next**.  
![\[Publish to AWS wizard 1\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-create-newapp-template.png)

1. On the **Application** page, enter your application details.

   1. For **Name**, type the name of the application.

   1. For **Description**, type a description of the application. This step is optional.

   1. The version label of the application automatically appears in the **Deployment version label**.

   1. Select **Deploy application incrementally** to deploy only the changed files. An incremental deployment is faster because you are updating only the files that changed instead of all the files. If you choose this option, an application version will be set from the Git commit ID. If you choose to not deploy your application incrementally, then you can update the version label in the **Deployment version label** box.   
![\[Publish to beanstalk wizard 2\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-publish-beanstalk1.png)

   1. Click **Next**.

1. On the **Environment** page, describe your environment details.

   1. Select **Create a new environment for this application**.

   1. For **Name**, type a name for your environment.

   1. For **Description**, characterize your environment. This step is optional.

   1. Select the **Type** of environment that you want.

      You can select either **Load balanced, auto scaled** or a **Single instance** environment. For more information, see [Environment types](using-features-managing-env-types.md).

       
**Note**  
For single-instance environments, load balancing, auto scaling, and the health check URL settings don't apply.

   1. The environment URL automatically appears in the **Environment URL** once you move your cursor to that box.

   1. Click **Check availability** to make sure the environment URL is available.  
![\[Publish to beanstalk wizard 3\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-publish-beanstalk2.png)

   1. Click **Next**.

1. On the **AWS Options** page, configure additional options and security information for your deployment. 

   1.  For **Container Type**, select **64bit Windows Server 2012 running IIS 8** or **64bit Windows Server 2008 running IIS 7.5**.

   1. For **Instance Type**, select **Micro**. 

   1. For **Key pair**, select **Create new key pair**. Type a name for the new key pair—in this example, we use **myuswestkeypair**—and then click **OK**. A key pair enables remote-desktop access to your Amazon EC2 instances. For more information on Amazon EC2 key pairs, see [Using Credentials](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-credentials.html) in the *Amazon Elastic Compute Cloud User Guide*. 

   1. Select an instance profile.

      If you do not have an instance profile, select **Create a default instance profile**. For information about using instance profiles with Elastic Beanstalk, see [Managing Elastic Beanstalk instance profiles](iam-instanceprofile.md).

   1. If you have a custom VPC that you would like to use with your environment, click **Launch into VPC**. You can configure the VPC information on the next page. For more information about Amazon VPC, go to [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc/). For a list of supported nonlegacy container types, see [Why are some platform versions marked legacy?](using-features.migration.md#using-features.migration.why)  
![\[Publish to beanstalk wizard 4\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-publish-beanstalk3b_iam.png)

   1.  Click **Next**. 

1. If you selected to launch your environment inside a VPC, the **VPC Options** page appears; otherwise, the **Additional Options** page appears. Here you'll configure your VPC options.  
![\[VPC options for load-balanced, scalable environment\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-publish-beanstalk3b_vpc.png)  
![\[VPC options for single-instance environment\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-publish-beanstalk3b_vpc-single.png)

   1. Select the VPC ID of the VPC in which you would like to launch your environment. 

   1. For a load-balanced, scalable environment, select **private** for **ELB Scheme** if you do not want your elastic load balancer to be available to the Internet.

      For a single-instance environment, this option is not applicable because the environment doesn't have a load balancer. For more information, see [Environment types](using-features-managing-env-types.md).

   1. For a load-balanced, scalable environment, select the subnets for the elastic load balancer and the EC2 instances. If you created public and private subnets, make sure the elastic load balancer and the EC2 instances are associated with the correct subnet. By default, Amazon VPC creates a default public subnet using 10.0.0.0/24 and a private subnet using 10.0.1.0/24. You can view your existing subnets in the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

      For a single-instance environment, your VPC only needs a public subnet for the instance. Selecting a subnet for the load balancer is not applicable because the environment doesn't have a load balancer. For more information, see [Environment types](using-features-managing-env-types.md).

   1. For a load-balanced, scalable environment, select the security group you created for your instances, if applicable.

      For a single-instance environment, you don't need a NAT device. Select the default security group. Elastic Beanstalk assigns an Elastic IP address to the instance that lets the instance access the Internet.

   1. Click **Next**.

1. On the **Application Options** page, configure your application options. 

   1. For Target framework, select **.NET Framework 4.0**. 

   1. Elastic Load Balancing uses a health check to determine whether the Amazon EC2 instances running your application are healthy. The health check determines an instance's health status by probing a specified URL at a set interval. You can override the default URL to match an existing resource in your application (e.g., `/myapp/index.aspx`) by entering it in the **Application health check URL** box. For more information about application health checks, see [Health check](environments-cfg-clb.md#using-features.managing.elb.healthchecks). 

   1. Type an email address if you want to receive Amazon Simple Notification Service (Amazon SNS) notifications of important events affecting your application.

   1. The **Application Environment** section lets you specify environment variables on the Amazon EC2 instances that are running your application. This setting enables greater portability by eliminating the need to recompile your source code as you move between environments.

   1. Select the application credentials option you want to use to deploy your application.  
![\[Publish to beanstalk wizard 6\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-publish-beanstalk3a.png)

   1. Click **Next**.

1. If you have previously set up an Amazon RDS database, the **Amazon RDS DB Security Group** page appears. If you want to connect your Elastic Beanstalk environment to your Amazon RDS DB Instance, then select one or more security groups. Otherwise, go on to the next step. When you're ready, click **Next**.  
![\[Publish to beanstalk wizard 7\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-publish-beanstalk6b.png)

1.  Review your deployment options. If everything is as you want, click **Deploy**.   
![\[Publish to beanstalk wizard 8\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-publish-beanstalk4.png)

   Your ASP.NET project will be exported as a web deploy file, uploaded to Amazon S3, and registered as a new application version with Elastic Beanstalk. The Elastic Beanstalk deployment feature will monitor your environment until it becomes available with the newly deployed code. On the env:<environment name> tab, you will see status for your environment.   
![\[Environment status\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-env-status.png)

## Terminating an environment
<a name="create_deploy_NET.terminating"></a>

To avoid incurring charges for unused AWS resources, you can terminate a running environment using the AWS Toolkit for Visual Studio.

**Note**  
 You can always launch a new environment using the same version later. 

**To terminate an environment**

1.  Expand the Elastic Beanstalk node and the application node in **AWS Explorer**. Right-click your application environment and select **Terminate Environment**.

1. When prompted, click **Yes** to confirm that you want to terminate the environment. It will take a few minutes for Elastic Beanstalk to terminate the AWS resources running in the environment.  
![\[Elastic Beanstalk terminate environment dialog box\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-terminate-confirm.png)
**Note**  
When you terminate your environment, the CNAME associated with the terminated environment becomes available for anyone to use. 

# Deploying to your environment
<a name="create_deploy_NET.sdlc.create.edit"></a>

Now that you have tested your application, it is easy to edit and redeploy your application and see the results in moments. 

 **To edit and redeploy your ASP.NET web application ** 

1.  In **Solution Explorer**, right-click your application, and then click **Republish to Environment <*your environment name*>**. The **Re-publish to AWS Elastic Beanstalk** wizard opens.  
![\[Publish to beanstalk wizard 1\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-republish-beanstalk-sameenv.png)

1.  Review your deployment details and click **Deploy**. 
**Note**  
If you want to change any of your settings, you can click **Cancel** and use the **Publish to AWS** wizard instead. For instructions, see [Create an Elastic Beanstalk environment](dotnet-toolkit.md#create_deploy_NET.sdlc.deploy).

   Your updated ASP.NET web project will be exported as a web deploy file with the new version label, uploaded to Amazon S3, and registered as a new application version with Elastic Beanstalk. The Elastic Beanstalk deployment feature monitors your existing environment until it becomes available with the newly deployed code. On the **env:<*environment name*>** tab, you will see the status of your environment. 

You can also deploy an existing application to an existing environment if, for instance, you need to roll back to a previous application version. 

**To deploy an application version to an existing environment**

1. Right-click your Elastic Beanstalk application by expanding the Elastic Beanstalk node in **AWS Explorer**. Select **View Status**. 

1. In the **App: <*application name*>** tab, click **Versions**.   
![\[Application versions\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-publish-app-version.png)

1. Click the application version you want to deploy and click **Publish Version**.

1.  In the **Publish Application Version** wizard, click **Next**.  
![\[Publish application version wizard 1\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-republish-beanstalk2a.png)

1.  Review your deployment options, and click **Deploy**.   
![\[Publish application version wizard 2\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-publish-app-version-wizard3.png)

   Your ASP.NET project will be exported as a web deploy file and uploaded to Amazon S3. The Elastic Beanstalk deployment feature will monitor your environment until it becomes available with the newly deployed code. On the **env:<*environment name*>** tab, you will see status for your environment. 

# Managing your Elastic Beanstalk application environments
<a name="create_deploy_NET.managing"></a>

With the AWS Toolkit for Visual Studio and the AWS Management Console, you can change the provisioning and configuration of the AWS resources used by your application environments. For information on how to manage your application environments using the AWS Management Console, see [Managing Elastic Beanstalk environments](using-features.managing.md). This section discusses the specific service settings you can edit in the AWS Toolkit for Visual Studio as part of your application environment configuration.

## Changing environment configurations settings
<a name="create_deploy_NET.managing.env"></a>

When you deploy your application, Elastic Beanstalk configures a number of AWS cloud computing services. You can control how these individual services are configured using the AWS Toolkit for Visual Studio.

**To edit an application's environment settings**
+ Expand the Elastic Beanstalk node and your application node. Then right-click your Elastic Beanstalk environment in **AWS Explorer**. Select **View Status**. 

  You can now configure settings for the following:
  + Server
  + Load balancing
  + Autoscaling
  + Notifications
  + Environment properties

# Configuring EC2 server instances using the AWS toolkit for Visual Studio
<a name="create_deploy_NET.managing.ec2"></a>

Amazon Elastic Compute Cloud (Amazon EC2) is a web service that you use to launch and manage server instances in Amazon's data centers. You can use Amazon EC2 server instances at any time, for as long as you need, and for any legal purpose. Instances are available in different sizes and configurations. For more information, go to [Amazon EC2](https://aws.amazon.com/ec2/).

You can edit the Elastic Beanstalk environment's Amazon EC2 instance configuration with the **Server** tab inside your application environment tab in the AWS Toolkit for Visual Studio. 

![\[Elastic Beanstalk servers configuration panel\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-server.png)


## Amazon EC2 instance types
<a name="create_deploy_NET.managing.ec2.instancetypes"></a>

**Instance type** displays the instance types available to your Elastic Beanstalk application. Change the instance type to select a server with the characteristics (including memory size and CPU power) that are most appropriate to your application. For example, applications with intensive and long-running operations can require more CPU or memory.

For more information about the Amazon EC2 instance types available for your Elastic Beanstalk application, see [Instance Types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) in the *Amazon Elastic Compute Cloud User Guide*.

## Amazon EC2 security groups
<a name="create_deploy_NET.managing.ec2.securitygroups"></a>

You can control access to your Elastic Beanstalk application using an *Amazon EC2 Security Group*. A security group defines firewall rules for your instances. These rules specify which ingress (i.e., incoming) network traffic should be delivered to your instance. All other ingress traffic will be discarded. You can modify rules for a group at any time. The new rules are automatically enforced for all running instances and instances launched in the future. 

You can set up your Amazon EC2 security groups using the AWS Management Console or by using the AWS Toolkit for Visual Studio. You can specify which Amazon EC2 Security Groups control access to your Elastic Beanstalk application by entering the names of one or more Amazon EC2 security group names (delimited by commas) into the **EC2 Security Groups** text box. 

**Note**  
Make sure port 80 (HTTP) is accessible from 0.0.0.0/0 as the source CIDR range if you want to enable health checks for your application. For more information about health checks, see [Health checks](create_deploy_NET.managing.elb.md#create_deploy_NET.managing.elb.healthchecks).

**To create a security group using the AWS toolkit for Visual Studio**

1.  In Visual Studio, in **AWS Explorer**, expand the **Amazon EC2** node, and then double-click **Security Groups**. 

1.  Click **Create Security Group**, and enter a name and description for your security group. 

1.  Click **OK**. 

For more information on Amazon EC2 Security Groups, see [Using Security Groups](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) in the *Amazon Elastic Compute Cloud User Guide*.

## Amazon EC2 key pairs
<a name="create_deploy_NET.managing.ec2.keypair"></a>

You can securely log in to the Amazon EC2 instances provisioned for your Elastic Beanstalk application with an Amazon EC2 key pair.

**Important**  
You must create an Amazon EC2 key pair and configure your Elastic Beanstalk–provisioned Amazon EC2 instances to use the Amazon EC2 key pair before you can access your Elastic Beanstalk–provisioned Amazon EC2 instances. You can create your key pair using the **Publish to AWS** wizard inside the AWS Toolkit for Visual Studio when you deploy your application to Elastic Beanstalk. If you want to create additional key pairs using the Toolkit, follow the steps below. Alternatively, you can set up your Amazon EC2 key pairs using the [AWS Management Console](https://console.aws.amazon.com/). For instructions on creating a key pair for Amazon EC2, see the [Amazon Elastic Compute Cloud Getting Started Guide](http://docs.aws.amazon.com/AWSEC2/latest/GettingStartedGuide/). 

 The **Existing Key Pair** text box lets you specify the name of an Amazon EC2 key pair you can use to securely log in to the Amazon EC2 instances running your Elastic Beanstalk application. 

**To specify the name of an Amazon EC2 key pair**

1. Expand the **Amazon EC2** node and double-click **Key Pairs**.

1.  Click **Create Key Pair** and enter the key pair name. 

1.  Click **OK**. 

For more information about Amazon EC2 key pairs, go to [Using Amazon EC2 Credentials](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-credentials.html) in the *Amazon Elastic Compute Cloud User Guide*. For more information about connecting to Amazon EC2 instances, see [Listing and connecting to server instances](create_deploy_NET.ec2connect.md). 

## Monitoring interval
<a name="create_deploy_NET.managing.monitoring"></a>

 By default, only basic Amazon CloudWatch metrics are enabled. They return data in five-minute periods. You can enable more granular one-minute CloudWatch metrics by selecting **1 minute** for the **Monitoring Interval** in the **Server** section of the **Configuration** tab for your environment in the AWS Toolkit for Eclipse.

**Note**  
Amazon CloudWatch service charges can apply for one-minute interval metrics. See [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) for more information.

## Custom AMI ID
<a name="create_deploy_NET.managing.customami"></a>

 You can override the default AMI used for your Amazon EC2 instances with your own custom AMI by entering the identifier of your custom AMI into the **Custom AMI ID** box in the **Server** section of the **Configuration** tab for your environment in the AWS Toolkit for Eclipse. 

**Important**  
Using your own AMI is an advanced task that you should do with care. If you need a custom AMI, we recommend you start with the default Elastic Beanstalk AMI and then modify it. To be considered healthy, Elastic Beanstalk expects Amazon EC2 instances to meet a set of requirements, including having a running host manager. If these requirements are not met, your environment might not work properly.

# Configuring Elastic Load Balancing using the AWS toolkit for Visual Studio
<a name="create_deploy_NET.managing.elb"></a>

Elastic Load Balancing is an Amazon web service that helps you improve the availability and scalability of your application. This service makes it easy for you to distribute application loads between two or more Amazon EC2 instances. Elastic Load Balancing enables availability through redundancy and supports traffic growth for your application. 

 Elastic Load Balancing lets you automatically distribute and balance the incoming application traffic among all the instances you are running. The service also makes it easy to add new instances when you need to increase the capacity of your application.

 Elastic Beanstalk automatically provisions Elastic Load Balancing when you deploy an application. You can edit the Elastic Beanstalk environment's Amazon EC2 instance configuration with the **Load Balancer** tab inside your application environment tab in AWS Toolkit for Visual Studio.

![\[Elastic Beanstalk Elastic Load Balancing configuration panel\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-loadbalancer.png)


 The following sections describe the Elastic Load Balancing parameters you can configure for your application.

## Ports
<a name="create_deploy_NET.managing.elb.ports"></a>

The load balancer provisioned to handle requests for your Elastic Beanstalk application sends requests to the Amazon EC2 instances that are running your application. The provisioned load balancer can listen for requests on HTTP and HTTPS ports and route requests to the Amazon EC2 instances in your AWS Elastic Beanstalk application. By default, the load balancer handles requests on the HTTP port. At least one of the ports (either HTTP or HTTPS) must be turned on.

![\[Elastic Beanstalk Elastic Load Balancing configuration - ports\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-loadbalancer-ports.png)


**Important**  
Make sure that the port you specified is not locked down; otherwise, users will not be able to connect to your Elastic Beanstalk application.

### Controlling the HTTP port
<a name="create_deploy_NET.managing.elb.ports.http"></a>

To turn off the HTTP port, select **OFF** for **HTTP Listener Port**. To turn on the HTTP port, you select an HTTP port (for example, **80**) from the list.

**Note**  
To access your environment using a port other than the default port 80, such as port 8080, add a listener to the existing load balancer and configure the new listener to listen on that port.  
For example, using the [AWS CLI for Classic load balancers](https://docs.aws.amazon.com/cli/latest/reference/elb/create-load-balancer-listeners.html), type the following command, replacing *LOAD\$1BALANCER\$1NAME* with the name of your load balancer for Elastic Beanstalk.  

```
aws elb create-load-balancer-listeners --load-balancer-name LOAD_BALANCER_NAME --listeners "Protocol=HTTP, LoadBalancerPort=8080, InstanceProtocol=HTTP, InstancePort=80"
```
For example, using the [AWS CLI for Application Load Balancers](https://docs.aws.amazon.com/cli/latest/reference/elbv2/create-listener.html), type the following command, replacing *LOAD\$1BALANCER\$1ARN* with the ARN of your load balancer for Elastic Beanstalk.  

```
aws elbv2 create-listener --load-balancer-arn LOAD_BALANCER_ARN --protocol HTTP --port 8080
```
If you want Elastic Beanstalk to monitor your environment, do not remove the listener on port 80.

### Controlling the HTTPS port
<a name="create_deploy_NET.managing.elb.ports.https"></a>

Elastic Load Balancing supports the HTTPS/TLS protocol to enable traffic encryption for client connections to the load balancer. Connections from the load balancer to the EC2 instances use plaintext encryption. By default, the HTTPS port is turned off.

**To turn on the HTTPS port**

1. Create a new certificate using AWS Certificate Manager (ACM) or upload a certificate and key to AWS Identity and Access Management (IAM). For more information about requesting an ACM certificate, see [Request a Certificate](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request.html) in the *AWS Certificate Manager User Guide*. For more information about importing third-party certificates into ACM, see [Importing Certificates](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html) in the *AWS Certificate Manager User Guide*. If ACM is not [available in your region](https://docs.aws.amazon.com/general/latest/gr/acm.html), use AWS Identity and Access Management (IAM) to upload a third-party certificate. The ACM and IAM services store the certificate and provide an Amazon Resource Name (ARN) for the SSL certificate. For more information about creating and uploading certificates to IAM, see [Working with Server Certificates](https://docs.aws.amazon.com/IAM/latest/UserGuide/ManagingServerCerts.html) in *IAM User Guide*.

1. Specify the HTTPS port by selecting a port for **HTTPS Listener Port**.  
![\[Elastic Beanstalk Elastic Load Balancing configuration - SSL\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-elb-ssl.png)

1. For **SSL Certificate ID**, enter the Amazon Resources Name (ARN) of your SSL certificate. For example, **arn:aws:iam::123456789012:server-certificate/abc/certs/build** or **arn:aws:acm:us-east-2:123456789012:certificate/12345678-12ab-34cd-56ef-12345678**. Use the SSL certificate that you created or uploaded in step 1.

To turn off the HTTPS port, select **OFF** for **HTTPS Listener Port**.

## Health checks
<a name="create_deploy_NET.managing.elb.healthchecks"></a>

The health check definition includes a URL to be queried for instance health. By default, Elastic Beanstalk uses TCP:80 for nonlegacy containers and HTTP:80 for legacy containers. You can override the default URL to match an existing resource in your application (e.g., `/myapp/default.aspx`) by entering it in the **Application Health Check URL** box. If you override the default URL, then Elastic Beanstalk uses HTTP to query the resource. To check if you are using a legacy container type, see [Why are some platform versions marked legacy?](using-features.migration.md#using-features.migration.why)

 You can control the settings for the health check using the **EC2 Instance Health Check** section of the **Load Balancing** panel.

![\[Elastic Beanstalk Elastic Load Balancing configuration - health checks\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-loadbalancer-healthcheck.png)


The health check definition includes a URL to be queried for instance health. Override the default URL to match an existing resource in your application (e.g., `/myapp/index.jsp`) by entering it in the **Application Health Check URL** box. 

The following list describes the health check parameters you can set for your application. 
+ For **Health Check Interval (seconds)**, enter the number of seconds Elastic Load Balancing waits between health checks for your application's Amazon EC2 instances.
+  For **Health Check Timeout (seconds)**, specify the number of seconds Elastic Load Balancing waits for a response before it considers the instance unresponsive.
+ For **Healthy Check Count Threshold** and **Unhealthy Check Count Threshold**, specify the number of consecutive successful or unsuccessful URL probes before Elastic Load Balancing changes the instance health status. For example, specifying **5** for **Unhealthy Check Count Threshold** means that the URL would have to return an error message or timeout five consecutive times before Elastic Load Balancing considers the health check failed.

## Sessions
<a name="create_deploy_NET.managing.elb.sessions"></a>

By default, a load balancer routes each request independently to the server instance with the smallest load. By comparison, a sticky session binds a user's session to a specific server instance so that all requests coming from the user during the session are sent to the same server instance. 

 Elastic Beanstalk uses load balancer–generated HTTP cookies when sticky sessions are enabled for an application. The load balancer uses a special load balancer–generated cookie to track the application instance for each request. When the load balancer receives a request, it first checks to see if this cookie is present in the request. If so, the request is sent to the application instance specified in the cookie. If there is no cookie, the load balancer chooses an application instance based on the existing load balancing algorithm. A cookie is inserted into the response for binding subsequent requests from the same user to that application instance. The policy configuration defines a cookie expiry, which establishes the duration of validity for each cookie. 

You can use the **Sessions** section on the **Load Balancer** tab to specify whether or not the load balancer for your application allows session stickiness.

![\[Elastic Beanstalk Elastic Load Balancing configuration - sessions\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-loadbalancer-sessions.png)


 For more information on Elastic Load Balancing, go to the [Elastic Load Balancing Developer Guide](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/). 

# Configuring Auto Scaling using the AWS toolkit for Visual Studio
<a name="create_deploy_NET.managing.as"></a>

Amazon EC2 Auto Scaling is an Amazon web service designed to automatically launch or terminate Amazon EC2 instances based on user-defined triggers. Users can set up *Auto Scaling groups* and associate *triggers* with these groups to automatically scale computing resources based on metrics such as bandwidth usage or CPU utilization. Amazon EC2 Auto Scaling works with Amazon CloudWatch to retrieve metrics for the server instances running your application.

Amazon EC2 Auto Scaling lets you take a group of Amazon EC2 instances and set various parameters to have this group automatically increase or decrease in number. Amazon EC2 Auto Scaling can add or remove Amazon EC2 instances from that group to help you seamlessly deal with traffic changes to your application. 

 Amazon EC2 Auto Scaling also monitors the health of each Amazon EC2 instance that it launches. If any instance terminates unexpectedly, Amazon EC2 Auto Scaling detects the termination and launches a replacement instance. This capability enables you to maintain a fixed, desired number of Amazon EC2 instances automatically. 

Elastic Beanstalk provisions Amazon EC2 Auto Scaling for your application. You can edit the Elastic Beanstalk environment's Amazon EC2 instance configuration with the **Auto Scaling** tab inside your application environment tab in the AWS Toolkit for Visual Studio.

![\[Elastic Beanstalk Auto Scaling configuration panel\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-autoscaling.png)


The following section discusses how to configure Auto Scaling parameters for your application. 

## Launch the configuration
<a name="create_deploy_NET.managing.as.launchconfig"></a>

You can edit the launch configuration to control how your Elastic Beanstalk application provisions Amazon EC2 Auto Scaling resources.

The **Minimum Instance Count** and **Maximum Instance Count** boxes let you specify the minimum and maximum size of the Auto Scaling group that your Elastic Beanstalk application uses.

![\[Elastic Beanstalk Auto Scaling launch config configuration window\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-autoscaling-launchconfig.png)


**Note**  
To maintain a fixed number of Amazon EC2 instances, set **Minimum Instance Count** and **Maximum Instance Count** to the same value.

The **Availability Zones** box lets you specify the number of Availability Zones you want your Amazon EC2 instances to be in. It is important to set this number if you want to build fault-tolerant applications. If one Availability Zone goes down, your instances will still be running in your other Availability Zones. 

**Note**  
Currently, it is not possible to specify which Availability Zone your instance will be in. 

## Triggers
<a name="create_deploy_NET.managing.as.trigger"></a>

A *trigger* is an Amazon EC2 Auto Scaling mechanism that you set to tell the system when you want to increase (*scale out*) the number of instances, and when you want to decrease (*scale in*) the number of instances. You can configure triggers to *fire* on any metric published to Amazon CloudWatch, such as CPU utilization, and determine if the conditions you specified have been met. When the upper or lower thresholds of the conditions you have specified for the metric have been breached for the specified period of time, the trigger launches a long-running process called a *Scaling Activity*.

You can define a scaling trigger for your Elastic Beanstalk application using AWS Toolkit for Visual Studio.

![\[Elastic Beanstalk Auto Scaling trigger\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-autoscaling-triggers.png)


Amazon EC2 Auto Scaling triggers work by watching a specific Amazon CloudWatch metric for an instance. Triggers include CPU utilization, network traffic, and disk activity. Use the **Trigger Measurement** setting to select a metric for your trigger.

The following list describes the trigger parameters you can configure using the AWS Management Console.
+ You can specify which statistic the trigger should use. You can select **Minimum**, **Maximum**, **Sum**, or **Average** for **Trigger Statistic**.
+ For **Unit of Measurement**, specify the unit for the trigger measurement.
+ The value in the **Measurement Period** box specifies how frequently Amazon CloudWatch measures the metrics for your trigger. The **Breach Duration** is the amount of time a metric can be beyond its defined limit (as specified for the **Upper Threshold** and **Lower Threshold**) before the trigger fires.
+ For **Upper Breach Scale Increment** and **Lower Breach Scale Increment**, specify how many Amazon EC2 instances to add or remove when performing a scaling activity. 

For more information on Amazon EC2 Auto Scaling, see the *Amazon EC2 Auto Scaling* section on [Amazon Elastic Compute Cloud Documentation](https://aws.amazon.com/documentation/ec2/).

# Configuring notifications using AWS toolkit for Visual Studio
<a name="create_deploy_NET.container.sns"></a>

Elastic Beanstalk uses the Amazon Simple Notification Service (Amazon SNS) to notify you of important events affecting your application. To enable Amazon SNS notifications, simply enter your email address in the **Email Address** box. To disable these notifications, remove your email address from the box.

![\[Elastic Beanstalk notifications window\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-notifications.png)


# Configuring .NET containers using the AWS toolkit for Visual Studio
<a name="create_deploy_NET.container"></a>

 The **Container/.NET Options** panel lets you fine-tune the behavior of your Amazon EC2 instances and enable or disable Amazon S3 log rotation. You can use the AWS Toolkit for Visual Studio to configure your container information.

**Note**  
You can modify your configuration settings with zero downtime by swapping the CNAME for your environments. For more information, see [Blue/Green deployments with Elastic Beanstalk](using-features.CNAMESwap.md).

If you want to, you can extend the number of parameters. For information about extending parameters, see [Option settings](ebextensions-optionsettings.md).

**To access the Container/.NET options panel for your Elastic Beanstalk application**

1. In AWS Toolkit for Visual Studio, expand the Elastic Beanstalk node and your application node. 

1. In **AWS Explorer**, double-click your Elastic Beanstalk environment.

1. At the bottom of the **Overview** pane, click the **Configuration** tab.

1. Under **Container**, you can configure container options.   
![\[Elastic Beanstalk container panel\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-container.png)

## .NET container options
<a name="create_deploy_NET.container.vs.options"></a>

You can choose the version of .NET Framework for your application. Choose either 2.0 or 4.0 for **Target runtime**. Select **Enable 32-bit Applications** if you want to enable 32-bit applications.

## Application settings
<a name="create_deploy_NET.container.vs.options.envprop"></a>

The **Application Settings** section lets you specify environment variables that you can read from your application code. 

![\[Elastic Beanstalk container panel\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-container-envproperties.png)


# Managing accounts
<a name="create_deploy_NET.accounts"></a>

## 
<a name="create_deploy_NET.accounts.details"></a>

If you want to set up different AWS accounts to perform different tasks, such as testing, staging, and production, you can add, edit, and delete accounts using the AWS Toolkit for Visual Studio.

**To manage multiple accounts**

1.  In Visual Studio, on the **View** menu, click **AWS Explorer**.

1.  Beside the **Account** list, click the **Add Account** button.   
![\[AWS explorer tab\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-aws-explorer-tab.png)

    The **Add Account** dialog box appears.   
![\[Add account dialog box\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-add-account.png)

1. Fill in the requested information. 

1.  Your account information now appears on the **AWS Explorer** tab. When you publish to Elastic Beanstalk, you can select which account you would like to use. 

# Listing and connecting to server instances
<a name="create_deploy_NET.ec2connect"></a>

You can view a list of Amazon EC2 instances running your Elastic Beanstalk application environment through the AWS Toolkit for Visual Studio or from the AWS Management Console. You can connect to these instances using Remote Desktop Connection. For information about listing and connecting to your server instances using the AWS Management Console, see [Listing and connecting to server instances](using-features.ec2connect.md). The following section steps you through viewing and connecting you to your server instances using the AWS Toolkit for Visual Studio.

**To view and connect to Amazon EC2 instances for an environment**

1.  In Visual Studio, in **AWS Explorer**, expand the **Amazon EC2** node and double-click **Instances**. 

1.  Right-click the instance ID for the Amazon EC2 instance running in your application's load balancer in the **Instance** column and select **Open Remote Desktop** from the context menu.   
![\[Open remote desktop dialog box\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-rdp-login.png)

1.  Select **Use EC2 keypair to log on** and paste the contents of your private key file that you used to deploy your application in the **Private key** box. Alternatively, enter your user name and password in the **User name** and **Password** text boxes.
**Note**  
If the key pair is stored inside the Toolkit, the text box does not appear.

1. Click **OK**.

# Monitoring application health
<a name="create_deploy_NET.healthstatus"></a>

When you are running a production website, it is important to know that your application is available and responding to requests. To assist with monitoring your application’s responsiveness, Elastic Beanstalk provides features where you can monitor statistics about your application and create alerts that trigger when thresholds are exceeded.

For information about the health monitoring provided by Elastic Beanstalk, see [Basic health reporting](using-features.healthstatus.md).

You can access operational information about your application by using either the AWS Toolkit for Visual Studio or the AWS Management Console.

The toolkit displays your environment's status and application health in the **Status** field.

![\[Elastic Beanstalk health status\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-env-status.png)


**To monitor application health**

1. In the AWS Toolkit for Visual Studio, in **AWS Explorer**, expand the Elastic Beanstalk node, and then expand your application node. 

1. Right-click your Elastic Beanstalk environment, and then click **View Status**.

1. On your application environment tab, click **Monitoring**.

   The **Monitoring** panel includes a set of graphs showing resource usage for your particular application environment.  
![\[Elastic Beanstalk monitoring panel\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-monitoring.png)
**Note**  
By default, the time range is set to the last hour. To modify this setting, in the **Time Range** list, click a different time range.

You can use the AWS Toolkit for Visual Studio or the AWS Management Console to view events associated with your application.

**To view application events**

1. In the AWS Toolkit for Visual Studio, in **AWS Explorer**, expand the Elastic Beanstalk node and your application node. 

1. Right-click your Elastic Beanstalk environment in **AWS Explorer** and then click **View Status**. 

1. In your application environment tab, click **Events**.  
![\[Elastic Beanstalk events panel\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-vs-events.png)

# Deploying Elastic Beanstalk applications in .NET using AWS deployment tools
<a name="deploy_NET_standalone_tool"></a>

AWS offers two command line tools to deploy .NET Core and ASP.NET Core applications to Elastic Beanstalk:
+ **AWS .NET deployment tool** – A modern command line tool that simplifies deploying .NET applications to AWS services, including Elastic Beanstalk. This tool provides an interactive experience and can automatically detect the best AWS service for your application. For more information, see [AWS .NET deployment tool](https://github.com/aws/aws-dotnet-deploy?tab=readme-ov-file#aws-net-deployment-tool).
+ **AWS Extensions for .NET CLI** – A set of .NET CLI extensions that provide commands for deploying .NET Core applications to Elastic Beanstalk and other AWS services. These extensions integrate with the standard .NET CLI workflow. For more information, see [AWS Extensions for .NET CLI](https://github.com/aws/aws-extensions-for-dotnet-cli?tab=readme-ov-file#aws-elastic-beanstalk-amazonelasticbeanstalktools).

# Migrating your on-premises .NET application to Elastic Beanstalk
<a name="dotnet-onpremmigration"></a>

AWS Elastic Beanstalk provides a streamlined migration path for your Windows applications running on Internet Information Services (IIS) through the Elastic Beanstalk Command Line Interface (EB CLI). The **eb migrate** command automatically discovers your IIS sites, applications, and virtual directories, preserves their configurations, and deploys them to the AWS Cloud.

This built-in migration capability offers a simpler approach that reduces the complexity and time typically associated with cloud migrations. The migration process helps maintain application functionality and configuration integrity during the transition to AWS.

For complete, detailed instructions about migrating your IIS applications to AWS Elastic Beanstalk, refer to the [Migrating IIS applications to Elastic Beanstalk](dotnet-migrating-applications.md) chapter in this guide.

# Recommendations for Windows Server retired components on Elastic Beanstalk
<a name="dotnet-deprecation-recommendations"></a>

This topic provides recommendations if your applications are currently running on the retired Windows Server 2012 R2 platform branches. It also addresses the deprecated support for the TLS 1.0 and 1.1 protocol versions on our AWS service API endpoints and the impacted platform branches.

## Windows Server 2012 R2 platform branches retired
<a name="dotnet-retired-branches"></a>

Elastic Beanstalk retired Windows Server 2012 R2 platform branches on [December 4, 2023](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2023-12-04-windows-2012-retire.html), and made the AMIs associated with those platforms private on April 10, 2024. This action prevents the launching of instances in your Windows Server 2012 environments that use the default Beanstalk AMI.

If you have any environments running on retired Windows platform branches we recommend that you migrate them to one of the following Windows Server platforms, which are current and fully supported:
+ Windows Server 2022 with IIS 10.0 version 2.x
+ Windows Server 2019 with IIS 10.0 version 2.x

For full migration considerations, see [Migrating from earlier major versions of the Windows server platform](dotnet-v2migration.md#dotnet-v2migration.migration).

For more information about platform deprecation, see [Elastic Beanstalk platform support policy](platforms-support-policy.md).

**Note**  
If you cannot migrate to these fully supported platforms, we recommend using custom AMIs created with Windows Server 2012 R2 or Windows Server 2012 R2 Core AMIs as the base image, if you have not done so already. For detailed instructions, see [Preserving access to an Amazon Machine Image (AMI) for a retired platform](using-features.customenv-env-copy.md). Reach out to the [AWS Support Center](https://console.aws.amazon.com/support/home#/) if you need temporary access to an AMI while you perform one of these migration steps.

## TLS 1.2 Compatibility
<a name="tls-1-2-enforcement."></a>

As of December 31, 2023, AWS started fully enforcing TLS 1.2 across all AWS API endpoints. This action removed the ability to use TLS versions 1.0 and 1.1 with all AWS APIs. This information was originally communicated on [June 28, 2022](https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/). To avoid the risk of availability impact, upgrade any environments running the platform versions identified here to a newer version as soon as possible, if you have not done so already.

**Potential impact**  
Elastic Beanstalk platforms versions that run TLS v1.1 or earlier are impacted. This change impacts environment actions that include but are not limited to the following: configuration deployments, application deployments, auto scaling, new environment launch, log rotation, enhanced health reports, and publishing application logs to the Amazon S3 bucket that's associated with your applications.

**Affected Windows Platform Versions**  
Customers with Elastic Beanstalk environments on the following platform version are advised to upgrade each of their corresponding environments to Windows platform version 2.8.3 or later, released on [ Feb 18, 2022](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2022-02-18-windows.html).
+ Windows Server 2019 — platform version 2.8.2 or prior versions

Customers with Elastic Beanstalk environments on the following platform versions are advised to upgrade each of their corresponding environments to Windows platform version 2.10.7 or later, released on [ Dec 28, 2022](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2022-12-28-windows.html).
+ Windows Server 2016 — platform version 2.10.6 or prior versions
+ Windows Server 2012 — all platform versions; this platform was retired on [December 4, 2023](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2023-12-04-windows-2012-retire.html) 
+ Windows Server 2008 — all platform versions; this platform was retired on [October 28, 2019](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2019-10-28-windows.html) 

For a list of the most recent and supported Windows Server platform versions, see [Supported Platforms](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net) in the *AWS Elastic Beanstalk Platforms* guide. 

For details and best practices about updating your environment, see [Updating your Elastic Beanstalk environment's platform version](using-features.platform.upgrade.md).