The AWS Architect Specialization Path: What I'm Learning, in Order
I'm currently working through the AWS Cloud Solutions Architect Specialization on Coursera, on top of the day job at Telered. People keep asking me what each piece is actually worth — so here are honest, working-engineer notes.
This isn't an "I crushed all the certs in 30 days" post. I have a full-time job, projects, and a mortgage. This is what fits in around that.
The path I'm on
The specialization stacks several courses end-to-end. Roughly in the order I'm taking them:
- AWS Cloud Technical Essentials — the foundation
- Architecting Solutions on AWS — the design patterns
- Migrating to the AWS Cloud — moving existing systems
- Building Data Lakes on AWS — analytics-flavored storage
- AWS Cloud Solutions Architect Specialization — the capstone-shaped piece
In parallel I'm doing Containers & Kubernetes Essentials because the certification track doesn't cover EKS in depth and I needed it for work.
Course-by-course honest read
AWS Cloud Technical Essentials
If you've already used AWS for a year you can skip large chunks. It's the "what is EC2, what is S3, what is IAM" tour.
Worth it for: people transitioning into AWS from another cloud, or from on-prem. The IAM section is genuinely better than most "intro" treatments — they spend real time on the difference between identity-based and resource-based policies.
Skim: the EC2 instance-type catalog. You'll forget it the day after the quiz.
Architecting Solutions on AWS
This one's the most useful if you're already shipping. It walks through reference architectures — load balancers in front of ASGs, S3 + CloudFront patterns, multi-AZ RDS, the basic well-architected stuff.
Worth it for: the discipline of articulating why you'd pick one pattern over another. Most working engineers have intuitions for this; the course makes you defend them.
Watch out for: the case studies skew toward "perfect-world" architectures. Real projects have constraints that make you pick the second-best option for legitimate reasons. Take the patterns, not the certainty.
Migrating to the AWS Cloud
The most directly applicable to my work right now. Lift-and-shift vs. re-platform vs. re-architect; the 6 R's framework; how to inventory a legacy environment before you touch it.
Worth it for: the chapter on assessing on-prem dependencies. There are tools (Migration Hub, Application Discovery Service) I knew existed but hadn't actually used to plan a migration. After this course I have.
The thing I'd add: the course mostly skips the people part of migration. The technical migration of a Laravel app to ECS is a weekend. Convincing the team that owns it that they should let you, navigating a regulator who has opinions about where data lives — that's the actual project.
Building Data Lakes on AWS
Honestly, the least relevant to me right now. We're not in heavy analytics territory at Telered yet. I'm doing it because the specialization expects it and because I want the option of taking on data-flavored work later.
Worth it for: S3 storage class economics. Lake Formation. Glue's role in the pipeline.
Skim: any module that's just "click through this console wizard." Read the IaC equivalent in the docs instead.
Containers & Kubernetes Essentials
Doing this in parallel because EKS is on Telered's near-term roadmap. Coursera's K8s coverage is fine but generic — for production-grade work you'll want the CKA prep material on top of it.
What certifications are actually for
Three things, ranked:
- A reading list. They force me to study material I'd otherwise skim, in a sequence someone smarter than me designed.
- A negotiation lever. "AWS Solutions Architect Professional" is a line on a CV that recruiters filter on. That's the world we're in.
- An actual assessment of skill. Distant third. The exam doesn't measure whether you can ship a system; it measures whether you can pick the right answer on a multiple-choice question. Those are different skills.
I take certs seriously because of #1 and #2. The systems I've shipped in production are the actual work.
The unglamorous truth about pacing
I do roughly 2–4 hours/week on this material — usually weekend mornings before my partner is up. At that pace, a 4-week course takes me about six. The specialization is going to take most of 2026 to finish.
That's fine. Forcing it would mean either burning out or skipping the parts where the material gets harder, which is also where the material gets useful. Engineering is a long game.
What's after
Probably AWS Solutions Architect Professional (the proctored exam, not just a Coursera completion). Then Kubernetes Administrator, since that's the gap between my current toolkit and where I'd like to be in two years.
After that — I'd rather be writing than taking exams. The certs prove I can do the work; the work proves what the certs can't.