10 steps for migrating your workloads to Amazon Web Services (AWS)

ClearPoint's Practice Lead - Cloud, Terence White, outlines and simplifies the 10 steps for migrating to Amazon Web Services (AWS) for those at the start of their cloud journey. Watch the session below to hear how organisations of all sizes can best leverage AWS.

Migrating your workloads to cloud providers such as Amazon Web Services (AWS) can be simpler, quicker and safer than you think. AWS allows you to migrate any workload from applications, websites, databases and servers to full data centres.

In this blog, we outline and simplify the 10 steps for migrating your workloads to AWS for those at the start of their cloud journey, using the example of a simple load-balanced, three-tier workload (front end, application servers and a database) running in your data centre that needs to be migrated to the cloud.

To prioritise transformation opportunities and ensure your organisation is Cloud-ready, learn more about best practices for Cloud adoption with AWS.

Set up a Landing Zone in AWS with networking back to your data centres
A Landing Zone is a pre-defined, secured, multi-account environment that is ready to onboard different workloads and teams in an automated manner. Use Control Tower, a tool for setting up and managing a multi-account AWS environment, as a base to get started and set up an Infrastructure as Code (IaC) tool with pipelines for consistent replicable deployments of your cloud infrastructure and applications. You also should connect your cloud environment to your existing network. This step will be the longest but you only need to do it once, even if there are multiple workloads you want to migrate.
Set up a new account for your workload environment
An AWS account is a logical container for your workloads and should be used as an isolation boundary for both security and billing purposes. Using a new account for each set of environments for each workload is best practice for those looking to scale – development, test, staging and production are examples of environments you might employ. This will allow you to get granular in determining how much each workload environment costs and who can make changes in them, resulting in greater flexibility and control.
Migrate the Domain Name Service (DNS) entries for the workload across to the Route 53 DNS service
This step isn’t strictly necessary but it makes it easier for your cloud team to manage the DNS entries for your application, as Route 53 is integrated with the other AWS services you are going to use.
Stand up a new database in AWS similar to your existing database
Amazon Relational Database Service (RDS) is a managed service that makes it simple to set up, operate, and scale relational databases in the cloud.
1. If your database engine is Oracle or SQL Server, then use RDS instead of setting up a new database server to reduce your maintenance burden going forward. Remember to review your Software Licensing Agreement and comply with Oracle’s or Microsoft’s licensing policies.
2. If your database is MySQL or PostgreSQL then use Amazon Aurora RDS. Aurora is a fully cloud-native managed relational database engine built by AWS to be fast, reliable, durable and fault tolerant but also 100% compatible with MySQL and PostgreSQL.
Load your data into your new database
Use native database tooling for copying your schemas and either native database replication or the managed service Database Migration Service (DMS) to bring the data across from your existing database.
Stand up the web and application tiers in AWS
1. Use an Application Load Balancer (ALB) for the front end of the workload. This is a managed service from AWS that acts as a front end for your workload and scales to handle any number of incoming web connections.
2. Put any large static files into the Simple Storage Service (S3). S3 is a fast and cheap yet highly durable object storage for virtually unlimited amounts of data.
3. If your workload is containerised, use the Elastic Container Service (ECS) Fargate managed service to run the Docker containers. You won’t need to manage any underlying servers going forward. If your workload is not containerised, virtual servers in the Elastic Compute Cloud (EC2) are the best option. Use Systems Manager to manage the servers altogether, and set up automatic operating system patching and backups.
4. Configure your application servers to connect to the new database.
5. Finally, put the Amazon CloudFront Content Distribution Network (CDN) in front of your workload - CloudFront has three network edges in Auckland so organisations based in New Zealand can connect locally for a better experience.
Test, test, test
You need to test your cloud-based application before it begins to serve live traffic. Those responsible for testing should not just confirm that the application is functionally correct but also that the performance is acceptable. This is the time to change memory or compute allocations to the application servers or the database, which you can do in seconds. Your cloud team can refresh the new database at any time when the testers need an updated copy more closely reflecting production.
Clean out and reload your new database
Once the testing team has signed off, refresh your database one last time and set up change replication from your original database to your new one. This will help keep your outage window short for the transition.
Go live!
1. At the appointed moment put up an outage page on the old URL to stop customers from doing anything else within the old environment.
2. Wait for the replication to migrate the last data changes across to AWS. This should only take a couple of minutes as you’ve been moving the changes across continuously since the refresh.
3. When both databases are in sync, switch the replication around to replicate from the new database back to the old. This will help should you need to fail back to the old environment because of unforeseen issues.
4. You can then switch the workload DNS entries to point to the new environment and you are live!
5. If you find issues in the new environment and want to fail back to the application running in your data centre, just repeat this step the other way around.
Clean up your old environment
After a successful period running in the cloud, you should clean up your old environment in your data centre. Don’t forget to stop the replication processes that are copying all the data changes from your new database back to your old one.