Securely administer servers migrated with AWS Application Migration Service using AWS Systems Manager Session Manager

Introduction

In this blog post, we will illustrate how to automate the configuration necessary to manage migrated servers with improved security and reduced costs.

To administer servers in an on-premises environment, administrators often use secure shell (SSH) or Remote Desktop Protocol (RDP) to connect. After migrating to Amazon Web Services (AWS), this may not be feasible due to changes in network connectivity or security policies. The traditional solution to this involves deploying one or more bastion hosts (also called “jump servers”) to access and manage the servers.

While this method works, it involves the administrative overhead to deploy, harden, maintain, and monitor the bastion hosts. Additionally, there is the financial cost of running bastion hosts as as Amazon Elastic Compute Cloud (Amazon EC2) instances

AWS Systems Manager Session Manager (AWS Session Manager) provides a serverless means of managing migrated servers which improves your security and audit posture by centralizing access control and reducing inbound access. Session Manager does not require open inbound access on SSH or RDP ports. To learn about all of the benefits of AWS Systems Manager Session Manager, please refer to the AWS Session Manager documentation. Configuring the prerequisites for Session Manager can be automated as part of the migration process using AWS Application Migration Service (MGN).

Solution Overview

In the traditional method (Figure 1), one or more bastion hosts with a public IPv4 address are deployed in a public subnet. An administrator first opens an SSH or RDP session to a bastion host; then once connected, opens a second SSH or RDP session from the bastion host to the managed server. This requires that SSH and RDP be allowed in from the internet to reach the bastion host(s) and that an internet gateway deployed in the VPC to route traffic to and from the internet.

Figure 1 – Using a Bastion host

The preferred method (Figure 2) is to leverage AWS Systems Manager Session Manager instead of a bastion host. The administrator opens an HTTPS connection to the AWS Management Console or through the AWS CLI to connect to Session Manager. Servers that have the AWS Systems Manager agent installed make outbound connections to the AWS Systems Manager service to establish bi-directional connectivity.

In this design, there is no bastion host so there is no need to allow inbound SSH or RDP from the internet to either a bastion host or to the EC2 instances themselves. Because VPC endpoints allow connectivity to EC2 and Session Manager services via private connectivity, there is also no need for an internet gateway in this design. This design works for EC2 instances that have no access to the internet.

Figure 2 – Using AWS Session Manager

In this walkthrough, we will use the Application Migration Service to deploy all of the necessary configuration required to allow administrators to securely manage migrated servers using Session Manager.

Prerequisites

To implement this solution requires a basic understanding of the Application Migration Service and you must have previously initialized the service in your account. For more details on how to setup and use the Application Migration Service, please refer to: Getting started with AWS Application Migration Service.

Walkthrough

Step 1: Launch the CloudFormation template

The first step is to create a Systems Manager document that contains the necessary steps to deploy this scenario. Later, we will import this document into the Application Migration Service and configure it as a Post-launch action in subsequent steps.

• Download the CloudFormation template found here.
• Log into the AWS Account where you will be migrating your server (the target account) and go to the CloudFormation Console.
• If there there are no previously created stacks in your account, Select the “Create stack” button from the CloudFormation home page (Figure 3).

Figure 3 – CloudFormation Welcome Page

• If there are existing stacks, Select the “Create stack” dropdown on the right, and then select “With new resources (standard)” (Figure 4).

Figure 4 – CloudFormation Page with existing stacks

• Select “Choose an existing template” and “Upload a template file” from the Create stack menu, then upload the provided template as seen below (Figure 5):

Accept the defaults and on the final screen check the box to acknowledge that AWS CloudFormation might create custom IAM resources. Finally, click the Submit button. This will create a CloudFormation stack called MGN-SSM-automation which includes the Systems Manager document. It also includes an IAM role: MGNSSMAutomationAssumeRole. This role grants the necessary permissions to AWS Systems Manager to create the VPC endpoints and security group for those endpoints required by Session Manager.

Step 2: Activate Post-launch actions in the Application Migration Service

If you have previously turned on Post-launch actions in your account, skip ahead to Step 3.

To implement any Post-launch actions, you must first configure the Application Migration Service to install the SSM agent as part of the migration and conversion process. The Application Migration Service will also apply an Instance Profile Role or IAM Role: AWSApplicationMigrationLaunchInstanceWithSsmRole to each test or cutover instance. This role includes the necessary permissions for the agent to support Systems Manager functions, including Session Manager.

Click Post-launch template under Settings in the left-hand menu bar in the Application Migration Service console. Then click the Edit button (Figure 6).

Slide the toggle to the right to activate the installation of the SSM agent (Figure 7). Then click the Save template button. This update will only apply to source servers added to MGN after making this change.

If you have already added servers to the Application Migration Service and want to apply this automation to them, you will need to update their individual Post-launch settings since changes to the default Post-launch settings template are not applied to existing source servers. First navigate to the Application Migration Service Active Source servers dashboard, then select the server you wish to update. Click on Post-launch settings and then click the Edit button (Figure 6) and continue as instructed below.

Step 3: Configure a Post-launch action to implement Session Manager

After saving the template, all of the predefined actions will become available. Note that the SSM agent action is now active. Click on the Create action button (Figure 8).

Enter a name such as “Configure Session Manager” for the custom Post-launch action. In the Systems Manager document name dropdown menu, type MGN and select the option that begins with: MGN-SSM-automation-SessionManagerEnablement… (Figure 9). Once selected, default values will be entered for the Description and Document version Creator fields. You may adjust any of the values to change the order this automation will be applied or the category type, or you may leave them as default.

At the bottom of the page, click the Add action button.

Step 4: Launch a test or cutover instance of the desired source server(s)

Once you have added new source servers to MGN or updated the individual Post-launch settings of existing source servers (refer to Step 2), initiate the deployment of the resources required for Session Manager by launching test or cutover instance(s).

After the instance(s) have successfully launched, Post-launch actions will be initiated, first the SSM agent will be installed, followed by the custom actions (Figure 10).

This Post-launch action will create four VPC endpoints in the target subnet as well as a security group allowing TCP 443 inbound from the migration target subnet to the VPC Endpoints (Figure 11).

Note: This Post-launch action does not need to be added to every source server. One set of VPC endpoints and their requisite security group will be sufficient for . Many customers migrate servers across multiple AZ’s, VPC’s, regions, or even AWS accounts. In these scenarios multiple sets of VPC endpoints may be required. The automation included in this Post-launch action includes checks to determine if the resources already exist and skips any that do. No duplicate resources will be created with this process.

Step 5a: Connect to a migrated Linux server

To connect to a migrated Linux server, check the box of the desired instance in the EC2 console and then click the Connect button in the upper middle area of the console (Figure 12).

On the next screen, click the Connect button (Figure 13).

This will open a new tab and you will be connected to the CLI of the Linux instance (Figure 14).

Step 5b: Connect to a migrated Windows server (PowerShell CLI)

The process to connect to a Windows Powershell CLI is identical to Linux. Check the box of the desired Windows instance in your EC2 console and then click the Connect button in the upper middle area of the console (figure 10).

On the next screen, click the Connect button (Figure 15).

This will open a new tab and you will be connected to a PowerShell CLI of the Windows instance (Figure 16).

Step 5c: Connect to a migrated Windows server (RDP)

To launch an RDP session to a Windows server, first select the checkbox next to a Windows instance and click the Connect button in the upper section of the console (explained in step 5b).

On the next screen, select the RDP client tab, and then choose the radio button labeled Connect using Fleet Manager. Click the button Fleet Manager Remote Desktop (Figure 17).

On the next screen, enter the appropriate credentials to launch an RDP session to the Windows instance using Session Manager (Figure 18).

Providing authorized credentials, you will be connected to the desktop of the Windows instance (Figure 19).

Conclusion

This post demonstrates how to deploy AWS Systems Manager Session Manager to administer migrated servers instead of deploying bastion hosts. Benefits of this approach include cost optimization, security posture improvement, and lower administrative overhead. AWS Systems Manager has additional features to aid in managing servers including Patch Manager, Automation, Change Manager, and more. Please refer to Getting Started with AWS Systems Manager for additional details.

About the Authors