Four AWS mistakes founders should avoid

Four AWS mistakes founders should avoid
Four things to avoid with AWS

We’ve run dozens of free office hours with startups, here are the four most common AWS mistakes we’ve seen startups making.

Please don’t do these!

1) Using root accounts instead of sub-accounts

We’ve seen many first-time founders use root-credentials way too liberally - don’t do this.

As AWS put it  themselves:

“We strongly recommend that you do not use the root user for your everyday tasks, even the administrative ones. Instead, use your root user credentials only to create your IAM admin user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks. For everyday tasks, do not use your IAM admin user. Instead, use roles to delegate permissions.”

For more founder security fundamentals, check out

Instead, user sub-accounts: setup multiple AWS accounts that are under one organisation so use the same billing.

These accounts should be organised per customer/per environment.

It gives you an advantage of keeping your resources more secure.

2) Infinite loops without scaling limitations

This Hacker News user’s company created a “several-hundred-thousand-dollar bill” this way.

Ensure you have scaling limitations on your auto-scaling groups.

And gosh, don’t call the same Lambda from inside itself! Even if the idea seems elegant and you think you’ve put all the necessary checks in place. This is not the place to flex your computer science mastery. Don’t build a cash-burning machine.

More information can be found here

Beware infinite loops

3) Using containers & lambdas incorrectly

There are two ways to run your backend code - containers and lambdas, both have tradeoffs.

Containers on something like ECS enable your services to always be online, so you can achieve low latency. Automatically scaling in case of a load spike will be slower, and when there is no load you’ll still pay for idle compute. It’s ideal for consistent workloads like handling requests from your front-end but don’t use containers if you need to quickly scale up or want to hyper-optimise compute costs.

Lambdas are serverless - they scale up much faster and can go down to 0. so if there is no usage, you pay zero. Low latency is harder to achieve with lambdas though because of so-called “cold start” problem. don’t use lambdas for handling your application requests that require fast response - users don’t like when things are slow

Use lambdas for spiky workloads

4) Using Elastic Beanstalk

It promises simplicity but it has barely changed in the last 10 years and has many problems.

The AWS forums are filled with complaints about users facing constant restarts of their services and their services entering into deadlock states.

If you’re a first-time founder working with AWS, we wrote a guide for you