5 Mistakes Startups Do While Buying & Managing Aws Resources

A majority of today’s startups or born-in-cloud businesses rely on public cloud, like AWS, instead of on-premises IT infrastructure. However, due to lack of in-house IT teams, they are coerced to take the DIY approach to provisioning and managing AWS cloud resources for their deployment and operational needs.

With no proper skill set, they need to learn and decipher several levels of abstraction that cloud brings with it and also familiarize themselves with siloed monitoring tools on their own. To top it, they are overwhelmed by the amount of information they need to soak in, analyze and act. It’s a natural human tendency to rely on what we already know or experienced in our past projects when we are learning a new technology or a tool.

Startups and newbies apply the same analogy of managing on-premise infrastructure management to cloud management as well and ultimately bite the bullet and shell out more money than expected. It’s because, they end up assuming too many things (mostly wrong ones).

This post discusses two primary and three common mistakes startups and newbies make while buying AWS compute resources:

#1 Not using Payer’s Account concept: When a team creates an account and they must avoid creating all their resources in a single account. One of the best practices is to create three AWS accounts — one account each for development, QA, and production. By doing so, the team can provision the resources accordingly. Another best practice is to create a fourth account and make it as payer account. While a team can provision resources to other three accounts, it is not recommended to create any resources in payer account, but link all the three account to this account. With this, the team will get a good discount and there will be separation of resources as well.

#2 Choosing the wrong instance model: An enterprise should know whether to launch an instance with On-Demand or RI or spot instance model. Check the need and calculate accordingly.

a) If you don’t know how long you will need the server up, On-Demand instances are the best, because On-demand instances are charged every hour and can be discarded anytime as required. Here, you have the freedom to use whenever or how much ever you want to use, but cost incurred are high. Basically, a server for one year would cost you $1*24*365= $8760 USD.

b) On the contrary, if you know how long you need a server, you can opt for Reserved instances, because you get it for discounted price compared to on-demand, however, if you want to discard the server after certain period of usage, you cannot get rid of it as it’s already been paid for and the cloud provider will not take it back.

c) If you are in need of a server for a very short duration of time, or really want to test something, Spot instances are ideal as the prices are typically one tenth of the “on-demand server” cost and one fifth of the “reserved server cost.” However, the catch is you need to bid  to buy it, say 0.1$ per hour. Hence, the server is available until someone else bids for it at a higher price. In that case, you have a window of 2 minutes to act before it’s gone. Here's you can use instance weighting for spot instances.

#3 Not monitoring AWS compute costs using CloudWatch alarms: Several newbie AWS users are not aware of CloudWatch alarms feature yet. They still are under the impression that they need to look into AWS cost explorer console manually. With CloudWatch service, a user can enable an alert for a specific instance to quickly know when cost touches a threshold point. One caveat here is, a user must know all the limitations associated with CloudWatch service like its ability to process huge amounts of custom log data, react to events in near real time, etc.

#4 Not having Disaster Recovery (DR) plan: DR plays a vital role in business continuity. Outages even from AWS can sometimes affect a business’ services, not just disasters or other calamities. Let’s recall February 2017 S3 service outage where approximately 148,213 websites, and 121,761 unique domains were down. One of the best solutions to such outages is buying instances for DR. Not many startups and newbies are aware that cross-region replication and well-designed AWS CloudFormation template can go a long way in continuous supply of computing resources for development and operational needs. Additionally, using region level DR rather than AZ-level DR can be the most useful in all scenarios.

#5 Not using a good cloud visibility tool and just relying on Trusted Advisor: To start with, many startups use Trusted Advisor feature to find loopholes in their AWS account, reduce cost, increase performance, and improve security. But, this feature does not provide complete visibility into resources usage and other metrics necessary for cloud optimization. Even though Trusted Advisor provides real-time guidance to help provision resources as per AWS best practices, it does not allow users to monitor, analyze, remediate and right-size AWS cloud with contextual insights and operational capabilities. A cloud visibility tool, like TotalCloud, which helps users to understand complete cloud usage contextually from a single pane view, will only help.

Are you a startup or a newbie still trying to get hold of your AWS usage? You can automate almost all AWS related actions through TotalCloud's Workflow Editor. Create simple workflows to achieve any use-case. You can sign up for a free trial to explore more!

5 Mistakes Startups Do While Buying & Managing Aws Resources

Smart Scheduling at your fingertips

Go from simple to smart, real-time AWS resource scheduling to save cost and increase team productivity.

Learn More
More Posts

You Might Also Like

Cloud Automation
New In: No-code cloud management workflows for Azure, VMware & Private Cloud (in addition to AWS)
At TotalCloud, we’ve been enabling workflow-based cloud management for AWS to make it intuitive, accelerated, and no-code. Instead of programming cloud management use cases or depending on siloed solutions, we built out a platform that gives you building blocks to assemble any cloud management solution. 
September 4, 2020
Sayonee
Cloud Computing
List of Essential Kubernetes Tools
Kubernetes is a Container-as-a-Service with tons of unique tools to choose from. External tools play a role in integrating with different systems or maintaining control over the clusters you deploy. Manual health checks and troubleshooting is not ideal to keep a system in full health.This list of tools will provide ample support to your containers and have enough configuration to leave management flexible...
August 12, 2020
Hrishikesh
AWS Use Case Files
TotalCloud Inventory Actions: Giving a new meaning to Cloud Inventory
Learn how the TotalCloud Inventory Dashboard can become equivalent to your cloud provider’s SDK. Carry out any action on any discovered resource with Inventory Actions.
July 30, 2020
Sayonee
AWS Tips & Tricks
AWS Tutorial: Create an AWS Instance Scheduler with Terraform
Terraform is a popular IaaS tool used by many to create, update, and maintain their AWS architecture. If you use Terraform to provision your AWS architecture, you won’t be disappointed with our new AWS tutorial video.We provide you with the means to set up your own instance scheduler from Terraform...
July 20, 2020
Hrishikesh
Cloud Computing
Azure vs AWS: What you need to know
Companies that have jumped the gun with cloud migration during this time of crisis have committed a fatal mistake. The knowledge gap among businesses that seek to migrate is often underestimated, leading to devastating expenditures and operational inefficiencies...
July 15, 2020
Hrishikesh
AWS Use Case Files
Automating Auto Scaling Group Updates
AWS introduced autoscaling to make EC2 cluster scaling easier. We've seen users constantly make changes to their EC2s and put new policies into play. It’s important to update your Autoscaling group with the new instances so that it doesn’t ignore these machines.
July 6, 2020
Hrishikesh