Deploy

Deploy on AWS

Take any application and deploy it to AWS with minimal user decisions.

Philosophy

Minimize cognitive burden. User has code, wants it on AWS. Pick the most straightforward services. Don't ask questions with obvious answers.

Workflow

1. Analyze - Scan codebase for framework, database, dependencies 2. Recommend - Select AWS services, concisely explain rationale 3. Estimate - Show monthly cost before proceeding 4. Generate - Write IaC code with security defaults applied 5. Deploy - Run security checks, then execute with user confirmation

Defaults

See defaults.md for the complete service selection matrix.

Core principle: Default to dev-sized (cost-conscious: small instance sizes, minimal redundancy, and non-HA/single-AZ defaults) unless user says "production-ready".

MCP Servers

awsknowledge

Consult for architecture decisions. Use when choosing between AWS services or validating that a service fits the use case. Helps answer "what's the right AWS service for X?"

Key topics: general for architecture, amplify_docs for static sites/SPAs, cdk_docs and cdk_constructs for IaC patterns.

awspricing

Get cost estimates. Always present costs before generating IaC so user can adjust before committing. See cost-estimation.md for query patterns.

awsiac

Consult for IaC best practices. Use when writing CDK/CloudFormation/Terraform to ensure patterns follow AWS recommendations.

Principles

• Concisely explain why each service was chosen
• Always show cost estimate before generating code
• Apply security defaults automatically (encryption, private subnets, least privilege)
• Run IaC security scans (cfn-nag, checkov) before deployment
• Don't ask "Lambda or Fargate?" - just pick the obvious one
• If genuinely ambiguous, then ask
• Never recommend AWS App Runner — it is in maintenance mode. Use ECS Express Mode instead.
• When user explicitly requests a managed application platform or signals low infrastructure involvement, route to Elastic Beanstalk

References

• Service defaults
• Security defaults
• Cost estimation patterns
• Elastic Beanstalk skill

Cost Estimation Patterns

Use the awspricing MCP server to get accurate cost estimates before generating IaC.

Workflow

1. Identify all AWS services in the architecture 2. Query pricing for each service 3. Calculate monthly estimates based on expected usage 4. Present total before proceeding

Service Codes

Fargate Pricing

Fargate charges per vCPU-hour and per GB-hour. Query with usagetype filters:

usagetype: "USE1-Fargate-vCPU-Hours:perCPU"  # vCPU pricing
usagetype: "USE1-Fargate-GB-Hours"           # Memory pricing

Typical small app (0.5 vCPU, 1GB):

• us-east-1: ~$18/month running 24/7

Aurora Serverless v2 Pricing

Aurora Serverless v2 charges per ACU-hour (Aurora Capacity Unit).

• Minimum: 0.5 ACU
• 1 ACU ≈ 2GB memory

Dev estimate (0.5-2 ACU range):

• ~$45-90/month depending on usage patterns

Production estimate (2-8 ACU range):

• ~$180-360/month depending on load

Amazon DocumentDB Serverless Pricing

Amazon DocumentDB Serverless charges per DCU-hour (DocumentDB Capacity Unit), storage (GB-month), and I/O (standard config only).

• Minimum: 0.5 DCU
• 1 DCU ≈ 2 GiB memory

Dev estimate (0.5-2 DCU range, 10GB storage):

• ~$35-120/month depending on usage patterns (scales to 0.5 DCU when idle)

Production estimate (2-8 DCU range, 100GB storage, multi-AZ):

• ~$130-400/month depending on load

Elastic Beanstalk Pricing

Elastic Beanstalk itself has no service fee. Cost equals the underlying AWS resources provisioned for the environment (EC2, ELB, EBS, CloudWatch). Query awspricing MCP server for region-accurate estimates. Approximate us-east-1 pricing:

Dev web (1x t3.small + ALB): ~$35-40/month Dev worker (1x t3.small, no ALB): ~$15-20/month Production web (4x t3.medium + ALB, Multi-AZ): ~$150-200/month

Include EBS volume costs (8GB gp3 default: ~$1/month per instance).

Quick Reference Estimates

Small web app (Fargate + Aurora Serverless v2 + ALB):

• Dev: ~$70-100/month
• Production: ~$200-400/month

Small web app (Fargate + Amazon DocumentDB Serverless + ALB):

• Dev: ~$70-155/month
• Production: ~$200-450/month

Static site / SPA (Amplify Hosting):

• Low traffic: ~$0-5/month (free tier covers most small sites)
• High traffic: ~$15-40/month

Static site (S3 + CloudFront):

• Low traffic: ~$1-5/month
• High traffic: ~$20-50/month

Serverless API (Lambda + API Gateway + DynamoDB):

• Low traffic: ~$5-20/month
• High traffic: scales with requests

Web app on Elastic Beanstalk:

• Dev (1x t3.small + ALB): ~$35-40/month
• Production (load-balanced, Multi-AZ): ~$80-200/month

Web app on EB + Aurora Serverless v2:

• Dev: ~$80-130/month
• Production: ~$200-400/month

Presenting Estimates

Always show:

1. Per-service breakdown 2. Monthly total 3. Key assumptions (e.g., "assumes 24/7 uptime", "assumes 1M requests/month") 4. Cost optimization tips if relevant

Service Defaults

Default AWS service selections. Override only when user explicitly requests alternatives.

Compute

⚠️ App Runner is in maintenance mode — AWS has moved App Runner to maintenance mode. Do not recommend App Runner for new workloads. Use ECS Express Mode instead.

Why Fargate over Lambda for web frameworks

Most web frameworks (Django, Rails, Flask with WSGI) expect long-running processes. Lambda's cold starts and request/response model require adapters and introduce latency. Fargate provides a more natural fit without framework modifications.

Why Amplify for static sites/SPAs

Amplify Hosting handles CI/CD, HTTPS, custom domains, and CDN automatically. Less configuration than S3 + CloudFront. Git-based deployments work out of the box. Use S3 + CloudFront when user needs fine-grained control over caching, edge functions, or has existing CloudFront infrastructure.

Use amplify_docs topic in awsknowledge MCP for framework-specific guidance (React, Next.js, Vue, Angular, etc.).

Why Elastic Beanstalk for managed platform deployments

Elastic Beanstalk is an application management service: the user provides code, AWS manages deployments, scaling, patching, monitoring, and health response. Choose when the user wants production-grade reliability with the lowest ongoing maintenance cost. Choose Fargate when the user wants direct container control.

Database

Why Aurora Serverless v2

Scales to near-zero in dev (0.5 ACU minimum), scales up automatically for production. Single choice works for both environments. Only use provisioned RDS if user has specific cost constraints or compliance requirements.

Why Amazon DocumentDB Serverless for MongoDB

Amazon DocumentDB Serverless is the on-demand, auto-scaling configuration of Amazon DocumentDB. It dynamically adjusts capacity based on application demand so you only pay for what you use. Ideal for dev/test, variable workloads, and new applications where capacity needs are unknown. Compatible with MongoDB 3.6, 4.0, 5.0 and 8.0 APIs. Use provisioned Amazon DocumentDB only when you have predictable, steady-state workloads or specific compliance requirements that need fixed instance sizing.

Storage

IaC

Why CDK

Most expressive, best IDE support, generates CloudFormation. TypeScript provides type safety without requiring Python/Java knowledge. If user's repo already has terraform/ or cdk.json, match existing choice.

Sizing (Dev vs Production)

Default to dev sizing unless user says "production", "prod", or "production-ready".

Security

See security.md for encryption, VPC placement, IAM, security group defaults, and pre-deployment security checks.

Security Defaults

Security configurations applied by default. Override only when explicitly requested.

Philosophy

Secure by default, right-sized by environment. Dev environments allow more permissive access for debugging. Production environments enforce strict boundaries.

Secure-by-Default Checklist

Apply these patterns automatically when generating IaC:

• [ ] Private S3 buckets - Block all public access unless explicitly serving static content
• [ ] Encryption at rest - Enable for all storage (S3, RDS, EBS, Secrets Manager)
• [ ] HTTPS enforcement - TLS 1.2+ with automatic HTTP→HTTPS redirect
• [ ] Origin Access Control - CloudFront accesses S3 via AWS internal network, not public URLs
• [ ] IAM least privilege - Minimal required permissions per service, no wildcards
• [ ] Security scanning - Detect exposed secrets before deployment
• [ ] Quality gates - Run available tests and static analysis before deploy

Encryption

Why SSE-S3 for dev, SSE-KMS for prod

SSE-S3 is zero-config and free. Production benefits from CMK for audit trails, key rotation control, and cross-account access patterns.

S3 Security

CloudFront + S3 Pattern

When serving static content via CloudFront:

• S3 bucket remains private (no public access)
• Use Origin Access Control (OAC) - CloudFront accesses S3 via internal AWS network
• Do NOT use legacy Origin Access Identity (OAI)

VPC Placement

Why private subnets for compute

Public IPs on compute resources invite direct attack. Route outbound traffic through NAT Gateway. ALB is the only public-facing component.

Dev simplification

For dev, a single-AZ VPC with 1 public + 1 private subnet is sufficient. Use awsknowledge topic vpc_patterns for multi-AZ production layouts.

IAM

Principle: Explicit grants only

Never use * for resources or actions unless unavoidable (e.g., S3 bucket contents require s3:GetObject on bucket/*). Enumerate specific ARNs. Use conditions where possible.

Consult awsiac MCP for IAM policy patterns by service.

Security Groups

Why deny-by-default

Start with no access, add only what's needed. Outbound 443 allows AWS API calls and package downloads. Lock down further for compliance if needed.

Secrets Management

Why Secrets Manager over Parameter Store for secrets

Secrets Manager provides automatic rotation, cross-account sharing, and audit logging. Parameter Store SecureString works but lacks rotation.

Always inject secrets at runtime, never bake into images.

Pre-Deployment Security Checks

Secret Detection

Before deployment, scan for exposed secrets:

• Check for hardcoded credentials, API keys, tokens
• Use git-secrets, truffleHog, or detect-secrets
• Fail deployment if secrets detected in codebase

IaC Security Scanning

Validate generated IaC before deployment:

Recommend running checkov or cfn-nag on generated templates before cdk deploy.

Quality Gates

Before deployment, run available checks:

1. Unit tests (if test suite exists) 2. Static code analysis (linters, type checkers) 3. IaC security scan 4. Secret detection scan

Logging & Monitoring

Why minimal logging in dev

Logging has cost. Dev environments rarely need audit trails. Enable VPC Flow Logs and ALB logs for production debugging and compliance.

Production Hardening Checklist

When user requests "production" or "prod", additionally enable:

• [ ] Multi-AZ for all stateful services
• [ ] VPC Flow Logs
• [ ] ALB Access Logs
• [ ] S3 Access Logs
• [ ] RDS Performance Insights
• [ ] Amazon DocumentDB profiler + audit logs exported to CloudWatch Logs
• [ ] AWS WAF on ALB (if public-facing web app)
• [ ] GuardDuty (recommend, don't auto-enable)
• [ ] Run checkov or cfn-nag before deployment

MCP References

• awsknowledge topics: vpc_patterns, iam_best_practices, security
• awsiac for CDK security constructs (L2 constructs apply many defaults)