Cloud Architecture Fundamentals: Thinking Like a Solutions Architect
A practical guide to the mindset behind cloud architecture. Instead of memorizing AWS services, learn how Solutions Architects think: understanding problems, identifying requirements, and choosing the right patterns before selecting any technology or service.
In this article I want to share the way of thinking I've been building while studying for the AWS Solutions Architect Associate exam — not the services themselves, but the questions a Solutions Architect asks before picking any service at all.
Most people start learning AWS by memorizing services: Lambda, S3, EC2, DynamoDB. That's a perfectly fine starting point, but it's not how architecture actually works in practice. An architect doesn't start with "which service should I use?" — they start with "what is the problem I'm actually trying to solve?"
A simple example: imagine you have a system generating a lot of orders, and you need to notify several other systems whenever an order is created. The instinctive answer is often "I'll use SNS, because I already know it." The architect's answer is different: "the real need here is to decouple producers from consumers." SNS might end up being part of the solution, but it's a consequence of understanding the problem — not the starting point.
This article walks through the core questions I believe every cloud architect should be comfortable answering, whatever the company size, industry, or specific AWS service catalog.
How should I structure my system in the first place?
This is usually the first real architectural decision, and it shapes everything that comes after.
Monolith — a single, unified application. It's simple, fast to start, and has low operational complexity. The trade-off shows up over time: as the system grows, coupling increases, deployments get slower and riskier, and scaling the whole application to fix a bottleneck in one part becomes wasteful.
Microservices — the application is broken into independent services, each owned by a different team, scaling and deploying on its own schedule. The only thing holding everything together is a contract between services (an API, an event schema). This unlocks team independence and selective scaling, but it comes at a real cost: more operational complexity, more moving parts to observe, and — because calls now travel over the network instead of in-process — higher latency.
Serverless isn't "no servers" — it just means you stop being responsible for them. You don't provision, patch, or scale the underlying infrastructure; the platform does that for you. This usually shows up as a mix of Lambda, API Gateway, DynamoDB, and Step Functions, paying only for what you actually use.
Three-Tier Architecture — the classic separation of presentation → application → data. On AWS, this commonly maps to something like CloudFront (presentation) → Lambda / ECS / EC2 (application) → RDS / DynamoDB (data). It's not a competing pattern to the ones above — it's more of a structural lens you can apply on top of a monolith, microservices, or a serverless stack.
(A good diagram here: a side-by-side comparison of monolith vs. microservices, showing coupling, deployment speed, and scaling behavior.)
How can different teams work on the same product, on different parts, at the same time?
This is, in my view, one of the most underrated architectural questions — and it's where microservices really earn their complexity.
Once a system is broken into independent services with a clear contract (an API spec, an event schema, a queue format), teams stop needing to coordinate on every change. Team A can deploy three times a day on the orders service while Team B is still in code review for the payments service, and neither blocks the other — as long as the contract between them doesn't break.
This is why API contracts and event schemas become a first-class architectural artifact, not an implementation detail. They're the boundary that lets teams move asynchronously and independently.
The trade-off is real, though: this independence is exactly what introduces the complexity, observability overhead, and latency mentioned above. A useful mental model is: the looser the coupling between teams, the more you need investment in contracts, versioning, and observability to keep things from silently breaking.
If you're modernizing a legacy monolith into this kind of structure gradually, instead of a risky big-bang rewrite, the Strangler Fig Pattern is the usual approach: you route traffic for specific functionality to new services one piece at a time, while the old monolith keeps serving everything else, until it's fully replaced.
How do different parts of the system talk to each other without becoming tightly coupled?
This question leads directly into Event-Driven Architecture, one of the most common patterns you'll find across AWS designs — largely because it makes the system reactive: if there's no event, there's no processing, and often no cost.
It works differently from a simple pipeline (
A → B → C). Instead, it looks more like A → N consumers, where any number of independent systems can react to the same event without A ever knowing they exist.
The services worth understanding here:
- EventBridge — event routing and rules between AWS services and SaaS applications
- SNS — pub/sub messaging, fan-out to multiple subscribers
- SQS — decoupled queues, buffering work between producers and consumers
- Kinesis — real-time streaming data at scale
- MSK (Managed Kafka) — for teams that need Kafka's ecosystem and semantics on AWS
The pattern that matters more than any single service: decoupling producers from consumers, so each side can fail, scale, or evolve independently.
What happens when something fails?
Designing for failure might be the single most important habit a cloud architect can build. The first question to ask about any component isn't "how does this work?" — it's "what happens when this doesn't work?" What if the Lambda function doesn't respond? What if the database becomes unavailable? What if a downstream service is slow instead of down?
A few concepts that should be second nature:
- Retry — automatically attempting a failed operation again, usually with backoff
- Timeout — defining how long you're willing to wait before giving up on a call
- Dead Letter Queue (DLQ) — capturing messages that repeatedly fail processing, so they aren't lost or silently retried forever
- Multi-AZ — replicating infrastructure across Availability Zones so a single zone failure doesn't take the system down
- Health checks — continuously verifying that a component is actually able to do its job, not just that it's "running"
- good path, retry works
None of these are exotic — but designing with them from the start, instead of bolting them on after the first outage, is what separates resilient architectures from fragile ones.
How do I keep the system secure?
Security is broad enough to deserve its own dedicated article later, but at a minimum, every architecture decision should pass through four lenses:
- Identity — who (or what) is making this request?
- Access — what are they allowed to do?
- Data protection — is data protected at rest and in transit?
- Encryption — are secrets and sensitive data actually encrypted, not just "stored somewhere private"?
The services that show up constantly here: IAM for identity and access, KMS for encryption keys, Secrets Manager for credentials and rotation, and WAF / Shield for protecting public-facing endpoints from common web exploits and DDoS.
The mindset that matters more than memorizing services: security by design — asking these questions while drawing the architecture, not after it's already in production.
How much is this actually going to cost?
Let's use the same problem throughout: processing images.
Option 1 — an EC2 instance running 24/7. Cost is driven by uptime, instance family, and size, regardless of whether there's actual work to do.
Option 2 — a Lambda function that only runs when triggered. You pay for execution time, not idle time.
Neither option is "correct" in isolation — it depends on traffic patterns, latency requirements, and predictability. But this is exactly why FinOps matters in cloud architecture: cost isn't a finance afterthought, it's a design constraint that determines whether a project is viable at all.
How do I know what's actually happening in my system?
This is where observability comes in — and it's worth being precise about the difference between observability and monitoring, since they're often used interchangeably but answer different questions.
Monitoring tells you what is happening: CPU is at 60%, RAM is at 90%, error rate just spiked.
Observability helps you understand why it's happening, and what to do about it: is this CPU spike caused by a genuine increase in traffic? Did a recent deployment introduce a regression? Would a bigger instance type fix this, or is auto-scaling the better long-term answer?
On AWS, this typically combines CloudWatch (metrics, logs, alarms) with X-Ray (distributed tracing across services) — especially important once you've adopted microservices and a single user request might touch five or six different services before returning a response.
The skill that matters more than any dashboard: learning to ask the right question about what you're seeing, instead of just reacting to a number crossing a threshold.
How do I know which pattern fits my scenario?
I'll close with a quick decision table — not as a strict rulebook, but as a starting point for the kind of reasoning this article is trying to build:
| Problem | Pattern |
|---|---|
| Many consumers need the same piece of information | Event-Driven Architecture |
| Small, simple system | Monolith |
| Independent teams shipping on their own schedule | Microservices |
| Minimal infrastructure to manage | Serverless |
| High availability requirements | Multi-AZ |
| Modernizing a legacy system | Strangler Fig Pattern |
The goal of this article was to lay out, in the simplest way I could, the questions a cloud architect should have in mind before reaching for any specific service. I intentionally left out a deep dive into VPCs, networking, IAM policy design, and per-service cost mechanics — those deserve their own dedicated article, which I'll be writing next.
# aws-certification# training-and-certification# architecture-patterns# architecture# solutions-architect
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article