AWS Solution Architect: Real Architecture Lessons Beyond the Certification

What the Certification Gets Right (and Wrong)

Earning the AWS Solution Architect Associate certification gave me a solid map of the AWS ecosystem — EC2, S3, RDS, Lambda, VPC, IAM, CloudFront, Route 53, and dozens of other services. The exam tests whether you can identify the right service for a scenario.

What it doesn't teach you: how to actually make these choices under real constraints — budget, team expertise, time pressure, and the reality that "it depends" is the true answer to most architecture questions.

Here's what I've learned building real systems.

The Serverless vs. Containers Decision

AWS Lambda is genuinely great for:

• ▸Event-driven processing (S3 upload triggers, DynamoDB streams, API Gateway)
• ▸Scheduled jobs that run infrequently
• ▸Workloads with highly variable traffic

Lambda is wrong for:

• ▸Jobs running longer than 15 minutes
• ▸ML inference with large models (cold start + memory limits)
• ▸Anything requiring persistent connections (WebSockets need ALB + ECS)
• ▸Cost at sustained high throughput (EC2 or Fargate is cheaper above ~1M requests/month)

For most backend APIs, I now default to Fargate (serverless containers) over Lambda. It gives you more control over runtime, no cold starts on warm tasks, and the mental model is simpler.

S3 is Not Just Storage

Most developers use S3 as a file store. It's actually the backbone for several patterns:

Static site hosting: S3 + CloudFront + Route 53 is the cheapest and most scalable way to host a static frontend. Costs cents per month at moderate traffic.

Data lake foundation: S3 with proper prefix organization (/year/month/day/ partitioning) integrates directly with Athena for SQL queries over raw files without loading into a database.

Event source: S3 event notifications can trigger Lambda functions, SQS messages, or SNS notifications on object creation/deletion. This is the foundation for ETL pipelines that process uploaded files.

IAM: The Thing That Will Actually Break Your Architecture

The most common cloud security failure is not "someone hacked in" — it's "the developer gave the Lambda function admin permissions because it was easier." IAM is boring and tedious and absolutely critical.

Principles I follow:

1. ▸Least privilege always: every Lambda, ECS task, and EC2 instance gets an IAM role with only the specific permissions it needs
2. ▸No long-lived access keys: use IAM roles and instance profiles, never hardcoded keys
3. ▸Enable CloudTrail: API call logging is free and invaluable for debugging ("why did this fail at 3am?")

Not s3:*. Not *. Specific actions, specific resources.

RDS vs. DynamoDB vs. Aurora Serverless

Use RDS (PostgreSQL) when: you have relational data with complex queries, your team knows SQL, and you need ACID transactions. This is the right default for most applications.

Use DynamoDB when: you need single-digit millisecond reads at any scale, you know your access patterns in advance, and you don't need ad-hoc queries. DynamoDB is excellent but requires upfront schema design that's completely different from relational modeling.

Use Aurora Serverless v2 when: you have an RDS workload but traffic is highly variable and you want to save on idle costs. It scales down to near-zero and back up in seconds.

Cost Control: The Architecture Skill Nobody Talks About

AWS can be devastatingly expensive when you're not careful. Things that surprise people:

• ▸Data transfer out is not free. Egress from EC2/RDS/ELB to the internet costs money. Keep your services in the same AZ when possible.
• ▸NAT Gateway charges per GB transferred. Use it only for services that truly need outbound internet access.
• ▸CloudWatch Logs storage adds up. Set retention policies on every log group.

I set up AWS Budgets with email alerts at 80% and 100% of budget on every account I manage. It takes 5 minutes and has saved me from several "I left a GPU instance running" situations.

The Architecture Philosophy

The best AWS architecture is the one that's simple enough for your team to operate at 2am when something breaks. Always ask: "what happens when this component fails?" If the answer is "we're down," either add redundancy or accept the risk explicitly. Don't assume it won't happen.