# Amazon Web Services (AWS)

> The safest bet for a company that plans to grow: clear primitives that compose. You have to be a pro to drive it, and AI now carries much of that load.

- Verdict: My default
- Vendor: AWS
- Layer: [Platforms](https://cloudlesslabs.com/stack/layers/platforms/index.md). Job: My default cloud
- Last reviewed: 21 October 2026, by Nicolas Dao (Cloudless Labs, Sydney)
- Web page: https://cloudlesslabs.com/stack/aws/. The whole stack in one file: https://cloudlesslabs.com/stack/brief.md

My default cloud, and not because it's the only one I know.

AWS wasn't my first cloud. My first production cloud was Windows Azure, from 2012, when the cloud was still something only startups did. With nothing to compare it with, I took it as the benchmark, and it was a pain from start to finish. I moved to AWS after Azure, not instead of trying it. The full story, with Google Cloud in the middle, is in the worked example "Why I ended up on AWS", linked below.

What made the difference is the primitives. AWS is, for the most part, the open-source building blocks you already know, made to run in the cloud: virtual machines, Postgres and MySQL, Redis, Kafka, OpenSearch, containers, an object store, a queue. Each one does a small, predictable job, so you can understand it, and because you can understand it, you can compose it. That's what Linux gets right: complicated systems built from simple parts. When I left the Microsoft stack for Node.js and open source, and left Azure for AWS, things started to make sense.

For SMEs and enterprises, it's the most versatile cloud there is. Their requirements are specific: compliance evidence, data residency, private networks, corporate sign-in, auditors. AWS has an answer to almost every one of them, and it builds for its clients rather than for itself. For a company that expects to grow, there's no safer bet.

It's not all rosy. IAM, security groups and network ACLs are what melts everybody's head on day one, and for years they melted mine. Queues and back pressure need lower-level work than on Google Cloud. And the real drawback: you have to be very technical to use it. If you're not, you drown, and then you get angry.

That last part is changing. Writing a least-privilege IAM policy, wiring a security group or tuning SQS retry windows is exactly the kind of detailed, well-documented work AI agents are good at. It's now largely the agent's problem, with a human reviewing the result. The complexity hasn't gone, but who carries it has.

## Use it when

- An SME or enterprise with specific requirements (compliance, data residency, private networking, single sign-on) that expects to grow.
- You don't yet know what the system will need in three years: AWS has a service for almost every answer, so growth doesn't force a move.
- The data has to stay in Australia: Sydney and Melbourne regions, with most services in Sydney.
- Someone technical (or an agent with a technical person reviewing it) will own the setup.

## Don't use it when

- Nobody on the team is technical and nobody will be. Vercel or Netlify give you one workflow you can drive; a complicated AWS setup you can't drive is worse than either.
- A single always-on box for agents or previews: Hostinger VPS does that job for a fraction of the price.

## Pricing

Pay for what you use, per service. Commit with Savings Plans once the baseline is known.

## In my words: what hurts

- IAM. Policies are JSON documents of actions, resources and conditions, and getting them least-privilege by hand was a nightmare for years.
- Security groups and network ACLs: two layers of firewall rules with different behaviour, and everyone's first VPC breaks on one of them.
- You have to be a pro. Someone who isn't drowns in it, then gets angry with it.
- Back pressure is assembled by hand from SQS, timeouts and retry settings, where other clouds give you a queue with a rate dial.

## Gotchas, with fixes

- **Gotcha:** IAM policies written by hand end up either too broad ("Action": "*") or so tight that every deploy fails on a missing permission.
  **Fix:** Have the agent write the policy from the code, validate it with IAM Access Analyzer's policy checks, and give people access through IAM Identity Center permission sets rather than IAM users.
- **Gotcha:** Security groups are stateful and only allow; network ACLs are stateless, allow and deny, and need the return traffic's ephemeral ports opened. Tightening a NACL silently breaks responses.
  **Fix:** Leave NACLs at their default and do the work in security groups, with rules that reference other security groups instead of IP ranges.
- **Gotcha:** There's no built-in rate dial between a queue and its consumer. A spike on SQS spins up Lambdas until the database downstream falls over.
  **Fix:** Set maximum concurrency on the SQS event source mapping, set the visibility timeout to at least six times the function timeout, and send failures to a DLQ with a deliberate maxReceiveCount.
- **Gotcha:** Budgets only send alerts. Nothing stops spending on its own.
  **Fix:** Attach budget actions that apply a deny policy or stop instances, set thresholds below the real limit, and review Cost Explorer monthly.

## Provisioning

Official Pulumi package · Official Terraform provider

@pulumi/aws and HashiCorp's aws provider cover practically every service, and both are the reference implementations for their tools.

## Instead, consider

- [Google Cloud](https://cloudlesslabs.com/stack/google-cloud/index.md): The client is already on Google Cloud and it works, or BigQuery is the centre of their analytics.
- [Hostinger VPS](https://cloudlesslabs.com/stack/hostinger-vps/index.md): One cheap always-on box for agents, jobs and previews.
- [Cloudflare Workers](https://cloudlesslabs.com/stack/cloudflare-workers/index.md): The edge, next to AWS rather than instead of it.
- [Vercel](https://cloudlesslabs.com/stack/vercel/index.md): A non-technical team shipping a website with one workflow.

## Worked examples

- [Why I ended up on AWS](https://cloudlesslabs.com/stack/guides/which-cloud/index.md): Which cloud should my company run on, and is AWS just the one you know?

## Sources

- [AWS Regions and Availability Zones](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)
- [IAM Access Analyzer policy validation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)
- [Control traffic to your AWS resources using security groups](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html)
- [Configuring maximum concurrency for Amazon SQS event sources](https://docs.aws.amazon.com/lambda/latest/dg/services-sqs-scaling.html)
- [Configuring a budget action](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-controls.html)

## Related

- [Platforms](https://cloudlesslabs.com/stack/layers/platforms/index.md): every tool in this layer, with its verdict
- [The whole stack in one file](https://cloudlesslabs.com/stack/brief.md): every use case and tool, for questions that span many
- [Map of every Markdown file on cloudlesslabs.com, with what each one answers](https://ask.cloudlesslabs.com)