Deploy

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)