🚀 AWS Mastery Guide: 100 Interview Questions for Senior Backend Developers
🚀 Backend Developer | Tech Enthusiast | Tech Blogger
I’m a passionate backend developer with 3+ years of experience building scalable systems and efficient APIs using the MERN stack. I advocate for clean code, maintainable architectures, and lifelong learning. Through blogs and videos, I simplify tech concepts, share insights on Node.js, system design, and interview prep, and inspire others to excel in software development.
Let’s connect and build something impactful together!
Author : Bodheesh vc
Your comprehensive preparation guide for AWS EC2, S3, Route 53, and IAM - tailored for professionals with 4+ years of experience
📋 Table of Contents
ec2
☁️ PART 1: AWS EC2 (Elastic Compute Cloud)
Questions 1-30
Q1: What is Amazon EC2, and how does it differ from traditional on-premises infrastructure?
📖 Detailed Explanation:
Amazon EC2 (Elastic Compute Cloud) is a web service that provides resizable compute capacity in the cloud. It allows you to launch virtual servers (instances) on-demand, scale capacity up or down automatically, and pay only for what you use.datacamp+1
Key Characteristics:
Virtual machines running on AWS global infrastructure
Multiple instance types optimized for different workloads (compute, memory, storage, GPU)
Pay-as-you-go pricing with options for Reserved Instances and Spot Instances
Launch instances in minutes vs. weeks for physical servers
Elastic scaling through Auto Scaling Groups
✅ Pros:
Capital to Operating Expense: No upfront hardware investment
Elasticity: Scale from 1 to 10,000+ instances based on demand
Global Reach: Deploy in 33+ regions worldwide within minutes
No Capacity Planning: Avoid over-provisioning or under-provisioning
Quick Experimentation: Test new configurations without hardware commitment
❌ Cons:
Ongoing costs: Can exceed on-premises costs if not optimized
Data transfer costs: Egress charges for outbound traffic
Learning curve: Requires cloud expertise for optimal configuration
Vendor lock-in: Migration complexity with AWS-specific features
Performance variability: Shared infrastructure can cause "noisy neighbor" issues
💼 Real-World Example:
Netflix migrated from on-premises data centers to AWS EC2, deploying over 100,000 EC2 instances across multiple regions. This enabled:
99.99% availability during peak viewing times (holidays, major releases)
Elastic scaling: Automatically scale from baseline 50,000 instances to 100,000+ during peak hours
Global expansion: Launch in new countries within weeks vs. years
Cost savings: 30% reduction in infrastructure costs through Reserved Instances and Spot Instances
Innovation velocity: Deploy new features daily vs. quarterly release cycles
Their architecture uses:
M5 instances for application servers (balanced compute/memory)
C5 instances for encoding services (compute-optimized)
R5 instances for caching layers (memory-optimized)
Auto Scaling to handle traffic spikes during new season releases.simplilearn+1
Q2: Explain the different EC2 instance types and when to use each.
📖 Detailed Explanation:
AWS offers 500+ instance types organized into families, each optimized for specific workload characteristics:finalroundai+1
Instance Families:
1. General Purpose (T3, T4g, M5, M6i)
vCPUs: 2-96
Memory: 0.5 GB to 384 GB
Use cases: Web servers, small databases, development environments
Burstable Performance (T instances): Accumulate CPU credits during idle time
2. Compute Optimized (C5, C6i, C7g)
vCPUs: 2-192
Memory: 4 GB to 384 GB
High CPU-to-memory ratio: 1:2
Use cases: Batch processing, media transcoding, high-performance web servers, scientific modeling
3. Memory Optimized (R5, R6i, X2iedn)
vCPUs: 2-128
Memory: 16 GB to 4 TB
High memory-to-CPU ratio: 1:8 to 1:32
Use cases: In-memory databases (Redis, Memcached), real-time big data analytics, SAP HANA
4. Storage Optimized (I3, I4i, D2)
vCPUs: 2-128
Local NVMe SSD storage: Up to 60 TB
Use cases: NoSQL databases (Cassandra, MongoDB), data warehousing, distributed file systems
5. Accelerated Computing (P4, G5, Inf1)
GPUs/Inference accelerators
Use cases: Machine learning training/inference, video rendering, high-performance computing
✅ Pros by Type:
General Purpose:
Cost-effective for varied workloads
T instances: 40% cost savings with burstable performance
Compute Optimized:
25% better price-performance for CPU-intensive tasks
Ideal for consistent high CPU utilization
Memory Optimized:
50% faster in-memory database performance
Reduce database licensing costs (fewer cores)
❌ Cons by Type:
General Purpose:
Suboptimal for specialized workloads
T instances: Poor performance if credits exhausted
Compute Optimized:
20-30% more expensive than general purpose
Overkill for I/O-bound applications
Memory Optimized:
40-60% more expensive than compute-optimized
Wasted resources if memory not fully utilized
💼 Real-World Example:
E-commerce platform architecture with optimized instance selection:
textFrontend Layer:
- ALB distributing traffic
- 20x t3.medium instances (Auto Scaling 10-50)
- Cost: $30/month each
- Handles web traffic with burst capacity
- 70% cost savings vs. m5.large
Application Layer:
- 10x c5.xlarge instances (CPU-intensive order processing)
- Cost: $123/month each
- Processes 50,000 orders/day
- 40% faster than m5.xlarge
Caching Layer:
- 3x r5.large instances (Redis cluster)
- Cost: $126/month each
- 26 GB memory per node
- 99.9% cache hit rate
- Reduced database load by 80%
Database Layer:
- RDS r5.4xlarge (128 GB memory)
- Primary + Read Replica
- Handles 10M queries/day
Analytics Layer:
- 5x i3.2xlarge instances (Elasticsearch)
- 1.9 TB NVMe storage each
- Sub-second search queries on 500M documents
Result:
- 45% cost reduction vs. uniform m5.xlarge deployment
- 60% performance improvement for compute-intensive tasks
- Black Friday scaling: 10 to 50 instances in 5 minutes
- Annual savings: $185,000
Cost Comparison (Monthly):
All m5.large: $69 × 100 instances = $6,900
Optimized mix: $3,800 (45% savings)
Performance improvement: 60% faster order processing.interviewbit+2
Q3: What are EC2 pricing models? When would you use each?
📖 Detailed Explanation:
AWS offers four pricing models for EC2, each suited for different usage patterns and cost optimization strategies:datacamp+1
1. On-Demand Instances
Pay by the second (Linux/Windows after first minute)
No upfront commitment
Price: Baseline rate (e.g., t3.medium = $0.0416/hour)
2. Reserved Instances (RI)
1 or 3-year commitment
Discount: 40-75% off On-Demand prices
Payment options:
All Upfront: Maximum discount (75%)
Partial Upfront: Moderate discount (50%)
No Upfront: Minimal discount (40%)
Types:
Standard RI: Fixed instance type/region
Convertible RI: Change instance family (54% discount)
3. Spot Instances
Bid on unused capacity
Discount: Up to 90% off On-Demand
Interruption: AWS can terminate with 2-minute warning
Ideal for: Fault-tolerant, stateless workloads
4. Savings Plans
Commitment to $ amount/hour (e.g., $10/hour)
Discount: Up to 72% off On-Demand
Flexibility: Automatically applies to EC2, Lambda, Fargate
Types:
Compute Savings Plans: Most flexible
EC2 Instance Savings Plans: Specific family/region
✅ Pros:
On-Demand:
Maximum flexibility
No long-term commitment
Ideal for unpredictable workloads
Reserved Instances:
Massive cost savings (75%)
Capacity reservation
Predictable billing
Spot Instances:
Lowest cost (90% discount)
Scale to massive capacity
Perfect for batch jobs
Savings Plans:
72% discount with flexibility
Automatically optimizes
No instance type lock-in
❌ Cons:
On-Demand:
Highest cost (baseline rate)
No discounts for steady usage
Reserved Instances:
Requires accurate capacity planning
Wasted money if underutilized
Less flexibility (Standard RI)
Spot Instances:
Unpredictable interruptions
Requires fault-tolerant architecture
Not suitable for critical workloads
Savings Plans:
Still requires commitment
28% less discount than RI (All Upfront)
💼 Real-World Example:
SaaS company with 1000 EC2 instances optimizing costs:
Original Architecture (100% On-Demand):
800x m5.large (baseline workload): $69 × 800 = $55,200/month
200x m5.large (variable traffic): $69 × 200 = $13,800/month
Total: $69,000/month = $828,000/year
Optimized Architecture:
textBaseline Workload (70% - Always Running):
- 700x m5.large Reserved Instances (3-year, All Upfront)
- Cost: $17.25/month each (75% discount)
- Monthly: 700 × $17.25 = $12,075
- Upfront: $145,000 (amortized to $4,028/month)
- Effective monthly: $16,103
Predictable Scaling (20% - Business Hours):
- 200x m5.large Savings Plans (1-year)
- Cost: $27.60/month each (60% discount)
- Monthly: 200 × $27.60 = $5,520
Traffic Spikes (10% - Unpredictable):
- 50x m5.large On-Demand
- Cost: $69 × 50 = $3,450/month
Batch Processing (Overnight Jobs):
- 300x m5.large Spot Instances (4 hours/night)
- Spot price: $7/month (90% discount)
- Cost: 300 × $7 = $2,100/month
New Total Cost:
RI: $16,103/month
Savings Plans: $5,520/month
On-Demand: $3,450/month
Spot: $2,100/month
Total: $27,173/month = $326,076/year
Savings: $501,924/year (61% reduction)
Additional Benefits:
Capacity reservation for critical workloads (RI)
Flexibility to change instance types (Savings Plans)
5x capacity for batch jobs at minimal cost (Spot)
Handled Black Friday 3x traffic spike without cost explosion
Implementation Strategy:
Analyzed 6-month usage patterns
Reserved 70% baseline capacity (RI)
Savings Plans for predictable scaling
On-Demand for burst capacity
Spot for fault-tolerant workloads (data processing, testing)
Risk Mitigation:
Implemented Spot Fleet with diversification (5 instance types)
Checkpointing for batch jobs (resume after interruption)
CloudWatch alarms for Spot interruptions.finalroundai+2
Q4: Explain EC2 Auto Scaling. How would you design an Auto Scaling strategy for a high-traffic web application?
📖 Detailed Explanation:
EC2 Auto Scaling automatically adjusts the number of EC2 instances based on demand, ensuring application availability while optimizing costs:simplilearn+2
Core Components:
1. Launch Template/Configuration
AMI ID, instance type, security groups
User data script for initialization
IAM role, key pair
2. Auto Scaling Group (ASG)
Minimum: Baseline capacity (always running)
Desired: Target capacity
Maximum: Upper limit to control costs
Availability Zones: Multi-AZ for high availability
3. Scaling Policies
a) Target Tracking Scaling
Maintain metric at target value
Example: CPU utilization at 70%
AWS automatically adjusts capacity
b) Step Scaling
Add/remove instances based on thresholds
Example: +2 instances if CPU > 80%, +5 if CPU > 90%
c) Simple Scaling
Single scaling adjustment
Cooldown period prevents flapping
d) Scheduled Scaling
Predictable traffic patterns
Example: Scale up weekdays 8 AM, scale down 6 PM
4. Health Checks
EC2 status checks (instance/system)
ELB health checks (application-level)
Automatic replacement of unhealthy instances
✅ Pros:
Cost optimization: Scale down during low traffic (40-60% savings)
High availability: Replace failed instances automatically
Performance: Handle traffic spikes without manual intervention
No capacity planning: Automatically adjust to demand
Multi-AZ: Built-in redundancy across availability zones
❌ Cons:
Cold start time: Instances take 2-5 minutes to become available
Over-scaling: Aggressive policies can cause unnecessary scaling
Cooldown complexity: Requires tuning to prevent thrashing
Cost spikes: Unexpected traffic can trigger expensive scaling
State management: Stateless architecture required
💼 Real-World Example:
News website with unpredictable traffic (viral articles drive 50x traffic spikes):
Architecture Design:
textLaunch Template:
AMI: Amazon Linux 2023 (custom with pre-baked app)
Instance Type: t3.medium (baseline), c5.large (peak)
User Data:
- Install application
- Configure monitoring agent
- Register with service discovery
Auto Scaling Group:
Minimum: 5 instances (baseline)
Desired: 10 instances (normal traffic)
Maximum: 100 instances (viral spike protection)
Availability Zones: 3 AZs (us-east-1a, 1b, 1c)
Health Check:
- Type: ELB + EC2
- Grace Period: 300 seconds
- Unhealthy Threshold: 2 consecutive failures
Scaling Policies:
1. Target Tracking (Primary):
- Metric: ALB Request Count Per Target
- Target: 1000 requests/instance
- Warmup: 180 seconds
2. Step Scaling (Aggressive for spikes):
- CPU > 60%: +2 instances
- CPU > 75%: +5 instances
- CPU > 85%: +10 instances
- CPU < 40%: -1 instance (300s cooldown)
3. Scheduled Scaling:
- Weekdays 6 AM: Min=10, Max=150
- Weekdays 11 PM: Min=5, Max=50
- Weekends: Min=5, Max=80
4. Predictive Scaling:
- ML model analyzes 14-day traffic patterns
- Pre-scales before expected traffic
- Reduces cold-start impact
Load Balancer:
Type: Application Load Balancer
Listeners:
- HTTP:80 (redirect to HTTPS)
- HTTPS:443
Target Group:
- Health Check: /health (200 OK)
- Deregistration Delay: 30s
- Stickiness: Disabled (stateless)
CloudWatch Alarms:
- High CPU (> 80%): Alert ops team
- Instances approaching max: Budget warning
- Failed health checks: Investigate ASG issues
Implementation Details:
python# Custom scaling metric: Application Queue Depth
import boto3
cloudwatch = boto3.client('cloudwatch')
autoscaling = boto3.client('autoscaling')
def publish_custom_metric():
"""Publish queue depth for scaling decisions"""
queue_depth = get_pending_jobs() # From application
cloudwatch.put_metric_data(
Namespace='CustomApp',
MetricData=[{
'MetricName': 'QueueDepth',
'Value': queue_depth,
'Unit': 'Count'
}]
)
# Target Tracking Scaling Policy
autoscaling.put_scaling_policy(
AutoScalingGroupName='web-app-asg',
PolicyName='queue-depth-scaling',
PolicyType='TargetTrackingScaling',
TargetTrackingConfiguration={
'CustomizedMetricSpecification': {
'MetricName': 'QueueDepth',
'Namespace': 'CustomApp',
'Statistic': 'Average'
},
'TargetValue': 100.0 # 100 jobs per instance
}
)
Real-World Results:
Normal Traffic (10K concurrent users):
Baseline: 10 instances
Cost: $300/month
Response time: 150ms
Viral Article Published (500K concurrent users in 10 minutes):
Scaled: 10 → 85 instances in 8 minutes
Peak instances: 85 (15 minutes duration)
Response time: Maintained at 180ms (20% degradation acceptable)
Zero downtime
Cost for spike: $42 (85 instances × 1 hour × $0.0416 × 3 AZs)
Annual Metrics:
Uptime: 99.97%
Auto-healing: 47 failed instances replaced automatically
Cost optimization: 52% savings vs. static 50-instance deployment
Traffic spikes handled: 23 viral events (no manual intervention)
False scales: 3 (tuned cooldown from 60s to 300s)
Optimization Techniques:
Pre-baked AMIs: Reduced launch time from 5 minutes to 90 seconds
Mixed Instance Policy: 70% On-Demand + 30% Spot (20% cost reduction)
Lifecycle Hooks: Graceful shutdown (drain connections before termination)
Warm Pools: Kept 5 pre-initialized instances in stopped state (instant scaling)
Predictive Scaling: ML model predicted morning traffic spikes (pre-scaled 5 minutes early).finalroundai+2
Q5: What are EC2 Security Groups and NACLs? How do they differ?
📖 Detailed Explanation:
Security Groups and Network ACLs (NACLs) are two layers of security for EC2 instances, providing defense-in-depth:interviewbit+1
Security Groups (Instance-Level Firewall):
Characteristics:
Stateful: Return traffic automatically allowed
Instance-level: Attached to ENI (network interface)
Default: Deny all inbound, allow all outbound
Rules: Only ALLOW rules (no explicit DENY)
Evaluation: All rules evaluated before decision
Limit: 5 security groups per instance, 60 rules per group
Example Security Group Rules:
textInbound:
- Type: HTTP, Protocol: TCP, Port: 80, Source: 0.0.0.0/0
- Type: HTTPS, Protocol: TCP, Port: 443, Source: 0.0.0.0/0
- Type: SSH, Protocol: TCP, Port: 22, Source: 10.0.0.0/8 (internal only)
- Type: Custom TCP, Port: 3000, Source: sg-12345678 (from ALB)
Outbound:
- Type: All Traffic, Protocol: All, Port: All, Destination: 0.0.0.0/0
Network ACLs (Subnet-Level Firewall):
Characteristics:
Stateless: Separate inbound/outbound rules required
Subnet-level: Applies to all instances in subnet
Default: ALLOW all inbound/outbound
Custom: DENY all by default (must explicitly allow)
Rules: Both ALLOW and DENY rules
Evaluation: Rules processed in order (lowest rule number first)
Limit: 20 rules per NACL (increasable to 40)
Example NACL Rules:
textInbound:
Rule 100: ALLOW HTTP (80) from 0.0.0.0/0
Rule 110: ALLOW HTTPS (443) from 0.0.0.0/0
Rule 120: ALLOW Ephemeral Ports (1024-65535) from 0.0.0.0/0
Rule 130: DENY SSH (22) from 0.0.0.0/0 (block external SSH)
Rule *: DENY All
Outbound:
Rule 100: ALLOW HTTP (80) to 0.0.0.0/0
Rule 110: ALLOW HTTPS (443) to 0.0.0.0/0
Rule 120: ALLOW Ephemeral Ports (1024-65535) to 0.0.0.0/0
Rule *: DENY All
✅ Pros:
Security Groups:
Stateful: Easier to configure (no return traffic rules)
Dynamic: Can reference other security groups
Granular: Per-instance control
Simple troubleshooting: Clear allow-only rules
NACLs:
Explicit DENY: Block specific IPs/ranges
Subnet-wide: Protect all instances automatically
Additional layer: Defense-in-depth security
Rule ordering: Flexible traffic control
❌ Cons:
Security Groups:
No DENY rules: Cannot explicitly block specific IPs
Soft limit: 5 SG per instance can be restrictive
Troubleshooting: Multiple SGs can complicate debugging
NACLs:
Stateless: Must configure return traffic explicitly
Rule limits: 20 rules can be insufficient for complex scenarios
Rule ordering: Easy to misconfigure (wrong order)
Ephemeral ports: Must allow broad range (1024-65535)
💼 Real-World Example:
Multi-tier web application security architecture:
Architecture:
textInternet → ALB (Public Subnet) → App Servers (Private Subnet) → RDS (Data Subnet)
Security Group Design:
text1. ALB Security Group (sg-alb):
Inbound:
- HTTP (80) from 0.0.0.0/0
- HTTPS (443) from 0.0.0.0/0
Outbound:
- All traffic to sg-app (application security group)
2. Application Security Group (sg-app):
Inbound:
- Port 3000 from sg-alb (only ALB can access)
- SSH (22) from sg-bastion (bastion host only)
Outbound:
- PostgreSQL (5432) to sg-db
- HTTPS (443) to 0.0.0.0/0 (external APIs)
3. Database Security Group (sg-db):
Inbound:
- PostgreSQL (5432) from sg-app (only app servers)
- PostgreSQL (5432) from sg-bastion (admin access)
Outbound:
- None (deny all)
4. Bastion Security Group (sg-bastion):
Inbound:
- SSH (22) from 203.0.113.0/24 (office IP)
Outbound:
- SSH (22) to sg-app and sg-db
NACL Design (Additional Layer):
textPublic Subnet NACL:
Inbound:
Rule 100: ALLOW HTTP/HTTPS from 0.0.0.0/0
Rule 110: ALLOW Ephemeral (1024-65535) from 0.0.0.0/0
Rule 200: DENY SSH from 0.0.0.0/0 (block brute force)
Rule *: DENY All
Outbound:
Rule 100: ALLOW HTTP/HTTPS to 0.0.0.0/0
Rule 110: ALLOW Custom (3000) to 10.0.2.0/24 (app subnet)
Rule 120: ALLOW Ephemeral (1024-65535) to 0.0.0.0/0
Rule *: DENY All
Private Subnet NACL:
Inbound:
Rule 100: ALLOW Custom (3000) from 10.0.1.0/24 (ALB subnet)
Rule 110: ALLOW SSH from 10.0.3.0/24 (bastion subnet)
Rule 120: ALLOW Ephemeral from 0.0.0.0/0
Rule *: DENY All
Outbound:
Rule 100: ALLOW PostgreSQL to 10.0.4.0/24 (database subnet)
Rule 110: ALLOW HTTPS to 0.0.0.0/0 (external APIs)
Rule 120: ALLOW Ephemeral to 0.0.0.0/0
Rule *: DENY All
Database Subnet NACL:
Inbound:
Rule 100: ALLOW PostgreSQL from 10.0.2.0/24 (app subnet)
Rule 110: ALLOW PostgreSQL from 10.0.3.0/24 (bastion subnet)
Rule *: DENY All
Outbound:
Rule 100: ALLOW Ephemeral to 10.0.2.0/24 (app subnet)
Rule 110: ALLOW Ephemeral to 10.0.3.0/24 (bastion subnet)
Rule *: DENY All
Security Incident - Before NACLs:
Attack: Brute force SSH attacks from 5,000+ IPs
Impact: 2M failed login attempts in 24 hours
CPU Load: 40% increase on bastion host
Solution: Security Group allowed SSH from 0.0.0.0/0
Security Improvement - After NACLs:
NACL Rule 200: Deny SSH from internet to public subnet
Result: Attacks blocked at subnet level (before reaching instances)
CPU Savings: Eliminated 2M connection attempts
Additional Protection: Blocked 3 DDoS attempts (NACL explicit deny for malicious IPs)
Best Practices Implemented:
Least Privilege: Only necessary ports opened
Defense-in-Depth: Security Groups + NACLs
Bastion Host: Centralized SSH access point
No Public IPs: App/DB in private subnets
Explicit Deny: NACLs block known malicious IPs
Audit Logging: VPC Flow Logs capture all traffic
Result:
Zero unauthorized access in 2 years
Passed PCI DSS audit
Blocked 47 attack attempts automatically
Reduced incident response time by 80%.datacamp+1
Q6: Explain EC2 instance storage options: EBS vs. Instance Store vs. EFS.
📖 Detailed Explanation:
EC2 offers three primary storage options, each with different performance characteristics, durability, and use cases:finalroundai+1
1. Amazon EBS (Elastic Block Store)
Characteristics:
Network-attached storage (persistent)
Persists independently of instance lifecycle
Snapshots to S3 for backup
Encryption at rest and in transit
Multi-Attach (io2 volumes only)
Types:
gp3/gp2 (General Purpose SSD): 3,000-16,000 IOPS
io2/io1 (Provisioned IOPS SSD): Up to 64,000 IOPS
st1 (Throughput Optimized HDD): 500 MB/s
sc1 (Cold HDD): 250 MB/s
2. Instance Store (Ephemeral Storage)
Characteristics:
Physically attached NVMe SSD to host
Ephemeral: Data lost on stop/terminate
No additional cost (included with instance)
High IOPS: Millions of IOPS possible
Cannot detach: Tied to instance lifecycle
Availability: Only on specific instance types (i3, i4i, c5d, m5d)
3. Amazon EFS (Elastic File System)
Characteristics:
Network file system (NFSv4)
Shared access: Multiple EC2 instances simultaneously
Elastic: Automatically grows/shrinks
Durability: Replicated across 3 AZs
Performance Modes:
General Purpose: Up to 35,000 IOPS
Max I/O: > 500,000 IOPS
Throughput Modes:
Bursting: Scales with size
Provisioned: Fixed throughput
✅ Pros:
EBS:
Persistent: Data survives instance termination
Snapshots: Point-in-time backups
Flexibility: Attach/detach, resize, change type
Availability: 99.999% durability
Instance Store:
Highest IOPS: Millions of IOPS (i4i instances)
Lowest latency: Sub-millisecond
No cost: Included with instance
High throughput: 60+ GB/s (i4i.32xlarge)
EFS:
Shared storage: Multiple instances read/write
Elastic: No capacity planning
Multi-AZ: Built-in redundancy
Concurrent access: Thousands of connections
❌ Cons:
EBS:
Network latency: 1-3ms vs. sub-millisecond for instance store
Cost: $0.08/GB-month (gp3) to $0.125/GB-month (io2)
IOPS limits: Max 64,000 IOPS (io2 Block Express: 256,000)
Single AZ: Must snapshot for DR
Instance Store:
Data loss: Stop/terminate loses all data
No snapshots: Cannot backup directly
Cannot resize: Fixed size
Limited availability: Not on all instance types
EFS:
Expensive: $0.30/GB-month (Standard), $0.016/GB-month (Infrequent Access)
Network overhead: NFS protocol latency
Complexity: Requires VPC configuration
Consistency: Eventual consistency in some scenarios
💼 Real-World Example:
E-commerce platform storage architecture:
Use Case 1: Application Servers (EBS gp3)
textConfiguration:
- 50x m5.large instances
- 100 GB gp3 EBS per instance (OS + application code)
- 3,000 IOPS, 125 MB/s throughput
- Daily snapshots (7-day retention)
Cost:
- Storage: 100 GB × $0.08 × 50 = $400/month
- Snapshots: 20 GB incremental × $0.05 × 50 = $50/month
- Total: $450/month
Performance:
- Boot time: 45 seconds
- Application start: 30 seconds
- Read/Write: 3,000 IOPS sustained
Benefits:
- Persistent application state
- Fast instance replacement (restore from snapshot)
- Encryption at rest (compliance requirement)
Use Case 2: Database Server (EBS io2)
textConfiguration:
- RDS PostgreSQL (r5.4xlarge)
- 2 TB io2 EBS (database volume)
- 32,000 Provisioned IOPS
- Multi-AZ deployment
Cost:
- Storage: 2,000 GB × $0.125 = $250/month
- IOPS: 32,000 × $0.065 = $2,080/month
- Total: $2,330/month
Performance:
- Read IOPS: 28,000 sustained
- Write IOPS: 15,000 sustained
- Latency: 1-2ms
- Throughput: 1,000 MB/s
Benefits:
- Consistent performance (Provisioned IOPS)
- 99.999% durability
- Snapshot-based DR (5-minute RPO)
Use Case 3: Temporary Processing (Instance Store)
textConfiguration:
- 20x i3.2xlarge instances (big data processing)
- 1.9 TB NVMe SSD instance store per instance
- Total ephemeral storage: 38 TB
Cost:
- Included with instance: $0 additional
- Instance cost: $0.624/hour × 20 = $12.48/hour
- Job duration: 4 hours/night
- Monthly: $12.48 × 4 hours × 30 days = $1,497
Performance:
- Read/Write: 1.6M IOPS
- Throughput: 16 GB/s
- Latency: 50 microseconds
Workflow:
1. Download 10 TB dataset from S3 to instance store
2. Process data (Spark jobs)
3. Write results to S3
4. Terminate instances
Benefits:
- 10x faster than EBS for sequential reads
- No storage cost (included with instance)
- Optimal for ETL pipelines (S3 → Process → S3)
Use Case 4: Shared Content Repository (EFS)
textConfiguration:
- 100x EC2 instances mounting EFS
- 5 TB shared storage (user uploads, media files)
- General Purpose performance mode
- Lifecycle Management: Move to IA after 30 days
Cost:
- Standard Storage: 2 TB × $0.30 = $600/month
- Infrequent Access: 3 TB × $0.016 = $48/month
- Total: $648/month
Performance:
- Read/Write IOPS: 15,000 (across all instances)
- Throughput: 300 MB/s (bursting)
- Concurrent connections: 100 instances
Workflow:
- User uploads file → Saved to EFS
- All web servers access shared content
- Automatic failover (Multi-AZ)
- CloudFront caches frequently accessed files
Benefits:
- Single source of truth (no S3 sync delays)
- Simplified deployment (no per-instance storage)
- Elastic scaling (no capacity planning)
- Cost optimization (70% savings with IA tier)
Cost Comparison for 10 TB Storage (1 Month):
textEBS gp3:
- 10,000 GB × $0.08 = $800/month
- IOPS: 30,000 × $0.005 = $150/month
- Total: $950/month
Instance Store:
- i3.4xlarge: 2x 1.9 TB NVMe = 3.8 TB per instance
- 3 instances needed
- Cost: $1.248/hour × 3 × 730 hours = $2,733/month
- Not cost-effective for permanent storage
EFS Standard:
- 10,000 GB × $0.30 = $3,000/month
- 3.75x more expensive than EBS
EFS with Lifecycle:
- 2 TB Standard + 8 TB IA
- (2,000 × $0.30) + (8,000 × $0.016) = $728/month
- 23% cheaper than EBS (if access pattern allows)
Decision Matrix:
OS/Application Volumes: EBS gp3 (balance of cost/performance)
High-Performance Databases: EBS io2 (consistent IOPS)
Temporary/Cache/Batch Processing: Instance Store (highest performance, zero cost)
Shared File Storage: EFS (multi-instance access)
Long-term Archives: S3 Glacier (not covered here, but $0.004/GB-month).finalroundai+1
<a name="s3"></a>
📦 PART 2: AWS S3 (Simple Storage Service)
Questions 31-55
Q31: What is Amazon S3? Explain its key features and use cases.
📖 Detailed Explanation:
Amazon S3 (Simple Storage Service) is object storage built for storing and retrieving any amount of data from anywhere on the internet:datacamp+1
Key Features:
1. Unlimited Storage
No capacity planning required
Objects from 0 bytes to 5 TB
Billions of objects per bucket
2. Durability & Availability
Durability: 99.999999999% (11 nines)
Availability: 99.99% (Standard class)
Data replicated across 3+ facilities
3. Storage Classes
S3 Standard: Frequently accessed data
S3 Intelligent-Tiering: Automatic cost optimization
S3 Standard-IA: Infrequent access
S3 One Zone-IA: Lower-cost infrequent access (single AZ)
S3 Glacier: Long-term archive (retrieval: minutes to hours)
S3 Glacier Deep Archive: Lowest cost (retrieval: 12 hours)
4. Performance
5,500 GET requests/second per prefix
3,500 PUT requests/second per prefix
Multi-part upload for large files
Transfer Acceleration (via CloudFront edge locations)
5. Security
Encryption at rest (SSE-S3, SSE-KMS, SSE-C)
Encryption in transit (HTTPS/TLS)
Bucket policies, IAM policies, ACLs
S3 Block Public Access (account-wide protection)
6. Management & Analytics
Versioning (maintain multiple object versions)
Lifecycle policies (automatic transitions/deletions)
Replication (Cross-Region, Same-Region)
S3 Analytics (storage insights)
✅ Pros:
Cost-effective: $0.023/GB-month (Standard), $0.004/GB-month (Standard-IA)
Scalability: No limits on storage
Durability: Virtually indestructible (11 nines)
Global access: HTTP/HTTPS access from anywhere
Integration: Native integration with 200+ AWS services
Versioning: Protection against accidental deletions
❌ Cons:
Latency: Not suitable for low-latency applications (50-100ms)
Cost structure: GET/PUT request charges can add up ($$0.0004 per 1,000 GET)
Eventual consistency: Rarely, reads may return stale data
No file system: Object storage paradigm (not hierarchical)
Large object updates: Must reupload entire object (no partial updates)
💼 Real-World Example:
Netflix uses S3 extensively for its global content delivery:
Architecture:
textContent Upload → S3 Standard → CloudFront → Global Users
↓
Lifecycle Policy (30 days)
↓
S3 Intelligent-Tiering → Archive old content
Use Cases & Configuration:
1. Video Storage (Primary Content)
textBucket: netflix-videos-prod
Storage Class: S3 Standard
Objects: 5 million video files (500 TB)
Access Pattern: Frequent (popular shows)
Cost:
- Storage: 500,000 GB × $0.023 = $11,500/month
- GET Requests: 10B requests × $0.0004/1K = $4,000/month
- Data Transfer: Covered by CloudFront (no S3 egress)
- Total: $15,500/month
Features Used:
- Versioning: Enabled (protect against corruption)
- Encryption: SSE-KMS (content protection)
- Replication: Cross-Region (disaster recovery)
2. User Generated Content (Profile Pictures, Reviews)
textBucket: netflix-user-content
Storage Class: S3 Intelligent-Tiering
Objects: 500 million images (50 TB)
Access Pattern: Unpredictable
Cost:
- Storage: Automatic tiering
- Frequent Access: 10 TB × $0.023 = $230/month
- Infrequent Access: 40 TB × $0.0125 = $500/month
- Monitoring: 500M objects × $0.0025/1K = $1,250/month
- Total: $1,980/month (40% savings vs. S3 Standard)
Benefits:
- Automatic cost optimization (no manual lifecycle policies)
- No retrieval fees (unlike Standard-IA)
3. Analytics & Logs (Historical Data)
textBucket: netflix-analytics-logs
Storage Class: S3 Standard → Glacier (after 90 days)
Objects: 2 PB (2,000 TB) cumulative logs
Access Pattern: Recent data frequent, old data rare
Lifecycle Policy:
- 0-30 days: S3 Standard
- 31-90 days: S3 Standard-IA
- 90+ days: S3 Glacier
- 365+ days: S3 Glacier Deep Archive
Cost:
- S3 Standard (30 days): 50 TB × $0.023 = $1,150/month
- S3 Standard-IA (60 days): 100 TB × $0.0125 = $1,250/month
- S3 Glacier: 500 TB × $0.004 = $2,000/month
- S3 Glacier Deep Archive: 1,350 TB × $0.00099 = $1,337/month
- Total: $5,737/month (90% savings vs. all-Standard)
Benefits:
- Compliance retention (7-year requirement)
- Cost-effective long-term storage
- Query with S3 Select (no need to restore)
4. Disaster Recovery Backups
textBucket: netflix-dr-backups
Storage Class: S3 Glacier Instant Retrieval
Objects: Database backups, config snapshots
Access Pattern: Rarely accessed, instant retrieval needed
Configuration:
- Versioning: Enabled (30 versions retained)
- MFA Delete: Enabled (prevent accidental deletion)
- Cross-Region Replication: To eu-west-1 (geographic redundancy)
- Lifecycle: Delete after 90 days
Cost:
- Storage: 20 TB × $0.004 = $80/month
- Replication: 20 TB × $0.02 (one-time) = $400
- Total: $80/month + $400 setup
Benefits:
- 99.9% availability (instant retrieval when needed)
- 90% cheaper than S3 Standard
- Geographic redundancy (disaster recovery)
Overall S3 Usage Statistics:
Total Storage: 2.5 PB across all buckets
Monthly Cost: $23,297 (vs. $57,500 if all S3 Standard)
Cost Savings: 60% through intelligent storage class selection
Request Volume: 50 billion GET requests/month
Data Transfer: 10 PB/month (mostly via CloudFront, no S3 egress cost)
Durability: Zero data loss in 15 years
Performance Optimization:
Multi-part Upload: 5 GB files split into 100 MB parts (10x faster)
Transfer Acceleration: 50% faster uploads from Asia-Pacific region
CloudFront Integration: 90% cache hit rate (reduced S3 GET requests by 90%)
S3 Batch Operations: Automated tagging of 500M objects (compliance)
Security & Compliance:
Encryption: All data encrypted at rest (SSE-KMS)
Access Logging: Enabled for audit trails
S3 Block Public Access: Enabled account-wide (prevent accidental public exposure)
Bucket Policies: Least-privilege access (specific IAM roles only)
Compliance: Passed SOC 2, ISO 27001 audits.datacamp+1
Q32: Explain S3 storage classes and when to use each. How do lifecycle policies optimize costs?
📖 Detailed Explanation:
S3 offers seven storage classes optimized for different access patterns, with lifecycle policies automating transitions to minimize costs:datacamp+1
S3 Storage Classes:
1. S3 Standard
Use Case: Frequently accessed data (> once/month)
Availability: 99.99%
Durability: 11 nines
Retrieval Fee: None
Minimum Storage: None
Cost: $0.023/GB-month
Examples: Active website assets, mobile app content
2. S3 Intelligent-Tiering
Use Case: Unknown or changing access patterns
Automatic Tiering:
Frequent Access: $0.023/GB-month
Infrequent Access: $0.0125/GB-month (30 days no access)
Archive Instant Access: $0.004/GB-month (90 days no access)
Archive Access: $0.0036/GB-month (180 days no access, optional)
Deep Archive Access: $0.00099/GB-month (180 days no access, optional)
Monitoring Fee: $0.0025/1,000 objects
No Retrieval Fee: Unlike other IA classes
Examples: Data lakes, analytics workloads
3. S3 Standard-IA (Infrequent Access)
Use Case: Accessed < once/month, needs instant retrieval
Availability: 99.9%
Retrieval Fee: $0.01/GB
Minimum Storage: 30 days
Minimum Object Size: 128 KB
Cost: $0.0125/GB-month (46% cheaper than Standard)
Examples: Disaster recovery, backups
4. S3 One Zone-IA
Use Case: Non-critical, reproducible data
Availability: 99.5% (single AZ)
Retrieval Fee: $0.01/GB
Cost: $0.01/GB-month (20% cheaper than Standard-IA)
Risk: Data lost if AZ destroyed (rare but possible)
Examples: Secondary backups, easily recreated thumbnails
5. S3 Glacier Instant Retrieval
Use Case: Long-term archive, rare access, instant retrieval
Availability: 99.9%
Retrieval Fee: $0.03/GB
Retrieval Time: Milliseconds
Minimum Storage: 90 days
Cost: $0.004/GB-month (83% cheaper than Standard)
Examples: Medical records, financial archives
6. S3 Glacier Flexible Retrieval
Use Case: Archive data accessed 1-2 times/year
Availability: 99.99%
Retrieval Options:
Expedited: 1-5 minutes ($0.03/GB)
Standard: 3-5 hours ($0.01/GB)
Bulk: 5-12 hours ($0.0025/GB)
Minimum Storage: 90 days
Cost: $0.0036/GB-month (84% cheaper than Standard)
Examples: Regulatory compliance archives
7. S3 Glacier Deep Archive
Use Case: Long-term retention (7-10 years)
Availability: 99.99%
Retrieval Time: 12-48 hours
Retrieval Fee: $0.02/GB (Standard), $0.0025/GB (Bulk)
Minimum Storage: 180 days
Cost: $0.00099/GB-month (96% cheaper than Standard)
Examples: Historical financial records, scientific data
Lifecycle Policies:
Automate transitions between storage classes and expiration of objects:datacamp
xml<LifecycleConfiguration>
<Rule>
<ID>TransitionRule</ID>
<Status>Enabled</Status>
<Transition>
<Days>30</Days>
<StorageClass>STANDARD_IA</StorageClass>
</Transition>
<Transition>
<Days>90</Days>
<StorageClass>GLACIER_IR</StorageClass>
</Transition>
<Transition>
<Days>365</Days>
<StorageClass>DEEP_ARCHIVE</StorageClass>
</Transition>
<Expiration>
<Days>2555</Days> <!-- 7 years -->
</Expiration>
</Rule>
</LifecycleConfiguration>
✅ Pros:
S3 Standard:
No retrieval fees
Instant access
Highest availability
S3 Intelligent-Tiering:
Automatic optimization (no manual policies)
No retrieval fees
Adapts to changing patterns
S3 Glacier Deep Archive:
Lowest cost ($1/TB-month)
Unlimited retention
Regulatory compliance
Lifecycle Policies:
Automated cost optimization
No operational overhead
Set-and-forget management
❌ Cons:
S3 Standard:
Most expensive for infrequent access
Wasted money if data rarely accessed
S3 Intelligent-Tiering:
Monitoring fees add up for small objects
Not suitable for objects < 128 KB
S3 Glacier:
Retrieval delays (minutes to hours)
Early deletion fees (if < minimum storage)
Complexity in planning retrievals
Lifecycle Policies:
Cannot reverse transitions (must delete/re-upload)
Minimum storage duration charges still apply
💼 Real-World Example:
Healthcare company managing patient records (HIPAA compliance):
Scenario:
Data Volume: 500 TB (5 million patient records)
Retention: 10 years (regulatory requirement)
Access Pattern: Frequent for 6 months, rare after 1 year
Option 1: S3 Standard Only (No Optimization)
textCost Analysis:
- Storage: 500,000 GB × $0.023 = $11,500/month
- Annual: $11,500 × 12 = $138,000
- 10-year retention: $138,000 × 10 = $1,380,000
Option 2: Intelligent-Tiering (Automatic)
textAccess Pattern Analysis (after 1 year):
- Frequent Access (< 30 days old): 40 TB (8%)
- Infrequent Access (30-90 days old): 60 TB (12%)
- Archive (> 90 days old): 400 TB (80%)
Cost Analysis:
- Frequent: 40,000 GB × $0.023 = $920/month
- Infrequent: 60,000 GB × $0.0125 = $750/month
- Archive: 400,000 GB × $0.004 = $1,600/month
- Monitoring: 5,000,000 objects × $0.0025/1K = $12.50/month
- Total: $3,282.50/month ($39,390/year)
10-year Total: $393,900
Savings vs. Standard: $986,100 (71% reduction)
Option 3: Lifecycle Policy (Optimized)
xml<LifecycleConfiguration>
<Rule>
<ID>PatientRecordsPolicy</ID>
<Status>Enabled</Status>
<Filter>
<Prefix>patient-records/</Prefix>
</Filter>
<!-- Transition to Standard-IA after 180 days -->
<Transition>
<Days>180</Days>
<StorageClass>STANDARD_IA</StorageClass>
</Transition>
<!-- Transition to Glacier Instant Retrieval after 1 year -->
<Transition>
<Days>365</Days>
<StorageClass>GLACIER_IR</StorageClass>
</Transition>
<!-- Transition to Glacier Flexible after 2 years -->
<Transition>
<Days>730</Days>
<StorageClass>GLACIER</StorageClass>
</Transition>
<!-- Transition to Deep Archive after 3 years -->
<Transition>
<Days>1095</Days>
<StorageClass>DEEP_ARCHIVE</StorageClass>
</Transition>
<!-- Delete after 10 years (3,650 days) -->
<Expiration>
<Days>3650</Days>
</Expiration>
</Rule>
<!-- Non-current versions deleted after 90 days -->
<Rule>
<ID>VersionCleanup</ID>
<Status>Enabled</Status>
<NoncurrentVersionTransition>
<NoncurrentDays>90</NoncurrentDays>
<StorageClass>GLACIER</StorageClass>
</NoncurrentVersionTransition>
<NoncurrentVersionExpiration>
<NoncurrentDays>365</NoncurrentDays>
</NoncurrentVersionExpiration>
</Rule>
</LifecycleConfiguration>
Cost Breakdown (10-Year Lifecycle):
Year 1:
0-6 months S3 Standard: 250 TB × $0.023 × 6 = $34,500
6-12 months S3 Standard-IA: 250 TB × $0.0125 × 6 = $18,750
Total: $53,250
Year 2:
- 0-12 months Glacier IR: 500 TB × $0.004 × 12 = $24,000
Year 3:
- 0-12 months Glacier Flexible: 500 TB × $0.0036 × 12 = $21,600
Years 4-10 (7 years):
- Deep Archive: 500 TB × $0.00099 × 12 × 7 = $41,580
10-Year Total Cost:
Year 1: $53,250
Year 2: $24,000
Year 3: $21,600
Years 4-10: $41,580
Grand Total: $140,430
Comparison:
S3 Standard Only: $1,380,000
Intelligent-Tiering: $393,900
Lifecycle Policy: $140,430
Savings vs. Standard: $1,239,570 (90% reduction)
Savings vs. Intelligent-Tiering: $253,470 (64% reduction)
Additional Benefits:
Compliance: Automatic retention enforcement (10-year expiration)
Versioning: Old versions archived automatically (90-day cleanup)
Zero Operational Overhead: Set once, runs automatically
Audit Trail: Object tags track lifecycle stage (metadata)
Retrieval Scenarios:
Scenario 1: Recent Record (< 1 year old)
Storage Class: Glacier Instant Retrieval
Retrieval Time: Milliseconds
Cost: $0.03/GB
Use Case: Patient returns for follow-up appointment
Scenario 2: Old Record (5 years old)
Storage Class: Deep Archive
Retrieval Time: 12 hours (Standard)
Cost: $0.02/GB
Use Case: Legal discovery request
Solution: Submit bulk retrieval request night before (cheaper)
Business Impact:
ROI: 10-year savings ($1.2M) funded 3 new healthcare initiatives
Scalability: Grew from 500 TB to 2 PB (no infrastructure changes)
Compliance: Passed HIPAA audit (automated retention policies)
Operational: Zero manual storage management (lifecycle automation).interviewbit+1
Q33: How do you secure S3 buckets? Explain bucket policies, IAM policies, and ACLs.
📖 Detailed Explanation:
S3 security involves multiple layers: IAM policies (user-based), bucket policies (resource-based), ACLs (legacy), and encryption:interviewbit+1
Security Layers:
1. IAM Policies (User/Role-Based Access)
Control what identities (users, roles) can do:interviewbit
json{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::my-bucket/user-data/${aws:username}/*"
}
]
}
Characteristics:
Attached to IAM users, groups, or roles
Evaluates identity making request
Supports conditions (MFA, IP, time)
Max policy size: 6,144 characters
2. Bucket Policies (Resource-Based Access)
Control who can access bucket and what actions they can perform:datacamp+1
json{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicReadGetObject",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-public-website/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
}
}
},
{
"Sid": "DenyInsecureTransport",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::my-bucket",
"arn:aws:s3:::my-bucket/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
]
}
Characteristics:
Attached directly to S3 bucket
Can grant cross-account access
Supports deny rules
Max policy size: 20 KB
3. Access Control Lists (ACLs) - Legacy
Object-level permissions (now deprecated in favor of IAM/bucket policies):interviewbit
xml<AccessControlList>
<Grant>
<Grantee>
<ID>account-id</ID>
</Grantee>
<Permission>READ</Permission>
</Grant>
</AccessControlList>
AWS Recommendation: Disable ACLs, use bucket policies instead
4. S3 Block Public Access
Account-wide or bucket-level settings to prevent public exposure:datacamp+1
textSettings:
- BlockPublicAcls: Reject public ACLs
- IgnorePublicAcls: Ignore existing public ACLs
- BlockPublicPolicy: Reject public bucket policies
- RestrictPublicBuckets: Restrict public bucket policies
5. Encryption
At Rest:
SSE-S3: S3-managed keys (AES-256)
SSE-KMS: AWS KMS-managed keys (audit trail, rotation)
SSE-C: Customer-provided keys
Client-Side Encryption: Encrypt before upload
In Transit:
HTTPS/TLS required
Bucket policy to deny non-SSL requests
6. Additional Security Features
Versioning: Protect against accidental deletion
MFA Delete: Require MFA to delete versions
Object Lock: WORM (Write Once Read Many) compliance
S3 Access Logging: Audit all requests
CloudTrail: Track API calls
Macie: Discover sensitive data (PII, credentials)
✅ Pros:
IAM Policies:
Centralized user management
Fine-grained per-user permissions
Supports temporary credentials (STS)
Bucket Policies:
Cross-account access without IAM roles
Public access control (websites)
Explicit deny rules (security enforcement)
S3 Block Public Access:
Account-wide protection (prevent human error)
Override individual bucket settings
Compliance requirement (PCI DSS, HIPAA)
Encryption:
SSE-KMS: Full audit trail (who accessed when)
Automatic encryption (bucket default)
Compliance (data-at-rest requirements)
❌ Cons:
IAM Policies:
Limited to 6 KB (large policies need splitting)
Doesn't work for anonymous access
Complex to manage at scale (100+ users)
Bucket Policies:
20 KB limit
No inheritance (must configure per bucket)
Evaluation order can be confusing
ACLs:
Legacy (deprecated)
Limited permissions (read, write, full-control)
Difficult to audit
SSE-KMS:
Additional cost ($0.03/10,000 requests)
Request throttling (KMS API limits)
Complexity (key management, rotation)
💼 Real-World Example:
Financial services company securing customer document storage:
Requirements:
Compliance: PCI DSS, SOC 2
Encryption: AES-256 at rest, TLS in transit
Access Control: Role-based (employees), customer self-service
Audit: Track all access (who, when, what)
Retention: 7-year immutability
Architecture:
textUsers → CloudFront (TLS) → Lambda@Edge (Auth) → S3 Bucket (Encrypted)
↓
WAF (IP Filter)
S3 Bucket Configuration:
json// Bucket Policy
{
"Version": "2012-10-17",
"Statement": [
// 1. Deny all non-HTTPS requests
{
"Sid": "DenyInsecureTransport",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::customer-documents-prod",
"arn:aws:s3:::customer-documents-prod/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
},
// 2. Allow CloudFront Origin Access Identity
{
"Sid": "AllowCloudFrontOAI",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity EXAMPLE123"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::customer-documents-prod/*"
},
// 3. Allow application Lambda functions
{
"Sid": "AllowLambdaUpload",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/DocumentUploadLambdaRole"
},
"Action": [
"s3:PutObject",
"s3:PutObjectAcl"
],
"Resource": "arn:aws:s3:::customer-documents-prod/uploads/*",
"Condition": {
"StringEquals": {
"s3:x-amz-server-side-encryption": "aws:kms",
"s3:x-amz-server-side-encryption-aws-kms-key-id": "arn:aws:kms:us-east-1:123456789012:key/abc-123"
}
}
},
// 4. Deny deletion by anyone except admin role
{
"Sid": "DenyDeleteExceptAdmin",
"Effect": "Deny",
"NotPrincipal": {
"AWS": "arn:aws:iam::123456789012:role/S3AdminRole"
},
"Action": [
"s3:DeleteObject",
"s3:DeleteObjectVersion"
],
"Resource": "arn:aws:s3:::customer-documents-prod/*"
}
]
}
IAM Policy (Employee Access):
json{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::customer-documents-prod/customer-${aws:userid}/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": [
"203.0.113.0/24", // Office network
"198.51.100.0/24" // VPN
]
},
"DateGreaterThan": {
"aws:CurrentTime": "2025-01-01T00:00:00Z"
},
"DateLessThan": {
"aws:CurrentTime": "2026-01-01T00:00:00Z"
}
}
}
]
}
Encryption Configuration:
json// Bucket Default Encryption
{
"Rules": [
{
"ApplyServerSideEncryptionByDefault": {
"SSEAlgorithm": "aws:kms",
"KMSMasterKeyID": "arn:aws:kms:us-east-1:123456789012:key/abc-123"
},
"BucketKeyEnabled": true
}
]
}
// KMS Key Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow S3 to use key",
"Effect": "Allow",
"Principal": {
"Service": "s3.amazonaws.com"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:ViaService": "s3.us-east-1.amazonaws.com"
}
}
},
{
"Sid": "Audit all key usage",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"kms:Decrypt",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:CallerAccount": "123456789012"
}
}
}
]
}
Object Lock (Compliance Mode):
json{
"ObjectLockEnabled": "Enabled",
"Rule": {
"DefaultRetention": {
"Mode": "COMPLIANCE", // Cannot delete even by root
"Days": 2555 // 7 years
}
}
}
S3 Block Public Access (Account-Wide):
textAll 4 settings enabled:
✓ Block public access to buckets and objects granted through new ACLs
✓ Block public access to buckets and objects granted through any ACLs
✓ Block public access to buckets and objects granted through new public bucket policies
✓ Block public and cross-account access to buckets an
