Skip to main content

AWS Decision Hub

Pick the Right AWS Service — Without the Spec-Sheet Tab Hell

Interactive decision trees, side-by-side comparison tables, and use-case stacks for the most common AWS choices. Opinionated, current with 2025+ services, and reviewed by AWS-Pro-certified architects.

What's in the hub

8
Service categories
29
Comparison guides
18
Free calculators
AWS Pro
Reviewed by certified architects

Interactive trees

Pick a decision tree

Each tree is a 60-second flowchart that turns 'which service should I use?' into a defensible default — with links to the comparison guides and services that go deeper.

Decision framework

How to choose the right AWS service

Four steps that work for almost every AWS choice — from picking compute for a new API to choosing the right database for a regulated workload.

Define the workload shape

Web app, async job, batch, container, or static site? The shape eliminates 70% of the AWS catalog before you compare a single price sheet.

Identify the hard constraints

Latency budget, compliance scope (HIPAA, PCI, FedRAMP), data residency, and existing team skill — these become non-negotiable filters.

Pick the AWS-native default

For most workloads, AWS has a single recommended path: Lambda for spiky APIs, Fargate for steady services, Aurora for relational, DynamoDB for high-scale key/value. Start there; deviate only with reason.

Validate against Well-Architected

Run the AWS Well-Architected Tool against your design before production. The five pillars (operational excellence, security, reliability, performance, cost) catch issues a comparison table cannot.

Quick reference

Service comparison tables

The most-asked AWS comparisons in one place. Each row links to the deep-dive guide; the highlighted row is the AWS-native default for that category.

Compute — Lambda vs ECS Fargate vs EKS vs EC2

The four real choices for running code on AWS in 2026. Pick by traffic shape and orchestration need first; cost falls out of those answers.

Default for new APIs and event-driven work
Best for
Spiky / event-driven APIs and workers
Max runtime
15 min
Scaling
Per-request, automatic
Cold start
~10–500 ms (SnapStart drops to single-digit ms)
Cost shape
Pay per invocation + GB-s
Best for
Steady production HTTP services and long jobs
Max runtime
Unlimited
Scaling
Task-level autoscaling
Cold start
None (warm)
Cost shape
Per-task vCPU + memory per second
Best for
Workloads that genuinely need the Kubernetes ecosystem
Max runtime
Unlimited
Scaling
Karpenter / HPA / cluster autoscaler
Cold start
None (warm)
Cost shape
Cluster fee + node compute (Auto Mode simplifies)
Best for
Custom AMIs, GPU, reserved-instance economics, legacy lift-and-shift
Max runtime
Unlimited
Scaling
Manual / ASG
Cold start
Boot time (1–3 min)
Cost shape
On-demand / RI / Savings Plans / Spot

Cold-start figures assume a typical Node.js / Python Lambda. Container services have no cold start once the task is warm.

Database — DynamoDB vs Aurora vs RDS vs DocumentDB

DynamoDB and Aurora cover ~90% of new workloads. RDS is the lift-and-shift answer for existing engines; DocumentDB is mainly an Atlas-migration target.

Default for greenfield serverless workloads
Best for
High-scale key/value, serverless apps, single-digit ms reads
Data model
Key/value + document
Scale ceiling
Effectively unlimited (partitioned)
Multi-region
Global Tables (active-active)
Latency
< 10 ms p99 (typical)
Best for
Relational workloads needing high throughput and multi-AZ HA
Data model
Relational (Postgres / MySQL compatible)
Scale ceiling
128 TiB; Aurora DSQL for active-active globally
Multi-region
Global Database / Aurora DSQL
Latency
~5 ms read replica lag
Best for
Lift-and-shift Postgres / MySQL / SQL Server / Oracle
Data model
Relational (engine of choice)
Scale ceiling
Engine-dependent (~64 TiB)
Multi-region
Read replicas; manual cross-region
Latency
Engine-dependent
Best for
MongoDB API workloads migrating from Atlas
Data model
Document (MongoDB-compatible API)
Scale ceiling
Cluster + read replicas
Multi-region
Global Cluster (read replication)
Latency
Single-digit ms (region-local)

Storage — S3 vs EFS vs EBS vs FSx

Pick by access pattern. S3 for objects, EFS for shared POSIX, EBS for single-instance block, FSx for managed file systems with engine-specific features.

Amazon S3 Default
Default for non-block, non-POSIX workloads
Best for
Object storage — backups, data lake, static assets, logs
Access pattern
HTTP API (PUT / GET object)
Throughput
Effectively unlimited; multipart uploads
Attach model
API only (no mount)
Durability
11 nines across 3+ AZs
Amazon EFS
Best for
Shared POSIX filesystem across many hosts
Access pattern
NFSv4 mount
Throughput
Elastic or Provisioned mode
Attach model
Multi-attach across AZs (regional)
Durability
Multi-AZ
Amazon EBS
Best for
Block storage attached to a single EC2 instance
Access pattern
Block device (single-attach default)
Throughput
Up to 256k IOPS (io2 Block Express)
Attach model
Single instance (Multi-Attach for io1 / io2)
Durability
Single-AZ (snapshot to S3 for backup)
Amazon FSx
Best for
Managed Windows / NetApp ONTAP / Lustre / OpenZFS
Access pattern
SMB / NFS / Lustre (engine-specific)
Throughput
Engine- and tier-dependent
Attach model
Multi-AZ (engine-dependent)
Durability
Engine-dependent

EBS Multi-Attach is supported on io1 / io2 only; treat it as a niche pattern rather than a default.

Real-world stacks

Use-case based recommendations

The AWS-native defaults we'd pick for each maturity stage — the stack we'd build on day one if we were standing in your shoes.

Startup MVP

Pre-product-market-fit, small team, speed beats cost optimization

Compute
Lambda + API Gateway, or AWS Amplify Hosting for the front end
Database
DynamoDB (single-table) — or Aurora Serverless v2 if you need SQL
Auth
Amazon Cognito User Pools
Observability
CloudWatch Logs + Application Signals (free tier covers most usage)

Scaling SaaS

Steady production traffic, tens of millions of requests / month, growing team

Compute
ECS Fargate for steady services + Lambda for async / event work
Database
Aurora (Postgres) primary; DynamoDB for hot key/value paths
Caching
ElastiCache for Valkey / Redis 8.x
Observability
CloudWatch + X-Ray, or Datadog / Honeycomb if budget allows

Enterprise / regulated

HIPAA, PCI, SOC 2 or FedRAMP scope; multi-account; central security team

Compute
EKS (Auto Mode) for shared platform + ECS Fargate for service teams
Database
Aurora with KMS CMK and multi-AZ; DynamoDB Global Tables for active-active
Security
AWS Organizations + Control Tower + Security Hub + GuardDuty
Networking
Transit Gateway + Network Firewall; private VPC endpoints for S3 / DDB

Cost vs performance

Tradeoffs we see on every architecture review

Four cost-vs-performance principles that change which AWS service wins. None of these show up in a spec sheet — they show up in your bill.

Steady traffic favors containers; spiky traffic favors serverless.

Above ~1M requests/day per service, Fargate is typically cheaper than Lambda. Below that, Lambda wins on idle time.

Multi-AZ is rarely optional.

Single-AZ saves money until your first AZ outage. Default to multi-AZ for any production datastore — the math works out over 12 months.

Egress cost beats compute cost on chatty services.

Cross-AZ and internet egress dominate the bill on talkative microservices. Use VPC endpoints for S3 / DDB and co-locate chatty workloads when latency budget allows.

Reserved Instances and Savings Plans need a 30-day baseline.

Buying RIs before a workload stabilizes locks you into capacity you do not need. Use the AWS RI Calculator after the workload runs unmodified for a month.

Common decision mistakes

  • Defaulting to EKS without ecosystem need

    ECS Fargate gives you 90% of the benefit with 30% of the operational overhead. Pick EKS only when Helm, operators, CRDs, or multi-tenancy are real requirements.

  • Picking RDS for serverless / spiky workloads

    A provisioned RDS instance is idle compute money. Use Aurora Serverless v2 (auto-scales to zero in v2.4+) or DynamoDB on-demand for variable load.

  • Buying RIs / Savings Plans before baseline

    Wait at least 30 days of unmodified traffic. Then run the AWS Reserved Instance Calculator. Locking in early is the most common cost mistake we see.

  • Ignoring egress in multi-AZ designs

    Cross-AZ traffic between EC2 and RDS, or microservice-to-microservice chatter, can dwarf compute spend. Co-locate hot paths and use VPC endpoints.

Run a workload-specific number with the AWS Cost Savings Calculator and the Reserved Instance Calculator before committing.

Hub FAQ

AWS service selection — quick answers

How do I choose the right AWS service?
Start with workload shape (web app, async job, batch, container, static site). Apply hard constraints (latency, compliance, team skill). Then pick the AWS-native default for that shape — Lambda for spiky APIs, Fargate for steady services, Aurora for relational, DynamoDB for high-scale key/value. Deviate only when you have a specific reason. The interactive decision trees on this page walk that exact flow.
EC2 vs Lambda vs Fargate — which is cheapest?
Lambda is cheapest when traffic is spiky and idle 50%+ of the time. Fargate becomes cheaper above roughly 1M requests/day per service for steady traffic. EC2 with Reserved Instances or Savings Plans is cheapest for predictable, sustained workloads where you can amortize 1–3 year commits. Use the AWS Lambda vs Container Cost Calculator for a workload-specific number.
When should I use DynamoDB instead of RDS or Aurora?
Use DynamoDB when you need single-digit-millisecond reads at any scale, your access patterns are well-defined and key-based, and you want zero database operations. Use RDS or Aurora when you need ad-hoc SQL, joins across tables, or are migrating an existing relational workload. The DynamoDB vs RDS comparison goes deeper on this trade-off.
What is the most common AWS architecture mistake?
Choosing EKS without genuinely needing the Kubernetes ecosystem. ECS Fargate gives you 90% of the benefit with 30% of the operational overhead. Pick EKS only when you actually need Helm, operators, CRDs, or multi-tenancy patterns. The compute decision tree captures this branch explicitly.
Are these decision trees current with 2025+ AWS releases?
Yes. The trees account for EKS Auto Mode (GA December 2024), Lambda SnapStart for Python and .NET, Aurora DSQL for global active-active SQL, and the current Fargate / Graviton pricing model. They are reviewed by AWS-Pro-certified architects on each major AWS release.
Do I need a Well-Architected review before going to production?
For anything customer-facing or revenue-generating, yes. The AWS Well-Architected Tool catches reliability, security, and cost issues no decision tree or comparison table will surface. FactualMinds runs Well-Architected reviews as a fixed-scope engagement — useful before launch and after every major architecture change.

Need a Second Opinion on Your Architecture?

Our AWS-certified architects review designs every week. Tell us your workload and we'll book a free 30-minute architecture review — no pitch deck, just an opinionated read on your design.