The 10 costliest mistakes to avoid when migrating your DevOps tools to AWS

Migrating your DevOps toolchain to AWS is great, but it is a big undertaking where it is easy to slip up. Some mistakes will hurt you immediately — and some you will regret forever. 

My team has guided companies along this journey many times and has seen which mistakes are being made. 

To help you avoid the same mistakes, I wrote down the most common ones for you, and what to do to avoid them. So read on and protect yourself from mistakes that will lead you to:

• Pay for services you don’t need or use

• Need more maintenance down the line

• Migrate the same old inefficiencies to the cloud

• Miss out on features that could make life a lot easier for you

• Invite extra work that you could easily get as a managed service

Let’s dig in.

1. Moving databases to AWS without looking at alternative database engines

Simply moving your existing database to AWS without looking at alternatives is the easiest option when migrating to the cloud. Just pick up your existing database and drop it in the cloud as is.

But this can be a costly mistake because you can often use other databases that do not have a licensing cost. 

An example

Let’s say you have a Microsoft SQL server database. You can potentially save tens of thousands of dollars per year on just one server by instead using an AWS-managed database service called RDS.

Do this instead

Investigate if it's possible to move your expensive database to a cheaper alternative. There are tools available from AWS to help you with this. I personally like AWS Babelfish for Aurora PostgreSQL. This tool lets your application talk to an AWS Aurora PostgreSQL database (even if your application was written for a Microsoft SQL Server) with little or no code change. 

AWS also has other tools to help you with database migration, such as AWS Schema Conversion Tool. The AWS-managed databases are fully managed by AWS, freeing up your time, but also have many other benefits. 

2. Simply migrating servers to AWS as EC2s without evaluating which AWS services can be used

Don't migrate to EC2 if a suitable managed or serverless service does the same job without the need to maintain and patch a server. Reduce complexity when you can. 

An example

If you use an AWS RDS database, AWS patches and takes care of redundancy if you enable the option. Of course, there are exceptions to this that you will need to evaluate.

You will potentially waste money and manpower that could be better spent elsewhere. Imagine having a service in the cloud that you never have to patch, upgrade, and maintain, that can still do the job.

There are many managed services from AWS that can make your life easier, and not evaluating them is a mistake.

Do this instead

To prevent this, you should look at which managed and serverless services AWS offers that could make your workload easier to manage. For example, look at what it would mean for you if you used managed databases from AWS or used a serverless kubernetes cluster from AWS.

Are you using a message-queuing service? AWS has a few different managed solutions you could consider, which would mean you don't have to manage any servers for this.

3. Not managing your costs

AWS can get expensive fast if you don’t monitor the costs closely. Maybe your developers started a few expensive servers for a test and forgot to terminate them, or you are not deleting backups correctly and the costs are adding up.

An example

Imagine realizing after a few months that your monthly costs have steadily increased, but the monthly increases were too small for you to notice them. You realize that resources have been lying around costing money when they in fact should have been deleted. 

Now you have a monthly cost that is a lot higher than before because you are paying for things you are not using.

Do this instead 

AWS has tools that can help you monitor your costs and also alert you if anything seems strange. But you need to activate these tools. 

There are also third-party tools that will monitor your cloud costs, give you suggestions, and help you find areas where you can save costs.

Perhaps you have a few servers that are only used Monday to Friday. Maybe you can stop them over the weekend to save money? Remember that in AWS you pay for the time your resources are running. So if you stop a server, you will no longer pay for that compute time.

Also, an EC2 Windows server is twice as expensive as an EC2 Linux server since you are paying for a Windows license. Avoid using Windows if possible, to lower costs.

Don't be afraid to try new instance types, such as AMD-powered instances or AWS Graviton. AMD is generally 5-10% cheaper than Intel, and you can save even more by using AWS Graviton if your application can run on ARM CPUs.

Benchmark the different instance types with your application and see what works for you.

4. Not realizing that instance size requirements can change over time

Some applications and services do not use auto-scaling, so you have to pick an instance type and size. But the compute requirements for a server might change over time. Maybe a specific server had a heavy load a few months ago but now has a very light load.

This could mean you are paying for a large instance when you would be perfectly fine with a smaller one. You are now paying AWS a lot more money than necessary when something as simple as downsizing the server can cut your server costs in half, or more!

An example

Perhaps you have an AWS RDS database that you can downsize, or an application running on an EC2 server, only using 10% of the available resources.

Do this instead

Re-evaluate your instance sizes a few times per year to make sure you are not paying more than you need. AWS has tools for this that are free, and you can also use third-party tools to help you manage instance sizes.

5. Not considering the costs of data transfer 

Data transfer often costs money in AWS, depending on source and destination. Data transfer from the internet to AWS is free, but it will cost money when you send data, such as:

• from AWS to the internet

• from one availability zone to another 

• to a different AWS region

If you are not aware of this and start using AWS, you could be in for a big surprise when your bill arrives. 

An example

If you, for example, have a server on premise that pulls many terabytes of data out of AWS, it could get expensive.

Do this instead

Estimate your networking costs before you start building. Maybe there is a better way to architect your solution. Perhaps the server that downloads a lot of data from AWS to on-premise can be moved to the cloud?

6. Developers deploy unnecessarily expensive services and servers 

When you deploy a server or service in AWS, it's very important that your developers understand the costs of what they are deploying.

An example

If you deploy a Microsoft SQL Enterprise server with 16 CPU cores it will cost around $5000 per month. There are many services you can deploy that can be configured with large instances and costly configuration options, such as very fast but expensive storage.

Do this instead

Make sure your developers understand the cost of what they deploy in AWS. In the cloud, it is easy to increase the server size later. Don't start with a big, oversized server like you maybe would on-premise.

Also, put in place alerts for unexpected cost increases, so you can find any mistakes before it gets expensive.

7. Not making a solid and feasible plan 

Make a solid and feasible plan — and expect the best, but prepare for the worst.

An example

Some companies start testing out AWS and it turns into a POC. That POC later turns into production. You now most likely have development, validation, and production environments mixed — and you have a mess on your hands.

Do this instead

Make a plan and build a landing zone. You need a solid foundation to build and grow your environment. It is more expensive in the beginning, but you will save yourself from having to rebuild your environment later. And in the end, you save money and have a more secure environment that follows best practices.

8. Falling in love with your servers/services

Often servers and services stay around too long because there could be something there that you need in the future.

This will lead to you paying more than necessary. If you look at these costs over a year it usually adds up to a lot of money.

Don´t name or fall in love with your servers/services. They are disposable things. Be brave to kill your precious resources.

Do this instead

In AWS it's fast to restore a server from backup. If you have servers you want to delete, don't wait too long to terminate the ones you are not using. Take a backup and delete the server. For every hour your server is still running, unnecessary costs accumulate.

9. Not understanding that (almost) everything costs something

A small cost may seem insignificant, but accumulated all those small costs add up to a big bill.

An example

Elastic IP is free if it is attached to an NIC / EC2 instance. Otherwise, it accumulates costs every hour. 

• A few EBS volumes laying around 
• A few snapshots that are old 

…all these things by themselves may not be a high cost, but together they can quickly run up to thousands of dollars.

Do this instead

Make sure you remove resources as soon as they are not needed anymore. A third-party tool could help here as well, which will remind you when you have unused resources.

10. Not realizing the migration is a great opportunity for some housekeeping 

Even though it may be tempting (and easier) to move your current on-prem setup to the cloud as is, this is a perfect opportunity to do some housekeeping and cut off and consolidate unnecessary or bloated setups.

An example

Maybe you have servers that you are not even using, that you are migrating over. Perhaps you could build something differently in AWS, to significantly lower the costs.

Do this instead

Take the opportunity to remove unneeded servers and optimize your setup when moving to the cloud. This relates to some of the previous points, but since it is such a crucial point (and is so often overlooked), it deserves its own spot on our list.

In summary

Having helped so many companies migrate their DevOps toolchains to AWS, we have seen it all. Hopefully, by sharing these common mistakes, I can help you avoid learning the lessons the hard way. 

In the words of Otto von Bismarck:

“Only a fool learns from his own mistakes. The wise man learns from the mistakes of others.”

Happy migration!