Provisioning perfected IT resources in AWS, without adding to the TCO, is an art. Because, AWS offers many computing, storage and networking services across Availability Zones (AZs) and regions. It gets overwhelming as the usage scales. The availability of several services at the fingertips creates an illusion of getting infinite capacity performance on a highly available and scalable infrastructure. It does but at a cost! With few precautions, it is avoidable. Here are top mistakes a team must avoid while provisioning resources in AWS Cloud:

#1 Not Making the right tradeoffs while selecting instance types

AWS provides a wide variety of instance types that differ based on use, such as general-purpose servers, CPU or memory intensive workloads, I/O performance, and size. One must choose the instance type carefully and based on their application use-case.

#2 Not taking advantage of multiple Availability Zones (AZs)

AWS AZ is a simple feature that distributes a user’s workload across multiple data centers within a given region. This is a very effective solution to lower risk in case of an outage. The key is to manage load balancing across distributed servers. Unfortunately, most users don’t think about distributing their workload until they experience an outage.

#3 Not Attaching EIP in production servers

Stop and start of server changes the Public IP of a server. So again you have to map the changed IP to Route53, which you don’t want. So attach EIP to the production, so that after stop and start as well, the IP of the server should not change.

#4 Provisioning instances in wrong subnets

Always provision Application servers and RDS in private subnets. Attach the Application layer with ELB and keep the ELB in public subnets. Don’t expose Application and DB in public subnet.

#5 Managing infrastructure manually

Setting up AWS resources via web-based management console implies manual infrastructure management. The biggest problem with this approach is, it is not reproducible. If not documented, chances of making mistakes are high.

AWS CloudFormation solves this problem at zero cost. Instead of creating all the resources like EC2 instances, Security Groups, Subnets, load balancers, etc. manually, describe them in a CloudFormation template. Then CloudFormation will figure out how to turn this template into a running stack.

To Wrap Up:

Cost of IT services (against their theoretical return), especially in AWS cloud, is always high. Moreover, a spike in cost is an engineering problem in the cloud. Making the right trade-offs, automation, the right use of IT resources, not using Auto Scaling Groups, underutilizing virtual machines in AWS are pivotal in increasing the ROI curve.

Provisioning infrastructure, monitoring utilization, and implementing a load balanced, auto scaled infrastructure, etc. in an ever-changing environment is overwhelming. Try TotalCloud.io, the world’s first interactive and immersive visual console for AWS cloud management and monitoring.

‍