# Deploying to AWS The Toolkit for Visual Studio supports application deployment to AWS Elastic Beanstalk containers or CloudFormation stacks. **Note** If you are using Visual Studio Express Edition: You can use the [Docker CLI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/docker-basics.use-ecr.html) to deploy applications to Amazon ECS containers. You can use the [AWS Management Console](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.deployment.newapp.html) to deploy applications to Elastic Beanstalk containers. For Elastic Beanstalk deployments, you must first create a web deployment package. For more information, see [How to: Create a Web Deployment Package in Visual Studio](http://msdn.microsoft.com/en-us/library/dd465323.aspx). For Amazon ECS deployment, you must have a Docker image. For more information, see [Visual Studio Tools for Docker](http://docs.microsoft.com/en-us/aspnet/core/publishing/visual-studio-tools-for-docker). **Topics** + [Publish to AWS](publish-experience.md) + [AWS Lambda](lambda-cli-publish.md) + [Deploying to AWS Elastic Beanstalk](deployment-beanstalk.md) + [Deploying to Amazon EC2 Container Service](deployment-ecs.md) # Working with Publish to AWS in Visual Studio **Publish to AWS** is an interactive deployment experience that assists you with publishing your .NET applications to AWS deployment targets, supporting applications targeting .NET Core 3.1 and later. Working with Publish to AWS keeps your work flow inside of Visual Studio by making these deployment features available, directly from your IDE: + The ability to deploy your application with a single click. + Deployment recommendations based on your application. + Automatic Dockerfile creation, as is relevant and required by your deployment destination's environment (deployment target). + Optimized settings for building and packaging your applications, as required by your deployment target. **Note** For additional information about publishing .NET Framework applications, see the guide [Creating and deploying .NET applications on Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_NET.html) You can also access Publish to AWS from the .NET CLI. For more information, see the [Deploy .NET applications on AWS](https://aws.github.io/aws-dotnet-deploy/) guide. **Topics** + [Prerequisites](#publish-experience-prerequisities) + [Supported application types](#publish-experience-apptypes) + [Publishing applications to AWS targets](#publish-experience-deployment) ## Prerequisites To successfully publish .NET applications to an AWS service, install the following to your local device: + .NET Core 3.1\$1(which includes .NET5 and .NET6): For additional information about these products and download information, visit the [Microsoft download site](https://dotnet.microsoft.com/download). + Node.js 14.x or later version: Node.js is required to run AWS Cloud Development Kit (AWS CDK). To download or obtain more information about Node.js, visit the [Node.js download site](https://nodejs.org/en/download/). **Note** Publish to AWS utilizes AWS CDK to deploy your application and all of its deployment infrastructure as a single project. For more information about AWS CDK see the [Cloud Development Kit](https://docs.aws.amazon.com/cdk/v1/guide/home.html) guide. + (Optional) Docker is used when deploying to a container-based service such as Amazon ECS. For more information and to download Docker, see the [Docker download](https://docs.docker.com/get-docker/) site. ## Supported application types Before publishing to a new or exiting target, begin by creating or opening one of the following project types in Visual Studio: + ASP.NET Core application + .NET Console application + Blazor WebAssembly application ## Publishing applications to AWS targets When publishing to a new target, Publish to AWS will guide you through the process by making recommendations and using common settings. If you need to publish to a target that was set up previously, your preferences are stored and can be adjusted, or are immediately available for one-click deployment. **Note** **Toolkits integration with the .NET CLI Server:** Publishing launches a .NET server process on the localhost to perform the publication process. ### Publish to a new target The following describes how to configure your Publish to AWS deployment preferences, when you're publishing to a new target. 1. From the **AWS Explorer**, expand the **Credentials** drop-down menu, then choose the AWS profile that corresponds with the region and AWS services that are required for your deployment. 1. Expand the **Region** drop-down menu, then choose the AWS region that contains the AWS services that are necessary for your deployment. 1. From the Visual Studio **Solutions Explorer** pane, open the context menu for (right-click) the project's name, and choose **Publish to AWS**. This will open **Publish to AWS**. 1. From **Publish to AWS**, choose **Publish to New Target** to configure a new deployment. **Note** To modify your default deployment credentials, choose or click the **Edit** link located next to the **Credentials** section, in **Publish to AWS**. To bypass the target configuration process, choose **Publish to Existing Target**, then pick your preferred configuration from the list of your previous deployment targets. 1. From the **Publish Targets** pane, choose an AWS service to manage your application deployment. 1. When you are satisfied with your configuration, choose **Publish** to start the deployment process. **Note** After initiating a deployment, **Publish to AWS** displays the following status updates: During the deployment process, **Publish to AWS** displays information about the deployment's progress. Following the deployment process, **Publish to AWS** indicates if the deployment succeeded or failed. After a successful deployment, the **Resources** panel offers additional information about the resource that was created. This information will vary depending on the type of application and deployment configuration. ### Publish to an existing target The following describes how to republish your .NET application to an existing AWS target. 1. From the **AWS Explorer**, expand the **Credentials** drop-down menu, then choose the AWS profile that corresponds with the region and AWS services that are required for your deployment. 1. Expand the **Region** drop-down menu, then choose the AWS region that contains the AWS services that are necessary for your deployment. 1. From the Visual Studio **Solutions Explorer** pane, right-click the project's name and choose **Publish to AWS** to open **Publish to AWS**. 1. From **Publish to AWS**, choose **Publish to Existing Target** to select your deployment environment from a list of existing targets. **Note** If you have recently published any applications to the AWS Cloud, those applications are displayed in Publish to AWS. 1. Select the publishing target that you want to deploy your application to, then click **Publish** to start the deployment process. # Deploying an AWS Lambda Project with the .NET Core CLI The AWS Toolkit for Visual Studio includes AWS Lambda .NET Core project templates for Visual Studio. You can deploy Lambda functions built in Visual Studio using the .NET Core command line interface (CLI). **Topics** + [Prerequisites](#lambda-cli-prereqs) + [Related topics](#lambda-cli-related) + [Listing the Lambda Commands Available through the .NET Core CLI](#listing-the-lam-commands-available-through-the-cli) + [Publishing a .NET Core Lambda Project from the .NET Core CLI](#publishing-a-net-core-lam-project-from-the-net-core-cli) ## Prerequisites Before working with .NET Core CLI to deploy Lambda functions, you must meet the following prerequisites: + Be sure Visual Studio 2015 Update 3 is installed. + Install [.NET Core for Windows](https://dotnet.microsoft.com/download#windowsvs2015). + Set up the .NET Core CLI to work with Lambda. For more information, see [.NET Core CLI](https://docs.aws.amazon.com//lambda/latest/dg/csharp-package-cli.html) in the *AWS Lambda Developer Guide*. + Install the Toolkit for Visual Studio. For more information, see [Installing the AWS Toolkit for Visual Studio](setup.md#install). ## Related topics The following related topics can be helpful as you use the .NET Core CLI to deploy Lambda functions: + For more information about Lambda functions, see [What is AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) in the *AWS Lambda Developer Guide*. + For information about creating Lambda functions in Visual Studio, see [AWS Lambda](lambda-index.md). + For more information about Microsoft .NET Core, see [.NET Core](https://docs.microsoft.com/en-us/dotnet/articles/core/) in Microsoft's online documentation. ## Listing the Lambda Commands Available through the .NET Core CLI To list the Lambda commands that are available through the .NET Core CLI, do the following. 1. Open a command prompt window, and navigate to the folder containing a Visual Studio .NET Core Lambda project. 1. Enter `dotnet lambda --help`. ``` C:\Lambda\AWSLambda1\AWSLambda1>dotnet lambda --help AWS Lambda Tools for .NET Core functions Project Home: https://github.com/aws/aws-lambda-dotnet . Commands to deploy and manage Lambda functions: . deploy-function Deploy the project to Lambda invoke-function Invoke the function in Lambda with an optional input list-functions List all of your Lambda functions delete-function Delete a Lambda function get-function-config Get the current runtime configuration for a Lambda function update-function-config Update the runtime configuration for a Lambda function . Commands to deploy and manage AWS serverless applications using AWS CloudFormation: . deploy-serverless Deploy an AWS serverless application list-serverless List all of your AWS serverless applications delete-serverless Delete an AWS serverless application . Other Commands: . package Package a Lambda project into a .zip file ready for deployment . To get help on individual commands, run the following: dotnet lambda help ``` ## Publishing a .NET Core Lambda Project from the .NET Core CLI The following instructions assume you've created an AWS Lambda .NET Core function in Visual Studio. 1. Open a command prompt window, and navigate to the folder containing your Visual Studio .NET Core Lambda project. 1. Enter `dotnet lambda deploy-function`. 1. When prompted, enter the name of the function to deploy. It can be a new name or the name of an existing function. 1. When prompted, enter the AWS Region (the Region to which your Lambda function will be deployed). 1. When prompted, select or create the IAM role that Lambda will assume when executing the function. On successful completion, the message **New Lambda function created** is displayed. ``` C:\Lambda\AWSLambda1\AWSLambda1>dotnet lambda deploy-function Executing publish command ... invoking 'dotnet publish', working folder 'C:\Lambda\AWSLambda1\AWSLambda1\bin\Release\netcoreapp1.0\publish' ... publish: Publishing AWSLambda1 for .NETCoreApp,Version=v1.0 ... publish: Project AWSLambda1 (.NETCoreApp,Version=v1.0) will be compiled because expected outputs are missing ... publish: Compiling AWSLambda1 for .NETCoreApp,Version=v1.0 ... publish: Compilation succeeded. ... publish: 0 Warning(s) ... publish: 0 Error(s) ... publish: Time elapsed 00:00:01.2479713 ... publish: ... publish: publish: Published to C:\Lambda\AWSLambda1\AWSLambda1\bin\Release\netcoreapp1.0\publish ... publish: Published 1/1 projects successfully Zipping publish folder C:\Lambda\AWSLambda1\AWSLambda1\bin\Release\netcoreapp1.0\publish to C:\Lambda\AWSLambda1\AWSLamb da1\bin\Release\netcoreapp1.0\AWSLambda1.zip Enter Function Name: (AWS Lambda function name) DotNetCoreLambdaTest Enter AWS Region: (The region to connect to AWS services) us-west-2 Creating new Lambda function Select IAM Role that Lambda will assume when executing function: 1) lambda_exec_LambdaCoreFunction 2) *** Create new IAM Role *** 1 New Lambda function created ``` If you deploy an existing function, the deploy function asks only for the AWS Region. ``` C:\Lambda\AWSLambda1\AWSLambda1>dotnet lambda deploy-function Executing publish command Deleted previous publish folder ... invoking 'dotnet publish', working folder 'C:\Lambda\AWSLambda1\AWSLambda1\bin\Release\netcoreapp1.0\publish' ... publish: Publishing AWSLambda1 for .NETCoreApp,Version=v1.0 ... publish: Project AWSLambda1 (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation. ... publish: publish: Published to C:\Lambda\AWSLambda1\AWSLambda1\bin\Release\netcoreapp1.0\publish ... publish: Published 1/1 projects successfully Zipping publish folder C:\Lambda\AWSLambda1\AWSLambda1\bin\Release\netcoreapp1.0\publish to C:\Lambda\AWSLambda1\AWSLamb da1\bin\Release\netcoreapp1.0\AWSLambda1.zip Enter Function Name: (AWS Lambda function name) DotNetCoreLambdaTest Enter AWS Region: (The region to connect to AWS services) us-west-2 Updating code for existing function ``` After your Lambda function is deployed, it's ready to use. For more information, see [Examples of How to Use AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/use-cases.html). Lambda automatically monitors Lambda functions for you, reporting metrics through Amazon CloudWatch. To monitor and troubleshoot your Lambda function, see [Troubleshooting and Monitoring AWS Lambda Functions with Amazon CloudWatch](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions.html). # Deploying to AWS Elastic Beanstalk in Visual Studio using AWS Toolkit for Visual Studio with Amazon Q AWS Elastic Beanstalk is a service that simplifies the process of provisioning AWS resources for your application. Elastic Beanstalk provides all of the AWS infrastructure required to deploy your application. This infrastructure includes: + Amazon EC2 instances that host the executables and content for your application. + An Auto Scaling group to maintain the appropriate number of Amazon EC2 instances to support your application. + An Elastic Load Balancing load balancer that routes incoming traffic to the Amazon EC2 instance with the most bandwidth. This user guide topic describes how to work with the Elastic Beanstalk wizard in the AWS Toolkit with Amazon Q. For detailed information specific to Elastic Beanstalk, see the [AWS Elastic Beanstalk](https://docs.aws.amazon.com//elasticbeanstalk/latest/dg/Welcome.html) Developer Guide. The Elastic Beanstalk wizard for the AWS Toolkit with Amazon Q is described in the following topic sections. **Topics** + [Deploy an ASP.NET App (Traditional)](deployment-beanstalk-traditional.md) + [Deploy an ASP.NET App (.NET Core) (Legacy)](deployment-beanstalk-netcore.md) + [Specify AWS Credentials](deployment-beanstalk-specify-credentials.md) + [Republish to Elastic Beanstalk (Legacy)](deployment-beanstalk-republish.md) + [Custom Deployments (Traditional)](deployment-beanstalk-custom.md) + [Custom Deployments (.NET Core)](deployment-beanstalk-custom-netcore.md) + [Multiple Application Support](deployment-beanstalk-multiple-application.md) # Deploy a Traditional ASP.NET Application to Elastic Beanstalk This section describes how to use the **Publish to Elastic Beanstalk** wizard, provided as part of the Toolkit for Visual Studio, to deploy an application through Elastic Beanstalk. To practice, you can use an instance of a web application starter project that is built in to Visual Studio or you can use your own project. **Note** The wizard also supports deploying ASP.NET Core applications. For information about ASP.NET Core, see the [AWS .NET deployment tool](https://aws.github.io/aws-dotnet-deploy/) guide and the updated [Deploying to AWS](https://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/deployment-chapt.html) table of contents. **Note** Before you can use the **Publish to Elastic Beanstalk** wizard, you must download and install [Web Deploy](http://www.microsoft.com/en-us/download/details.aspx?id=39277). The wizard relies on Web Deploy to deploy web applications and websites to Internet Information Services (IIS) web servers. ## To create a sample web application starter project 1. In Visual Studio, from the **File** menu, choose **New**, and then choose **Project**. 1. In the navigation pane of the **New Project** dialog box, expand **Installed**, expand **Templates**, expand **Visual C\$1**, and then choose **Web**. 1. In the list of web project templates, choose any template containing the words `Web` and `Application` in its description. For this example, choose **ASP.NET Web Forms Application**. ![\[New Project window showing ASP.NET web application templates for Visual C# in .NET Framework 4.5.\]](http://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/images/tkv-new-web-project-console.png) 1. In the **Name** box, type `AEBWebAppDemo`. 1. In the **Location** box, type the path to a solution folder on your development machine or choose **Browse**, and then browse to and choose a solution folder, and choose **Select Folder**. 1. Confirm the **Create directory for solution** box is selected. In the **Solution** drop-down list, confirm **Create new solution** is selected, and then choose **OK**. Visual Studio will create a solution and project based on the ASP.NET Web Forms Application project template. Visual Studio will then display Solution Explorer where the new solution and project appear. ![\[Solution Explorer window showing project structure with folders and files for a web application.\]](http://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/images/tkv-web-app-solution-explorer-console.png) ## To deploy an application by using the Publish to Elastic Beanstalk wizard 1. In Solution Explorer, open the context (right-click) menu for the **AEBWebAppDemo** project folder for the project you created in the previous section, or open the context menu for the project folder for your own application, and choose **Publish to AWS Elastic Beanstalk**. ![\[Solution Explorer context menu showing "Publish to AWS..." option for AEBWebAppDemo project.\]](http://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/images/tkv-publish-to-aws-console.png) The **Publish to Elastic Beanstalk** wizard appears. ![\[Publish to AWS Elastic Beanstalk wizard interface for creating or redeploying an application environment.\]](http://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/images/tkv-aeb-wizard-app-console.png) 1. In **Profile**, from the **Account profile to use for deployment** drop-down list, choose the AWS account profile you want to use for the deployment. Optionally, if you have an AWS account you want to use, but you haven't yet created an AWS account profile for it, you can choose the button with the plus symbol (`+`) to add an AWS account profile. 1. From the **Region** drop-down list, choose the region to which you want Elastic Beanstalk to deploy the application. 1. In **Deployment Target**, you can choose either **Create a new application environment** to perform an initial deployment of an application or **Redeploy to an existing environment** to redeploy a previously deployed application. (The previous deployments may have been performed with either the wizard or the deprecated Standalone Deployment Tool.) If you choose **Redeploy to an existing environment**, there may be a delay while the wizard retrieves information from previous deployments that are currently running. **Note** If you choose **Redeploy to an existing environment**, choose an environment in the list, and then choose **Next**, the wizard will take you directly to the **Application Options** page. If you go this route, skip ahead to the instructions later in this section that describe how to use the **Application Options** page. 1. Choose **Next**. ![\[Application Environment setup page for AWS with fields for name, environment, and URL.\]](http://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/images/tkv-aeb-wizard-env-console.png) 1. On the **Application Environment** page, in the **Application** area, the **Name** drop-down list proposes a default name for the application. You can change the default name by choosing a different name from the drop-down list. 1. In the **Environment** area, in the **Name** drop-down list, type a name for your Elastic Beanstalk environment. In this context, the term *environment* refers to the infrastructure Elastic Beanstalk provisions for your application. A default name may already be proposed in this drop-down list. If a default name is not already proposed, you can type one or choose one from the drop-down list, if any additional names are available. The environment name cannot be longer than 23 characters. 1. In the **URL** area, the box proposes a default subdomain of `.elasticbeanstalk.com` that will be the URL for your web application. You can change the default subdomain by typing a new subdomain name. 1. Choose **Check availability** to make sure the URL for your web application is not already in use. 1. If the URL for your web application is okay to use, choose **Next**. ![\[AWS EC2 launch configuration settings for deploying an application to Amazon Web Services.\]](http://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/images/tkv-aeb-wizard-ec2-console.png) 1. On the **AWS Options** page, in **Amazon EC2 Launch Configuration**, from the **Container type** drop-down list, choose an Amazon Machine Image (AMI) type that will be used for your application. 1. In the **Instance type** drop-down list, specify an Amazon EC2 instance type to use. For this example, we recommend you use **Micro**. This will minimize the cost associated with running the instance. For more information about Amazon EC2 costs, go to the [EC2 Pricing](https://aws.amazon.com/ec2/pricing/) page. 1. In the **Key pair** drop-down list, choose an Amazon EC2 instance key pair to use to sign in to the instances that will be used for your application. 1. Optionally, in the **Use custom AMI** box, you can specify a custom AMI that will override the AMI specified in the **Container type** drop-down list. For more information about how to create a custom AMI, go to [Using Custom AMIs](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.customami.html) in the [AWS Elastic Beanstalk Developer Guide](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/) and [Create an AMI from an Amazon EC2 Instance](tkv-create-ami-from-instance.md). 1. Optionally, if you want to launch your instances in a VPC, select the **Use a VPC** box. 1. Optionally, if you want to launch a single Amazon EC2 instance and then deploy your application to it, select the **Single instance environment** box. If you select this box, Elastic Beanstalk will still create an Auto Scaling group, but will not configure it. If you want to configure the Auto Scaling group later, you can use the AWS Management Console. 1. Optionally, if you want to control the conditions under which your application is deployed to the instances, select the **Enable Rolling Deployments** box. You can select this box only if you have not selected the **Single instance environment** box. 1. If your application uses AWS services such as Amazon S3 and DynamoDB, the best way to provide credentials is to use an IAM role. In the **Deployed Application Permissions** area, you can either choose an existing IAM role or create one the wizard will use to launch your environment. Applications using the AWS SDK for .NET will automatically use the credentials provided by this IAM role when making a request to an AWS service. 1. If your application accesses an Amazon RDS database, in the drop-down list in the **Relational Database Access** area, select the boxes next to any Amazon RDS security groups the wizard will update so that your Amazon EC2 instances can access that database. 1. Choose **Next**. + If you selected **Use a VPC**, the **VPC Options** page will appear. + If you selected **Enable Rolling Deployments**, but did not select **Use a VPC**, the **Rolling Deployments** page will appear. Skip ahead to the instructions later in this section that describe how to use the **Rolling Deployments** page. + If you did not select **Use a VPC** or **Enable Rolling Deployments**, the **Application Options** page will appear. Skip ahead to the instructions later in this section that describe how to use the **Application Options** page. 1. If you selected **Use a VPC**, specify information on the **VPC Options** page to launch your application into a VPC. ![\[VPC Options interface for configuring AWS Elastic Beanstalk application deployment settings.\]](http://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/images/tkv-aeb-wizard-vpc-console.png) The VPC must have already been created. If you created the VPC in the Toolkit for Visual Studio, the Toolkit for Visual Studio will populate this page for you. If you created the VPC in the [AWS Management Console](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo-vpc-basic.html), type information about your VPC into this page. ## Key considerations for deployment to a VPC + Your VPC needs at least one public and one private subnet. + In the *ELB Subnet* drop-down list, specify the public subnet. The Toolkit for Visual Studio deploys the Elastic Load Balancing load balancer for your application to the public subnet. The public subnet is associated with a routing table that has an entry that points to an Internet gateway. You can recognize an Internet gateway because it has an ID that begins with `igw-` (for example, `igw-83cddaex`). Public subnets that you create by using the Toolkit for Visual Studio have tag values that identify them as public. + In the *Instances Subnet* drop-down list, specify the private subnet. The Toolkit for Visual Studio deploys the Amazon EC2 instances for your application to the private subnet. + The Amazon EC2 instances for your application communicate from the private subnet to the Internet through an Amazon EC2 instance in the public subnet that performs network address translation (NAT). To enable this communication, you will need a [VPC security group](https://console.aws.amazon.com/vpc/home) that allows traffic to flow from the private subnet to the NAT instance. Specify this VPC security group in the *Security Group* drop-down list. For more information about how to deploy an Elastic Beanstalk application to a VPC, go to the [AWS Elastic Beanstalk Developer Guide](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/). 1. After you have filled in all of the information on the **VPC Options** page, choose **Next**. + If you selected **Enable Rolling Deployments**, the **Rolling Deployments** page will appear. + If you did not select **Enable Rolling Deployments**, the **Application Options** page will appear. Skip ahead to the instructions later in this section that describe how to use the **Application Options** page. 1. If you selected **Enable Rolling Deployments**, you specify information on the **Rolling Deployments** page to configure how new versions of your applications are deployed to the instances in a load-balanced environment. For example, if you have four instances in your environment and you want to change the instance type, you can configure the environment to change two instances at a time. This helps ensure your application is still running while changes are being made. ![\[Rolling Deployments configuration interface for AWS application updates and environment settings.\]](http://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/images/tkv-aeb-wizard-rolling-console.png) 1. In the *Application Versions* area, choose an option to control deployments to either a percentage or number of instances at a time. Specify either the desired percentage or number. 1. Optionally, in the *Environment Configuration* area, select the box if you want to specify the number of instances that remain in service during deployments. If you select this box, specify the maximum number of instances that should be modified at a time, the minimum number of instances that should remain in service at a time, or both. 1. Choose *Next*. 1. On the **Application Options** page, you specify information about build, Internet Information Services (IIS), and application settings. ![\[Application Options interface for configuring build and deployment settings for AWS.\]](http://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/images/tkv-aeb-wizard-options-console.png) 1. In the **Build and IIS Deployment Settings** area, in the **Project build configuration** drop-down list, choose the target build configuration. If the wizard can find it, **Release** appears otherwise, the active configuration is displayed in this box. 1. In the **App pool** drop-down list, choose the version of the .NET Framework required by your application. The correct .NET Framework version should already be displayed. 1. If your application is 32-bit, select the **Enable 32-bit applications** box. 1. In the **App path** box, specify the path IIS will use to deploy the application. By default, **Default Web Site/** is specified, which typically translates to the path `c:\inetpub\wwwroot`. If you specify a path other than **Default Web Site/**, the wizard will place a redirect in the **Default Web Site/** path that points to the path you specified. 1. In the **Application Settings** area, in the **Health check URL** box, type a URL for Elastic Beanstalk to check to determine if your web application is still responsive. This URL is relative to the root server URL. The root server URL is specified by default. For example, if the full URL is `example.com/site-is-up.html`, you would type `/site-is-up.html`. 1. In the area for **Key** and **Value**, you can specify any key and value pairs you want to add to your application's `Web.config` file. **Note** Although not recommended, you can use the area for **Key** and **Value**, to specify AWS credentials under which your application should run. The preferred approach is to specify an IAM role in the **Identity and Access Management Role** drop-down list on the **AWS Options** page. However, if you must use AWS credentials instead of an IAM role to run your application, in the **Key** row, choose **AWSAccessKey**. In the **Value** row, type the access key. Repeat these steps for **AWSSecretKey**. 1. Choose **Next**. ![\[Review window for publishing an application to AWS Elastic Beanstalk with deployment details.\]](http://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/images/tkv-aeb-wizard-review-console.png) 1. On the **Review** page, review the options you configured, and select the **Open environment status window when wizard closes** box. 1. If everything looks correct, choose **Deploy**. **Note** When you deploy the application, the active account will incur charges for the AWS resources used by the application. Information about the deployment will appear in the Visual Studio status bar and the **Output** window. It may take several minutes. When the deployment is complete, a confirmation message will appear in the **Output** window. 1. To delete the deployment, in AWS Explorer, expand the **Elastic Beanstalk** node, open the context (right-click) menu for the subnode for the deployment, and then choose **Delete**. The deletion process might take a few minutes. # Deploying an ASP.NET Core Application to Elastic Beanstalk (Legacy) **Important** This documentation refers to legacy services and features. For updated guides and content, see the [AWS .NET deployment tool](https://aws.github.io/aws-dotnet-deploy/) guide and the updated [Deploying to AWS](https://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/deployment-chapt.html) table of contents. AWS Elastic Beanstalk is a service that simplifies the process of provisioning AWS resources for your application. AWS Elastic Beanstalk provides all of the AWS infrastructure required to deploy your application. The Toolkit for Visual Studio supports deploying ASP.NET Core applications to AWS using Elastic Beanstalk. ASP.NET Core is the redesign of ASP.NET with a modularized architecture that minimizes dependency overhead and streamlines your application to run in the cloud. AWS Elastic Beanstalk makes it easy to deploy applications in a variety of different languages to AWS. Elastic Beanstalk supports both traditional ASP.NET applications and ASP.NET Core applications. This topic describes deploying ASP.NET Core applications. ## Using the Deployment Wizard The easiest way to deploy ASP.NET Core applications to Elastic Beanstalk is with the Toolkit for Visual Studio. If you have used the toolkit before to deploy traditional ASP. NET applications, you'll find the experience for ASP.NET Core to be very similar. In the steps below, we'll walk through the deployment experience. If you have never used the toolkit before, the first thing you'll need to do after installing the toolkit is register your AWS credentials with the toolkit. See [How to Specify the AWS Security Credentials for Your Application](deployment-beanstalk-specify-credentials.md#tkv-deploy-specify-credentials-for-application) for Visual Studio documentation for details on how to do so. To deploy an ASP.NET Core web application, right-click the project in the Solution Explorer and select **Publish to AWS…**. On the first page of the Publish to AWS Elastic Beanstalk deployment wizard, choose to create a new Elastic Beanstalk application. An Elastic Beanstalk application is a logical collection of Elastic Beanstalk components, including environments, versions, and environment configurations. The deployment wizard generates an application that in turn contains a collection of application versions and environments. The environments contain the actual AWS resources that run an application version. Every time you deploy an application, a new application version is created and the wizard points the environment to that version. You can learn more about these concepts in [Elastic Beanstalk Components.](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/concepts.components.html). Next, set names for the application and its first environment. Each environment has a unique CNAME associated with it that you can use to access the application when the deployment is complete. The next page, **AWS Options**, allows you to configure the type of AWS resources to use. For this example, leave the default values, except for the **Key pair** section. Key pairs allow you retrieve the Windows administrator password so you can log on to the machine. If you haven't already created a key pair you might want to select **Create new key pair**. ## Permissions The **Permissions** page is used for assigning AWS credentials to the EC2 instances running your application. This is important if your application uses the AWS SDK for .NET to access other AWS services. If you are not using any other services from your application then you can leave this page at its default. ## Application Options The details on the **Application Options** page are different from those specified when deploying traditional ASP.NET applications. Here, you specify the build configuration and framework used to package the application, and also specify the IIS resource path for the application. After completing the **Application Options** page, click **Next** to review the settings, then click **Deploy** to begin the deployment process. ## Checking Environment Status After the application is packaged and uploaded to AWS, you can check the status of the Elastic Beanstalk environment by opening the environment status view from the AWS Explorer in Visual Studio. Events are displayed in the status bar as the environment is coming online. Once everything is complete, the environment status will move to healthy state. You can click on the URL to view the site. From here, you can also pull the logs from the environment or remote desktop into the Amazon EC2 instances that are part of your Elastic Beanstalk environment. The first deployment of any application will take a bit longer than subsequent re-deployments, as it creates new AWS resources. As you iterate on your application during development, you can quickly re-deploy by going back through the wizard, or selecting the **Republish** option when you right click the project. Republish packages your application using the settings from the previous run through the deployment wizard and uploads the application bundle to the existing Elastic Beanstalk environment. # How to Specify the AWS Security Credentials for Your Application The AWS account you specify in the **Publish to Elastic Beanstalk** wizard is the AWS account the wizard will use for deployment to Elastic Beanstalk. Although not recommended, you may also need to specify AWS account credentials that your application will use to access AWS services after it has been deployed. The preferred approach is to specify an IAM role. In the **Publish to Elastic Beanstalk** wizard, you do this through the **Identity and Access Management Role** drop-down list on the **AWS Options** page. In the legacy **Publish to Amazon Web Services** wizard, you do this through the **IAM Role** drop-down list on the **AWS Options** page. If you must use AWS account credentials instead of an IAM role, you can specify the AWS account credentials for your application in one of the following ways: + Reference a profile corresponding to the AWS account credentials in the `appSettings` element of the project's `Web.config` file. (To create a profile, see [Configuring AWS Credentials](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-config-creds.html).) The following example specifies credentials whose profile name is `myProfile`. ``` ``` + If you're using the **Publish to Elastic Beanstalk** wizard, on the **Application Options** page, in the **Key** row of the **Key** and **Value** area, choose **AWSAccessKey**. In the **Value** row, type the access key. Repeat these steps for **AWSSecretKey**. + If you're using the legacy **Publish to Amazon Web Services** wizard, on the **Application Options** page, in the **Application Credentials** area, choose **Use these credentials**, and then type the access key and secret access key into the **Access Key** and **Secret Key** boxes. # How to Republish Your Application to an Elastic Beanstalk Environment (Legacy) **Important** This documentation refers to legacy services and features. For updated guides and content, see the [AWS .NET deployment tool](https://aws.github.io/aws-dotnet-deploy/) guide. You can iterate on your application by making discrete changes and then republishing a new version to your already launched Elastic Beanstalk environment. 1. In Solution Explorer, open the context (right-click) menu for the **AEBWebAppDemo** project folder for the project you published in the previous section, and choose **Publish to AWS Elastic Beanstalk**. ![\[Solution Explorer context menu showing "Publish to AWS..." option for AEBWebAppDemo project.\]](http://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/images/tkv-publish-to-aws-console.png) The **Publish to Elastic Beanstalk** wizard appears. ![\[Publish to AWS Elastic Beanstalk dialog with profile and deployment options.\]](http://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/images/tkv-aeb-wizard-app-console2.png) 1. Select **Redeploy to an existing environment** and choose the environment you previously published to. Click **Next**. The **Review** wizard appears. ![\[Review wizard showing deployment details for an AWS Elastic Beanstalk application.\]](http://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/images/tkv-aeb-wizard-app-review.png) 1. Click **Deploy**. The application will redeploy to the same environment. You cannot republish if your application is in the process of launching or terminating. # Custom Elastic Beanstalk Application Deployments This topic describes how the deployment manifest for Elastic Beanstalk's Microsoft Windows container supports custom application deployments. Custom application deployments are a powerful feature for advanced users who want to leverage the power of Elastic Beanstalk to create and manage their AWS resources, but want complete control on how their application is deployed. For a custom application deployment, you create Windows PowerShell scripts for the three different actions Elastic Beanstalk performs. The install action is used when a deployment is initiated, restart is used when the `RestartAppServer` API is called from either the toolkit or the web console, and uninstall which is invoked on any previous deployment whenever a new deployment occurs. For example, you might have an ASP.NET application that you want to deploy while your documentation team has written a static website that they want included with the deployment. You can do that by writing your deployment manifest like this: ``` { "manifestVersion": 1, "deployments": { "msDeploy": [ { "name": "app", "parameters": { "appBundle": "CoolApp.zip", "iisPath": "/" } } ], "custom": [ { "name": "PowerShellDocs", "scripts": { "install": { "file": "install.ps1" }, "restart": { "file": "restart.ps1" }, "uninstall": { "file": "uninstall.ps1" } } } ] } } ``` The scripts listed for each action must be in the application bundle relative to the deployment manifest file. For this example, the application bundle will also contain a documentation.zip file which contains a static website created by your documentation team. The `install.ps1` script extracts the zip file and sets up the IIS Path. ``` Add-Type -assembly "system.io.compression.filesystem" [io.compression.zipfile]::ExtractToDirectory('./documentation.zip', 'c:\inetpub\wwwroot\documentation') powershell.exe -Command {New-WebApplication -Name documentation -PhysicalPath c:\inetpub\wwwroot\documentation -Force} ``` Since your application is running in IIS, the restart action will invoke an IIS reset. ``` iisreset /timeout:1 ``` For uninstall scripts, it is important to clean up all settings and files used during the install stage. That way during the install phase for the new version, you can avoid any collision with previous deployments. For this example, you need to remove the IIS application for the static website and remove the website files. ``` powershell.exe -Command {Remove-WebApplication -Name documentation} Remove-Item -Recurse -Force 'c:\inetpub\wwwroot\documentation' ``` With these script files and the documentation.zip file included in your application bundle, the deployment creates the ASP.NET application and then deploys the documentation site. For this example, we choose a simple example that deploys a simple static website, but with custom application deployment you can deploy any type of application and let Elastic Beanstalk manage the AWS resources for it. # Custom ASP.NET Core Elastic Beanstalk Deployments This topic describes how deployment works and what you can do customize deployments when creating ASP.NET Core applications with Elastic Beanstalk and the Toolkit for Visual Studio. After you complete the deployment wizard in the Toolkit for Visual Studio, the toolkit bundles the application and sends it to Elastic Beanstalk. Your first step in creating the application bundle is to use the new dotnet CLI to prepare the application for publishing by using the **publish** command. The framework and configuration are passed down from the settings in the wizard to the **publish** command. So if you selected **Release** for `configuration` and **netcoreapp1.0** for the `framework`, the toolkit will execute the following command: `dotnet publish --configuration Release --framework netcoreapp1.0` When the **publish** command finishes, the toolkit writes the new deployment manifest into the publishing folder. The deployment manifest is a JSON file named **aws-windows-deployment-manifest.json**, which the Elastic Beanstalk Windows container (version 1.2 or later) reads to determine how to deploy the application. For example, for an ASP.NET Core application you want to be deploy at the root of IIS, the toolkit generates a manifest file that looks like this: ``` { "manifestVersion": 1, "deployments": { "aspNetCoreWeb": [ { "name": "app", "parameters": { "appBundle": ".", "iisPath": "/", "iisWebSite": "Default Web Site" } } ] } } ``` The `appBundle` property indicates where the application bits are in relation to the manifest file. This property can point to either a directory or a ZIP archive. The `iisPath` and `iisWebSite` properties indicate where in IIS to host the application. ## Customizing the Manifest The toolkit only writes the manifest file if one doesn't already exist in the publishing folder. If the file does exist, the toolkit updates the `appBundle`, `iisPath` and `iisWebSite` properties in the first application listed under the `aspNetCoreWeb` section of the manifest. This allows you to add the **aws-windows-deployment-manifest.json** to your project and customize the manifest. To do this for an ASP.NET Core Web application in Visual Studio add a new JSON file to the root of the project and name it **aws-windows-deployment-manifest.json**. The manifest must be named **aws-windows-deployment-manifest.json** and it must be at the root of the project. The Elastic Beanstalk container looks for the manifest in the root and if it finds it will invoke the deployment tooling. If the file doesn't exist, the Elastic Beanstalk container falls back to the older deployment tooling, which assumes the archive is an **msdeploy** archive. To ensure the dotnet CLI `publish` command includes the manifest, update the `project.json` file to include the manifest file in the include section under `include` in `publishOptions`. ``` { "publishOptions": { "include": [ "wwwroot", "Views", "Areas/**/Views", "appsettings.json", "web.config", "aws-windows-deployment-manifest.json" ] } } ``` Now that you've declared the manifest so that it's included in the app bundle, you can further configure how you want to deploy the application. You can customize deployment beyond what the deployment wizard supports. AWS has defined a JSON schema for the **aws-windows-deployment-manifest.json file**, and when you installed the Toolkit for Visual Studio, the setup registered the URL for the schema. When you open `windows-deployment-manifest.json`, you'll see the schema URL selected in the Schema drop down box. You can navigate to the URL to get a full description of what can be set in the manifest. With the schema selected, Visual Studio will provide IntelliSense while you're editing the manifest. One customization you can do is to configure the IIS application pool under which the application will run. The following example shows how you can define an IIS Application pool ("customPool") that recycles the process every 60 minutes, and assigns it to the application using `"appPool": "customPool"`. ``` { "manifestVersion": 1, "iisConfig": { "appPools": [ { "name": "customPool", "recycling": { "regularTimeInterval": 60 } } ] }, "deployments": { "aspNetCoreWeb": [ { "name": "app", "parameters": { "appPool": "customPool" } } ] } } ``` Additionally, the manifest can declare Windows PowerShell scripts to run before and after the install, restart and uninstall actions. For example, the following manifest runs the Windows PowerShell script `PostInstallSetup.ps1` to do further setup work after the ASP.NET Core application is deployed to IIS. When adding scripts like this, make sure the scripts are added to the include section under publishOptions in the `project.json` file, just as you did with the `aws-windows-deployment-manifest.json` file. If you don't, the scripts won't be included as part of the dotnet CLI **publish** command. ``` { "manifestVersion": 1, "deployments": { "aspNetCoreWeb": [ { "name": "app", "scripts": { "postInstall": { "file": "SetupScripts/PostInstallSetup.ps1" } } } ] } } ``` ## What about .ebextensions? The Elastic Beanstalk **.ebextensions** configuration files are supported as with all the other Elastic Beanstalk containers. To include .ebextensions in an ASP.NET Core application, add the `.ebextensions` directory to the `include` section under `publishOptions` in the `project.json` file. For further information about .ebextensions checkout the [Elastic Beanstalk Developer Guide](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/ebextensions.html). # Multiple Application Support for .NET and Elastic Beanstalk Using the deployment manifest, you have the ability to deploy multiple applications to the same Elastic Beanstalk environment. The deployment manifest supports [ASP.NET Core](http://www.asp.net/core) web applications as well as msdeploy archives for traditional ASP.NET applications. Imagine a scenario where you have written a new amazing application using ASP.NET Core for the frontend and a Web API project for an extensions API. You also have an admin app that you wrote using traditional ASP.NET. The toolkit's deployment wizard focuses on deploying a single project. To take advantage of multiple application deployment, you have to construct the application bundle by hand. To start, write the manifest. For this example, you will write the manifest at the root of your solution. The deployment section in the manifest has two children: an array of ASP.NET Core web applications to deploy, and an array of msdeploy archives to deploy. For each application, you set the IIS path and the location of the application’s bits relative to the manifest. ``` { "manifestVersion": 1, "deployments": { "aspNetCoreWeb": [ { "name": "frontend", "parameters": { "appBundle": "./frontend", "iisPath": "/frontend" } }, { "name": "ext-api", "parameters": { "appBundle": "./ext-api", "iisPath": "/ext-api" } } ], "msDeploy": [ { "name": "admin", "parameters": { "appBundle": "AmazingAdmin.zip", "iisPath": "/admin" } } ] } } ``` With the manifest written, you’ll use Windows PowerShell to create the application bundle and update an existing Elastic Beanstalk environment to run it. The script is written assuming that it will be run from the folder containing your Visual Studio solution. The first thing you need to do in the script is setup a workspace folder in which to create the application bundle. ``` $publishFolder = "c:\temp\publish" $publishWorkspace = [System.IO.Path]::Combine($publishFolder, "workspace") $appBundle = [System.IO.Path]::Combine($publishFolder, "app-bundle.zip") If (Test-Path $publishWorkspace){ Remove-Item $publishWorkspace -Confirm:$false -Force } If (Test-Path $appBundle){ Remove-Item $appBundle -Confirm:$false -Force } ``` Once you've created the folder, it is time to get the frontend ready. As with the deployment wizard, use the dotnet CLI to publish the application. ``` Write-Host 'Publish the ASP.NET Core frontend' $publishFrontendFolder = [System.IO.Path]::Combine($publishWorkspace, "frontend") dotnet publish .\src\AmazingFrontend\project.json -o $publishFrontendFolder -c Release -f netcoreapp1.0 ``` Notice that the subfolder "frontend" was used for the output folder, matching the folder you set in the manifest. Now you need to do the same for the Web API project. ``` Write-Host 'Publish the ASP.NET Core extensibility API' $publishExtAPIFolder = [System.IO.Path]::Combine($publishWorkspace, "ext-api") dotnet publish .\src\AmazingExtensibleAPI\project.json -o $publishExtAPIFolder -c Release -f netcoreapp1.0 ``` The admin site is a traditional ASP.NET application, so you can't use the dotnet CLI. For the admin application, you should use msbuild, passing in the build target package to create the msdeploy archive. By default the package target creates the msdeploy archive under the `obj\Release\Package` folder, so you will need to copy the archive to the publish workspace. ``` Write-Host 'Create msdeploy archive for admin site' msbuild .\src\AmazingAdmin\AmazingAdmin.csproj /t:package /p:Configuration=Release Copy-Item .\src\AmazingAdmin\obj\Release\Package\AmazingAdmin.zip $publishWorkspace ``` To tell the Elastic Beanstalk environment what to do with all these applications, copy the manifest from your solution to the publish workspace and then zip up the folder. ``` Write-Host 'Copy deployment manifest' Copy-Item .\aws-windows-deployment-manifest.json $publishWorkspace Write-Host 'Zipping up publish workspace to create app bundle' Add-Type -assembly "system.io.compression.filesystem" [io.compression.zipfile]::CreateFromDirectory( $publishWorkspace, $appBundle) ``` Now that you have the application bundle, you could go to the web console and upload the archive to a Elastic Beanstalk environment. Alternatively, you can continue to use the AWS PowerShell cmdlets to update the Elastic Beanstalk environment with the application bundle. Make sure you have set the current profile and region to the profile and region that contains your Elastic Beanstalk environment by using `Set-AWSCredentials` and `Set-DefaultAWSRegion` cmdlets. ``` Write-Host 'Write application bundle to S3' # Determine S3 bucket to store application bundle $s3Bucket = New-EBStorageLocation Write-S3Object -BucketName $s3Bucket -File $appBundle $applicationName = "ASPNETCoreOnAWS" $environmentName = "ASPNETCoreOnAWS-dev" $versionLabel = [System.DateTime]::Now.Ticks.ToString() Write-Host 'Update Beanstalk environment for new application bundle' New-EBApplicationVersion -ApplicationName $applicationName -VersionLabel $versionLabel -SourceBundle_S3Bucket $s3Bucket -SourceBundle_S3Key app-bundle.zip Update-EBEnvironment -ApplicationName $applicationName -EnvironmentName $environmentName -VersionLabel $versionLabel ``` Now, check the status of the update using either the Elastic Beanstalk environment status page in either the toolkit or the web console. Once complete you will be able to navigate to each of the applications you deployed at the IIS path set in the deployment manifest. # Deploying to Amazon EC2 Container Service **Important** The new **Publish to AWS** feature is designed to simplify how you publish .NET applications to AWS. You may be asked if you want to switch to this publishing experience after you choose **Publish Container to AWS**. For more information, see [Working with Publish to AWS in Visual Studio](publish-experience.md). Amazon Elastic Container Service is a highly scalable, high performance container management service that supports Docker containers and allows you to easily run applications on a managed cluster of Amazon EC2 instances. To deploy applications on Amazon Elastic Container Service, your application components must be developed to run in a Docker container. A Docker container is a standardized unit of software development, containing everything that your software application needs to run: code, runtime, system tools, system libraries, etc. The Toolkit for Visual Studio provides a wizard that simplifies publishing applications through Amazon ECS. This wizard is described in the following sections. For more information about Amazon ECS, go to the [Elastic Container Service documentation](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html). It includes an overview of [Docker basics](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/docker-basics.html) and [creating a cluster](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create_cluster.html). **Topics** + [Specify AWS Credentials](deployment-ecs-specify-credentials.md) + [Deploy an ASP.NET Core 2.0 App (Fargate) (Legacy)](deployment-ecs-aspnetcore-fargate.md) + [Deploy an ASP.NET Core 2.0 App (EC2)](deployment-ecs-aspnetcore-ec2.md) # Specify AWS Credentials for Your ASP.NET Core 2 Application There are two types of credentials in play when you deploy your application to a Docker container: deployment credentials and instance credentials. Deployment credentials are used by the Publish Container to AWS wizard to create the environment in Amazon ECS. This includes things like tasks, services, IAM roles, a Docker container repository, and if you choose, a load balancer. Instance credentials are used by the instance (including your application) to access different AWS services. For example, if your an ASP.NET Core 2.0 application reads and writes to Amazon S3 objects, it will need appropriate permissions. You can provide different credentials using different methods based on the environment. For example, your ASP.NET Core 2 application might target *Development* and *Production* environments. You could use a local Docker instance and credentials for development and a defined role in production. ## Specifying deployment credentials The AWS account you specify in the **Publish Container to AWS** wizard is the AWS account the wizard will use for deployment to Amazon ECS. The account profile must have permissions to Amazon Elastic Compute Cloud, Amazon Elastic Container Service, and AWS Identity and Access Management. If you notice options missing from drop-down lists, it may be because you lack permissions. For example, if you created a cluster for your application but do not see it on the **Publish Container to AWS** wizard Cluster page. If this happens, add the missing permissions and try the wizard again. ## Specifying development instance credentials For non-production environments, you can configure your credentials in the appsettings..json file. For example, to configure your credentials in the appsettings.Development.json file in Visual Studio 2017: 1. Add the AWSSDK.Extensions.NETCore.Setup NuGet package to your project. 1. Add AWS settings to appsettings.Development.json. The configuration below sets `Profile` and `Region`. ``` { "AWS": { "Profile": "local-test-profile", "Region": "us-west-2" } } ``` ## Specifying production instance credentials For production instances, we recommend you use an IAM role to control what your application (and the service) can access. For example, to configure an IAM role with Amazon ECS as the service principal with permissions to Amazon Simple Storage Service and Amazon DynamoDB from the AWS Management Console: 1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane of the IAM console, choose Roles, and then choose Create role. 1. Choose the **AWS Service** role type, and then choose **EC2 Container Service**. 1. Choose the **EC2 Container Service Task** use case. Use cases are defined by the service to include the trust policy that the service requires. Then choose **Next: Permissions**. 1. Choose the **AmazonS3FullAccess** and **AmazonDynamoDBFullAccess** permissions policies. Check the box next to each policy, and then choose **Next: Review**, 1. For **Role name**, type a role name or role name suffix to help you identify the purpose of this role. Role names must be unique within your AWS account. They are not distinguished by case. For example, you cannot create roles named both `PRODROLE` and `prodrole`. Because various entities might reference the role, you cannot edit the name of the role after it has been created. 1. (Optional) For **Role description**, type a description for the new role. 1. Review the role and then choose **Create role**. You can use this role as the **task role** on the **ECS Task Definition** page of the **Publish Container to AWS** wizard. For more information, see [Using Service-Based Roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html). # Deploying an ASP.NET Core 2.0 App to Amazon ECS (Fargate) (Legacy) **Important** This documentation refers to legacy services and features. For updated guides and content, see the [AWS .NET deployment tool](https://aws.github.io/aws-dotnet-deploy/) guide and the updated [Deploying to AWS](https://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/deployment-chapt.html) table of contents. This section describes how to use the **Publish Container to AWS** wizard, provided as part of the Toolkit for Visual Studio, to deploy a containerized ASP.NET Core 2.0 application targeting Linux through Amazon ECS using the Fargate launch type. Because a web application is meant to run continuously, it will be deployed as a service. ## Before you publish your container Before using the **Publish Container to AWS** wizard to deploy your ASP.NET Core 2.0 application: + [Specify your AWS credentials](deployment-ecs-specify-credentials.md) and [get setup with Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/get-set-up-for-amazon-ecs.html). + [Install Docker](https://docs.docker.com/engine/installation). You have a few different installation options including [Docker for Windows](https://docs.docker.com/docker-for-windows/install/). + In Visual Studio, create (or open) a project for an ASP.NET Core 2.0 containerized app targeting Linux. ## Accessing the Publish Container to AWS wizard To deploy an ASP.NET Core 2.0 containerized application targeting Linux, right-click the project in the Solution Explorer and select **Publish Container to AWS**. ![\[Context menu showing "Publish Container to AWS" option highlighted for deployment.\]](http://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/images/wiz-ecspub-fargate-step0a.png) You can also select **Publish Container to AWS** on the Visual Studio Build menu. ## Publish Container to AWS Wizard ![\[AWS Publish Container interface showing profile, Docker image, and deployment options for ECR.\]](http://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/images/wiz-ecspub-fargate-step1.png) **Account profile to use** - Select an account profile to use. **Region** - Choose the deployment region. Profile and region are used to set up your deployment environment resources and to select the default Docker registry. **Configuration** - Select the Docker image build configuration. **Docker Repository** - Choose an existing Docker repository or type in the name of a new repository and it will be created. This is the repository the build container is pushed to. **Tag** - Select an existing tag or type in the name of a new tag. Tags can track important details like version, options or other unique configuration elements of the Docker container. **Deployment Target** - Select **Service on an ECS Cluster**. Use this deployment option when your application is meant to be long-running (like an ASP.NET web application). **Save settings to `aws-docker-tools-defaults.json` and configure project for command line deployment** - Check this option if you want the flexibility of deploying from the command line. Use `dotnet ecs deploy` from your project directory to deploy and `dotnet ecs publish` the container. ## Launch Configuration page ![\[AWS Launch Configuration interface for creating an empty ECS cluster with FARGATE launch type.\]](http://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/images/wiz-ecspub-fargate-step2.png) **ECS Cluster** - Pick the cluster that will run your Docker image. If you choose to create an empty cluster, provide a name for your new cluster. **Launch Type** - Choose **FARGATE**. **CPU Maximum (vCPU)** - Choose the maximum amount of compute capacity needed for your application. To see allowed ranges of CPU and Memory values, see [task size](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html). **Memory Maximum (GB)** - Select the maximum amount of memory available to your application. **VPC Subnets** - Choose one or more subnets under a single VPC. If you choose more than one subnet, your tasks will be distributed across them. This can improve availability. For more information, see [default VPC and default subnets](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/default-vpc.html). **Security Groups** - Choose a security group. A security group acts as a firewall for associated Amazon EC2 instances, controlling both inbound and outbound traffic at the instance level. [Default security groups](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html) are configured to allow inbound traffic from instances assigned to the same security group and all outbound IPv4 traffic. You need outbound allowed so the service can reach the container repository. **Assign Public IP Address** - Check this to make your task accessible from the internet. ## Service Configuration page ![\[AWS Service Configuration interface for deploying an application with customizable parameters.\]](http://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/images/wiz-ecspub-fargate-step3.png) **Service** - Select one of the services in the drop-down to deploy your container into an existing service. Or choose **Create New** to create a new service. Service names must be unique within a cluster, but you can have similarly named services in multiple clusters within a region or across multiple regions. **Number of Tasks** - The number of tasks to deploy and keep running on your cluster. Each task is one instance of your container. **Minimum Healthy Percent** - The percentage of tasks that must remain in `RUNNING` state during a deployment rounded up to the nearest integer. **Maximum Percent** - The percentage of tasks that are allowed in the `RUNNING` or `PENDING` state during a deployment rounded down to the nearest integer. ## Application Load Balancer page ![\[Application Load Balancer configuration interface for AWS with options for load balancer and target group settings.\]](http://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/images/wiz-ecspub-fargate-step4.png) **Configure Application Load Balancer** - Check to configure an application load balancer. **Load Balancer** - Select an existing load balancer or choose **Create New** and type in the name for the new load balancer. **Listener Port** - Select an existing listener port or choose **Create New** and type in a port number. The default, port `80`, is appropriate for most web applications. **Target Group** - Select the target group Amazon ECS will register the tasks to the service to. **Path Pattern** - The load balancer will use path-based routing. Accept the default `/` or provide a different pattern. The path pattern is case-sensitive, can be up to 128 characters in length, and contains a [select set of characters](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#path-conditions). **Health Check Path** - The ping path that is the destination on the targets for health checks. By default, it is `/`. Enter a different path if needed. If the path you enter is invalid, the health check will fail and it will be considered unhealthy. If you deploy multiple services, and each service will be deployed to a different path or location, you will need custom check paths. ## Task Definition page ![\[AWS Task Definition interface for configuring Docker container parameters and permissions.\]](http://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/images/wiz-ecspub-fargate-step5.png) **Task Definition** - Select an existing task definition or choose **Create New** and type in the new task definition name. **Container** - Select an existing container or choose **Create New** and type in the new container name. **Task Role** - Select an IAM role that has the credentials your app needs to access AWS Services. This is how credentials are passed in to your application. See [how to specify AWS security credentials for your application](deployment-ecs-specify-credentials.md). **Task Execution Role** - Select a role with permissions to pull private images and publish logs. AWS Fargate will use it on your behalf. **Port Mapping** - Choose the port number on the container that is bound to the automatically assigned host port. **Environment Variables** - Add, modify, or delete environment variables for the container. You can modify it to suit your deployment. When you are satisfied with the configuration, click **Publish** to begin the deployment process. ## Publishing Container to AWS ![\[AWS container publishing progress window showing steps for deploying to ECS and ECR.\]](http://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/images/wiz-ecspub-fargate-step6.png) Events are displayed during deployment. The wizard is automatically closed on successful completion. You can override this by unchecking the box at the bottom of the page. You can find the URL of your new instances in the AWS Explorer. Expand Amazon ECS and Clusters, then click on your cluster. # Deploying an ASP.NET Core 2.0 App to Amazon ECS (EC2) This section describes how to use the **Publish Container to AWS** wizard, provided as part of the Toolkit for Visual Studio, to deploy a containerized ASP.NET Core 2.0 application targeting Linux through Amazon ECS using the EC2 launch type. Because a web application is meant run continuously, it will be deployed as a service. ## Before you publish your container Before using the **Publish Container to AWS** to deploy your ASP.NET Core 2.0 application: + [Specify your AWS credentials](deployment-ecs-specify-credentials.md) and [get setup with Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/get-set-up-for-amazon-ecs.html). + [Install Docker](https://docs.docker.com/engine/installation). You have a few different installation options including [Docker for Windows](https://docs.docker.com/docker-for-windows/install/). + [Create an Amazon ECS cluster](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-cluster.html) based on the needs of your web application. It only takes a few steps. + In Visual Studio, create (or open) a project for an ASP.NET Core 2.0 containerized app targeting Linux. ## Accessing the Publish Container to AWS wizard To deploy an ASP.NET Core 2.0 containerized application targeting Linux, right-click the project in the Solution Explorer and select **Publish Container to AWS**. You can also select **Publish Container to AWS** on the Visual Studio Build menu. ## Publish Container to AWS Wizard **Account profile to use** - Select an account profile to use. **Region** - Choose a deployment region. Profile and region are used to set up your deployment environment resources and select the default Docker registry. **Configuration** - Select the Docker image build configuration. **Docker Repository** - Choose an existing Docker repository or type in the name of a new repository and it will be created. This is the repository the built container image is pushed to. **Tag** - Select an existing tag or type in the name of a new tag. Tags can track important details like version, options or other unique configuration elements of the Docker container. **Deployment** - Select **Service on an ECS Cluster**. Use this deployment option when your application is meant to be long-running (like an ASP.NET Core 2.0 web application). **Save settings to `aws-docker-tools-defaults.json` and configure project for command line deployment** - Check this option if you want the flexibility of deploying from the command line. Use `dotnet ecs deploy` from your project directory to deploy and `dotnet ecs publish` the container. ## Launch Configuration page **ECS Cluster** - Pick the cluster that will run your Docker image. You can [create an ECS cluster](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create_cluster.html) using the AWS Management Console. **Launch Type** - Choose EC2. To use the Fargate launch type, see [Deploying an ASP.NET Core 2.0 Application to Amazon ECS (Fargate)](deployment-ecs-aspnetcore-fargate.md). ## Service Configuration page **Service** - Select one of the services in the drop-down to deploy your container into an existing service. Or choose **Create New** to create a new service. Service names must be unique within a cluster, but you can have similarly named services in multiple clusters within a region or across multiple regions. **Number of Tasks** - The number of tasks to deploy and keep running on your cluster. Each task is one instance of your container. **Minimum Healthy Percent** - The percentage of tasks that must remain in `RUNNING` state during a deployment rounded up to the nearest integer. **Maximum Percent** - The percentage of tasks that are allowed in the `RUNNING` or `PENDING` state during a deployment rounded down to the nearest integer. **Placement Templates** - Select a task placement template. When you launch a task into a cluster, Amazon ECS must determine where to place the task based on the requirements specified in the task definition, such as CPU and memory. Similarly, when you scale down the task count, Amazon ECS must determine which tasks to terminate. The placement template controls how tasks are launched into a cluster: + AZ Balanced Spread - distribute tasks across Availability Zones and across container instances in the Availability Zone. + AZ Balanced BinPack - distribute tasks across Availability Zones and across container instances with the least available memory. + BinPack - distribute tasks based on the least available amount of CPU or memory. + One Task Per Host - place, at most, one task from the service on each container instance. For more information, see [Amazon ECS Task Placement](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement.html). ## Application Load Balancer page **Configure Application Load Balancer** - Check to configure an application load balancer. **Select IAM role for service** - Select an existing role or choose **Create New** and a new role will be created. **Load Balancer** - Select an existing load balancer or choose **Create New** and type in the name for the new load balancer. **Listener Port** - Select an existing listener port or choose **Create New** and type in a port number. The default, port `80`, is appropriate for most web applications. **Target Group** - By default, the load balancer sends requests to registered targets using the port and protocol that you specified for the target group. You can override this port when you register each target with the target group. **Path Pattern** - The load balancer will use path-based routing. Accept the default `/` or provide a different pattern. The path pattern is case-sensitive, can be up to 128 characters in length, and contains a [select set of characters](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#path-conditions). **Health Check Path** - The ping path that is the destination on the targets for health checks. By default, it is `/` and is appropriate for web applications. Enter a different path if needed. If the path you enter is invalid, the health check will fail and it will be considered unhealthy. If you deploy multiple services, and each service will be deployed to a different path or location, you might need custom check paths. ## ECS Task Definition page **Task Definition** - Select an existing task definition or choose **Create New** and type in the new task definition name. **Container** - Select an existing container or choose **Create New** and type in the new container name. **Memory (MiB)** - Provide values for **Soft Limit** or **Hard Limit** or both. The *soft limit* (in MiB) of memory to reserve for the container. Docker attempts to keep the container memory under the soft limit. The container can consume more memory, up to either the hard limit specified with the memory parameter (if applicable), or all of the available memory on the container instance, whichever comes first. The *hard limit* (in MiB) of memory to present to the container. If your container attempts to exceed the memory specified here, the container is killed. **Task Role** - Select a task role for an IAM role that allows the container permission to call the AWS APIs that are specified in its associated policies on your behalf. This is how credentials are passed in to your application. See [how to specify AWS security credentials for your application](deployment-ecs-specify-credentials.md). **Port Mapping** - Add, modify or delete port mappings for the container. If a load balancer is on, the host port will be default to 0 and port assignment will be dynamic. **Environment Variables** - Add, modify, or delete environment variables for the container. When you are satisfied with the configuration, click **Publish** to begin the deployment process. ## Publishing Container to AWS Events are displayed during deployment. The wizard is automatically closed on successful completion. You can override this by unchecking the box at the bottom of the page. You can find the URL of your new instances in the AWS Explorer. Expand Amazon ECS and Clusters, then click on your cluster.