10 things I wish I knew before architecting AWS applications

Getting started using AWS can be hard.

Here are a few things I wish I'd known before starting aws.

  1. Learn more about IAM as early as you can. If you don't you'll run into countless auth errors and the few hours of investment will pay off in spades. Brigid Johnson's talk on this gives a great foundation. https://www.youtube.com/watch?v=YQsK4MtsELU&ab_channel=AmazonWebServices

  2. The names of aws services are weird. https://expeditedsecurity.com/aws-in-plain-english/ helps a lot. I've just given up trying to make sense of any name and always try to map it to "What problem does this service solve and what are the tradeoffs between the other products"

  3. There's no one messaging system that rules it all. It's more than likely you'll have to choose the right thing for the job and SQS will almost definitely factor in some part of a dead-letter-queue even if you land on something like eventbridge, sns or kinesis. Learn the tradeoffs between them and when to use which or combination of message queues.

  4. Prototype in aws console, but build using infrastructure as code (ie aws cdk). These help document which services you're using and help migrating between environments.

  5. Try serverless services when doing the initial draft architecture before you know your actual loads can free you from many constraints and can be swapped out for non-serverless services either once you have an actual load picture or even just stay in the design.

  6. Kubernetes and EKS are complex and require a lot of management overhead. Consider serverless like lambda or less server like ECS/fargate if that's an option.

  7. Keep multiple accounts for dev/qa/prod. This will greatly help keep your infrastructure and user accounts separate.

  8. Add alarms on everything. Tune them until only the important alerts and thresholds are hit and funnel them via sns into whatever messaging system your team uses

  9. Design for observability, on the flipside cloudwatch costs more than you think. Factor in costs related to logging lots of information and be able to turn on more logging with a switch.

  10. It's worth learning at least one cloud provider well. The underlying architectures and systems can save you from having to build core infrastructure these and can greatly simplify the code you have to write.

Bonus tips

  1. Lots of products are released around aws:re-invent so keep your eyes on if a problem you had is solved by a new product launch or feature

  2. Plan for multi region up front unless you can survive downtime in a region.

  3. Solutions from other providers may still be better for specific cases. Planetscale, temporal, supabase, and upstash may abstract a lot of the complexities of db from your infrastructure.

  4. If you don't have a messaging system it's likely you have points of failure that you need to account for. Even if you have a messaging system you need to account for it's failures and how to reprocess them.