I Don’t Want to Learn 200 AWS Services — I Want to Know Which One to Ignore.
Beginners often think becoming good at AWS means learning as many services as possible. But perhaps the more important skill is knowing which service you DON'T need for a particular problem.
When I started exploring AWS, one thing immediately surprised me: the number of services.
EC2. S3. Lambda. RDS. DynamoDB. Bedrock. SageMaker. ECS. EKS. CloudFront. VPC...
At first, I thought becoming good at AWS meant learning all of them.
Then I started asking a different question:
“What if being good at AWS isn't about knowing every service — but knowing which ones you don't need?”
The "more services = more knowledge" trap
Explain that beginners can easily start memorizing service names instead of understanding problems.
For example:
"I need a database → DynamoDB!"But the better question is:What type of data? What access pattern? What scale? What consistency requirements? What budget?### Start with the problem, not the AWS serviceGive 3 examples:Problem: I need to store images
→ Think about object storage → S3 may be relevant.Problem: I need code to run when an event occurs
→ Serverless/Lambda may be relevant.Problem: I want to add generative AI to an application
→ Amazon Bedrock may be worth exploring.AWS itself provides Decision Guides specifically to help users choose services for use cases, which fits this idea nicely### The "Ignore List"This could be the unique part of your article.Say:> Before building an application, I want to create two lists:**What do I need?****What don't I need?Example:Building a tiny student portfolio websiteMaybe you don't need:❌ Kubernetes
❌ Complex microservices
❌ Multiple databases
❌ Complicated AI infrastructureInstead, you might need only a small number of appropriate services.The point isn't that those technologies are bad — they're simply unnecessary for that particular problem.### You can write:> AI has made this problem even more interesting.Today, a beginner can ask an AI assistant:“Design an AWS architecture for my application.”**Within seconds, the AI may produce a diagram containing 10 different services.But here's the question:**Does a bigger architecture mean a better architecture?I don't think so.A beginner should learn to question the architecture instead of blindly accepting it. End with:> I'm starting to think that AWS expertise isn't about collecting services like Pokémon.It's about understanding a problem well enough to say:“I could use this service, but I don't need it.”**Maybe the next AWS skill I need to learn isn't another service.**Maybe it's learning what to leave out.**Then ask:> What's one AWS service you initially thought you needed but later realized you didn't?
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article