microworks - Fotolia


Four common AWS cloud migration mistakes

With more than one million customers, AWS has convinced enterprises of all shapes, sizes and industries that its cloud can improve IT operations. But the move isn't always flawless.

Every enterprise IT environment has its own unique characteristics, which is why migrating applications to the...

cloud requires detailed and careful planning. However, there are some best practices all enterprises should follow -- and some things to avoid -- when moving servers and applications to the cloud. Here are four common AWS cloud migration mistakes.

1. Selecting the wrong AWS instance type

Moving an on-premises server to AWS requires administrators to select the appropriate Amazon Elastic Compute Cloud (EC2) instance type. AWS provides several classes of instance types, making it confusing to select the correct one. This is especially true for busy workloads that have demand for high performance. Selecting the right instance type requires more planning than simply selecting the right amount of virtual CPUs and memory.

For example, EC2 instances typically store data on Amazon Elastic Block Store (EBS) volumes. Instances connect to EBS via the network; strong connectivity to EBS aids workloads that require high storage performance. Certain instance types within each instance family support a feature called EBS optimization, which provides dedicated throughput for EBS I/O operations. This can vastly improve performance for EBS volumes and can be a factor in getting the best read/write performance.

Each EC2 instance family also includes certain instance types that support high-speed or 10 Gb network connections, as well as an enhanced networking feature. These types are suitable for busy server workloads that send and receive large amounts of data over the network.

Admins must select an instance type that provides the right amount of CPU and memory resources, as well as enough network connectivity for both EBS storage and application data transmission. Instances -- and the applications -- running on them will suffer from performance issues if there is a lack of CPU or memory resources. This is also true when there is a bottleneck in the network. The end result of selecting an instance type without enough resources is a slow server and bad experience for end users of an application.

2. Selecting the wrong storage configuration

Many enterprise workloads require a lot of storage I/O, and many enterprises select a storage configuration during AWS migration that doesn't provide adequate I/O performance. EBS volumes are commonly used for storing critical data, and there are several EBS volume types to consider.

Moving an on-premises server to AWS requires administrators to select the appropriate Amazon Elastic Compute Cloud instance type.

There are three EBS volume types available, and selecting the right one can be a critical factor for production systems. The magnetic EBS volume type is backed by traditional hard disk drives with spinning platters. This volume type provides the least amount of I/O performance and is typically only used for storing infrequently accessed data.

The other two EBS volume types -- general purpose and provisioned -- are backed by solid-state drives (SSDs). SSDs use flash-based memory and have no moving parts; therefore, they fail less frequently and are much faster than traditional magnetic disks. SSD-backed EBS volumes support more IOPS per disk. General-purpose EBS volumes support up to 10,000 IOPS; provisioned IOPS volumes support up to 20,000 IOPS.

Properly planning of storage requirements includes choosing the right instance type -- with EBS optimization and good network connectivity -- and selecting the proper EBS storage class. Failing to do this typically results in network and storage bottlenecks that cripple cloud applications.

3. Failing to implement the right architecture

One of the key architectural patterns for deploying workloads on AWS is to eliminate single points of failure. This typically involves using multiple EC2 instances for each workload to add redundancy across an AWS region. For example, IT administrators can place web front-end servers for an application in two separate availability zones; the servers can also reside in two distinct physical locations. Those web front-end servers can then be load balanced using a service like AWS Elastic Load Balancing. This is a simple way to ensure that a particular workload continues to run when there is a single instance failure or when an availability zone is lost.

Failing to implement high availability from the start is a common cloud migration mistake. Some organizations choose to implement a single-instance architecture during the migration phase -- with plans to implement high availability later. This approach increases chances of a service outage and can increase operational overhead and architecture complexity once the AWS cloud migration is complete. For best results, build applications based on best practices before beginning the migration.

4. Improperly or insufficiently training IT staff

Running enterprise applications on a mature public cloud platform such as AWS allows an enterprise to easily mimic existing on-premises deployments. However, successfully deploying and operating a complex environment on AWS is quite different than managing on-premises infrastructure.

IT teams must understand AWS operations and best practices to make an AWS cloud migration project a success. If you cannot get staff trained prior to the move, consider hiring an experienced AWS partner to help you properly plan and execute the project.

Next Steps

Consider these five AWS migration methods

Plot a migration roadmap for legacy apps

Boost Amazon EBS volume performance

Dig Deeper on AWS streaming and file transfer services