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:
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.
-
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.
- 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.
- 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.
- 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.
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.
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.
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. Let those mistakes do not come back to bite your business. Try https://TotalCloud.io, an interactive and immersive visual platform offering complete cloud visibility.
Top comments (0)