Migrating to the AWS Cloud

Getting ready to migrate to the Amazon Web Services (AWS) Cloud? You aren’t alone. Companies that are looking to modernize existing business applications often realize the best way to do so is to migrate them to the cloud. By doing so, you can improve agility, performance, and cost savings by moving all, or a key subset, of your workloads to the cloud. Before you start migrating workloads, you have a few key questions to answer. First, you need to determine what the ideal end state looks like for your organization. Is it hybrid or all-in on the cloud? Next, you need to consider which workloads are the right ones to migrate, and in what order. Following that step, you need to decide what your migration approach will be: lift and shift, partial or full refactoring, or supplementing with SaaS. Lastly, you must determine what your cloud-based architecture will look like. What instance types and services will you use? We will explore each of these considerations in detail in this eBook.

What’s my Ideal End State?

The first step in planning a migration is to define your desired end state. What goals are you looking to accomplish by migrating workloads to AWS? Common drivers of adopting the cloud include improved business agility and performance, availability, lower TCO, improved security, and scalability. Considering these drivers will shape the desired end state of your environment: will it be hybrid or all-in on the cloud? What will the architecture look like? Consider which of these common architectures makes the most sense for your organization:

1. Hybrid cloud with workload separation. This is a common approach to hybrid cloud, locating workloads either on-premises or on the cloud, based on business requirements. For example, static or legacy workloads may remain on-premises, while dynamic workloads are hosted on the public cloud.

2. Hybrid cloud with workload balancing. In this model, a single workload is hosted across both private data centers and AWS. The workload is deployed in an active-active configuration and is load balanced between the different environments, or uses AWS for on-demand, scalable capacity.

3. Hybrid cloud for disaster recovery. A simpler approach is spreading a single workload across the cloud and the data center, using one site for the primary and the other for the disaster recovery, or failover site. Depending on SLAs, you can replicate data and standby systems to the alternate site to be used in case of failure at the primary site.

4. All-in on the cloud. The most straightforward approach, of course, is to go all-in on AWS. This approach is typically the easiest to manage and is often less expensive than hybrid approaches.

Which Workloads Should I migrate first?

When tackling a project of significant magnitude, the most challenging part is deciding where to get started. If you haven’t migrated to AWS yet, the best approach is to begin migrating the workloads with the fewest dependencies. This allows you to ramp up slowly, building expertise and confidence before tackling the more complex workloads. Another approach is to start with the workloads that have the most overprovisioned, or idle resources. Industry research suggests that as many as 30% of on-premises servers, both physical and virtual servers, are zombies (showing no signs of useful compute activity for 6 months or more). On top of that, more than 35% of servers showed activity less than 5% of the time. As long as you right-size your cloud deployment on AWS, these workloads will see the greatest price/performance improvements once migrated.

What is my migration strategy?

Once you’ve determined your end state and which workloads you will begin with, you must decide on a migration strategy. You may have multiple different strategies depending on the workload, application, and business unit, but typically, organizations pick one of the following options:

1. 1. Lift and shift. This approach allows you to keep the application mostly as is, and make any necessary adjustments to run on AWS. This is one of the fastest approaches, and there are many migration tools that can assist with the process.
2. 2. Partial refactor. Some aspects of your applications can remain as is, but other parts may need to be rebuilt to operate properly on AWS. A partial refactor may also leave the existing application as is, and build additional supporting services on top of it.
3. 3. Full refactor. A full rebuild of your application is the most time consuming approach, but it also represents the greatest opportunity to take advantage of the elasticity and availability of the AWS Cloud. This could also be a good opportunity to break an application down into microservices, or build out a container-based architecture.
4. 4. Transition to SaaS or PaaS. If the workload you are migrating is a commodity application (e.g., email, CRM), or has commodity components (e.g., a relational database), you can incorporate a SaaS or PaaS into the mix. This will help accelerate migration plans, as well as reduce management overhead.

What will my technical architecture look like on AWS?

The last question to consider is tactical, but complex: what will your infrastructure look like on AWS? Which instance types should you use, and in which configurations? Which Reserved Instances should you purchase to maximize your investments? To properly answer these questions, you must look at historical performance data across CPU, memory, network, and disk for servers, and across throughput, capacity, and IO for storage. Decide how much “headroom” you want to give each asset (typically 25%), and then look at the actual minimum, maximum, and average usage across these metrics to determine which instance type makes the most sense on AWS. A virtual machine is considered undersized when the amount of CPU demand peaks above 70% for more than 1% of any 1 hour. On the other hand, a virtual machine is considered oversized when the amount of CPU demand is below 30% for more than 1% of the time during a 7-day period. Looking at 30 days of history is sufficient, because it is easy to scale up resources on the cloud if you need to. When going through this process, it’s critical to normalize for different generations of physical infrastructure.

Conclusion

Ready to take the next steps in planning your migration? Find out how the OpsGuard Migration Assessment simplifies the process of migrating assets from your data center to the AWS cloud. Our Migration Assessment enables you to efficiently assess and model workloads for migration and then manage and optimize your infrastructure for cost, usage, performance, and security once they are running on the cloud. This helps reduce complexity and helps you move faster in your migration process.