Prerequisites for testing on AWS

Verify the prerequisites below before you test your application on AWS.

S3 bucket

You must have an S3 bucket in the AWS Region where you want to run the test deployment. You can create a S3 bucket using Amazon Simple Storage Service (Amazon S3). Toolkit for .NET Refactoring supports the following Regions:

• US East (Ohio) – us-east-2

• Europe (London) – eu-west-2

Toolkit for .NET Refactoring uses the S3 bucket to do the following:

• Prepare the data for the container image build.

• Transfer the application files to the Amazon ECS task.

VPC requirements

When you create a test deployment, the default setting is to create a new virtual private cloud (VPC) in your AWS account. For more information, see Virtual private clouds (VPC) in the Amazon Virtual Private Cloud User Guide.

Alternatively, you can choose to use an existing VPC. If you use an existing VPC, it must satisfy the following requirements:

• It must have two public subnets in different Availability Zones. For information about Availability Zones, see Regions and Zones in the Amazon Elastic Compute Cloud User Guide.

• It must have an internet gateway. For information about internet gateways, see Connect to the internet using an internet gateway in the Amazon VPC User Guide.

  It must have a routing table that connects the internet gateway to the subnets. This means that the subnet is public. For information about subnets, see VPC with public and private subnets (NAT) in the Amazon VPC User Guide.

Application listener ports

The application that you want to test on AWS must listen on the following port:

0.0.0.0:port

Note that the application should not listen on localhost:port or 127.0.0.1:port. This is because when your application is deployed to the cloud, you will connect to the application using a public IP address.

Kestrel server

When your application is ported from .NET to .NET Core, the Kestrel server, which is part of the .NET Core framework, is used as a default web server. The default endpoints (http://localhost:5000 and https://localhost:5001) will not work for the AWS connection. You must explicitly set the Kestrel endpoints. For information about how to set the Kestrel endpoints, see the Microsoft Configure endpoints for the ASP.NET Core Kestrel web server documentation. Note that the documentation uses http://localhost:5000 as an example but you must use http://0.0.0.0:5000 or https://0.0.0.0:5001.

HTTPS requirements

If the application supports HTTPS, the certificate and private key are required and must be included in the application artifacts.

Linux compatibility requirements

The application that you port to .NET Core will run on a Linux OS, which can cause errors if you are porting your application from a Windows OS and you are unaware of the differences between the operating systems.

In particular, the Linux file system is case-sensitive and the Windows file system is not. Therefore, the paths and names of the files that your application uses must be consistent. For example, if you have a file named Dinosaur.cfg and you refer to it as dinosaur.cfg in your code, you will receive an error. You must refer to the file as Dinosaur.cfg in your code.

AWS Identity and Access Management (IAM) overview

If you are using a license included Visual Studio Amazon Machine Images (AMIs) on Amazon EC2, you can use the caller role (refactoringtoolkit-RefactoringToolkitCallerRole) without providing user credentials or editing configuration files. In this case, you do not need to follow the steps in the AWS Identity and Access Management section of this guide. For more information, see Install Toolkit for .NET Refactoring in this guide.

If you are not using a license included Visual Studio AMI on Amazon EC2 or you prefer to create a user and assign roles to the user, see AWS Identity and Access Management in the Security section of this guide to view the IAM prerequisites. Follow the steps to create the user, create the access keys, and configure your AWS profile.