If you’re studying for the AWS Certified Solutions Architect (Associate and Professional), you’re not just learning “AWS services.” You’re learning the building blocks of reliable, cost-aware, secure systems—and how AWS expects Solutions Architects to think.
This guide is a deep-dive into the AWS architecture core services you’ll repeatedly see across exam scenarios and real-world customer designs. We’ll cover Compute, Storage, Networking, and the supporting services that tie everything together. Expect architecture patterns, decision trade-offs, and practical examples that align with how AWS Solutions Architect questions are usually written.
And yes—this is also a career ROI guide. Knowing these services quickly can reduce your study time, improve your interview performance, and make your early projects more impressive (and less expensive).
What “Mastery” Means for Solutions Architect Exams
“Mastery” on these exams isn’t memorizing buttons in the console. It’s being able to answer questions like:
- Which service fits the workload and constraints?
- How do you design for security, availability, scalability, and cost?
- What trade-offs are being made (latency, operational burden, durability, elasticity)?
- How do networking and storage choices affect compute and data flows?
A helpful way to frame your preparation: treat each core service as a decision node in your architecture. When you understand those nodes well, the exam’s “story problems” become solvable.
The Exam’s Architecture Mindset: Systems, Not Services
AWS Solutions Architect questions are often written like product requirements:
- “We need variable demand and fast scaling”
- “We need durable storage with lifecycle controls”
- “We need global users with low latency”
- “We need private services with controlled access”
- “We need managed data layers with performance and failover”
Your job is to translate requirements into architecture—usually by combining core services.
You’ll repeatedly connect:
- Compute (EC2, Lambda, containers)
- Storage (S3, EBS, EFS)
- Networking (VPC, routing, DNS, load balancing, CDN)
- Managed services (databases, messaging, caching)
- Operations & governance (IAM, monitoring, backups, compliance)
Compute: EC2, Lambda, Fargate, and the “Right Tool” Mental Model
Compute is where most candidates get tripped up because there are many choices that overlap. The trick is understanding the operational model and scaling behavior.
EC2 (Elastic Compute Cloud): The Core of Many Enterprise Architectures
Amazon EC2 is the default “go-to” compute service in AWS architecture. It provides virtual servers where you control the OS, runtime, patching strategy, and system-level configuration.
You typically choose EC2 when you need:
- Long-running workloads (web servers, APIs, batch processing)
- Custom OS/runtime requirements
- Predictable capacity or control over instance types
- Tight integration with other AWS services using VPC networking
Key concepts to master:
- Instance families and sizing (general-purpose vs compute-optimized vs memory-optimized)
- Auto Scaling Groups for elastic capacity
- EBS for block storage attached to EC2
- Security Groups and NACLs for traffic control
- User data and image management (AMIs) for repeatable provisioning
For exam-style scenarios about scaling or customizing infrastructure, EC2 is often part of the “best fit” option—even when managed services exist.
Internal link (compute patterns):
Designing with EC2, Lambda, and Fargate: Compute Patterns You Need for the AWS Solutions Architect Exams
That article helps you build a pattern-based approach instead of guessing based on surface features.
Lambda: Event-Driven Compute Without Server Management
AWS Lambda is ideal for event-driven or bursty workloads where you want AWS to manage servers automatically.
Lambda is commonly the best choice when you want:
- Automatic scaling from zero to demand
- Pay-per-request pricing (cost-friendly for spiky traffic)
- Event triggers (S3 events, API Gateway, event buses, etc.)
- Simpler operations vs managing EC2 fleets
What you must understand for mastery:
- Invocation model: synchronous vs asynchronous
- Durability of execution context: ephemeral, not a “server”
- Timeout limits and runtime constraints
- Concurrency considerations (including reserved concurrency)
- VPC access if you need private networking (with NAT trade-offs)
In exam questions, Lambda is frequently recommended for “lightweight compute tasks” that are triggered by events.
Expert insight: Many candidates underestimate how networking affects Lambda cost and architecture. Running Lambda inside a VPC often requires NAT for egress, which changes the cost picture and sometimes the best design decision.
AWS Fargate (Containers Without Cluster Management)
AWS Fargate lets you run containers without managing EC2 instances or cluster capacity. It’s a middle ground between “full control” (EC2) and “no server management” (Lambda).
You’ll use Fargate when:
- You have containerized applications
- You want a managed approach without running EC2 instances for container hosts
- You need predictable platform behavior for services like web apps, background workers, and APIs
Important mastery topics:
- ECS vs EKS trade-offs (Fargate commonly pairs with ECS)
- Task definitions and resource limits
- Networking mode (awsvpc)
- Logging strategy and operational visibility
Internal link (compute patterns):
If you want the “how to choose” framework, the same compute patterns article linked above is the perfect companion for Lambda vs Fargate vs EC2 decisions:
Designing with EC2, Lambda, and Fargate: Compute Patterns You Need for the AWS Solutions Architect Exams
Containers vs Serverless vs Servers: A Practical Decision Table
Here’s the decision lens you should internalize for Solutions Architect questions:
| Requirement | Typical Best Fit |
|---|---|
| Need custom OS control, long-running processes | EC2 |
| Event-driven, bursty, minimal ops overhead | Lambda |
| Containerized workloads, managed servers, stable runtime | Fargate |
| Highly orchestrated microservices with Kubernetes | EKS (not always “core” but frequently appears) |
Even when EKS or other services appear, EC2/Lambda/Fargate are the baseline comparison set.
Storage: S3, EBS, EFS, and How Data Shapes Your Architecture
Storage decisions are often “quietly responsible” for performance, cost, and reliability outcomes. On exams, storage isn’t just where data lives—it’s how you meet requirements.
Amazon S3: Object Storage and Data Lifecycle Mastery
S3 is the anchor for object storage in AWS. It’s used for:
- Static website assets
- Data lakes and backups
- Application data (uploads, logs)
- Integration pipelines and event triggers
What to master:
- Storage classes and lifecycle policies
- Standard for frequent access
- Infrequent Access / Glacier tiers for cost-optimized retention
- Durability model (designed for high durability)
- Versioning and object recovery
- Encryption (at rest and in transit)
- Bucket policies and least-privilege access
- Performance expectations and multipart uploads for large objects
Exam scenarios often ask: “We need secure, durable, cost-effective storage with lifecycle controls.” That’s classic S3 territory.
Internal link (storage architectures):
For a deeper comparison you’ll see again and again:
S3, EBS, and EFS Compared: Storage Architectures You’ll See Again and Again on the AWS Solutions Architect Path
EBS: Block Storage for EC2 (Low Latency, Attach-and-Use)
EBS provides block storage volumes that attach to EC2 instances. It’s used when you need:
- File systems for EC2-hosted applications
- Low-latency access to block-level storage
- Consistent performance for databases and operating system disks
Key concepts:
- Volume types (general purpose SSD, provisioned IOPS, throughput optimized, etc.)
- I/O performance tuning
- Snapshots and how they relate to backups and disaster recovery
- Elastic Volumes (scaling volume size)
- Encryption and access control patterns
For exam questions, EBS is typically mentioned when the workload runs on EC2 and requires block storage performance.
EFS: Shared File Storage for Scaling and Multi-Client Access
Amazon EFS provides managed NFS-compatible file storage. You choose EFS when:
- Multiple compute instances need to share the same file system
- You need shared storage for distributed workloads
- You want elastic capacity without manually managing storage servers
Important mastery topics:
- Performance modes (general purpose vs max I/O)
- Throughput modes and how they scale
- Lifecycle policies for cost optimization (transitioning files to storage tiers)
- Mount targets per Availability Zone
- Security integration with VPC and security groups
EFS commonly appears in scenarios involving horizontally scaled application servers that share content or configuration.
Choosing Between S3, EBS, and EFS: The “Access Pattern” Test
A reliable strategy for exam questions:
- If you need object storage → think S3
- If you need block storage attached to a single EC2 → think EBS
- If you need shared file system across multiple instances → think EFS
But real life adds nuance—latency, throughput, and multi-AZ behavior matter.
The storage comparison link above gives you deeper architecture patterns:
S3, EBS, and EFS Compared: Storage Architectures You’ll See Again and Again on the AWS Solutions Architect Path
Networking: VPC, Routing, DNS, and CDN Fundamentals
Networking is where “almost correct” answers fail. Most candidates know networking exists—but not how design choices affect security posture, latency, and cost.
VPC: The Foundation of AWS Network Architecture
A VPC (Virtual Private Cloud) is your isolated network environment. Everything connects back to VPC design: subnets, routing tables, gateways, and security controls.
Core components you should master:
- CIDR blocks and subnetting strategy
- Availability Zones and spreading for resilience
- Public vs private subnets
- Internet Gateway (IGW) for inbound/outbound public connectivity
- NAT Gateway/Instance for private subnet internet access (egress)
- Route tables and how routes govern traffic flow
- VPC endpoints to keep traffic private to AWS services
A lot of exam questions essentially test whether you can place resources in the correct subnet type and pick the correct route strategy.
Security Controls: Security Groups and Network ACLs
You should understand security enforcement layers:
- Security Groups (stateful)
- Applied to ENIs (network interfaces)
- Allow/deny inbound/outbound at the instance level
- State is tracked automatically
- Network ACLs (stateless)
- Applied at subnet level
- Rules are explicit for inbound and outbound
- You must allow both directions
Exam writers love scenarios involving “restricting access” and “allowing only necessary traffic.” Your job is to use the right control with the right scope.
Route 53: DNS for Reliability and Routing Control
Amazon Route 53 is the DNS service you use to map hostnames to endpoints. It’s frequently paired with:
- Load balancers
- CloudFront
- Multi-region routing policies
- Health checks for failover scenarios
What to master:
- Record types (A/AAAA, CNAME, alias records)
- Routing policies (simple, weighted, latency-based, failover, geolocation)
- Health checks and failover routing strategies
In exam scenarios asking for resilient DNS and global traffic routing, Route 53 is almost always relevant.
Internal link (networking fundamentals):
VPC, Route 53, and CloudFront Fundamentals: Networking Concepts That Make or Break Your AWS Architect Designs
This is the networking “glue” article that helps you avoid missing the subtle route/DNS/CDN relationship.
CloudFront: CDN for Global Performance and Reduced Latency
Amazon CloudFront sits at the edge worldwide and caches content closer to users. It’s often recommended for:
- Static and dynamic content delivery
- API acceleration (depending on architecture)
- Reducing origin load on application infrastructure
Key concepts:
- Origin selection (S3, ALB, custom HTTP endpoints)
- Cache behaviors and invalidation strategy
- Geo restrictions (if required)
- HTTPS, certificates, and secure delivery patterns
If your exam scenario includes “global users with low latency,” CloudFront is a strong candidate—especially when combined with S3 and/or ALB.
Load Balancing: Distributing Traffic Reliably
Load balancers are part of network architecture even when they’re classified as “compute-adjacent.” In exam questions, they support:
- High availability across multiple instances
- Health checks and failover behavior
- TLS termination patterns (depending on design)
- Auto Scaling integration
You should know which load balancer fits which requirement:
- ALB for HTTP/HTTPS (common for web apps)
- NLB for high-throughput, low-latency use cases (TCP/UDP)
- Classic load balancers appear less in modern best practices
Subnet Placement and NAT: Where Cost Mistakes Happen
One of the most common AWS learning pitfalls is placing resources in the wrong subnet or forgetting how egress works.
- Private subnets without NAT generally can’t reach the internet.
- NAT Gateway enables outbound internet access for private resources, but it can add cost.
- VPC endpoints can keep traffic private and often reduce costs and security risks.
If you master how traffic flows (and how it’s routed), you’ll outperform many candidates who only know service names.
Managed Databases: RDS, DynamoDB, and Aurora Scenarios
Databases often show up as “core services” because they impact architecture quality, cost, and scalability. Even if your title focuses on compute/storage/networking, a Solutions Architect must understand how data persistence layers affect the system.
Internal link (databases):
For exam-focused scenarios:
Managed Databases on AWS: RDS, DynamoDB, and Aurora Scenarios Every Solutions Architect Candidate Should Know
Below is a practical mastery overview you can use alongside that guide.
RDS: Managed Relational Databases (MySQL, PostgreSQL, Oracle, SQL Server)
Amazon RDS is the managed relational database option. Choose RDS when you need:
- Structured queries and relational integrity
- Familiar SQL workflows
- Managed backups, patching, and scaling options
Mastery topics:
- Multi-AZ deployments for high availability
- Read replicas for scaling reads
- Backup retention, point-in-time recovery
- Performance: indexes, parameter groups, and instance sizing
- Connection management and application-level pooling
In exam scenarios, RDS is often the “best” answer for relational requirements where minimizing ops is key.
DynamoDB: NoSQL Key-Value and Document-Style Data at Scale
Amazon DynamoDB is a managed NoSQL database designed for high throughput and low latency.
Choose DynamoDB when you need:
- Predictable low latency at scale
- Flexible data modeling (partition key / sort key)
- Managed scaling without sharding complexity
- High-availability storage and built-in replication
Mastery topics:
- Partition key design and request distribution
- Capacity models (on-demand vs provisioned with auto-scaling)
- Consistency models (eventual vs strongly consistent reads)
- TTL for record expiration
- Global Tables for multi-region replication
Exams commonly test whether you recognize “access patterns” and model the data accordingly.
Aurora: MySQL/PostgreSQL-Compatible Relational with Performance Focus
Amazon Aurora combines compatibility with additional performance and resiliency features.
You typically choose Aurora when:
- You need MySQL/PostgreSQL compatibility
- You want managed scaling and strong performance
- You’re aiming for enterprise-grade availability and durability
Mastery topics:
- Multi-AZ architecture and failover behavior
- Storage auto-scaling
- Performance considerations and read replicas
- Backup and recovery
If the scenario includes “relational database with high availability and performance,” Aurora is frequently a strong candidate.
The Identity Layer: IAM and Secure Access Patterns (You Can’t Skip This)
Security is not a separate topic. It’s the thread running through every architecture decision.
IAM Basics That Matter for Architects
AWS IAM (Identity and Access Management) controls who can do what.
Mastery requires you to know:
- Identity types: users, groups, roles
- Policy types: identity-based vs resource-based
- Least privilege principles
- When to use roles (especially for services and cross-account access)
- Trust relationships in role assumption
- Use of conditions (IP, MFA, tags)
Exam scenarios often include “least privilege” or “secure access.” Incorrect answers typically involve overly broad permissions or wrong identity boundaries.
Practical architecture security pattern: least privilege + scoped networking
In a strong design:
- IAM limits actions to what’s required
- Network controls limit where traffic comes from
- Encryption ensures confidentiality at rest and in transit
- Monitoring alerts on unusual behavior
If you can explain security like that, you’re aligning with how AWS expects Solutions Architects to reason.
Integration and Messaging: SQS, SNS, and Event-Driven Systems
Even though compute/storage/networking dominate your study list, integration services are where real architectures become robust.
SQS: Reliable Message Queues for Decoupling
Amazon SQS decouples producers and consumers. Use it for:
- Buffering traffic during spikes
- Reliable processing with retry behavior
- Work distribution across consumers
Mastery topics:
- Visibility timeout and retry behavior
- Dead-letter queues (DLQs)
- Standard vs FIFO queues
- Cost implications and throughput patterns
SNS: Pub/Sub Notifications
Amazon SNS broadcasts messages to multiple subscribers.
Use it when:
- You want fan-out to multiple endpoints
- You need topic-based messaging patterns
EventBridge: Event Routing and Automation
EventBridge supports event-driven architectures across AWS services and custom apps.
You’ll commonly see it in patterns like:
- Event ingestion → routing rules → targeted processing
- Integrating SaaS events and AWS events
- Lightweight orchestration without heavy coupling
Mastery insight: many exam questions reward candidates who can identify where decoupling improves reliability and reduces operational load.
Observability: CloudWatch for Monitoring, Logging, and Alarms
If you’re studying for Solutions Architect, you don’t need every CloudWatch feature—but you must understand the architecture purpose.
CloudWatch Metrics, Logs, and Alarms
Mastery topics:
- Metrics for performance and health visibility
- Logs for troubleshooting and auditability
- Alarms for proactive detection
- Dashboards for operational clarity
A good design often includes monitoring for:
- Error rates and latency
- CPU/memory saturation
- Application-level health checks
- Database performance indicators
Cost Awareness: Designing for the Budget Without Breaking Reliability
This is a “budgetcourses.net” friendly truth: cost management isn’t optional. In AWS, design choices can swing monthly bills dramatically.
Practical cost levers Solutions Architects actually use
- Right-size compute (instance types, autoscaling thresholds)
- Prefer serverless where workload patterns match (Lambda)
- Use storage lifecycle policies to reduce long-term costs
- Avoid unnecessary internet egress and NAT usage
- Use caching/CDN (CloudFront) for reduced origin load
- Choose DynamoDB capacity wisely and design partition keys to avoid hot partitions
- Use reserved instances/savings plans when you have steady workloads (learn the trade-offs)
A realistic exam scenario cost lesson
Many candidates pick “the most scalable” service without considering cost. In real customer conversations, the best answer balances requirements and constraints. Your exam choices should reflect that trade-off.
Reference Architectures You Should Be Able to Explain
Let’s turn the core services into repeatable architectures. These are the kinds of patterns exam questions often hint at.
Architecture 1: Web App with Auto Scaling, S3, and CloudFront
Goal: Global low-latency delivery, resilient backend, efficient static asset storage.
Common components:
- CloudFront for cached content
- S3 for static assets (and possibly log storage)
- ALB in public subnets
- Auto Scaling EC2 instances in private subnets
- EBS for instance block storage needs
What to mention in an exam answer:
- Private subnet protection with security groups
- Scaling via Auto Scaling Group
- S3 lifecycle policies for cost management
- CloudFront caching strategy and secure delivery
If this sounds like a lot, don’t worry—this is exactly why the core services approach works.
Internal link (networking fundamentals):
VPC, Route 53, and CloudFront Fundamentals: Networking Concepts That Make or Break Your AWS Architect Designs
Architecture 2: Event-Driven Processing with Lambda + S3 + SQS
Goal: Process uploaded files or events reliably, with decoupling.
Common components:
- S3 bucket receives uploads
- S3 events trigger Lambda
- Lambda publishes tasks to SQS
- Worker consumers process messages
- DLQs for failure handling
- Logs/metrics in CloudWatch
What exam questions like here:
- Reliability under spikes
- Retry behavior and failure isolation
- Minimal coupling between components
This architecture is a great example of “compute + storage + integration” in one clean design.
Architecture 3: Shared File System for Scale-Out Compute with EFS
Goal: Multiple compute nodes need shared data access.
Common components:
- EC2 instances in multiple AZs
- EFS mounted on instances
- Security groups and mount target configuration
- Optional lifecycle policies depending on usage patterns
Exam answers should include:
- Multi-AZ mount targets
- Security and network placement
- Performance mode selection based on usage intensity
Architecture 4: Multi-Region Resilience for Data and Traffic
Goal: Failover and reduced latency for global users.
Common components:
- Route 53 routing policies and health checks
- CloudFront for edge delivery
- Database replication (Aurora Global Database, DynamoDB Global Tables—depending on engine)
- Subnet and routing design to support resilience
This architecture tests whether you understand the “control plane” aspects like DNS routing and health.
Study Strategy: How to Learn These Services Faster (and Remember Them Longer)
If you’re trying to optimize cost and time, your study plan matters as much as your content.
Use a “service template” approach
For each core service you study (EC2, S3, VPC, etc.), fill in:
- What it is (core capability)
- Where it fits in an architecture
- When it’s the best choice
- Common pitfalls and limitations
- Security and networking considerations
- Cost considerations
When you do this repeatedly, your brain starts to map requirements → services naturally.
Train with scenario questions (not flashcards only)
Flashcards help memorize terms. Scenarios help you win the exam.
For each scenario, ask:
- What is the workload pattern? (steady, spiky, event-driven)
- What is the data access pattern? (object vs block vs shared file)
- What is the connectivity requirement? (public/private, low latency, global users)
- What is the availability requirement? (single AZ vs multi-AZ vs multi-region)
- What is the operational constraint? (minimal ops, compliance, patching)
Deep-Dive Pitfalls: The Mistakes Candidates Make Most Often
Let’s make you safer by preempting common “wrong answer” patterns.
Pitfall 1: Confusing S3 and EBS in architecture diagrams
A frequent mistake: treating S3 like block storage or assuming EBS can act like shared object storage.
- S3 is objects with APIs and lifecycle management
- EBS is block volumes attached to EC2
- EFS is shared file storage for NFS-style access
The correct choice depends on the access and performance requirements.
Pitfall 2: Ignoring subnet placement and egress behavior
Private resources that need internet access will require:
- NAT Gateway/Instance, or
- VPC endpoints (often preferred), or
- Another architecture path
If you forget this, your design becomes impossible or expensive.
Pitfall 3: Over-privileging IAM roles
Exams often reward least privilege.
If the question says “only allow access to X bucket,” but your answer grants access to all buckets, it’s typically wrong.
Pitfall 4: Picking compute based on familiarity rather than workload shape
Lambda and Fargate are not just “newer compute.” They have specific models:
- Lambda excels at event-driven scaling
- Fargate excels at running containers without server management
EC2 excels when you need full system control and long-running processes.
Putting It All Together: A Mastery Checklist for Solutions Architect Candidates
If you can confidently discuss the items below, you’re in great shape for both Associate and Professional readiness.
Compute mastery checklist
- EC2: instance selection, Auto Scaling, AMIs, security integration
- Lambda: event model, timeouts, concurrency, VPC access trade-offs
- Fargate: container tasks, networking modes, ECS integration
- Choose the compute service based on workload pattern and operational constraints
Storage mastery checklist
- S3: storage classes, lifecycle, versioning, encryption, access policies
- EBS: volume types, performance, snapshots, encryption
- EFS: NFS use cases, mount targets, performance/throughput modes
- Choose storage based on access pattern: objects vs blocks vs shared files
Networking mastery checklist
- VPC: subnets, routing tables, IGW/NAT, multi-AZ strategy
- Security groups vs NACLs
- Route 53: routing policies and failover concepts
- CloudFront: caching, edge delivery, HTTPS and origin considerations
- Understand how networking affects cost and feasibility
Supporting services mastery checklist
- IAM least privilege and role-based access patterns
- CloudWatch metrics/logs/alarms for operational readiness
- SQS/SNS/EventBridge for decoupled event-driven architectures
- RDS/DynamoDB/Aurora for database selection by workload needs
Recommended Next Reads (From the Same Study Cluster)
To reinforce the concepts above with exam-aligned patterns and comparisons, use these internal resources:
- Designing with EC2, Lambda, and Fargate: Compute Patterns You Need for the AWS Solutions Architect Exams
- S3, EBS, and EFS Compared: Storage Architectures You’ll See Again and Again on the AWS Solutions Architect Path
- VPC, Route 53, and CloudFront Fundamentals: Networking Concepts That Make or Break Your AWS Architect Designs
- Managed Databases on AWS: RDS, DynamoDB, and Aurora Scenarios Every Solutions Architect Candidate Should Know
These will help you sharpen decision-making—the exact skill that drives exam performance and real-world architecture success.
Final Take: Your Career ROI Comes from Architecture Thinking
The best Solutions Architects don’t just know which services exist. They can explain why a design works, why it’s secure, why it scales, and why it’s cost-aware.
When you truly master AWS core services—Compute, Storage, and Networking, plus the database and observability layer—you stop “guessing” answers. You start reasoning your way to the best architecture.
If you want a fast, practical path: study service fundamentals, then immediately translate them into architecture patterns. That loop is what makes your AWS Certified Solutions Architect goals feel achievable.
Now go build something (even a small demo project). The moment you draw a VPC with the correct subnets and routes, choose the right storage class for the use case, and pick compute based on workload shape—you’ll feel the exam shift from memorization to confident decision-making.
