How to migrate your existing server to EC2? A clear explanation of AWS migration tools and practical steps

Many people who want to migrate their existing on-premise or virtual servers to the cloud may be unsure of which migration method to choose and what steps to take to ensure safety. Amazon Web Services (AWS) offers migration tools and support services that allow you to efficiently replicate your existing servers on Amazon EC2.

In this article, we will clearly explain the practical steps for migration and the configuration concepts while comparing the features of major tools such as AWS Application Migration Service (AWS MGN) and AWS VM Import/Export.

What is server migration to Amazon EC2?

Basic concepts of migration from on-premise/virtual environments

There are several basic principles to consider when migrating an existing on-premise environment or virtual server to the cloud. The following two are typical:

■ Rehosting (Lift & Shift)

This method migrates existing server operating systems and applications to Amazon EC2 as is, with as few changes as possible. Because the environment is not significantly changed, the migration can be completed in a short period of time, minimizing risk.

■ Replatforming

This is a method of partially optimizing for AWS managed services without changing the configuration itself. For example, optimizing storage to Amazon EBS and shifting monitoring to Amazon CloudWatch can improve operability.

Replatforming is a migration method that replaces only the surrounding infrastructure with AWS managed services, without making any changes to the application structure or code. While it goes further than rehosting, it does not involve as major changes as a complete redesign (refactoring).

Example:

• Migrating a database running on a server to Amazon RDS

• Replacing existing file servers with Amazon EFS/Amazon S3

• Change your message queue to Amazon SQS

• Migrating batch processing infrastructure from server-resident to AWS Lambda/AWS Batch

It is common to combine these methods and move to the cloud in stages.

Why choose EC2 as your migration target?

Amazon EC2 has the advantage of being able to easily replicate the configuration of existing servers, significantly reducing the difficulty of migration. It is often chosen as a migration destination for the following reasons:

• The OS and middleware can be used continuously, so there is no need to modify the application.

• Easily adjust performance and capacity, such as instance type and EBS volume

• Existing Linux/Windows operational know-how can be utilized as is, minimizing the burden of operational migration

• EC2 can easily function as an intermediate step when migrating to ECS, Lambda, etc. in the future.

Among all AWS services, this is the one that offers the most flexibility and compatibility with existing environments.

Key benefits of migration (cost, flexibility, availability)

Migrating to Amazon EC2 offers the following benefits:

1. Cost optimization

You can adopt a pay-as-you-go model, eliminating the need for server purchases and maintenance contracts. By reviewing instance sizes, you can reduce wasted resources.

2. Increased flexibility

You can adjust the environment according to load fluctuations by changing the CPU, memory, and storage later. You can also deploy it in multiple AZs (Availability Zones) as needed, allowing you to flexibly expand the configuration.

3. Enhanced availability

By combining multi-AZ configuration, EBS snapshots, Auto Scaling, etc., you can achieve high availability that is difficult to achieve on-premises.

Typical AWS server migration methods

AWS Application Migration Service (AWS MGN)

AWS Application Migration Service (AWS MGN) is a standard service that allows you to migrate your existing servers to Amazon EC2 in the safest and most automated way. It is the migration method officially recommended by AWS and plays a central role in current lift and shift migrations.

Features

• Install the agent on your existing server and it will replicate at the block level.

• Automatically generate an equivalent environment on the AWS side (supports multiple machine configurations)

• Test environments can be started with one click, minimizing the risk of switching to production.

Supported Environment

• Physical Server

• VMware Virtual Machine

• Hyper-V

• Wide range of support, both on-premise and cloud

Benefit

• It can automatically reproduce a configuration that is almost identical to an existing server, preventing manual errors.

• The server continues to operate during replication, minimizing downtime.

• A flow from test switch to production switch is in place, making post-migration verification easy

Demerit

• Some environments may have additional requirements, such as Windows licenses.

• Difficult to use in environments where an agent cannot be installed on the server side

• If you transfer the server configuration without organizing it, there is a possibility that the legacy configuration will be retained.

AWS VM Import/Export

AWS VM Import/Export is a service used when you want to bring VM images (virtual machine images) to Amazon EC2. It is primarily suitable for cases where you want to recreate an environment built with VMware or Hyper-V on EC2 as is. It is effective in cases where migration of VM images is required.

Supported image formats

• VMware (VMDK/OVA)

• Microsoft Hyper-V (VHD/VHDX)

• Citrix Xen (VHD)

Suitable cases

• I want to migrate my existing virtual machines to EC2 without changing the OS or applications.

• Environments where agent installation is difficult

• Companies that want to migrate images without using MGN

Benefit

• Existing virtual machines can be migrated as is

• Simpler and easier to manage than MGN

Demerit

• There are no functions such as replication or test switching

• Migration may require outages, which can lead to downtime

• Not suitable for migrating many servers

Comparison with manual migration (AMI creation/rsync, etc.)

There are also ways to manually migrate to EC2 without using AWS MGN or VM Import/Export. Typical examples are as follows:

• Manually create an Amazon Machine Image (AMI) to replicate the environment

• Transfer application data using rsync or file copy

• Recreate server construction using configuration management (Ansible/Chef, etc.)

Benefit

• High degree of freedom and easy to fine-tune configuration

• Supports cases where tools are not compatible, such as old operating systems and special configurations

Demerit

• High workload and prone to human error

• You need to prepare all the test procedures and production switchover procedures yourself

• Not suitable for migrating many servers

Judgment criteria

• AWS MGN is the foundation: the leading platform in terms of automation, safety, and testability

• If you want to transfer the virtual machine as is, use VM Import/Export

• Manual migration is possible for special configurations or small environments

Practical steps for migrating to Amazon EC2

1. Visualizing the current environment and organizing dependencies

The success of the migration depends largely on the preliminary inventory. First, you need to understand the configuration of your current server.

Examples of inventory items

• OS/middleware version (Linux/Windows, Apache, Nginx, IIS, etc.)

• Application configuration (framework, dependent libraries, service configuration)

• Network requirements (ports, firewall settings, external connections)

• Storage capacity and I/O requirements

• Backup/Batch Processing Schedule

In particular, it is important to identify dependencies such as external databases, external APIs, and log management platforms early on, as these can easily cause problems after migration, such as them not working properly.

2. Selecting a migration method

Once the inventory is complete, you can decide which migration method to use. The best method depends on your migration schedule, risk tolerance, and technical debt.

Rehosting (Lift & Shift)

• Migrate your existing environment to EC2 as is

• Ideal for those who want to minimize downtime and move to the cloud in a short period of time

• AWS MGN is the best choice

リプラットフォーム

• The app remains the same, but the peripheral configuration is optimized for AWS.

• Example: Migrate monitoring to Amazon CloudWatch and backup to Amazon EBS snapshots

• Effective when considering operational improvements after migration

3. Migration using AWS MGN and AWS VM Import/Export

Based on the selected migration method, we will proceed to the actual migration work.

When using AWS MGN

Prerequisites

• The agent can be installed on the source server.

• Network requirements (communication ports, proxy settings) are met

Itinerary

1. Configure replication on the AWS side

2. Installing an agent on an existing server

3. Block-level replication

4. Launch a test EC2 instance

5. Once testing is complete, perform the production cutover

It is designed to minimize downtime, allowing you to migrate with minimal impact to your business.

When using AWS VM Import/Export

Prerequisites

• Ability to obtain virtual machine images (VMDK/OVA/VHD, etc.)

• The environment must be capable of uploading to S3

Itinerary

1. Upload the virtual machine image to S3

2. Execute VM Import using AWS CLI

3. Launch as Amazon EC2

4. After verifying operation, tune as necessary

This is a simple method for migrating on a VM-by-VM basis, but it does not include a test switching function.

4. Test operation and performance verification

Verify that the migrated EC2 instance works as expected.

Examples of check items:

• Application normal operation

• Checking connections with external APIs and DBs

• File path and environment variable integrity

• Check CPU/memory/I/O performance

• Batch processing and backup job behavior

• Consistency of security settings (security groups and IAM roles)

Regarding performance requirements, significant improvements can be achieved by reviewing the instance type and optimizing the EBS volume type.

5. Switching to production and DNS update/monitoring settings

Once testing is complete, we will perform the cutover to production. After the cutover, we will check that the entire app is running properly and make performance adjustments as necessary.

• Final sync from old environment (automatic when using MGN)

• Stopping the old server

• Launching a new EC2 instance

• DNS switching (Route 53 or existing DNS)

• Amazon CloudWatch monitoring settings

• Operational log management using AWS CloudTrail

AWS environment configuration concepts

Basic design of VPC/subnet/security group

To operate Amazon EC2 safely, it is important to first design the Amazon VPC, which serves as the network infrastructure. Because the network is directly linked to availability and security after migration, it is essential to design it at an early stage.

VPC design basics

• Separate VPCs for development, testing, and production to clarify the scope of impact

• Decide on the CIDR design early and plan for future expansion (additional subnets, VPN connections)

• Separate public and private subnets by purpose

Subnet design points

• The basic configuration is to place EC2 in a private subnet.

• Internet communication is performed via NAT Gateway

• Manageability improves if you divide subnets by role, such as application layer, DB layer, and management EC2.

Security Group Design

• Ensuring "zero trust-like least privilege" by allowing only the minimum necessary ports

• Inbound traffic is only permitted from specific IP addresses and servers.

• It is recommended to configure SSH/RDP via a bastion host.

IAM and Access Control (Separation of Privilege)

AWS Identity and Access Management (IAM) is the foundation for managing permissions within accounts. This is an area where accidents are likely to occur during post-migration operations, so it is important to implement appropriate controls early on. By strictly adhering to the principle of least privilege, you can reduce the risk of security incidents.

IAM design basics

• For daily operations, use IAM roles + AWS SSO (IAM Identity Center) instead of IAM users.

• Separating roles between developers, operators, and administrators and fine-grained control of permissions

• Do not store access keys directly in EC2. EC2 obtains access permissions through IAM roles.

Common mistakes

• Administrator privileges (AdministratorAccess) are granted unconditionally

• Leaving access keys stored locally

• Insufficient organization of unnecessary roles and policies

Backup Snapshot Strategy

In an EC2 environment, it is essential to build an appropriate data protection system. Backups are directly linked to stable operation after migration, so it is an area that must be designed during the construction phase.

Backup method example

• Amazon EBS snapshots: A standard method to take snapshots without stopping EC2 instances

• AWS Backup: An integrated service that automates schedule and generation management

• Saving server images using AMI: Effective for backing up entire applications

Key Points

• Production environments require regular operations such as daily snapshots and weekly storage.

• Determine recovery time (RTO) and recovery point (RPO) in advance

• Backups are stored in multiple AZs and multiple generations to prepare for disaster recovery.

Monitoring and log management (Amazon CloudWatch/AWS CloudTrail)

To visualize the operational status after migration, we will put in place a monitoring and log management system.

Amazon CloudWatch (monitoring)

• Monitor metrics such as CPU, memory, and I/O

• Logs (CloudWatch Logs) can be aggregated to enable application and middleware log analysis.

• Automate anomaly detection with alarm settings

AWS CloudTrail (operation logs)

• Record all operations within your AWS account

• It allows you to visualize IAM user/role operations, which helps detect unauthorized operations.

Key points to consider when building

• Be sure to set CloudWatch alarms (CPU, memory, StatusCheck, etc.)

• CloudTrail logs are stored in S3 and the retention period is clearly defined.

• Combined with threat detection such as GuardDuty, it creates a more secure environment.

Points to note when migrating

Check licenses and IP restrictions (Windows/commercial apps)

When migrating, you should pay particular attention to license requirements for operating systems and commercial applications, as well as IP address dependencies. Applications that are IP- or hardware-dependent are the most likely to cause problems, so it's important to check these issues early on.

Windows Server/SQL Server

• Licensing models may differ between on-premise and AWS

• Check in advance whether you can use BYOL (Bring Your Own License) or whether you should use Amazon EC2 AMIs that include licenses.

• When it comes to SQL Server, be aware that costs can vary greatly depending on the edition and core count requirements.

Commercial application

• Some apps have licenses tied to hostnames, MAC addresses, static IP addresses, etc.

• There are cases where license re-authentication is required after migrating to EC2.

• Completing the reissue procedures and vendor confirmation in advance will help avoid any issues when switching over.

Downtime Minimization and Rollback Planning

To minimize the impact on business operations during migration, it is essential to prepare a downtime and rollback (returning to the old environment) plan in advance. Especially when migrating a production environment, whether or not there is a rollback will determine risk tolerance.

How to minimize downtime

• Real-time replication using AWS Application Migration Service (AWS MGN)

• Data synchronization is completed in advance to minimize downtime during switchover.

• Set an appropriate maintenance time to avoid overlapping batch processing and DB updates.

Rollback Plan

• Maintain the old environment before the switchover for a certain period of time

• Prepare a procedure to immediately return to the old environment in the event of a serious problem after migrating to EC2

• Like the switchover procedure, the rollback procedure should be documented in advance.

Security Governance (Understanding the Shared Responsibility Model)

In AWS, security is based on a shared responsibility model between AWS and the customer. Misunderstanding this can lead to serious security risks after migration. EC2, in particular, is an IaaS, so the customer has a greater responsibility for security at the OS and application layer.

AWS Responsibilities

• Physical security of data centers, hardware, networks, etc.

• Availability and redundancy of virtualized infrastructure and entire regions

User Responsibility

• Network settings such as VPC, subnets, and security groups

• Managing IAM User Roles

• Applying patches to EC2 instance OS and applications

• Encryption, backup, and access log management

Cost estimation and billing structure (EC2 billing, storage, and communication costs)

To accurately estimate post-migration costs, you need to understand the AWS-specific billing structure. It is not uncommon for costs to increase more than expected after migration. Upfront calculations and configuration optimization are key.

Amazon EC2 billing points

• Instance type (number of vCPUs and memory amount)

• Usage time (charged by the second, costs increase with continuous operation)

• EBS (I/O performance by storage capacity and type)

Network and communication costs

• Outbound communication to the Internet is subject to charges

• Connection to the internal network (VPN/Direct Connect) also incurs separate costs.

Cost optimization example

• Start with a smaller instance type and scale based on load

• Use Savings Plans to reduce long-term costs

• Set up automatic termination of unnecessary instances (EventBridge + Lambda)

My Feelings, Then and Now

Migration to Amazon EC2 can be done safely and efficiently by using the multiple migration tools provided by AWS. In particular, AWS Application Migration Service (AWS MGN) automates replication and test switchover, making it ideal for migrations that require a short period of time and low risk. If you want to transfer VM images as is, you can use AWS VM Import/Export, while manual migration is an option for small-scale or special configurations.

For a successful migration, it is important to carefully carry out the process from preliminary inventory, determining the migration method, test operation, and switching to production. After the migration, stable operation can be achieved by preparing the operational infrastructure, such as VPC design, IAM authority separation, backup, monitoring and log management.

As long as you keep in mind points such as license restrictions and cost structure, migrating to EC2 will be a sure first step towards utilizing the cloud.