The 10 Biggest Mistakes Startups Make on AWS in 2023
Adopting AWS as your cloud infrastructure seems to be a common choice for most growing companies, but it is not as easy as it looks. Choosing the right services, configuration, and management of these services needs skills and experience. At Qovery, we've heard hundreds of stories about the mistakes made by startups on AWS, and here are the biggest ones.
Make sure you take care of these pitfalls when you start your journey on AWS, which will help you successfully migrate and set up on AWS.
Morgan PerryApril 5, 2022 · 6 min read
[Last updated on 07/26/2023]
Although you can create infrastructure on AWS easily and quickly, manually doing it has a couple of drawbacks. First, you cannot clone your infrastructure when scalability needs arise in the future. Secondly, there is no documentation for all the infrastructure you have created manually. Maintenance will be complex due to a lack of documentation.
Managing your Infrastructure through Infrastructure as Code (IaC) simplifies infrastructure management. AWS provides CloudFormation to easily create and manage all the infrastructure through simple text files.
It is very common to use EC2 instances in AWS, but beginners often miss using it as part of auto scaling groups. Remember, even if you do not have an immediate need for scaling out, it is still beneficial to use your EC2 instance as part of an auto-scaling group. An Auto Scaling group is just a collection of one or more EC2 instances that are treated as a logical grouping for automatic scaling and monitoring the health of instances. Auto Scaling groups enable you to use Amazon EC2 Auto Scaling features such as health check replacements and scaling policies.
It happens so many times that you forget to stop an EC2 instance, resulting in an increased monthly bill. Sometimes you have too many instances to identify which ones to stop. That’s where tagging comes in. It will be easier for you to identify which instance to stop if they are properly named and tagged. And it applies not just to EC2 instances; it applies to all the resources, including databases, lambda functions, etc.
Using too few resources is also a mistake startups make. They suspect that the provisioned resources might not be able to support the application needs. Note that AWS provides an on-demand business model, which means you do not need to kick off all the resources needed for peak loads. Users can add resources as needed without any downtime, and ideally, they should automate resource provisioning with AWS’s auto-scaling features.
Not having visibility on critical metrics is a recipe for disaster and can lead to irreversible consequences for your organization. It would be best to have as many metrics as possible from day-1. Tools like CloudWatch, Datadog, and Cloudtrail help you easily keep a vigilant eye on various metrics.
CloudWatch, for example, is a built-in tool of AWS for monitoring and logging every AWS service you use. You can see memory, CPU, bandwidth, disk usage, load times, and other useful metrics to analyze the usage. Not only it helps you monitor your resources and applications, but you can set alarms on your resources. E.g., send me an email if the CPU of my production server goes beyond 80%. To take most of the CloudWatch, you should create custom dashboards to keep an eye on your desired metrics like page load times, page not found errors, CPU spike patterns, etc.
AWS has too many services to choose from, offering 200+ universally featured resources, from infrastructure to machine learning. Some of the notable infrastructure services include EC2, RDS, Lambda, EKS, Elastic Beanstalk, ECS, CloudFront, Fargate, Dynamo DB...etc. , Newcomers to AWS sometimes choose a service not really suited to their business needs. Take the example of the EC2 instance. You can choose spot instances for non-mission-critical tasks, and it is super cheap too, but many startups still use the reserved or on-demand instance. Similarly, using managed services by AWS will save you a lot of time and errors instead of setting your own service e.g., Redis, RDBMS, etc.
Many startups fall victim to over-engineering a solution. Even in the early stages of the business, they tend to deal with the edge cases of the solution. Premature micro-optimizations are bad for business because micro-optimizations leave out context. Some examples of over-engineering are “Our system needs to support 10 thousand transactions per second”, “Our system should recover within X seconds in case of system failure,” etc. As a startup, your priorities should be to build a reliable product, launch it, get customers, keep them happy and gradually scale out your application.
Users usually adopt automation when they start losing revenue because of too many manual tasks and errors due to manual intervention. It does not apply just to infrastructure management; it applies to any task part of the business cycle. Some useful tools for automation on AWS include CI/CD tools, AWS lambda, Cloud formation, etc. Note that you can start the automation with only high-priority tasks and then gradually add more tasks to the automation.
Modern applications require frequent code integrations and multiple deployments every day. Not adopting any CI/CD tools and processes will result in slow development cycles and errors. There is no need to worry about the complexity of CI/CD, because you can start small, even with a simple pipeline. Tools like Qovery can help you get rid of any complexities around CI/CD management directly set up on your AWS account.
Security is of utmost importance for any business. Note that moving your application to AWS only secures the infrastructure. You need to make your application secure by taking various measures. Some of the mistakes startups make in the security area include the following:
- Using root account for daily tasks. You must create IAM users to perform administration and management of AWS services
- Not setting up MFA. You must set up multi-factor authentication for console log-ins
- Giving your S3 buckets public access
- Giving your EC2 instance public access on ports 22 and 3389
Still, from a security point of view, giving unnecessary higher privileges is a common mistake most of startups make, and can lead to unfortunate consequences. When you get some permission error on AWS or a production bug due to a lack of permissions, the easiest way is to allow all permissions to the user. That might be a quick fix, but that is one of the biggest security mistakes. If the credentials are compromised or the employee goes rogue, this broad access might cause a lot of damage. Always define privileges as narrow as possible to avoid any security issues.
The above list of mistakes can significantly impact your business in one way or another. Keeping an eye on the points mentioned previously will help you learn from others’ mistakes instead of making your own and will facilitate you in achieving your business goals. A solution like Qovery helps you deliver business value by automating your manual tasks and simplifying your DevOps needs without compromising the quality.