- [Instructor] Okay, hi, and welcome back. That brings to a conclusion this course. So let's summarize what we've covered in this Getting Started with the AWS Migration Service course. First, we overviewed the AWS migration hub. Now the AWS migration hub provides a dashboard view of your migration project, and so is a useful way to plan, track and manage a migration project. The migration hub can be used to discover and audit your server inventory on a number of different networks or nodes. And it can also manage and track the migration of servers and applications to the AWS cloud. Discovery and migration are separate steps. They can be run independently of each other, and each of these steps requires a different service. The discovery tool can be either agent lists or with an agent you install on your virtual or physical servers.

The discovery connector is a VMWare appliance that can only collect information about VMWare VMs. So it's very useful with a VMWare only in migration, as you don't have to install and configure an agent on or in your data center. So you should use the Discovery Connector if you need to quickly assess your infrastructure using a tool that isn't specific to any operating system, without it having to install anything on the servers themselves. The benefit of using the Discovery Connector is that it provides a fast infrastructure assessment.

The other Discovery tool is the Discovery Agent. And that needs to be installed on servers in your data center environment and configured to allow the agent to send outbound data to the migration hub service. Now you can install the Discovery agents on both virtual machines and physical servers. The Discovery agent supports a wide range of server types, so it's very good for heterogenous environments, and the benefit of using the Discovery Agent, is that it provides more detailed information than the Discovery Connector can. The Discovery Agent needs outbound access from your on-premises environment to send the data to the AWS migration hub, which is going to be running in the US West region, so it needs to be able to send information on port 443 over the Internet.

There are two strategies you can adopt in your migration plan. The first strategy is discover and migrate. This strategy suites heterogeneous environments where we have numerous servers and applications, where there may be a number of different unknown factors that could possibly impact your migration project. The benefit of discovery and migrate, is that the discovery step provides detail on the environment. If you opt to use the Discovery Agent, you can gather detailed environmental details on a broad range of servers and applications. And this audit can provide you with detailed discovery of your current servers and application, which in turn can help you prioritize and plan your migrations.

The second strategy is just migrate. And this can appeal if you have a homogenous environment using VMWare and you have a good understanding of your operating environment, and you just want to get started with the migration. The benefit of the just migrate strategy is that the servers are grouped together while you are migrating servers. So for migration, we can choose a migration service from AWS or from one of the partner migration services to run the actual migration. Now you need to set up the correct roles and permissions to use the AWS Migration Hub console in API. And AWS manage policies for the AWS Migration Hub are the easiest way to do that. So first you need a permission policy to use the AWS Migration Hub console and API, and then you must define a trust policy that authorizes the migration tool.

Next up we looked at the AWS Server Migration Service. The AWS Server Migration Service can migrate your VMWare, vSphere or Microsoft Huyper-V/SCVMM virtual machines to AWS. So the AWS Server Migration Server replicates your server VMs as cloud-hosted Amazon machine images, ready for deployment on Amazon EC2. So working with AMIs, you can easily test and update your cloud-based images before deploying them into production. So the server migration service replicates incremental changes to your on-premise servers, and transfers only the delta of that change to the cloud. So you can test small changes iterably and save on network band within time. So the server migration service supports replication of Windows and Linux operating system images. Now there's no charge for using the AWS Server Migration Service, you only pay for the resources you consume in it, and any data you might store while you're using it.

You can run up to 50 concurrent virtual machine migrations per account, which is a soft per account limit, so you can request a limit increase by the AWS console or by contacting AWS Support if you want to increase it. You get 90 days of service usage per VM, beginning with the initial replication of a virtual machine. AWS then terminates any of those replications after the 90 days of ongoing replication, unless you request a limit increase. Okay, so that brings this course to a close. I hope you have found it informative, and I want to say thank you very much for your attention during this content. If you have any questions or feedback, please contact us at support@cloudacademy.com and good luck with your future migrations.