The AWS Power User Playbook

AWS has over 200 services. The good news: most real-world applications use 5-10 of them. The overwhelming feeling you get navigating the AWS console for the first time is normal — the console is genuinely poorly organized, the naming is cryptic, and the pricing documentation is a maze. This guide cuts through to what actually matters for the majority of use cases, from a solo developer deploying their first app to an engineering team scaling a production system.

Getting Started: First Account Setup

Don't just sign up and start clicking. The first 30 minutes you spend on account configuration will save you from expensive surprises and security incidents.

The 5-Minute Security Checklist Before Anything Else

1. ENABLE MFA ON ROOT ACCOUNT (mandatory)
   → AWS Console → Your account → Security credentials
   → Never use root credentials for day-to-day work
   → Use root ONLY for account-level tasks (billing, closing account)

2. CREATE AN IAM USER for your work
   → Attach policies: AdministratorAccess (for now, tighten later)
   → Generate access keys ONLY if programmatic access is needed
   → Never store access keys in code or commit to git

3. SET UP AWS BUDGETS (do this before anything else)
   → Billing → Budgets → Create budget
   → Set alerts at $10, $50, $100/month
   → Email alert to your billing email
   → This is the single most important "no surprises" step

4. ENABLE CLOUDTRAIL
   → Creates an audit log of all API calls
   → Free tier: 90 days of management event history
   → Critical for debugging "who deleted that resource" incidents

5. CHECK DEFAULT VPC SETTINGS
   → EC2 → Security Groups → Default security group
   → Ensure inbound rules don't allow 0.0.0.0/0 on all ports

Core Services: EC2, S3, Lambda, RDS

These four services handle 80% of what most applications need. Understanding their strengths and limitations is foundational.

EC2: Virtual Machines in the Cloud

EC2 is AWS's virtual machine service. You choose the instance type (CPU/RAM), operating system, and storage. Pay by the hour (or second for Linux).

Instance type quick guide:

• t3/t4g (burstable): Start here for web apps, APIs, dev environments. CPU "bursts" above baseline for short periods — great for variable workloads, cheap ($0.008-0.16/hour).
• m6i/m7i (general purpose): Production web servers and application servers with consistent CPU needs. No bursting — predictable performance.
• c6i/c7i (compute optimized): CPU-intensive work: video encoding, batch processing, ML inference.
• r6i/r7i (memory optimized): Databases, caching, in-memory analytics. When your workload needs more RAM than a standard instance provides.
• p3/p4/g4 (GPU): ML training, graphics, CUDA workloads. Expensive. Only use when you actually need GPU.

S3: Object Storage

S3 is one of AWS's most reliable and most misunderstood services. It's not a filesystem — it's an object store. Objects are stored with unique keys; there's no real directory structure (the "/" in key names is cosmetic).

KEY S3 CONCEPTS:
Bucket: Container for objects (one bucket per project/environment is common)
Object: File + metadata, identified by key
Prefix: Simulated "folder" using "/" in key names
Storage class: Standard, Intelligent-Tiering, Glacier, etc.

CRITICAL BUCKET SETTINGS:
✓ Block all public access (unless you're hosting a static website)
✓ Enable versioning for important buckets (recovers deleted objects)
✓ Enable server-side encryption (SSE-S3 or SSE-KMS)
✓ Set lifecycle policies to move old objects to cheaper storage
✓ Enable access logging for security auditing

S3 STORAGE CLASSES (when to use each):
Standard: $0.023/GB — active, frequently accessed data
Intelligent-Tiering: ~$0.023/GB — automatic tier shifting, good for unpredictable access
Standard-IA: $0.0125/GB — accessed monthly, retrieval fee applies
Glacier Instant: $0.004/GB — accessed quarterly
Glacier Deep Archive: $0.00099/GB — rarely accessed, 12-48hr retrieval

Lambda: Serverless Functions

Lambda runs code without managing servers. You write a function, deploy it, and AWS handles scaling, availability, and infrastructure. You pay only when code runs — idle functions cost nothing.

LAMBDA LIMITS TO KNOW:
Max execution time: 15 minutes per invocation
Max memory: 10GB
Max package size: 50MB (250MB unzipped)
Concurrency: 1,000 concurrent executions by default (can be increased)

WHEN LAMBDA WINS:
- Event-driven tasks (S3 file processing, DynamoDB streams)
- API backends with variable traffic
- Scheduled jobs (replace cron servers)
- Webhooks and real-time data processing
- Tasks that run infrequently (cold start is acceptable)

WHEN LAMBDA LOSES:
- Long-running processes (over 15 min)
- Very latency-sensitive requests (cold starts add 100ms-1s)
- Workloads requiring persistent connections (WebSockets, streaming)
- GPU workloads

RDS: Managed Relational Databases

RDS manages PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, and Amazon Aurora. AWS handles backups, patches, failover, and replication. You pay more than self-managed but save significant operational overhead.

Aurora specifically deserves attention: it's AWS's MySQL/PostgreSQL-compatible database with up to 3x MySQL performance and built-in clustering. For new projects choosing between RDS PostgreSQL and Aurora PostgreSQL, Aurora wins for production workloads — the performance and HA advantages outweigh the slightly higher cost.

Cost Optimization

AWS cost optimization is a discipline. Left unmanaged, AWS bills grow continuously as teams add resources and forget to clean up. Here are the highest-leverage optimizations:

Savings Plans and Reserved Instances

The practical strategy: run Spot Instances for batch workloads and dev/test environments. Use Compute Savings Plans for baseline production load you know will exist. Use On-Demand for the variable portion. Never over-reserve — Savings Plans are more flexible than Reserved Instances and usually the right choice for most teams.

The Quick-Win Cost Cuts

• Delete unused EBS volumes: When you terminate an EC2 instance, the attached EBS volume persists unless you set "delete on termination." These orphaned volumes accumulate. Run: aws ec2 describe-volumes --filters "Name=status,Values=available" to find them.
• Release unused Elastic IPs: Elastic IPs cost $0.005/hour when NOT attached to a running instance. It adds up.
• Enable S3 Intelligent-Tiering: For S3 buckets with mixed access patterns, Intelligent-Tiering automatically moves objects to cheaper storage tiers after 30 days of inactivity. Zero retrieval fee. Usually saves 30-50% on S3 costs for typical application buckets.
• Right-size instances: AWS Compute Optimizer (free service) analyzes EC2, Lambda, and RDS usage and recommends right-sized instances. Most accounts have 20-40% of instances significantly over-provisioned.
• Use CloudFront in front of S3: S3 data transfer to the internet costs $0.09/GB. CloudFront's first 1TB/month is free (then $0.085/GB), and cached content is even cheaper. For any static assets, CloudFront in front of S3 reduces both cost and latency.

Security Best Practices

IAM: Least Privilege Is Not Optional

GOLDEN RULES FOR IAM:
1. No root credentials for applications or scripts
2. Each service/application gets its own IAM role with minimal permissions
3. Use IAM roles for EC2 instances (not access keys stored on the instance)
4. Rotate access keys every 90 days (or better, eliminate them via roles)
5. Use AWS Organizations + Service Control Policies for multi-account setups
6. Enable AWS Config to detect IAM policy drift

PERMISSION BOUNDARY PATTERN:
Application needs to read from S3 bucket "my-app-data":
→ Create IAM policy: Allow s3:GetObject on arn:aws:s3:::my-app-data/*
→ Attach to IAM role (not user)
→ Assign role to EC2 instance profile or Lambda execution role
→ Application code uses the role automatically — no keys needed

Network Security

• VPC design: Public subnets (load balancers only), private subnets (application servers), isolated subnets (databases). Traffic from the internet should hit load balancers only — never expose application servers or databases directly.
• Security Groups are stateful firewalls: Inbound rules only allow what you explicitly permit. If port 443 isn't in the inbound rules, HTTPS traffic can't reach the instance. Common mistake: opening 0.0.0.0/0 on ports 22 (SSH) or 3389 (RDP) to "make it easier." Don't. Use AWS Systems Manager Session Manager instead — no open ports needed.
• Enable GuardDuty: AWS's threat detection service monitors CloudTrail, VPC Flow Logs, and DNS logs for suspicious patterns. $1-3/month for small accounts. Catches credential theft, cryptomining, and data exfiltration attempts. Always worth it.

Serverless Architecture

Serverless on AWS isn't just Lambda — it's a pattern. The full serverless stack for a typical web API:

SERVERLESS API PATTERN:
Client → API Gateway → Lambda → DynamoDB

Benefits:
- Zero servers to manage
- Automatic scaling (Lambda scales to thousands of concurrent requests)
- Pay only for actual usage ($0 when idle)
- No patching, no capacity planning

REAL COST EXAMPLE (medium traffic API, 1M requests/month):
API Gateway: 1M × $3.50/million = $3.50
Lambda: 1M invocations × 200ms × 512MB = ~$0.83
DynamoDB (on-demand): depends on read/write volume, ~$5-20
Total: ~$10-25/month vs $50-150+/month for equivalent EC2 setup

WHEN SERVERLESS FALLS SHORT:
- Latency requirements under 50ms (cold starts)
- Long-running processes (ETL jobs, video processing)
- Stateful connections (use ECS/EC2 instead)
- Complex in-process caching needs

AWS SAM and CDK: Infrastructure as Code

If you're doing anything beyond a single Lambda function, use Infrastructure as Code (IaC). Two options:

• AWS SAM (Serverless Application Model): YAML templates purpose-built for serverless. Simpler than CloudFormation for Lambda/API Gateway/DynamoDB patterns. Excellent for getting started.
• AWS CDK (Cloud Development Kit): Write infrastructure in TypeScript, Python, or Java. More powerful, more testable, better for complex applications. The direction AWS is pushing for new development.

IaC isn't optional for production — it's the difference between reproducible deployments and "I don't remember why I changed that setting six months ago."

vs Google Cloud vs Azure

Pricing Traps to Avoid

These are the charges that surprise people most often:

• Data transfer OUT to internet: Ingress is free. Egress costs $0.09/GB. Moving 1TB of data out per month = $90/month. For high-egress workloads, use CloudFront (cheaper rates, caching) or consider if you're in the right region.
• NAT Gateway: $0.045/hour ($32/month) PLUS $0.045/GB processed. A NAT Gateway processing 1TB/month costs $77/month. Use VPC Endpoints instead for S3, DynamoDB, and other AWS services to avoid routing traffic through NAT.
• EC2 instances left running: Set up AWS Instance Scheduler to stop dev/staging instances outside business hours. A t3.large running 24/7 costs $60/month; stopped nights and weekends, it's $22/month.
• RDS storage autoscaling: RDS can auto-scale storage, but scaling down requires snapshot + restore. Teams accumulate large RDS instances without realizing storage isn't elastic downward.
• CloudWatch detailed monitoring: Enabled by default on some services, $0.30/metric/month extra. Audit your CloudWatch metrics and alarms quarterly.

Frequently Asked Questions