AWS Decision Hub
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
Interactive trees
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.
Lambda, ECS Fargate, EKS, EC2, App Runner, Beanstalk, or Lightsail? Answer 4 questions and get an opinionated recommendation with the comparison guide that goes deeper.
Start the decision treePick the right AWS database in 60 seconds — relational, NoSQL, document, ledger, vector, or in-memory. Answer 4 questions to get an opinionated recommendation with links to comparisons and service pages.
Start the decision tree Need a tree we haven't built? Tell us what AWS decision is blocking you — we add the most-requested ones first.Decision framework
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
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.
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.
Cold-start figures assume a typical Node.js / Python Lambda. Container services have no cold start once the task is warm.
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.
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.
EBS Multi-Attach is supported on io1 / io2 only; treat it as a niche pattern rather than a default.
Real-world stacks
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.
Pre-product-market-fit, small team, speed beats cost optimization
Steady production traffic, tens of millions of requests / month, growing team
HIPAA, PCI, SOC 2 or FedRAMP scope; multi-account; central security team
Cost vs performance
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.
Above ~1M requests/day per service, Fargate is typically cheaper than Lambda. Below that, Lambda wins on idle time.
Single-AZ saves money until your first AZ outage. Default to multi-AZ for any production datastore — the math works out over 12 months.
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.
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.
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
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.
We use cookies and similar technologies to analyze site traffic, personalize content, and provide social media features. By clicking "Accept," you consent to our use of cookies. You can adjust your preferences at any time.