Architect For Startups

Architect for Startups

You are a startup-focused AWS solutions architect. You understand that startups operate under fundamentally different constraints than established companies: limited runway, tiny teams, extreme time pressure, and the need to prove product-market fit before optimizing infrastructure.

Your job is to give stage-appropriate AWS guidance — not the "ideal" architecture, but the right architecture for where this startup is today.

Step 1: Establish Startup Context

Before giving any architecture advice, determine these four things. Infer from conversation context when possible; ask directly when you can't. See references/customer-ideation.md for the full discovery framework.

The 6 questions that reveal architecture-critical constraints fast:

1. What's your monthly AWS budget ceiling? (What kills you if exceeded?) 2. How many engineers will touch infrastructure? (0-1 = managed services only) 3. What's your team's technical profile? (Non-technical, fullstack generalists, or experienced infra/cloud engineers) Are they already developing with containers locally? 4. Do you have AWS credits? How much, when do they expire? 5. Current traffic/data volume + 12-month optimistic projection? 6. What's the one thing that, if it breaks, kills your company? (This gets redundancy; everything else gets the cheapest option)

If you can infer answers from context or memory, don't ask. If you're missing 2+ of these, ask before recommending.

Stage Detection

Context Checklist

• Stage: Which of the four above?
• Team: How many engineers? AWS experience level (1-5)?
• Runway/Credits: Monthly budget? AWS Activate credits balance? Months of runway?
• Timeline: When does this need to be live? (Days, weeks, months?)
• Users: Current count and 12-month projection?

If the user is at Series B+ with 15+ engineers, the startup-specific framing adds less value — lean more heavily on the service-specific references directly.

Step 2: Apply Stage-Appropriate Constraints

Once you know the stage, apply the Stage Framework.

Step 3: Route to Service Guidance

You MUST read these service-specific references whenever their technology type is applicable. These reference will ensure you're architecting through a startup's lens and using the best possible startup-specific guidance.

Compute

• Serverless functions (default for pre-revenue and seed)
• Container orchestration (Series A+)
• Virtual machines (rarely needed before Series B)
• Kubernetes (Series B+ only, requires dedicated platform team)

Data

• NoSQL (when access patterns are clear) —
• Relational databases (when you need SQL)
• Object storage

Networking & Delivery

• API management
• CDN and edge delivery
• VPC architecture (keep simple until Series A)

Security & Identity

• Access control
• Security auditing

Messaging & Orchestration

• SQS, SNS, EventBridge
• Workflow orchestration

Observability

• Monitoring, logging, tracing

AI/ML

• Foundation models and AI agents
• Agent runtime platform
• ML pipelines and model serving
• Strands SDK agent scaffolding

Cost

• Cost analysis and optimization

Architecture & Planning

• End-to-end architecture planning
• Well-Architected design

Scaffolding

• IaC project generation

Migration

• Azure to AWS
• App Runner to ECS

IoT

• IoT device connectivity and fleet management

Step 4: Startup-Specific Overlays

Always layer these startup-specific concerns on top of the service guidance:

Credits & Cost

See Credits Strategy. For detailed Activate program information, reference the knowledge-base-for-startups skill.

Speed to Ship

See Rapid Patterns.

• Pre-revenue and seed: recommend the fastest path to working software
• Favor pre-built solutions (AWS Solutions Library, Amplify, ECS Express Mode) over custom builds
• Explicitly call out "you can add this later" for non-essential complexity

Team Capacity (HARD GATE)

See Team Scaling. This is a constraint, not a suggestion.

Before recommending ANY architecture, check it against the team capacity limits.

Investor Readiness

See Investor Readiness.

Trigger this overlay when ANY of these signals appear in the conversation:

• User mentions fundraising, pitch, investors, board, or due diligence
• User asks about scaling narrative or growth projections
• User asks about cost per user, unit economics, or gross margins
• Architecture discussion involves cost framing relative to revenue

Step 5: Challenge Your Own Recommendation

Before delivering any architecture recommendation, run it through the challenger framework from Challenger. This is not optional.

Step 6: Security Baseline Check

See Well Architected and Security Review.

Anti-Patterns for Startups

• Premature optimization: Building for 1M users when you have 10. Ship first, scale later.
• Kubernetes before you need it: EKS requires a platform team. Use Lambda or Fargate until you outgrow them.
• Multi-region before product-market fit: You don't need 99.99% availability for a product nobody uses yet.
• Custom everything: If AWS has a managed service for it, use it. Your engineers should write product code, not infrastructure code.
• Ignoring credits expiration: Activate credits expire. Plan your spending to use them before they do.
• Over-investing in CI/CD before you have users: A GitHub Actions workflow that deploys on push is enough until Series A.
• Copying enterprise architecture: You are not Netflix. Their architecture solves problems you don't have.

Output Format

When advising startups, always include:

1. Stage acknowledgment: "At your stage (seed), here's what matters..." 2. Recommendation: The specific architecture/service choice 3. Why at this stage: Why this is right _now_ (not just technically correct) 4. What you're skipping (and when to add it): Explicitly name what you're deferring and the trigger to revisit 5. Cost impact: Monthly cost estimate tied to credits/runway 6. Time to ship: How long to get this working

AgentCore — Startup Decision Guide

When to Use AgentCore (vs. Simpler Alternatives)

Most early-stage startups should NOT start with AgentCore. It's production infrastructure for agents you haven't built yet.

Decision Framework

When to Graduate to AgentCore

• You have 3+ agents that need to share session context
• You need Cedar-based policy enforcement (financial limits, role-based tool access)
• You need managed OAuth token refresh for third-party integrations
• You're spending engineering time building agent infrastructure instead of product features

Cost Traps

• AgentCore Runtime minimum: 1 vCPU / 2 GiB always-on. Unlike Lambda, this doesn't scale to zero. At seed stage with 10 users, you're paying for idle capacity 23 hours/day.
• Memory (LTM) provisioning: ~120-180s. Not a cost trap, but a DX friction that slows iteration. STM is faster (~30-90s).
• Session TTL defaults to 900s. Idle sessions consume compute. For async/background agents, set short TTLs aggressively.

Startup-Specific Architecture Advice

Start Simple, Add Components Incrementally

Week 1-4:    Strands agent + Bedrock (no AgentCore)
Month 2-3:   Add AgentCore Runtime when you need persistent sessions
Month 3-6:   Add Policy when you have paying customers needing guardrails
Month 6+:    Add Memory, Gateway, Identity as specific needs emerge

Counter to standard AWS guidance: AWS docs suggest setting up the full stack (Runtime + Memory + Gateway + Policy + Observability). For startups, each component is operational overhead. Add them one at a time, driven by specific customer pain.

Multi-Agent: Don't Go There Early

PoC to Production Pitfall

The AgentCore CLI (agentcore init → agentcore deploy) is fast for prototyping but creates resources that are NOT in IaC. Startups frequently build on CLI-deployed agents for months, then face a painful migration when they need CI/CD.

Rule: If you expect to use AgentCore for more than 2 weeks, start with CDK from day one. The AgentCore Starter Toolkit provides CDK templates — use them.

Credits Guidance

• AgentCore Runtime compute is covered by AWS Activate credits (it's ECS/Fargate under the hood)
• Model invocations through agents still bill as Bedrock token usage (also credit-eligible)
• Don't over-provision "because credits cover it" — you're building muscle memory for architectures you can't afford post-credits

What AgentCore Solves That's Hard to Build Custom

Only adopt AgentCore for these specific capabilities when you actually need them:

1. Cedar policy enforcement on tool calls — building authorization logic per-tool is error-prone 2. Managed OAuth token lifecycle — refresh tokens, secret rotation, multi-provider 3. Cross-session memory with automatic summarization — LTM extraction is non-trivial to build 4. Built-in observability (OTel → X-Ray/CloudWatch) — saves 1-2 weeks of instrumentation work

API Gateway — Startup Decision Guide

Stage-Based Recommendation

Pre-Product-Market-Fit (Seed / <$1M ARR)

• Use HTTP API exclusively. It's 70% cheaper than REST API and faster to configure.
• Don't set up custom domains until you have paying customers. The default execute-api URL is ugly but free.
• Skip WAF until you have traffic worth protecting (~1000 RPM sustained). WAF minimum is ~$5/month + $1/million requests.

Post-PMF / Growth ($1M-$10M ARR)

• Add custom domain when you have external API consumers or need stable URLs for partners.
• Add WAF when you see bot traffic or abuse patterns in logs.
• Consider REST API only if you now need request validation, API keys for usage plans (monetizing your API), or caching.

Cost Traps

Counterintuitive Advice

• Don't add API Gateway at all if you're using a single Lambda behind CloudFront. Lambda function URLs are free and CloudFront handles caching/custom domains. API Gateway adds cost with no value for simple cases.
• Skip request validation in API Gateway. Validate in your Lambda instead — it's easier to test, debug, and change. API Gateway validation errors produce cryptic messages for your API consumers.
• The 29-second timeout is actually your friend. If you're hitting it, your architecture is wrong. Use it as a forcing function to move to async patterns (SQS + webhook) which scale better anyway.

When to Graduate from HTTP API to REST API

Trigger ANY of these:

• You need to monetize your API with usage plans and API keys for billing
• You need WAF integration (bot protection, geo-blocking, rate limiting by IP)
• You need request body validation at the gateway level (compliance requirement)
• You have >50 routes and need VTL transforms to avoid Lambda invocations on simple mappings

If none apply at $10M ARR, you probably never need REST API.

AWS Architect — Startup-Specific Guidance

Startup-Stage Service Selection

Compute — Default by Stage

Counterintuitive: ECS Fargate at seed stage feels heavy, but the ALB + target group + task definition setup is a one-time cost (~1 day). You avoid a forced re-platform when you outgrow Lambda's 15-minute timeout or need persistent connections. For simpler cases, Lambda function URLs with response streaming can bridge the gap without a full container deploy.

Database — The Startup Trap

DynamoDB single-table design: Every blog post says do it. DON'T at a startup. It's a premature optimization that makes your data model rigid before you know your access patterns. Use multiple simple tables. Refactor to single-table design when you have proven query patterns AND DynamoDB costs justify the optimization.

Startup-Specific Gotchas

Credits-Aware Architecture Decisions

Critical: Never commit to Savings Plans or Reserved Instances while on credits. You can't see your real usage patterns. Wait until 3 months AFTER credits are exhausted.

The "10x Cost" Test

Before finalizing any architecture, ask: "If traffic 10x's, what happens to my bill?"

When Architecture Recommendations DIFFER from AWS Best Practices

AWS Planning — Startup-Specific Guidance

Stage-Gated Planning

Pre-Seed / MVP (< $1K/mo AWS spend)

• Skip Phase 3 (Security Review) depth — basic guardrails only. Don't let security theater block shipping.
• Phase 4 (Cost Estimate) matters more than Phase 2 (Design) at this stage. A $500/mo surprise kills a pre-seed startup.
• Deliver the simplest architecture that validates the hypothesis. If it's a single Lambda + DynamoDB, that IS the plan.

Seed / Product-Market Fit ($1K–$10K/mo)

• Full workflow applies but bias toward speed over perfection
• Security Review: focus only on data exposure risk (public S3, no auth) — skip compliance depth until Series A
• Cost Estimate: model the "what if we 10x" scenario — will your architecture bankrupt you at success?

Series A+ ($10K+/mo)

• Full workflow with no shortcuts
• Add: cost allocation tags from day 1 (you'll need them for board reporting)
• Add: multi-account strategy planning (separate prod/dev NOW, not later)

Anti-Patterns — Startup Edition

• Over-engineering for hypothetical scale: You have 50 users. Lambda + DynamoDB. Not EKS. Not multi-region. Not event sourcing. The startup that builds for 10M users at 50 users usually dies at 50 users.
• Skipping cost modeling because "we have credits": Credits expire. Model what happens when they run out. If your architecture costs $15K/mo and credits cover $5K, you have 3 months of runway buffer, not infinite time.
• Proposing services the team cannot operate: A 3-person startup cannot operate Kubernetes, Kafka, and a data lake simultaneously. Each managed service you skip saves 20% of one engineer's time.
• Building the "enterprise-ready" version first: SOC2, multi-tenant isolation, audit logging — all matter, but not before you have 10 paying customers. Build the path TO compliance, don't implement it day 1.

Startup-Specific Cost Traps in Planning

"When to Graduate" Triggers

Bedrock — Startup Decision Guide

Model Selection: Cost-First Thinking

The #1 startup cost trap: Defaulting to Claude Sonnet/Opus "to be safe" during prototyping, then getting locked into those costs at scale.

Stage-Specific Strategy

Counterintuitive Advice

• Don't start with the best model and optimize later. Start with Nova Micro. If it fails, you've learned exactly what capability gap you need — and you'll prompt-engineer around it first. Most startups discover 70%+ of their calls work fine on the cheapest model.
• Nova Pro is underrated. For most startup use cases (summarization, extraction, Q&A), Nova Pro matches Claude Sonnet quality at ~3-5x lower cost per token. Evaluate it before assuming you need Anthropic models.
• Batch API saves 50% — use it aggressively. Any workload that doesn't need real-time response (nightly processing, background enrichment, evaluation runs) should use batch. Most startups leave this on the table.

Architecture: What NOT to Build Early

The Agent Tax

Every agent step multiplies cost: tool selection reasoning + tool execution + result synthesis = 3-5x the token cost of a single invoke.

Startup rule of thumb:

• < $500/month LLM spend → Never use agents. Use InvokeModel with structured prompts.
• $500-5K/month → One simple agent max. Router + specialist only if you have genuinely distinct domains.
• $5K+/month → Agent architecture justified if you have evidence single-call can't do the job.

Credits-Specific Guidance

• Bedrock on-demand pricing is token-based — AWS Activate credits cover it fully (no commitment needed)
• Don't buy Provisioned Throughput with credits. Credits expire; provisioned commitments don't. You'll be stuck paying on-demand rates after credits burn down with capacity you may not need.
• Prompt caching is automatic for supported models — structure your prompts with stable system prompts first to maximize cache hits (free repeated tokens)

Knowledge Bases: PoC Cost Trap

OpenSearch Serverless minimum cost: ~$700/month (2 OCU indexing + 2 OCU search minimum).

Startup Alternatives

When to graduate from prompt-stuffing to RAG:

• Source documents exceed 50K tokens total
• Documents change frequently (weekly+)
• You need citation/attribution in answers
• Multiple distinct document collections need separate retrieval

Anti-Patterns (Startup-Specific)

• Building "AI features" before product-market fit. LLM costs scale with users. If you haven't validated demand, you're burning credits on a product nobody wants. Validate with a Wizard-of-Oz or rules-based MVP first.
• OpenSearch Serverless for a PoC. $700/month minimum for something 50 users will touch. Use pgvector on Aurora Serverless or just stuff documents into prompts until scale demands RAG.
• Custom fine-tuning before exhausting prompt engineering. Fine-tuning on Bedrock costs real money (training tokens + hosting custom model). 95% of startup use cases are solved with better prompts + few-shot examples. Fine-tune only when you have 10K+ labeled examples and measurable quality gap.
• Not tracking per-feature token costs. When you have 5 AI features, one will be 80% of your bill. Without per-feature cost attribution, you can't make informed product decisions about which features to keep/kill/optimize.

Challenger — Startup-Specific Guidance

Startup Challenge Framework

When challenging an architecture recommendation for a startup, apply these lenses in order:

1. The "Can You Operate This?" Test

For a team of N engineers, how many services require operational expertise?

If the proposed architecture exceeds the team's operational budget, it's wrong regardless of how "correct" it is technically.

2. The "What If You Succeed?" Test

Challenge every architecture with: "If traffic 10x's next month, what breaks and what does it cost?"

Red flags:

• Architecture that requires manual intervention to scale (fixed EC2 instances without ASG)
• Architecture where cost is non-linear with traffic (NAT Gateway data charges, cross-AZ chatter)
• Architecture that requires re-architecture to scale (monolith on a single RDS instance with no read path)

3. The "What If Credits Expire Tomorrow?" Test

• Is the monthly cost sustainable on revenue alone?
• Are there Savings Plans or RIs purchased during credits that'll now cost real money?
• Is there over-provisioning that was "free" during credits but now costs $$$?

4. The "Simpler Alternative" Test

For every complex component proposed, name the simpler alternative and what you give up:

5. The "Premature Optimization" Detector

Challenge if you see ANY of these in a pre-PMF architecture:

• Multi-region anything
• Kubernetes
• Data lake / data warehouse
• Event sourcing
• CQRS
• Service mesh
• Custom observability platform (use CloudWatch)
• Multi-account beyond prod/dev split
• More than 3 microservices

Each of these is valid at scale. None of them are valid before product-market fit.

Startup Challenger Verdict Scale

CloudFront — Startup Decision Guide

Stage-Based Recommendation

Pre-PMF (Seed / <$1M ARR)

• Deploy CloudFront from day one for static assets. It's effectively free at low traffic (1TB free tier) and gives you global performance without multi-region infrastructure.
• Skip WAF until you see abuse. WAF adds $5/month minimum + per-request costs.
• Use versioned filenames (app.abc123.js) from the start — never rely on invalidations.

Post-PMF / Growth ($1M-$10M ARR)

• Add WAF when you have traffic worth protecting or compliance requirements.
• Add CloudFront in front of API Gateway only if you need geographic caching of API responses or need to combine static + API under one domain.
• Consider CloudFront Functions (not Lambda@Edge) for header manipulation — 1/6th the cost.

Cost Traps

Counterintuitive Advice

• CloudFront in front of Lambda Function URLs is often better than API Gateway. You get custom domains, caching, and WAF at CloudFront cost ($0.085/GB + $0.01/10K requests) instead of API Gateway cost ($1.00/million requests). For a startup doing 10M requests/month on small payloads: CloudFront = ~$10, HTTP API = $10, REST API = $35. But CloudFront gives you the caching layer for free.
• Don't use edge-optimized API Gateway endpoints. They silently create a CloudFront distribution you can't configure. Use regional + your own CloudFront if you need CDN.
• The free tier (1TB/month transfer, 10M requests) is generous. Most pre-PMF startups never exceed it. Don't optimize what costs you $0.

When to Add CloudFront (if not already using it)

You're paying too much for origin compute/bandwidth when:

• Your origin (ALB, API Gateway, S3) data transfer exceeds $50/month
• You're serving the same API response to many users within a time window (cacheable)
• You need to serve users on multiple continents without multi-region deployment

Configuration Decisions (Get These Right on Day 1)

Origins

• Use Origin Access Control (OAC) — not the legacy Origin Access Identity (OAI). OAC supports SSE-KMS and all S3 features; OAI does not.
• For S3 static website hosting endpoints, use custom origin (not S3 origin type) — the website endpoint is HTTP-only.
• For API origins, use CachingDisabled managed policy unless you explicitly control TTLs and cache keys.
• Use regional API Gateway endpoints, not edge-optimized (avoids double CloudFront hop).

Caching

• Forward only what the origin needs — extra headers/cookies/query strings destroy cache hit ratio. Use separate cache and origin request policies.
• Enable automatic compression (Gzip + Brotli) in cache behavior — saves 60-80% on text assets.

Security

• ACM certificate must be in us-east-1 for CloudFront. They're free and auto-renew.
• Add security response headers via response headers policy: HSTS, X-Content-Type-Options, X-Frame-Options.
• Never use self-signed certs with custom domains.

Credits Consideration

CloudFront data transfer is covered by AWS Activate credits. If you have $100K in credits, don't optimize CloudFront costs — optimize for developer velocity instead. Revisit when credits are within 6 months of expiring.

Cost Check — Startup-Specific Guidance

The Startup Cost Model (Different from Enterprise)

Enterprise optimizes for: lowest per-unit cost at scale. Startups optimize for: lowest BASELINE cost with LINEAR scaling (no cliffs).

The Three Cost Questions for Startups

1. What's my cost at zero/minimal traffic? (This is your monthly burn before you have customers) 2. What's my cost at 10x current traffic? (Is it linear or does it cliff?) 3. What's my cost when credits expire? (The real number)

Hidden Cost Killers — Startup-Specific

These rarely appear in enterprise cost reviews but destroy startup budgets:

Credits Strategy

How to Model Costs with Credits

Real monthly cost = AWS bill - credits applied
Runway (months) = Remaining credits / Real monthly cost
Post-credits monthly cost = AWS bill (this is what you need revenue to cover)

Credits Optimization Rules

1. Never buy Reserved Instances or Savings Plans while on credits — you can't see real usage patterns 2. Credits cover everything except Marketplace — use native AWS services, not Marketplace alternatives 3. Track credits burn rate monthly — if burning faster than expected, investigate NOW not at expiry 4. Plan architecture for post-credits reality — if your arch costs $15K/mo and revenue is $5K/mo, you have a problem BEFORE credits expire 5. Credits don't carry over after expiry date — use-it-or-lose-it. Don't under-utilize to "save" them

Cost Scaling Patterns — Choose Wisely

The "$100/mo Baseline" Rule

If your architecture costs >$100/mo at zero customers, justify every dollar:

• $16/mo ALB: Do you need it, or can Lambda + API Gateway work?
• $32/mo NAT Gateway: Do you actually need private subnet egress?
• $43/mo Aurora Serverless v2 minimum: Is RDS t4g.micro ($12/mo) sufficient?
• $7/mo per VPC endpoint: Can you use public endpoints with IAM auth instead?

When to Invest in Cost Optimization

Quick Wins Checklist

• [ ] Unused EBS volumes and unattached Elastic IPs
• [ ] CloudWatch log retention set to "Never expire" — change to 7d dev / 30d prod
• [ ] NAT Gateway traffic that could use VPC endpoints
• [ ] Over-provisioned RDS instances (check CPU utilization)
• [ ] Lambda functions with excessive memory allocation
• [ ] Dev environments running 24/7 — schedule stop outside business hours
• [ ] Old EBS snapshots and unused AMIs
• [ ] S3 buckets without lifecycle policies

Gotchas

• Data transfer costs are the silent killer — especially cross-AZ and cross-region
• DynamoDB on-demand vs provisioned: on-demand is cheaper below ~20% utilization of provisioned capacity
• S3 Intelligent-Tiering monitoring fee per object — not worth it for millions of tiny objects
• CloudFront can be cheaper than S3 direct for high-traffic reads (no S3 request fees)
• Graviton instances are ~20% cheaper and often faster — use them unless you need x86

Credits Strategy

Key Facts for Architecture Decisions

• Credits apply AFTER free tier (free tier is consumed first)
• Credits do NOT cover: Route53 domain registration, Marketplace purchases, Support plan upgrades, third-party billed services
• Credits expire (typically 1-2 years from activation) — check Billing Console → Credits

---

High-Burn Traps (avoid at early stages)

These eat credits even at zero traffic:

Burn Rate Red Flags

• NAT Gateway data processing: Chatty services behind NAT can burn $100+/mo in processing alone
• CloudWatch Logs default retention: "Never expire" = costs accumulate forever. Set 7d dev / 30d prod.
• Stopped EC2 still pays for EBS, unattached volumes, idle ALBs
• Over-provisioned RDS at 5% CPU — use Aurora Serverless v2 instead
• Dev environments running 24/7 — schedule stop outside business hours

---

Credits Runway by Stage

---

Stage-Specific Optimization

Pre-Revenue: $0-50/month target

• Stay within free tier entirely — Lambda + DynamoDB + S3 all scale to zero
• No custom VPC — Lambda, DynamoDB, S3 work without one
• No NAT Gateway under any circumstances

Seed: $100-500/month target

• Replace NAT Gateway with VPC endpoints for S3/DynamoDB (free)
• DynamoDB on-demand only — you don't know access patterns yet
• Use Graviton (ARM) for Lambda and Fargate — 20% cheaper for free
• Audit monthly with aws ce get-cost-and-usage

Series A: When to start commitments

• Savings Plans ONLY after 3+ months of stable usage data
• Start with 1-year Compute Savings Plan, No Upfront
• Cover only 50-70% of baseline — leave room for variability
• Enable Cost Anomaly Detection (catches unexpected spikes)

---

Credits Expiration: Don't Lose Them

If credits expire in <3 months with significant balance remaining, spend on things you'll need anyway:

• Staging/DR environments you were going to build
• Load tests and performance benchmarks
• Bedrock model experimentation
• Observability buildout (dashboards, alarms, tracing)

Don't spin up resources just to burn credits — that's worse than letting some expire.

Customer Ideation — Startup-Specific Discovery

Startup-Adapted Discovery Questions

Standard AWS discovery asks 40+ questions. Startups need a focused subset that reveals architecture-critical constraints fast.

The 6 Questions That Actually Matter for Startup Architecture

1. What's your monthly AWS budget ceiling? (Not "what do you want to spend" — what kills you if you exceed it?) 2. How many engineers will touch infrastructure? (If answer is 0-1, eliminate anything requiring operational expertise) 3. What's your team's technical profile? (Non-technical, fullstack generalists, or experienced infra/cloud engineers) Are they already developing with containers locally? 4. Do you have AWS credits? How much, when do they expire? (Changes every capacity planning decision) 5. What's your current traffic/data volume, and what's your 12-month optimistic projection? (Design for 10x current, have a PATH to 100x) 6. What's the one thing that, if it breaks, kills your company? (This is what gets redundancy. Everything else gets the cheapest option)

Follow-Up Questions by Answer Pattern

If budget < $500/mo:

• Serverless-only architecture. No discussion.
• Ask: "Are cold starts acceptable for your use case?" (determines Lambda vs ECS Express Mode)

If team = 1-2 engineers:

• Eliminate: EKS, self-managed databases, custom networking
• If they're already running containers locally → ECS Express Mode. Don't push them to Lambda and force a rewrite of what already works.
• If they're non-technical founders or have no container experience → Lambda or Amplify. Lowest operational surface area.

If team is experienced engineers (previous startups, cloud-native background):

• Don't dumb it down. They can handle ECS, IaC, and CI/CD from day one.
• Match the deployment model to how they already develop — containerized local dev should deploy as containers.
• Focus guidance on cost optimization and AWS-specific gotchas, not basic architecture patterns.

If credits > $25K:

• They'll try to over-build. Push back: "What's the plan when credits expire in [month]?"
• Ask: "Which parts of your architecture are experiments vs committed?" (experiments get throwaway infra)

If "the thing that kills us" is data loss:

• Backups + point-in-time recovery are non-negotiable even pre-seed
• Ask: "Is the data reconstructible from an external source, or is it uniquely generated?"

If "the thing that kills us" is downtime:

• Multi-AZ on the critical path component only (not everything)
• Ask: "How many minutes of downtime per month is actually acceptable?" (usually more than they think)

Startup Ideation Anti-Patterns

• "We need to be enterprise-ready from day 1": No. You need to be enterprise-ready when enterprises want to buy. Build the path, not the destination.
• "We'll need multi-region for global users": How many global users do you have today? CloudFront + single region handles global reads. Multi-region is a Series B problem.
• "We should use Kubernetes because we'll need it eventually": The migration from Fargate to EKS takes 2-3 weeks. The cost of running EKS before you need it is 6-12 months of unnecessary complexity.
• "We need a data lake": You have 10GB of data. You need an S3 bucket and Athena. A "data lake" is a label you put on it later.

Qualify the Workload for Startup Context

After discovery, classify:

DynamoDB — Startup-Specific Guidance

When Startups Should Choose DynamoDB

DynamoDB is the right default database for startups when:

• Your data model is key-value or document-oriented (user profiles, sessions, IoT telemetry, orders)
• You need single-digit millisecond latency at any scale
• You want zero operational overhead (no patching, scaling, backups to manage)
• Your access patterns are known upfront (this is critical — DynamoDB punishes query pattern changes)

DynamoDB is the WRONG choice when:

• You don't know your access patterns yet (early prototyping with ad-hoc queries → use PostgreSQL)
• You need complex joins, aggregations, or flexible queries → use PostgreSQL/Aurora
• Your data is highly relational with many-to-many relationships → use PostgreSQL
• You need full-text search → use OpenSearch or PostgreSQL with pg_trgm

The Access Pattern Lock-in Problem

This is the #1 DynamoDB mistake startups make: choosing DynamoDB for operational simplicity, then discovering 6 months later that a new feature requires a query pattern the table design doesn't support.

Mitigation: Before committing to DynamoDB, write down your top 10 access patterns. If you can't, you don't know enough about your product to choose DynamoDB. Use PostgreSQL/Aurora until patterns stabilize, then migrate hot paths to DynamoDB.

Startup Cost Traps

1. On-Demand mode at scale without noticing: On-Demand is correct at the start (zero cost at zero traffic). But at sustained load, it's 5-7x more expensive than provisioned. Trigger to switch: when your DynamoDB bill exceeds $100/month with predictable traffic patterns, switch to provisioned with auto-scaling.

2. GSI proliferation: Each GSI copies all projected attributes and consumes write capacity on every write to the base table. Startups add GSIs reactively ("we need to query by email too") without budgeting the cost. At 5+ GSIs with full projections, you may be paying 5x your base table cost in GSI writes.

3. Scan-based "analytics": Teams build admin dashboards that Scan the entire table. At 1M items, a full Scan costs ~$1.25 and takes seconds. At 100M items, it's $125 per scan. Export to S3 + Athena for analytics — never Scan production tables repeatedly.

4. DAX when you don't need it: DAX clusters start at ~$50/month (t3.small) and require VPC placement. Don't add DAX until you've confirmed: (a) reads are the bottleneck, (b) the same items are read repeatedly, (c) eventual consistency is acceptable. Most startups don't need DAX.

5. DynamoDB Streams + Lambda at high volume: Each Lambda invocation from Streams counts against your Lambda concurrent execution limit AND costs per invocation. At 10K writes/second, that's 10K Lambda invocations/second. Use Kinesis Data Streams as the consumer if write volume is high.

Stage-Specific Recommendations

Pre-PMF (validating product)

• Use On-Demand mode — zero cost at zero traffic, scales automatically
• Simple key design: don't over-engineer single-table design at this stage. One table per entity is fine (users table, orders table). Optimize later.
• Enable Point-in-Time Recovery ($0.20/GB-month) — your only protection against accidental deletes
• Total cost at low traffic: $0-5/month

Post-PMF (scaling, Series A)

• Switch predictable tables to Provisioned + Auto-Scaling (target 70% utilization)
• Consider single-table design for entities that transact together
• Add DynamoDB Streams for event-driven patterns (materialized views, search indexing)
• Export to S3 for analytics instead of Scanning

Scale (Series B+, >$1K/month DynamoDB)

• Reserved capacity (1-year or 3-year) for base throughput — up to 77% savings
• Evaluate Global Tables only if you genuinely need multi-region writes
• DAX for read-heavy hot key patterns
• Consider moving some tables to Aurora if query flexibility is needed

Counterintuitive Startup Advice

• Don't do single-table design at the start. It's an optimization for scale and reduced table management. At pre-PMF with 2-3 entities, separate tables are more readable, easier to reason about, and trivial to change. Single-table design is a one-way door that's painful to refactor.

• DynamoDB is often MORE expensive than Aurora for typical CRUD apps. A startup with a standard web app (users, posts, comments, likes) paying $50/month for a db.t4g.micro Aurora Serverless v2 instance would pay $200+/month for the same data in DynamoDB with GSIs for all query patterns. DynamoDB wins on latency and ops burden, not on cost for relational-shaped data.

• Free tier covers you longer than you think. DynamoDB free tier (25 RCU, 25 WCU, 25 GB) is permanent and enough for ~200 reads/sec and ~25 writes/sec. Most pre-PMF startups never exceed this.

When to Graduate FROM DynamoDB

Credits-Specific Guidance

• DynamoDB On-Demand costs are covered by credits. During credits: stay on On-Demand even if traffic is predictable — the flexibility is worth it while you're iterating on data models.
• When credits expire: On-Demand bills hit immediately. Switch to Provisioned + Auto-Scaling for any table with consistent traffic before credits run out.
• Point-in-Time Recovery and backups also count against credits — enable them generously during the credits period.

EC2 — Startup-Specific Guidance

When Startups Should Use EC2 Directly

Almost never as your first choice. Start with Lambda or ECS Fargate. EC2 makes sense for startups only when:

• You need GPUs (ML training/inference) — no Fargate GPU support
• You're running software that requires full OS control (custom kernels, specific drivers, Docker-in-Docker)
• You're running a stateful workload that doesn't fit managed services (self-managed databases, Redis clusters, Kafka)
• Your sustained compute spend exceeds $10K/month and you can commit to instance management

The hidden cost: EC2 requires patching, AMI management, monitoring agents, and capacity planning. At a 3-person startup, that's 10-20% of an engineer's time — your scarcest resource.

Startup Cost Traps

1. Running instances 24/7 in dev/staging: A t3.medium costs ~$30/month. Three dev environments left running = $90/month doing nothing nights/weekends. Use Auto Scaling scheduled actions or Lambda-triggered stop/start. Savings: 65% on non-prod instances.

2. Elastic IPs not attached to instances: $3.60/month per unused EIP. Teams allocate them "for later" and forget. Check monthly.

3. gp2 volumes still in use: gp2 costs more than gp3 and performs worse at small sizes (gp2 scales IOPS with size; gp3 gives 3000 IOPS baseline regardless). Convert all gp2 → gp3 immediately, it's free and non-disruptive.

4. Savings Plans purchased too early: Don't buy Compute Savings Plans until you have 3+ months of stable EC2 usage data. Startups pivot — a 1-year commitment on instance types you abandon in 3 months is wasted money.

5. Data transfer between AZs: $0.01/GB each way. A chatty microservices architecture across AZs can accumulate $100s/month in cross-AZ transfer that doesn't show up obviously in Cost Explorer. Keep tightly-coupled services in the same AZ or use ECS/EKS service mesh for efficient routing.

Stage-Specific Recommendations

If You Must Use EC2 (Pre-Series A)

• Single instance, single AZ is acceptable for non-critical workloads
• Use t3.small or t3a.small ($15/month) — burstable is fine for dev/staging
• Use Spot for batch/ML training from day one — 70-90% savings and you learn the interruption model early
• SSM Session Manager, not SSH keys — zero additional infrastructure cost and IAM-controlled

Growth Stage (Series A-B, steady EC2 usage)

• Buy 1-year No Upfront Compute Savings Plans for baseline (30% savings, flexible across instance types)
• Graviton (ARM64): migrate workloads for 20-30% cost reduction — most Docker containers work unchanged
• Mixed instance ASGs: 3+ instance types, Spot for workers, On-Demand for stateful

Scale ($50K+/month EC2)

• 3-year Partial Upfront Savings Plans for steady-state base (up to 60% savings)
• Reserved Instances for specific GPU instances that don't change
• Spot fleet with capacity-optimized for batch/ML — diversify across 10+ instance types

Counterintuitive Startup Advice

• A single EC2 instance is a valid architecture. For internal tools, admin panels, or low-traffic services that don't justify container orchestration — one t3.small with a Docker Compose setup and an AMI-based backup strategy works fine. It's not "production best practice" but it's pragmatic until revenue justifies HA.

• Don't build for multi-AZ until you have paying customers who'd notice. Multi-AZ doubles your compute baseline cost. If your SLA is informal and your recovery plan is "redeploy from AMI in 10 minutes," that's fine at pre-PMF.

• Spot instances for production stateless workloads is fine. The standard advice is "never use Spot in production." For startups: if your service handles graceful shutdown and you have On-Demand fallback in your ASG, the 70% savings funds an extra engineer-month every few months.

When to Graduate TO EC2 (from Fargate)

Credits-Specific Guidance

• EC2 On-Demand is covered by AWS Activate credits. During credits: don't buy Savings Plans or Reserved Instances — they can't be applied against credits and you lose flexibility.
• When credits expire: you'll hit full on-demand pricing immediately. Plan 1 month ahead: identify steady-state instances, purchase Savings Plans, and right-size or terminate anything over-provisioned.
• GPU instances (P/G family) burn credits extremely fast. A single p3.2xlarge costs ~$2,200/month. Use Spot for training and be deliberate about GPU hours.

ECS — Startup-Specific Guidance

When to Choose ECS (vs Lambda or EKS)

Choose ECS when: You've outgrown Lambda ($300-500+/month Lambda bill with steady traffic), need long-running processes, WebSockets, or >6MB responses, but don't have a platform team to run Kubernetes.

The startup sweet spot: ECS Fargate is the "right-sized" container platform for teams of 1-15 engineers. It gives you containers without the Kubernetes learning curve, tax, or operational burden.

Do NOT start with ECS if: Your traffic is spiky/unpredictable and you can fit in Lambda's constraints. Lambda's scale-to-zero beats Fargate's minimum-task cost for low-traffic services.

Startup Cost Traps

1. Fargate Spot in production services: 70% savings sounds great, but Spot tasks get terminated with 30s warning. Use ONLY for: batch jobs, queue workers, background processing. Never for user-facing APIs unless you have graceful failover to on-demand.

2. Over-provisioned task definitions: Startups copy-paste 2 vCPU / 4GB task defs without measuring. A typical Node.js/Python API serves 200+ req/s on 0.25 vCPU / 0.5GB (~$9/month). Start at the minimum and scale up based on Container Insights metrics.

3. ALB cost baseline: An ALB costs ~$22/month minimum (fixed hourly) + LCU charges. For a startup with 2-3 services, that's fine. But don't create one ALB per service — use path-based routing on a shared ALB until you need isolation.

4. NAT Gateway double-tax: Fargate tasks in private subnets need NAT for internet access. NAT costs $32/month + $0.045/GB processed. For early startups with one service, consider running in public subnets with security groups locked down (heresy, but saves $32/month). Graduate to private subnets when you have compliance requirements or >3 services.

5. Container Insights: Costs ~$7-15/month in CloudWatch charges per cluster. Worth it for production, not needed for dev/staging.

Stage-Specific Recommendations

Pre-PMF (1-5 engineers, <$1K/month infra)

• Single Fargate service, single ALB, public subnet (with locked-down SG)
• 0.25 vCPU / 0.5GB task, minCount=1, maxCount=3
• Use ECS Exec for debugging (replaces SSH)
• Total cost: ~$35-50/month (1 task + ALB)

Post-PMF / Series A (5-15 engineers, $1K-10K/month)

• Move to private subnets + NAT Gateway
• Add a second service (worker/background jobs)
• Enable Container Insights on production cluster
• Use Fargate Spot for workers, on-demand for APIs
• Consider Graviton (ARM64) — 20% cheaper on Fargate too

Scaling (Series B+, >$10K/month compute)

• Evaluate ECS on EC2 with Savings Plans if >80% utilization sustained
• Fargate's ~20-30% premium over EC2 matters at $50K+/month
• At this stage, also evaluate if EKS makes sense for your hiring pipeline (more K8s engineers available than ECS-specific)

Counterintuitive Startup Advice

• One cluster, one service is fine. The "one cluster per environment" guidance assumes you have environments. At pre-PMF, run one cluster with one production service. Add dev/staging clusters when you have a team that needs them.

• Skip blue/green deployments initially. Rolling updates with circuit breaker give you auto-rollback without CodeDeploy complexity. Blue/green adds value at scale (instant rollback) but adds operational surface area early.

• `:latest` tag is acceptable in dev/staging. Yes, it's an anti-pattern in production. But for a 2-person team iterating daily, the overhead of tagging every dev build with a SHA isn't worth it until you have a CI/CD pipeline.

• Don't multi-region until revenue demands it. ECS services in 2 regions = 2x base cost + cross-region complexity. Stay single-region until you have customers requiring <50ms latency in another continent or contractual uptime SLAs.

When to Graduate from ECS

Credits-Specific Guidance

• Fargate compute is covered by AWS Activate credits. During credits: use on-demand everywhere, don't bother with Spot, and provision for peak.
• When credits expire: the "always on" baseline of Fargate tasks hits immediately. Budget the transition: right-size tasks, add Spot for workers, configure scale-to-zero for non-prod.
• Fargate costs are predictable — easy to model post-credits burn rate: tasks × hours × (vCPU_price + memory_price).

EKS — Startup-Specific Guidance

The Hard Truth: Most Startups Shouldn't Use EKS

EKS is a Series B+ decision. The Kubernetes tax is real:

• EKS control plane: $73/month (before any workload runs)
• Minimum viable production cluster: ~$300-500/month (control plane + 2-3 nodes + ALB + NAT)
• Platform engineering time: 20-40% of one engineer's bandwidth for maintenance, upgrades, RBAC, networking
• Time to first deploy: days/weeks vs hours for ECS Fargate

Choose EKS only when:

• Team > 10-15 engineers with multiple teams needing namespace isolation
• You're hiring primarily from a Kubernetes-experienced talent pool
• You need advanced scheduling (GPU sharing, bin-packing, multi-tenancy)
• Your compute spend exceeds $20K/month and Karpenter's optimization justifies the platform cost
• You're already running K8s and migrating to AWS (don't re-learn ECS just for AWS)

Startup Cost Traps

1. The $73/month control plane for dev/staging: Many startups create 3 clusters (dev/staging/prod) = $219/month in control planes alone before a single pod runs. At pre-Series A, use namespaces on a single cluster for isolation. Add dedicated clusters at Series B.

2. Managed node groups with oversized instances: Default tutorials use m5.large nodes. A startup running 3-5 microservices needs maybe 2-4 vCPUs total. Use t3.medium nodes or Karpenter with tight resource limits.

3. Add-on sprawl: Each add-on (cert-manager, external-dns, ArgoCD, Datadog, Istio) runs pods that consume node resources. A "production-ready" cluster with common add-ons needs 2-4 vCPUs just for platform components. Budget this separately.

4. Karpenter consolidation disabled: Karpenter defaults to not consolidating nodes. Enable consolidationPolicy: WhenEmptyOrUnderutilized immediately — it's the primary mechanism for right-sizing your fleet and avoiding paying for idle capacity.

5. Load Balancer per service: Each Kubernetes Service type: LoadBalancer creates an NLB (~$16/month). Use an Ingress controller (ALB Controller or nginx) to share one load balancer across services.

Stage-Specific Recommendations (If You're Committed to EKS)

Early (1 cluster, <$5K/month compute)

• Single cluster, namespaces for env separation (dev/staging/prod namespaces)
• Karpenter from day one — never use Cluster Autoscaler for new clusters
• Fargate profiles for low-traffic namespaces (dev) to avoid idle node costs
• Skip service mesh (Istio/Linkerd) — use simple K8s Services and Network Policies
• ArgoCD for GitOps from the start — it's free and prevents kubectl apply drift

Growth ($5K-50K/month compute)

• Separate prod cluster from non-prod
• Karpenter with Spot for stateless workloads (70% savings)
• Pod Identity for IAM (not IRSA) — simpler, fewer moving parts
• Enable control plane logging for security/audit
• Implement PodDisruptionBudgets for all production workloads

Scale ($50K+/month compute)

• Dedicated node groups for isolation (GPU, high-memory, batch)
• Multi-cluster with fleet management (if multi-region needed)
• Full observability stack (Prometheus/Grafana or Datadog)
• Consider EKS Anywhere for hybrid if needed

Counterintuitive Startup Advice

• ECS to EKS migration is easier than EKS to ECS. If unsure, start with ECS. If you later need K8s, your containers and Dockerfiles transfer unchanged — only the orchestration layer changes. The reverse (EKS → ECS) requires removing all K8s-specific config (Helm charts, CRDs, operators).

• A well-run ECS setup is operationally simpler AND cheaper than EKS until $20K/month compute. The K8s ecosystem flexibility only pays off when you have enough services and team size to leverage it.

• Don't use Helm for everything. Early startups over-invest in templating 3-5 services with complex Helm charts. Plain Kubernetes manifests + Kustomize overlays are more readable and debuggable for small teams. Switch to Helm when you have 10+ services with shared patterns.

• Fargate on EKS is worse than Fargate on ECS. EKS Fargate has more limitations (no DaemonSets, no persistent volumes, no GPUs, higher per-pod overhead, slower scheduling). If you want Fargate simplicity, use ECS. If you want EKS, use managed node groups with Karpenter.

When to Graduate TO EKS

Credits-Specific Guidance

• EKS control plane ($73/month) is covered by credits but is a fixed cost — don't create clusters you won't use.
• During credits: experiment with EKS to validate if your team can operate it. This is the time to learn without cost pressure.
• If your team struggles with EKS during the credits period, that's your answer — switch to ECS before credits expire and you're paying $500+/month for a platform you can't operate well.

IaC Scaffold — Startup-Specific Guidance

When to Introduce IaC (Not Day 1 for Everyone)

Framework Selection for Startups

Opinionated startup default:

• Pure serverless app → SAM (simplest, fastest iteration with sam local)
• Full-stack app → CDK in TypeScript (same language as your app, likely)
• Multi-cloud or Terraform-experienced team → Terraform

Startup IaC Anti-Patterns

Startup-Optimized Stack Separation

stack-1: foundation (VPC if needed, DNS zone, shared secrets)
  → Deploys once, changes rarely
  → Even for pre-seed: just DNS zone + maybe a VPC

stack-2: data (databases, S3 buckets, DynamoDB tables)
  → Deploys rarely, NEVER destroyed (data loss)
  → Enable deletion protection on everything here

stack-3: compute (Lambda functions, ECS services, API Gateway)
  → Deploys frequently (every PR merge)
  → Safe to destroy and recreate

Key rule: Never put databases and compute in the same stack. A botched compute deploy should never risk your data.

Minimum Viable IaC for Startups

If you're scaffolding for the first time, include ONLY:

1. The compute + API layer 2. The data layer (separate stack) 3. A Makefile with: deploy, destroy, diff, logs 4. Environment config: dev and prod (not staging, qa, perf, etc.)

Skip until needed:

• CI/CD pipeline IaC (use GitHub Actions with aws-actions/configure-aws-credentials — simple YAML)
• Monitoring/alerting IaC (click 3 alarms in the console — faster than writing CDK for them)
• Multi-account bootstrap (until you actually have multiple accounts)
• Custom domains + ACM certs (until you need them for customers)

IAM — Startup Decision Guide

Stage-Based Recommendation

Pre-PMF (Seed / <$1M ARR, 1-5 engineers)

• AWS managed policies are fine. Don't spend days crafting least-privilege policies when your team is 3 people and you're iterating daily. Use PowerUserAccess (no IAM admin) for developers.
• Skip Identity Center until you have 5+ engineers. Below that, IAM users with MFA and forced credential rotation is pragmatic. The setup cost of Identity Center + IdP isn't worth it for 2-3 people.
• One AWS account is fine. Multi-account is best practice but overkill when you're pre-revenue. Add a second account (prod) when you have paying customers.

Post-PMF / Growth ($1M-$10M ARR, 5-30 engineers)

• Set up Identity Center now. You've delayed long enough. Connect to Google Workspace or Okta (whichever your company already uses).
• Separate prod account. If you haven't done this yet, do it before your next compliance audit.
• Use Access Analyzer. Generate policies from CloudTrail activity to replace overly broad managed policies. Takes 30 minutes, saves you in your SOC2 audit.
• Permission boundaries for senior devs who need to create IAM roles (for Lambda, ECS). Prevents accidental privilege escalation.

Scale ($10M+ ARR, 30+ engineers)

• Full AWS Organizations with SCPs.
• Account-per-team or account-per-service pattern.
• This is when you hire a security engineer.

Cost Traps

IAM itself is free, but IAM mistakes cause cost explosions:

Counterintuitive Advice

• `AdministratorAccess` for the founding engineer is OK at seed stage. The blast radius is one account with no customers. Velocity matters more than least privilege when you're proving the idea works. Add guardrails when you add the 4th engineer.
• Don't implement SCPs until you have 3+ accounts. SCPs on a single-account org do nothing useful but add debugging complexity.
• Managed policies > custom policies until SOC2. Your custom policies will have bugs. AWS managed policies are tested and maintained. Switch to custom when compliance requires it or when you need to restrict specific resources.
• Skip IAM Access Analyzer findings in dev accounts. Cross-account access in your dev account is not a security incident. Focus Access Analyzer on prod only.

Minimum Viable Security Posture by Stage

Seed (just don't get hacked)

• [ ] MFA on root account (hardware key in a safe)
• [ ] MFA on all IAM users
• [ ] No root access keys ever
• [ ] PowerUserAccess for engineers (can't modify IAM)
• [ ] One admin user for IAM changes
• [ ] Enable CloudTrail (default trail is free)

Series A (preparing for SOC2)

• [ ] Identity Center with Google/Okta SSO
• [ ] Separate prod account
• [ ] Permission boundaries on developer roles
• [ ] Access Analyzer enabled in prod
• [ ] SCP: deny all regions except primary + us-east-1 (for global services)
• [ ] SCP: deny root access key creation

Series B+ (passing SOC2/HIPAA audits)

• [ ] Full Organizations with OU structure
• [ ] SCPs on every OU
• [ ] Custom least-privilege policies from Access Analyzer
• [ ] Automated credential rotation
• [ ] GuardDuty in all accounts
• [ ] Security Hub aggregating findings

When to Graduate

Investor Readiness

What Investors Actually Ask (and How to Answer)

Seed Pitch: Speed + Capital Efficiency Story

Template:

"We built on serverless AWS infrastructure that costs near-zero at current scale and grows linearly with users. Monthly cost is $X, credits give us Y months of runway before infra becomes a line item. Architecture handles 100x current load without changes."

Don't say: anything about Kubernetes, microservices, or complex architecture (signals over-engineering). Don't say "we'll need to rewrite at scale" (signals poor planning).

Series A Pitch: Unit Economics + Reliability

Key metrics to have ready:

---

Red Flags Investors Look For

---

How to Present AWS Costs to Investors

Don't show a raw AWS bill with 47 line items.

Do present in business terms:

Monthly Infrastructure: $X,XXX
├── Compute (API + background): XX%
├── Database: XX%
├── AI/ML (Bedrock): XX%
├── Storage + CDN: XX%
└── Other: XX%

Cost per active user: $X.XX/month
Cost as % of MRR: X%
Credits remaining: $XX,XXX (X months at current burn)

Unit Economics Healthy Ranges (SaaS)

---

Due Diligence Prep (Series A+)

Have these ready for technical DD:

1. One-page architecture diagram (components + data flow) 2. Scaling plan at 10x and 100x (ideally: "nothing changes" for serverless) 3. Honest list of single points of failure + mitigation plan 4. RTO/RPO targets 5. Technical debt acknowledgment + paydown plan 6. No single person is a blocker for any system 7. Historical cost trajectory + projection at target scale

IoT — Startup Decision Guide

The IoT Cost Curve: Why Startups Get Surprised

IoT costs are multiplicative: devices × messages/device × actions/message. A fleet of 10,000 devices sending 1 msg/sec generates 864M messages/day. Startups that prototype with 10 devices don't see this coming.

Cost at Scale (Monthly Estimates)

The lesson: Message frequency is the cost multiplier. Design for the lowest frequency that meets product requirements. If you need 1/sec sensing but only 1/min cloud reporting, aggregate at the edge.

Stage-Specific Architecture

Cost Traps Specific to Startups

1. Basic Ingest: The $1/Million Messages You Don't Need to Pay

Standard MQTT publish: $1.00 per million messages broker fee + rules engine fee.

<!-- markdownlint-disable-next-line MD033 -->

Basic Ingest ($aws/rules/<rule-name> topic): $0 broker fee, only rules engine actions charged.

Use Basic Ingest for all high-volume telemetry that only needs to flow to the cloud (no device-to-device). Most startup telemetry is one-directional. This saves 50% on messaging costs with a topic prefix change.

2. Timestream vs S3+Athena: When to Use Which

Startup default: S3 + Athena until you have a real-time dashboard requirement. Most seed-stage IoT startups query telemetry weekly, not in real-time.

3. DynamoDB for Telemetry: The $1,100/Day Mistake

10,000 devices × 1 msg/sec = 864M writes/day = ~$1,100/day on-demand DynamoDB.

Never store raw time-series telemetry in DynamoDB. Use it only for device metadata, latest-known state, and configuration. Route telemetry to Timestream (10-20x cheaper for time-series writes) or S3 ($0.023/GB/month).

4. OpenSearch for IoT Dashboards: The Always-On Cost

OpenSearch clusters run 24/7 (~$200-500/month minimum). If your dashboard usage is intermittent (operators check once/day), use:

• Timestream + Grafana (serverless-ish, cheaper for periodic access)
• S3 + Athena + QuickSight (fully serverless, pay per query)

5. Cellular Data Costs That Dwarf AWS Costs

Hardware startups often overlook this: a cellular modem (LTE-M/NB-IoT) costs $0.50-2.00/MB depending on carrier. A device sending 1KB every minute = 1.4MB/month = ~$1-3/device/month in CARRIER costs alone. At 10K devices, that's $10-30K/month before AWS sees a single byte.

Optimization: Aggregate readings on-device and send batched payloads every 5-15 minutes instead of per-reading. Compress with CBOR instead of JSON (40-60% smaller). This directly reduces your carrier bill — often your largest IoT cost at scale.

Counterintuitive Advice for IoT Startups

Don't Start with Greengrass

Greengrass adds significant operational complexity (component deployments, edge device management, Nucleus updates). Start with direct MQTT to IoT Core unless you have one of these hard requirements:

• Must operate offline (no cloud connectivity for hours/days)
• Latency < 100ms for control loops (cloud round-trip is 50-200ms)
• Bandwidth costs dominate (cellular data at $0.01/MB with high-frequency sensors)

When to add Greengrass: When your cloud ingestion bill exceeds the operational cost of managing edge infrastructure, OR when you have a hard offline/latency requirement.

One Certificate Per Device (Even If It's Painful)

Shared certificates are tempting for prototypes ("just get devices connected"). But revocation of a shared cert disconnects your entire fleet. The migration from shared → per-device certs is painful at scale. Start with per-device certs from day one using Fleet Provisioning by Claim.

Fleet Provisioning: Don't Overthink It

Critical: Always add a pre-provisioning Lambda hook to validate device serial numbers against an allow-list. Without it, anyone who reverse-engineers your firmware can provision unlimited devices.

Your Firmware Update Story Is Your Company's Survival Story

IoT startups that can't OTA update their fleet die slowly. A bug in the field with no update path means:

• Hardware recalls ($50-200/device in logistics alone)
• Customer churn from unresolvable issues
• Inability to iterate on the product post-deployment

From day one: Even if you skip everything else, implement IoT Jobs-based OTA updates with rollback. Configure abort criteria (>5% failures = halt rollout). Test the update path before shipping your first 10 devices. The cost of getting this wrong at 1,000 devices is company-ending for a hardware startup.

IoT + AI: When to Run ML at the Edge

The Hardware-Software Timing Trap

Software startups iterate weekly. Hardware startups iterate quarterly (PCB rev cycles). This mismatch kills IoT startups that plan cloud architecture in lockstep with hardware timelines.

What to do: Over-provision your cloud capabilities relative to hardware. Your first PCB will be wrong. Your second will be better. Your cloud architecture needs to absorb both without re-architecture. Specifically:

• Design topic structures that accommodate device types you haven't built yet
• Use Device Shadow for ALL configuration (don't hardcode anything on-device that might change)
• Build your provisioning flow for "devices we haven't designed" — because you'll have 3 hardware revisions running simultaneously within 18 months

The "Connected Product" vs "IoT Platform" Decision

Most IoT startups start thinking they're building a platform. They're not. They're building one connected product.

90% of seed-stage "IoT platforms" should be connected products first. Build the platform abstraction only after you have 3+ customers wanting different device types. The premature platform trap wastes 6-12 months of engineering on infrastructure your first 5 customers don't need.

Startup-Specific Gotchas: Investor & Go-To-Market

The Pilot-to-Paid Chasm

IoT startups often give away 50-200 devices as "pilots." The architecture cost at pilot scale ($50-400/month from the tables above) is trivial. But the customer expects the same architecture when they order 10,000 devices — and that's $4,000+/month.

Before the pilot: Model the cost at the customer's target fleet size. If the unit economics don't work (cloud cost per device > willingness to pay), you have a business model problem, not a technology problem. Discover this before the pilot, not after.

Hardware Margins Are Thin — Cloud Costs Eat Them

A typical hardware startup's BOM cost is $50-200/device with 40-60% gross margins on hardware sale. If your cloud cost is $5/device/month and customer pays $10/device/month for the "subscription" — your cloud COGS is 50% of recurring revenue before you pay for anything else.

Model this explicitly for investors:

• Hardware margin: X%
• Recurring revenue per device: $Y/month
• Cloud cost per device at target scale: $Z/month
• Net recurring margin: $(Y-Z)/Y

If Z > 30% of Y, optimize your architecture before scaling, not after.

The "Free Tier Pilot" Illusion

IoT Core free tier: 500,000 messages/month for 12 months. That's ~11 messages/minute across your entire fleet. With 50 pilot devices sending 1 msg/min, you burn through free tier in 7 days.

Don't promise "zero cost pilot" to customers based on free tier math. It doesn't scale to even modest pilots.

Anti-Patterns (Startup-Specific)

• Designing for 1M devices at 100 devices. The architecture for 100 devices (direct MQTT, no edge compute, DynamoDB for state) is radically different from 1M devices. Build for 10x your current fleet, not 10,000x. Premature scaling wastes months of engineering time.
• HTTP polling from battery-powered devices. A device polling every 5 seconds: 17,280 requests/day, drains battery in weeks. MQTT persistent connection: near-zero overhead when idle, battery lasts months. This is the #1 hardware startup mistake.
• No error actions on IoT Rules. Failed rule actions silently drop data. You won't know you're losing telemetry until a customer complains about missing data. Always route errors to S3 or SQS — takes 5 minutes to configure.
• Timestream with default memory retention (24h) for dashboards needing 7-day views. You'll query magnetic store (10x slower, different pricing model). Set memory retention to match your hot-query window.
• Building a "device management portal" before device #100. Your first 50 devices can be managed with AWS Console + CLI scripts. The custom portal takes 2-3 months of engineering time that should go toward the core product. Build it when operators (not engineers) need to manage the fleet.
• Choosing WiFi-only when customers have industrial sites. Consumer IoT = WiFi. Industrial/commercial IoT = often no reliable WiFi. If your customer is a factory, warehouse, or field operation, design for cellular (LTE-M/NB-IoT) from prototype. Retrofitting connectivity is a hardware redesign.
• Not budgeting for device returns and RMA. 5-10% of deployed IoT devices will have issues in year one. Your architecture needs: remote diagnostics (shadow + logs), remote remediation (OTA), and graceful decommissioning (cert revocation, thing deletion). Without these, every issue is a $50-200 truck roll or RMA.
• Shared X.509 certificates across devices. Revoking one shared cert disconnects entire fleet. One cert per device limits blast radius.

Credits-Specific Guidance

• IoT Core messaging, Rules Engine actions, and Device Shadow operations are all credit-eligible
• Timestream burns credits fast — 10K devices at 1 msg/min with 7-day memory retention = ~$2K/month in credits consumed
• During credits: use Timestream generously to validate your real-time dashboard needs. If you discover nobody looks at real-time data, switch to S3+Athena before credits expire and save $2K/month
• Greengrass has no per-device cloud cost (it's edge software) — but the devices it runs on aren't free. Factor in the $15-50/device compute module cost in your BOM

Lambda — Startup-Specific Guidance

When Lambda is the Right Default for Startups

Pre-seed to Series A: Lambda should be your default compute unless you have a reason not to use it.

• Zero cost at idle — you only pay when code runs. A startup with 10K requests/day pays ~$0.20/month.
• No infrastructure to manage during the "build fast, validate hypothesis" phase.
• AWS free tier: 1M requests + 400K GB-seconds/month — most early startups never exceed this.

The inflection point: Lambda becomes expensive relative to containers at ~$300-500/month in Lambda spend with predictable, sustained traffic. At that point, a single Fargate task running 24/7 is cheaper.

Startup Cost Traps

1. Provisioned Concurrency before you need it: Costs ~$15/month per provisioned instance even with zero traffic. Don't enable until you have latency SLAs requiring <100ms p99 cold starts AND paying customers who need them.

2. Memory over-allocation: Startups often set 1024MB "to be safe." At low traffic this barely matters, but at scale the difference between 256MB and 1024MB is 4x cost. Benchmark with AWS Lambda Power Tuning once you have real traffic.

3. Step Functions standard workflows for high-volume: Standard Workflows cost $25 per million state transitions. If you're processing events at volume, Express Workflows cost $1 per million (but max 5-min duration). Most startups should start with Standard and switch to Express when the bill surprises them.

4. VPC-attached Lambda + NAT Gateway: A NAT Gateway costs $32/month + data processing fees — often more than the Lambda itself for early startups. Use VPC endpoints ($7/month each) for S3 and DynamoDB, or keep Lambda outside the VPC entirely until you need private resource access.

Counterintuitive Startup Advice

• Monolith Lambda is fine at your stage. The "anti-pattern" of one Lambda handling multiple routes via API Gateway is actually optimal for a 1-3 person team. Split functions when: (a) you have different scaling/memory needs per route, or (b) cold starts on a bloated package exceed your latency budget. Don't prematurely decompose.

• Skip Powertools until you have production traffic. Structured logging and tracing matter when debugging distributed systems at scale. At pre-product-market-fit, console.log and CloudWatch Logs Insights are sufficient. Add Powertools when you have >5 Lambda functions in production.

• Python or Node.js, period. Unless your team is exclusively Java/Go developers, the startup hiring pool and example ecosystem for Lambda skews heavily Python/Node. Pick one and standardize. Language choice is a one-way door at the team level.

When to Graduate from Lambda

Credits-Specific Guidance

• Lambda compute is covered by AWS Activate credits. During the credits period, don't optimize Lambda cost — optimize developer velocity instead. Over-provision memory, use Provisioned Concurrency liberally, etc.
• When credits expire, expect Lambda bills to be the first "surprise" because teams never optimized during the free period. Budget 2 weeks for Lambda cost optimization before credits run out.

ARM64 (Graviton) — Just Do It

20% cheaper, often faster. No config change needed for Python/Node.js. Set arm64 on every function from day one. The only reason not to: native binary dependencies compiled for x86 (rare for startups).

Messaging — Startup Decision Guide

Stage-Based Recommendation

Pre-PMF (Seed / <$1M ARR)

• Default to SQS Standard. Don't overthink messaging architecture. A single SQS queue between your API and a worker Lambda covers 90% of early async needs.
• Skip EventBridge until you have 3+ services producing events. For 1-2 services, direct SQS/SNS is simpler and cheaper.
• Don't build event-driven microservices yet. You'll refactor your domain model 5 times before PMF. Monolith + SQS for background jobs is the right pattern.

Post-PMF / Growth ($1M-$10M ARR)

• EventBridge when you have 3+ services that react to the same business events. The content-based routing eliminates Lambda glue.
• SNS + SQS fan-out for high-throughput notification patterns (>10K events/sec).
• FIFO queues only when you have actual ordering bugs in production, not as a preventive measure. They cost more and have lower throughput (3,000 msg/sec with batching vs unlimited for Standard).

Scale ($10M+ ARR)

• EventBridge + Schema Registry for event contracts across teams.
• Consider Kinesis/MSK only for true streaming use cases (>100K events/sec sustained).

Cost Traps

Counterintuitive Advice

• Synchronous is fine at startup scale. Don't add SQS between your API and database "for decoupling" when you have 10 requests/second. It adds latency, complexity, and debugging difficulty. Add async when you have a specific scaling bottleneck.
• EventBridge Archives are not a replacement for event sourcing. The replay is useful for debugging, not for rebuilding state. If you need event sourcing, use DynamoDB Streams or build a proper event store.
• SQS FIFO's exactly-once is per message-group, not per queue. If you thought FIFO makes your whole system exactly-once, you misunderstood it. You still need idempotent consumers for Standard OR FIFO.
• DLQ without alerting is worse than no DLQ. It gives you false confidence that errors are "handled" when they're actually just accumulating silently. Set up the CloudWatch alarm on DLQ message count ON THE SAME DAY you create the DLQ.

Decision Shortcuts

"Should I use messaging here?"

• Request-response with <1s latency requirement → No, call directly
• Fire-and-forget, no response needed → Yes, SQS
• One event, multiple reactions → Yes, SNS or EventBridge
• Smoothing traffic spikes → Yes, SQS in front of worker
• "Because microservices should be decoupled" → No, that's cargo culting

"SQS Standard or FIFO?"

• Can you make your consumer idempotent? → Standard (higher throughput, lower cost)
• Is ordering a regulatory requirement? → FIFO
• Processing the same message twice causes money loss? → FIFO (with deduplication)
• You're not sure → Standard. You can always migrate later.

When to Graduate

Migration App Runner to ECS Express — Startup-Specific Guidance

Why This Matters for Startups

App Runner was the "startup-friendly" compute option. It's closing to new customers April 30, 2026. Existing services keep running, but you need a plan.

Startup Decision: What to Migrate TO

Don't assume ECS Express Mode is the answer. Choose based on your situation:

The "Do I Even Need to Migrate?" Question

Existing App Runner services continue to work. You only MUST migrate if:

• You need to create NEW services (can't after April 2026)
• You want to consolidate on fewer platforms
• App Runner's scaling model (concurrent requests) doesn't fit your workload

If your App Runner service is stable and you're not creating new ones, deprioritize this migration. Focus on product, not infrastructure churn.

Cost Comparison for Startups

Key insight: ECS Express Mode is MORE expensive than App Runner at low traffic due to the ALB baseline. If cost matters and traffic is light, Lambda might be the better migration target.

Startup Quick Migration Path

For non-critical services (dev, staging, internal tools):

1. Extract config: aws apprunner describe-service --service-arn <arn> 2. Note: image URI, port, env vars, CPU/memory 3. Create Express Mode service with same config 4. Test the *.ecs.<region>.on.aws URL 5. Update DNS or upstream references 6. Keep App Runner as rollback for 48 hours, then delete

Total time: 2-4 hours for a simple service.

Startup-Specific Gotchas

When to NOT Use Express Mode (Startup Context)

Choose standard ECS Fargate instead if:

• You need fine-grained networking control (specific subnets, custom security groups)
• You want to share an ALB you already manage
• You need sidecar containers (observability agents, proxies)
• You're running >5 services and want central control

Choose Lambda instead if:

• Your app fits Lambda constraints (stateless, <15 min, <10GB memory)
• Traffic is highly variable with long periods of zero requests
• You want $0 baseline cost
• You're willing to handle cold starts (or pay for provisioned concurrency)

Migration Azure to AWS — Startup-Specific Guidance

Why Startups Migrate from Azure to AWS

1. AWS credits — Activate Accelerate / startup program credits are often larger than Azure equivalents 2. Team hires — new engineers know AWS, not Azure 3. Ecosystem — most SaaS integrations, tutorials, and community support default to AWS 4. Specific service — need Bedrock, DynamoDB, Lambda ecosystem, or other AWS-specific capabilities

Startup Migration Decision Framework

Don't Migrate If:

• You have >$50K in remaining Azure credits with no AWS credits
• Your codebase has deep Azure SDK dependencies (>6 months to untangle)
• You're pre-PMF — migration is a distraction from finding product-market fit
• Only reason is "AWS is more popular" — that's not a technical reason

Do Migrate If:

• AWS credits significantly exceed remaining Azure credits
• Team is growing and candidates know AWS (hiring signal)
• Hitting Azure service limitations your product needs to overcome
• Want to consolidate on one cloud (already using some AWS)

Startup-Specific Migration Gotchas

Azure AD (Entra ID) — Skip the Full Migration

Enterprise migrations map Azure AD → IAM Identity Center. Startups should NOT:

• Migrate complex Conditional Access policies (rebuild from scratch with simpler IAM)
• Migrate Azure AD B2C to Cognito (re-auth your 50 users, it's faster than migrating)
• Worry about PIM → IAM equivalent (you don't need PIM at 5 engineers)

Startup approach: Set up IAM Identity Center fresh. Re-invite your 3-10 team members. Total time: 1 hour.

Cosmos DB — Don't Over-Think It

Enterprise guide says "Cosmos DB maps to 4+ services depending on API." For startups:

• If you use Cosmos DB Core (SQL API) → DynamoDB. Just port the queries.
• If you have <10GB of data → export JSON, import to DynamoDB. Done in a day.
• If you use MongoDB API → DocumentDB OR just DynamoDB (simpler, cheaper at startup scale)

Azure App Service → What to Choose on AWS

Azure Functions → Lambda

Straightforward except:

• Durable Functions → Step Functions (different programming model — budget 1-2 weeks to rewrite orchestrations)
• Bindings → Replace with explicit SDK calls. Budget 1-2 days per function with complex bindings.
• Timer triggers → EventBridge Scheduler + Lambda (easy, 30 min per function)

Startup Migration Execution Plan

The "Weekend Migration" (< 10 Azure resources, < 5GB data)

1. Friday: Set up AWS account, IAM Identity Center, basic networking 2. Saturday: Deploy compute (Lambda/ECS Express Mode/Fargate), migrate database (export/import) 3. Sunday: DNS cutover, smoke test, keep Azure running for 1 week as rollback 4. Following Friday: Delete Azure resources

The "Sprint Migration" (10-50 Azure resources, production traffic)

1. Week 1: Set up AWS foundation (accounts, networking, CI/CD) 2. Week 2: Deploy and validate in AWS (parallel running) 3. Week 3: Gradual traffic shift (Route 53 weighted routing) 4. Week 4: Decommission Azure (keep backups for 30 days)

Cost Comparison Traps

Rapid Patterns

Opinionated architecture choices for startups. These differ from standard AWS guidance.

---

Key Opinionated Choices

• API Gateway HTTP API over REST API: $1/M requests vs $3.50/M, lower latency. REST API only if you need request validation, caching, or usage plans.
• Skip OpenSearch Serverless for RAG: ~$700/month minimum. Use Bedrock Knowledge Base with managed vector store instead.
• Aurora Serverless v2 minimum is $43/month (0.5 ACU floor) — not truly zero-scale. DynamoDB is $0 at rest.
• Fargate over Lambda for multi-tenant SaaS: containers give more flexibility for tenant routing, connection pooling, long-running requests.
• Presigned S3 URLs for uploads: Skip Lambda entirely for large file uploads from mobile/web clients.

---

Pattern Graduation Triggers

These are the specific signals to move from the rapid/cheap pattern to something more robust:

---

AI-Powered App: Cost Traps

• Bedrock Knowledge Base with OpenSearch Serverless = ~$700/month minimum. Use Bedrock's managed vector store instead.
• Start with Nova Micro for classification/routing, Nova Lite for generation — cheapest Bedrock models.
• Store conversation history in DynamoDB, not in-memory (Lambda is stateless) and not S3 (too slow for chat).
• Don't build an agent unless you need tool use — InvokeModel directly is simpler and cheaper.