I've been using AWS for around two years, mainly focusing on ECS deployments and a bit of Lambda. However, most of my job entails maintaining what was previously built by others. I understand the services individually, but when it comes to designing things from scratch, I find myself struggling.
I'm actively trying to improve by digging through AWS documentation, watching re:Invent videos, and taking structured courses on A Cloud Guru. I also try out small projects to practice my Infrastructure as Code (IaC) skills and use coding assistants like Claude and beyz while writing Terraform or CDK to ensure I'm not missing anything crucial. Recently, I've even started looking into the AWS Well-Architected Framework to understand AWS's approach to such architectural decisions.
My main issue is that while I can follow tutorials without a problem, I feel lost when asked to make architectural trade-offs independently. When someone questions why I chose one service over another, or how I would balance cost, performance, and operational complexity, my responses often lack depth and rely heavily on what I've read rather than my own reasoning. For those who have transitioned from using AWS to designing solutions, how did you cultivate that intuitive understanding of architecture trade-offs? Is practice the key, or is there a better way to learn the rationale behind various architectural decisions?
5 Answers
Experience is everything. Build a solution, run it, and then challenge yourself with questions: 'What if the load increases tenfold?' or 'What happens during a zone failure?'. This hands-on approach is crucial. Remember, though, that relying too much on AI tools for answers can hinder long-term growth. Stick to reading the official docs and experimenting on your own.
It's all about experience! The best way to learn is often through trial and error. Try making the wrong decisions in a safe environment, and you'll learn from those. Finding a job that allows for this hands-on experience is key.
Keep it simple and cost-effective. Your primary goal should be to solve the problem as cleanly as possible. This approach is a major advantage over those who complicate things unnecessarily, leading to expensive architectures.
Yes, experience is invaluable, but logical study helps, too. Have you actually set up projects using ECS and Lambda? Understanding the contexts of when to use one over the other is important. Use AWS's cost calculator to compare services and see how operational costs factor into performance.
Look for architectural patterns. Most problems you face have been tackled by others who usually write about their solutions. It takes time—I've spent years in IT before jumping into architecture. So don't be discouraged; growth in this area won't happen overnight!
Exactly! Following established patterns helps, especially when you're a junior—just stick to what has worked for others.
Absolutely! And as you consider different components in your architecture, always think about the limitations. For example, Lambda has a max runtime of 15 minutes—ask yourself if that matters for your workload. And if you're using EC2, remember that scaling takes time; for crazily fluctuating workloads, scheduling can help.