• AWS
  • HOW TO
  • IAAS
About Me

T here are many different ways to approach moving to a cloud infrastructure provider such as Amazon. Over the past couple of years,  and many different cloud projects, I have come up with a bit of a road map. I consider these my steps to successfully plan for the cloud. Most of the steps will make you say “no duh” . But, they are important to know and follow because when you have the whole plan in mind, you will know what to look for later on.

Successful Cloud Server Planning


Obviously, a pretty key part of any plan. In this phase I try to document as much as possible. This includes IP schemes and security groups and features that will be used. For example if I’m using AWS I will document if RDS, EC2, ElastiCache, S3 etc. are going to be used. This helps to understand how the different products will interact, and how they are going to scale, and how you are going to build in some fault tolerance. I generally leave instance sizes out in the scenario because those will change in the proof of concept phase.

When I’m in the planning stages there are a couple of things that I try to make sure are accounted for:

  1. Modular – I want to be able to add and remove pieces of the infrastructure without effecting anything else, functionality or otherwise. Also, we want to be able to easily duplicate our production environment into a development environment as well. We will explore our options, such as cloud formation in a separate post.
  2. Scalable – This goes hand in hand with the modular piece above. We have to build a core group of products that is easily scaled. We want the opportunity to scale horizontally rather than scale vertically. Meaning, we want to add more small instances rather than needing to have large high-priced instances.
  3. Simple – With the amount of features that are available it is really easy to think we need to utilize them all. Cloud computing by nature can be very complex. I try to build in basic simplicity whenever its possible. While documentation is imperative, I want others to be able to understand the basics behind the design by simply viewing a diagram, or even just the management console.



In this phase, I want to establish the fact that our new design is going to actually work. I will build out the servers as small as possible to keep costs down, or free if possible. We document any steps that we take to make sure that the design is working as planned. This step is not meant to establish capacity planning. Typically, I will build the network groups such as the VPC, subnets, and autoscaling across multiple availability zones. However in the early stages I will only add the compute instances to a single AZ. I’ve found that this helps keep the cost down and allows for quick scaling when needed.



In this phase, I will build out the infrastructure. It’s important to make sure that every step of this process is documented. Any changes that you made to the proof of concept will come into play here as well.

We will also want to move the data over at this point. Typically a database snapshot from the old infrastructure will be moved to the new design to make sure you have an equal database load.

The AWS Import/Export Tool comes in handy in this step as well if you are moving from on premise infrastructure.



In this phase of development, I will fine tune my design with actual data. This way we have a better idea how the data will affect performance. There are a couple of things we want to optimize.

  1. Performance – Obviously user experience is the ultimate goal here. There are several tools to test user load.
  2. Cost – This is a very important step to make sure that you do. There are a couple of things to do without ever even touching the actual design. For example moving instances from On-Demand, to Reserved will typically save as much as 50% of your monthly bill. You don’t have to change anything other than tell Amazon that you want to have reserved instances, This is an accounting function only.


Maintenance and Review 

This phase is pretty basic in nature, it is has two distinct goal

  1. Support – Maintaining user experience throughout the product life cycle is very important. Not to mention reducing customer churn will make the higher-ups happy. It’s important to document issues. Knowing which ones are recurring are vital to continuing to increase customer satisfaction.
  2. Reporting – Quality reporting is what will bring this entire timeline full circle. Getting accurate and up to date reporting will allow changes to be made moving forward. Fine tuning is imperative to keeping the project current. For example, as new instance types are available it will often times save money and increase performance  by upgrading.


Regardless of the phase of your project, it’s important to not let the design or infrastructure go stagnant. Features, and updates are constantly changing, and if you don’t stay on top of them you stand a good chance of losing customer satisfaction.

Please contact us at any time to help you on your project.