Before production traffic: secure IAM, network isolation, encrypted data, monitored alarms, tested backups, cost guardrails, and a runbook for common failures.
Checklist
- MFA on root and admins; no root daily use
- IAM roles for EC2/Lambda/CI—no embedded access keys
- VPC with private subnets for app and database tiers
- Security groups least privilege; no admin ports open globally
- S3 Block Public Access enabled; encryption at rest
- RDS Multi-AZ or Aurora; backup retention and restore drill completed
- CloudWatch alarms on errors, latency, CPU, billing
- AWS Budgets alerts; tagged resources for cost allocation
- CloudTrail enabled for API audit trail (awareness)
- Document runbooks: failover, key rotation, incident contacts
Cost guardrails
# Enable billing alarm (us-east-1 for billing metrics)
aws cloudwatch put-metric-alarm \
--alarm-name sandbox-billing-alert \
--metric-name EstimatedCharges \
--namespace AWS/Billing \
--statistic Maximum \
--period 86400 \
--threshold 10 \
--comparison-operator GreaterThanThreshold \
--evaluation-periods 1 \
--dimensions Name=Currency,Value=USDAdjust threshold for your sandbox. Free tier still needs monitoring—NAT gateways and EIPs add up.
Next steps
Deepen app security on Cybersecurity. Build full stacks with Django + RDS PostgreSQL. Compare managed SQL on PostgreSQL track.
Important interview questions and answers
- Q: Backup without restore test?
A: Unknown RTO—treat as incomplete disaster planning. - Q: Why CloudTrail?
A: Audit who called which AWS API—critical for security investigations.
Self-check
- List five pre-launch checks from this lesson.
- Why enable billing alarms on a sandbox account?
Tip: Tag every resource Environment=learning in sandbox to spot strays in Cost Explorer.
Interview prep
- CloudTrail?
Audit log of AWS API calls for security investigations.
- Pre-launch must?
MFA, private subnets, tested backups, alarms, no root daily use.