The Mobilize stage of planning a migration to AWS has a focus on two key AWS services, these refer to the 

• AWS Application Discovery Service

• AWS Control Tower

In this lecture, I want to explain what these services are used for enabling you to determine when and if you need them as a part of your migration planning.

So, the AWS Application Discovery Service follows on nicely from the Assess stage and enables you to dive deeper into your workloads by collating additional information, such as usage, configuration, and behavior data from these workloads running within your data centers.  With this useful information collated, security is of course paramount and so the Application Discovery Service encrypts all information that it has retained.  This encrypted data can also be read by other AWS services, such as the AWS Migration Hub.  Also, if you are familiar with Amazon Athena and Amazon QuickSight you can export the data for additional analysis and help you identify the TCO of running your workloads in AWS.

So how does the Application Discovery Service gather key data from your resources in your own data centres? Well, it can be done in one of two different ways. Firstly, through an Agent-based discovery, and secondly via an Agentless discovery.

Let’s look at the agent-based option first.  As expected, in this scenario an agent is installed across your fleet of servers that you want to gather information for, which can be installed on both Linux and Windows operating systems.  Also, this agent can be installed both on physical servers in addition to virtual machines. When installed, the agent is then used to capture configuration data, system performance, network connections, in addition to the different processes that are running on the server, helping you to map out service dependencies.

Once the agent has been registered, it will connect to the AWS Application Discovery Service in the specified region and integrate with the AWS Migration Hub.  From this point, the agent will gather the data and send it back to the application Discovery Service over a secure connection using Transport Layer Security (TLS) approximately every 15 minutes. For an in-depth look at the data captured, please refer to the AWS documentation found here.

Now let’s look at the Agentless discovery, which is also referred to as the Discovery Connector.  The first thing to mention is that this option is only available for gathering data on your VMware virtual machines.  The reason being is that agentless discovery is configured by deploying an AWS agentless Discovery Connector (OVA file) via your VMware vCenter.  Again, it captures information relating to each VM and which vCenter they are associated with, in addition to configurational data, IP and MAC address data, utilization and disk resource allocations, plus average peak metrics for RAM, CPU and Disk I/O.

Much like the Agent-based discovery, it operates in a very similar way.  Once the connector has been distributed as the OVA file, it will connect to the AWS Application Discovery Service and integrate with the AWS Migration Hub.  However, communication between the Connector and the Application Discovery Service will only occur approximately once every 60 minutes. Also, as expected any data collected is sent over an encrypted TLS connection back to the service.  

AWS Control Tower is an essential service if you are looking to deploy a multi-account strategy as a part of your migration.  It provides a simple and effective way to set up your accounts, teams, in addition to meeting governance requirements based upon best practices in the form of a Landing Zone, but what is a landing zone? 

A Landing Zone is a multi-account architecture that follows the well-architected framework and is based around the ideas of security and compliance best practices. Your landing zone will be automatically created by AWS Control Tower and it is inherent part of the service, your landing zone is created from a series of best practice blueprints that help us set up systems that deal with identity, federated access, and overall account structure, these blueprints create a multi-cloud environment using AWS organizations.  There are three organizational units that are provisioned here, the Root OU, this will be the parent OU that contains every other OU, within your landing zone, the core OU this OU contains the log archive and any audit member accounts, we generally refer to these accounts as the shared accounts.  And then a custom OU, this OU and other member OUs contain the actual working accounts that your users need to perform whatever duties they do within your AWS environment

The service also builds out two shared accounts, a log archive in the account which will be the place where all the logs will be sent between all accounts, it will store the logs of all API calls and resource configurations for every account within the landing zone and an audit account which has a restricted account that has been created to give your security and compliance team members read and write access to any account within your AWS landing zone.

From this account, you'll have programmatic access to review all other accounts, by way of a role that grants use of Lambda functions only, this account does not allow you to log into other accounts manually. 

Control tower will also provide single sign-on through IAM identity center to define the scope or permissions available for each of those users. It will also provide federated access to those accounts.  You can also integrate your own active directory service. 

When you create your new landing zones using AWS Control Tower, there are a large number of AWS resources that are created on your behalf, you need to be very careful about deleting or removing these pre-configured resources. If you were to destroy or tamper with these resources you can render the control tower into an unknown state. If you would like to learn more about AWS Control Tower and how to build multi-account infrastructure, please see our existing course here.