Introduction
AWS MGN is a highly automated, adaptable, and dependable lift and shift system. Anyone can utilize the AWS application migration service (AWS MGN), a lift-and-shift AWS service, using the AWS administration console. In this post, i will explain the AWS MGN service and network architecture.
AWS MGN can assist with streamlining, accelerating, and lowering the cost of application migration to AWS. AWS MGN can be used to move physical, virtual, or cloud services to AWS without affecting performance, causing a disturbance, or requiring a lengthy cutover period. Any source infrastructure that utilizes an operating system that is supported can be used to migrate apps and databases. This includes widely used databases like Oracle and SQL Server, vital programs like SAP, and in-house developed programs. AWS MGN supports the most common Windows and Linux operating systems and continuously replicates their data at the block level.
Architecture – Phase 1
Network Requirements
Connectivity Between AWS MGN API Endpoints & Source Servers
Allow communication on port 443 between the AWS MGN endpoint and the source servers’ AWS replication agents. This connectivity is used for monitoring, configuration, and authentication purposes. For the installation of the AWS replication agent and as long as the source server is replicating, this connectivity is required. This is an HTTPS connection, thus it can be routed using the source server’s default settings through a web proxy. Additionally, you must permit communication between S3 and the source servers. Set up this link so that the S3 bucket containing the required software components can be accessed by the AWS replication agent.
Connectivity Between Source Servers & Staging Subnet
Data is sent over port 1500 directly from the source servers to the replication servers by the AWS replication agent. For continuous data replication, communication across port 1500 must be permitted.
Connectivity Out of Staging Subnet
For purposes of authentication, configuration, and monitoring, the AWS MGN replication servers and conversion servers launched in the staging area subnet must be in constant communication with the AWS MGN endpoints on port 443. As long as replication is active, this link is required. Additionally, S3 connectivity must be permitted. The replication or conversion server connects to an S3 bucket when it starts up to obtain configuration and software.
The replication server’s responsibility includes making an API call to capture snapshots of the EBS volumes used for staging during replication. Connectivity to an EC2 API endpoint on port 443 must also be present for this to happen.
In this example, the source environment is located on the left. A mix of physical, virtual, and cloud servers may be used. In this illustration, the source environment consists of two servers, one server having one 50 GB disk and the second server having two attached disks. The AWS region where the servers will be moved is shown on the right. For this example, we only see a staging subnet and a migration subnet; however you can create any many subnets as you need and designated them any way you require.
Task 1 – Pregame
Installing the AWS replication agent on your source servers is the first step. The agent link can be obtained in the MGN console. The agent, upon installation, does not require a reboot and may be installed via scripts without intervention. You should be cognizant of the fact that the root drive needs 2 GB of free drive space when you attempt to launch post replication. The unfortunate part of MGN is that if you modify your source volumes/drives, replication has to rescan ALL volumes/drives and not just the volume you modified.
After installation, the agent initiates an authentication handshake with the TLS-encrypted AWS MGN API endpoint. By doing this, the agent registers with a service, which then automatically provisions the resources for the staging area subnet.
The data from the source environment is kept synchronized on AWS by the staging area subnet using low-cost compute and storage. The following resources are part of the staging area subnet:
- Replication Servers – lightweight EC2 instances
- Staging Volumes – low-cost Elastic Block Store
- EBS Snapshots – EBS snapshots which are incremental.
AWS MGN produces an equally sized EBS volume in the staging area subnet for each source disk that is duplicated so that data synchronization can take place. In this example, three similar EBS volumes are attached to the staging area replication servers as a result of the three replicating source drives.
Replication starts after the installation of the agent and the establishment of the resources for the staging area subnet. Directly from the source servers to the replication server volumes, the data is transported while being encrypted. How the replication happens is under the user’s control since replication can be done over the public internet, Site to Site VPN, or Direct Connect.
The service automatically manages the subnet resources for the staging area, scaling them up or down based on the concurrent replication of the source servers and disks. As a result, the user is not required to perform any maintenance tasks to administer the staging area subnet. The service periodically rotates its AWS MGN servers, which are transient resources.
Servers for replication by default use T3.small Linux instances with T3 unlimited pricing turned on. One replication server can typically support up to 15 disks that are simultaneously duplicating information. AES 256 bit encryption key is by default used to compress and encrypt data while it is in transit. Using Amazon EBS encryption, it can also be encrypted when in your AWS region. An initial sync is the first step in replication. The agent copies all of the data on the source disks to EBS volumes in the staging area subnet during the initial sync. The agent asynchronously replicates the data to the appropriate resource in the staging area subnet while concurrently monitoring and continuously replicating data rights as they happen. After the initial replication, continuous replication continues forever.
Task 2 – Launch
Review the launch settings once agent installation and replication starts. The launch configurations consist of a service, particular configurations, and an accessible template. The launch settings, which include subnet security groups, instance type, volume type, and tags, specify where and how migrated instances are launched. Wait for the initial sync to finish after configuring the launch settings. You can select the test and cutover button and launch instances when the source server is ready for testing. The instance will then be automatically launched on AWS in accordance with your selected launch settings once AWS MGN issues a series of API calls to start the launch procedure.
The service automatically spins up a conversion server during launch. To ensure that the instance boots natively on AWS, the conversion process involves modifications to the drivers, network, and operating system license.
The conversion server is spun up just for the express purpose of converting servers during the launch process and is then promptly stopped, in contrast to the replication servers, which stay alive as long as replication is active. The new instance gets spun up on AWS after the conversion is finished and is prepared for use. Keep in mind that the source servers’ current state is represented by the volumes associated to the launched instance.
The newly formed volumes are no longer kept in sync with the source servers after the launch. The AWS replication agent still continually replicates any modifications made to your source servers to the staging area volumes, but the modifications are not reflected in the launched instances. The most recent status of the data replicated from the source server to the staging area subnet will be reflected each time you create a new test or cutover instance. With this layout, you can easily test the spun-up instances without interfering with the replication or source servers. Additionally, you can instantly spin up the most recent version of the source servers. A previous copy of the same source server that was launched will be automatically cleaned up and replaced when a new instance of the server is launched. As a result, expenses are kept to a minimum and wasteful resource accumulation is prevented.
Conclusion
AWS Application Migration Service (MGN) is a fully automated lift-and-shift (rehost) service that makes moving apps to AWS easier, faster, and less expensive. It allows businesses to move a lot of physical, virtual, or cloud servers around quickly and easily without worrying about compatibility difficulties, performance issues, or lengthy cutover windows. Your AWS account receives source server replication from MGN. It automatically converts and runs your servers on AWS when you’re ready, allowing you to reap the cost savings, productivity gains, resilience, and agility of the Cloud right away. Lift-and-shift is a speedy path to modernization because once your apps are operating on AWS, you can use AWS services and capabilities to quickly and easily replatform or rework those applications.