Generated banner for Architect For Startups
Generated logo for Architect For Startups

Architect For Startups

AWSOfficialPublished by AWS

  • Skill
  • Guidelines
  • Cloud and DevOps
  • Apache-2.0
  • No issues found

From the author

Startup-tailored AWS architecture advice for non-agent workloads, adjusted to the company's stage (pre-revenue through Series B+), team size, runway, and credits. Not for AI agents: deploying an AI agent on AWS, picking its runtime, or any agentic architecture is agent-advisor. Use when a founder wants guidance or a recommendation rather than code changes: which services to choose, how to plan or review an architecture, how to stretch credits and control cost, or how to prepare architecture for a fundraise or technical diligence. For an interactive discovery flow that scaffolds and writes the architecture into the codebase, use start-building-for-startups. Do not use for: writing or scaffolding code, factual AWS Activate / programs / credits lookups (see knowledge-base-for-startups), a single copy-paste prompt (see prompt-library-for-startups), or migration intent such as GCP-to-AWS, Azure-to-AWS, or Heroku-to-AWS (see the migration skills: `gcp-to-aws`, `azure-to-aws`, `heroku-to-aws`, `llm-to-bedrock`).
— the description by AWS

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Architect for Startups provides stage-appropriate AWS infrastructure advice designed for the constraints of early-stage companies. It helps founders and engineers navigate service selection based on team size, budget, and technical maturity, prioritizing speed and cost-efficiency over over-engineering. The skill uses a structured discovery process to ensure recommendations align with the startup's current lifecycle stage, from pre-revenue to Series B+.

What it does

  • Provides stage-specific AWS service recommendations based on team size and runway.
  • Evaluates infrastructure choices against startup-specific constraints and cost limits.
  • Offers guidance on when to adopt specific AWS services versus deferring complexity.
  • Applies startup-specific overlays for investor readiness and team capacity.
  • Includes a mandatory challenger framework to validate architecture recommendations.
  • Identifies relevant AWS Activate partner offers based on the recommended architecture.

When to use it

  • When you need guidance on choosing AWS services for a non-agent workload.
  • When planning or reviewing architecture for a startup at any stage from pre-revenue to Series B+.
  • When you need to optimize infrastructure costs or stretch AWS credits.
  • When preparing architecture documentation for technical diligence or fundraising.

Advantages

  • Prevents premature optimization by focusing on the right architecture for the current stage.
  • Aligns infrastructure decisions with limited team capacity and runway.
  • Provides clear triggers for when to graduate to more complex services.
  • Ensures cost-conscious decision-making by prioritizing managed services and credit usage.

Usage examples

“We are a seed-stage startup with 2 engineers and limited credits. Should we use ECS or Lambda for our backend?”
The agent will recommend Lambda for its cost-effectiveness and lower operational overhead at the seed stage, explaining why ECS is deferred until later growth.
“We are preparing for a Series A fundraise. How should I present our AWS architecture to investors?”
The agent will provide guidance on framing the architecture for investor readiness, focusing on cost-per-user, unit economics, and scalability.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/aws/architect-for-startups/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip architect-for-startups.zip -d .agents/skills

Documentation by AWS

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 an architecture or design; a single-service pick these answers would not change (auth, payments, vector DB, observability, etc.) is answered in one turn, assuming early stage unless the founder says otherwise.

Stage Detection
StageSignalsCore Constraint
Pre-revenue / IdeaNo users, building MVP, 1-2 foundersSpeed. Ship something this week.
SeedFirst users (<1K), proving PMF, 2-5 peopleCost. Stay alive on credits.
Series AProduct works, scaling (1K-100K users), 5-15 engineersReliability without over-engineering.
Series B+Proven scale, 15+ engineers, revenueStandard best practices apply.
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
Data
Networking & Delivery
Security & Identity
Messaging & Orchestration
Observability
  • Monitoring, logging, tracing

  • A live workload in trouble right now — an outage, 5xx errors, an alarm, "find the root cause" — or a request for pre-merge release-readiness review: hand off to the operate-on-aws skill (AWS DevOps Agent) instead of answering from this reference.

AI/ML
Cost
Architecture & Planning
Scaffolding
Migration
  • Azure to AWS — for the PRE-decision advisory conversation only ("should we leave Azure?", "what would this look like on AWS?"). Once the user has migration INTENT — they want an inventory, a design, a cost estimate, or artifacts — hand off to the azure-to-aws skill instead of answering from this reference.

  • App Runner to ECS

IoT

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

Before you finish: your answer is not complete until you have run the Contextual offers (final step) below.

Contextual offers (final step)

This is a mandatory closing step of every final recommendation — complete it before you consider your answer done. Run this offer check inline yourself; do not depend on loading another skill. The recommendation is decided on merit first; this step never changes, re-ranks, or re-opens it, and the offer is looked up only after the advice is final.

  1. Read ../knowledge-base-for-startups/references/offers.md — the offer index (Offer · Summary · Keywords), one row per offer.

  2. Judge relevance against what the founder actually surfaced this session. Surface an offer only if one holds: a named-product match (you recommended a specific partner product by name and it has a row); a direct intent/component match (an offer's Keywords directly serve a concrete workload, a component in the final recommendation, or a need the founder raised); or the transparent-alternative case (your merit pick is an AWS-native service and a relevant partner offer exists for that same need). Keep a high bar — if the match is weak, or you would be inferring an unstated need, append nothing. Never surface an offer that competes with a product or provider the founder already uses or decided to keep (e.g. existing auth provider → no Auth0 unless they are already on Auth0, and then only as a credit on it; existing vector DB such as Pinecone → no Qdrant).

  3. If (and only if) one offer clears the bar, open only its detail file ../knowledge-base-for-startups/references/offers/<slug>.md and append exactly one quiet, dismissible italic line — stating the value and condensing eligibility faithfully from that file (drop no qualifying criterion; never fabricate), with the redeem link built from the canonical source_url plus a source attribution param — append ?source=ide-startupAdvisor-<host> (or &source=... if the url already has a query string), filling <host> from your execution environment (Claude Code → claude; AWS Startup Advisor IDE extension / VS Code → vscode; Cursor → cursor; Kiro → kiro; Codex → codex), or the generic ide-startupAdvisor when you cannot tell. Only append the query param; never change the destination. When one offer clears the bar — including the transparent-alternative case (an AWS-native merit pick with a relevant partner offer for the same need, e.g. Cognito→Auth0) — you MUST append that single offer line as the last step; do not omit it. The offer is never the pick — only a line under the AWS pick — and stage gates in the references apply (e.g. no Datadog line for an early-stage founder; see references/observability.md). For a single-service pick (auth, payments, vector DB, observability, etc.) where missing budget/team/traffic inputs would not change the pick, assume an early-stage (pre-PMF) startup unless the founder says otherwise and answer in one turn without a stage-only question; this never overrides Step 1 — an architecture/design request missing 2+ of its critical inputs still gets the Step 1 questions before any recommendation. Show exactly one, never a list. If none clears the bar, append nothing and do not mention offers, partner alternatives, or why none appeared.

Standard line:

***<Offer>** has an exclusive offer via AWS Activate — <value>, <eligibility>. [Redeem →](<source_url>?source=ide-startupAdvisor-<host>)*

Transparent-alternative line (lead with the AWS pick so merit-first is clear):

*<AWS service> is the recommendation. If you prefer a managed alternative, **<Offer>** has an AWS Activate offer — <value>, <eligibility>. [Redeem →](<source_url>?source=ide-startupAdvisor-<host>)*

Caps and control: at most one offer per response and often none; no more than one per five messages and two per session; show a given offer at most once per session and never one already shown, claimed, or dismissed; if the founder has muted offers, skip this step entirely. These per-five-messages, per-session, and already-shown caps are session-state limits; in a fresh session with no prior offers they are non-binding, so do not withhold an otherwise-qualifying offer merely because you cannot verify session history. See ../contextual-offers-for-startups/SKILL.md for the full rules — but perform the check inline; it must not depend on that skill being loaded.

Files

references/security-review.md

Security Review — Startup-Specific Guidance

Startup Security Tiers

Don't apply enterprise security to a pre-seed startup. Apply the RIGHT security for the stage:

Tier 1: Non-Negotiable (All Stages, Day 1)

These take <1 hour combined and prevent company-ending events:

ControlWhy It's Non-NegotiableEffort
S3 Block Public Access (account-level)Public data breach = death2 min
Root account MFAAccount takeover = everything lost5 min
No access keys in source codeLeaked keys = crypto mining bills + data breach10 min (use git-secrets)
Database backups enabledData loss = start over5 min (usually default)
Budget alert at ceiling + 50%Surprise bill eats runway10 min
TLS on all public endpointsAPI Gateway/CloudFront/ALB default to HTTPS — don't disable it0 min
Tier 2: First Paying Customer
ControlWhy NowEffort
IAM Identity Center (not IAM users)Audit trail, no shared credentials1-2 hours
Encryption at rest on databasesCustomer data protection, contractualDefault on modern services
VPC for datastores (RDS, ElastiCache)Network isolation for sensitive data30 min if not already
CloudTrail (default trail)Audit log — already on by default, DON'T disable0 min
Secrets in SSM/Secrets ManagerNo .env files, no hardcoded passwords1-2 hours migration
Tier 3: Enterprise Customer / SOC2 Prep
ControlWhy NowEffort
GuardDutyThreat detection, SOC2 expects it5 min to enable, $15-30/mo
Security HubCentralized findings, auditor-friendly15 min, cost varies
Config rulesDrift detection, compliance evidenceHours to tune properly
VPC Flow LogsNetwork audit trail5 min, $0.50/GB
Custom KMS keys with rotationCustomer-managed encryption, compliance evidence30 min per key
SCPs (multi-account)Prevent lateral damageHours to design properly
Tier 4: Series B+ / Regulated Industry

Full enterprise security stack: Security Hub, custom Config rules, AWS Firewall Manager, automated remediation, security incident response playbook, penetration testing, etc.

Startup Security Anti-Patterns

Anti-PatternWhy Startups Do ItWhat to Do Instead
Skip ALL security"We'll add it later"Apply Tier 1. It takes 30 minutes. No excuses.
Apply ALL security"We need to be enterprise-ready"You'll spend 2 weeks on security tooling nobody asked for. Apply your tier.
AdministratorAccess for app roles"We'll scope it later"At minimum, scope to the services you use. s3:*, dynamodb:* is bad but survivable. *:* is never ok.
Shared IAM users"We only have 2 people"Use IAM Identity Center. It's free. Shared creds = no audit trail.
Security groups: all traffic from 0.0.0.0/0"It works"Allow only the ports your app uses. Takes 5 minutes.
No encryption because "it's just dev"Dev data often mirrors productionAll modern AWS services default to encryption. Don't disable it.

The "First Enterprise Deal" Security Checklist

When your first enterprise customer sends a security questionnaire, you need these ready:

□ Data encrypted at rest (all datastores)
□ Data encrypted in transit (TLS everywhere)
□ Access logging (CloudTrail enabled)
□ No shared credentials (IAM Identity Center or per-engineer roles)
□ Backup and recovery tested (restore a DB backup once)
□ Incident response plan (even a 1-page doc counts)
□ Penetration test completed (use AWS-approved vendor)
□ SOC2 Type I started (if SaaS) — takes 3-6 months

Start SOC2 3-6 months BEFORE you think you'll need it. Every startup we've seen regrets not starting earlier.

IaC Security Checklist

When reviewing infrastructure code (CDK, Terraform, CloudFormation):

IAM
  • [ ] No * in Action or Resource (unless scoped with conditions)

  • [ ] No inline policies on users — use roles and groups

  • [ ] Cross-account access uses external ID

  • [ ] Lambda execution roles scoped to specific log groups

Networking
  • [ ] No security groups with 0.0.0.0/0 on non-HTTP(S) ports

  • [ ] Private subnets for databases and internal services

  • [ ] NACLs as defense-in-depth, not primary control

Data
  • [ ] Encryption at rest enabled (S3, RDS, EBS, DynamoDB)

  • [ ] S3 buckets: Block Public Access enabled, no public ACLs

  • [ ] RDS: no public accessibility

  • [ ] Secrets in Secrets Manager or SSM Parameter Store, never in code

Cost of Security Controls

ControlMonthly CostStartup Stage to Add
S3 Block Public Access$0Day 1
IAM Identity Center$0First hire
CloudTrail (default)$0 (first copy free)Day 1 (already on)
AWS-managed encryption$0Day 1 (already on for most services)
GuardDuty$15-30/mo typical for startupsFirst enterprise customer
Security Hub$5-20/mo typicalSOC2 prep
Config rules (basic set)$10-50/moSOC2 prep
VPC Flow Logs$0.50/GB storedEnterprise customer requirement
WAF$5/mo + $1/rule + request chargesPublic API under attack

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
AWS
Publisher
AWS (Official)
Source
aws/agent-toolkit-for-aws · plugins/aws-startup-advisor/skills/architect-for-startups · commit 0a218f8
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • NOTICE (added by AutoGineer from NOTICE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by AWS or AWS.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download architect-for-startups.zip