SW BBANG

TL;DR Writing a processed file back to the same S3 bucket that triggers your Lambda creates an infinite recursive loop. Every write fires a new invocation, which writes again, which fires again — until your account hits concurrency limits or your bill explodes. Strategy Complexity Cost Impact Best For Write to a separate output bucket Low Minimal (extra bucket, no extra compute) Most use cases — cleanest solution Prefix/suffix filtering on S3 trigger Low None When a single bucket is a hard requirement Object metadata/tag check in code Medium Slight (extra S3 API calls) Defense-in-depth layer Core Fix: Use a dedicated output bucket, or apply S3 event filter rules so the trigger only fires on input/ prefix objects, never on processed output. Why This Happens: The Recursive Trigger Loop S3 event notifications are bucket-scoped and prefix/suffix filtered. When you configure a trigger with no filter (or a filter that matches both input and outp...

TL;DR Stop embedding IAM User credentials in your EC2 instances. Use an IAM Role attached to the instance profile instead. It is more secure, requires zero credential management, and is the AWS-recommended standard. Attribute IAM User IAM Role Identity Type Permanent identity for a person or service Temporary identity assumed by a trusted entity Credentials Long-lived Access Key ID + Secret (static) Short-lived STS tokens (auto-rotated) Rotation Required Yes — manual or scripted No — AWS rotates automatically Best For Human operators, CI/CD pipelines (OIDC preferred) EC2, Lambda, ECS, cross-account access Risk if Leaked High — static key valid until manually revoked Low — token expires in 1–12 hours EC2 Recommendation ❌ Never ✅ Always The Core Problem: Static Credentials Are a Liability An IAM User has a permanent Access Key ID and Secret Access Key. When you embed these in an EC2 instance — via ~/.aws/credentials , an environ...

TL;DR Setting an S3 object ACL to public-read is not enough . AWS S3 has a bucket-level (and account-level) "Block Public Access" firewall that overrides all object-level ACLs and bucket policies. Both layers must be configured correctly before a public URL works. Layer Setting Required Where to Change Account-level BPA Disable relevant block settings S3 Console > Block Public Access (account) Bucket-level BPA Disable BlockPublicAcls & IgnorePublicAcls Bucket > Permissions > Block Public Access Bucket Policy or ACL Grant s3:GetObject to * Bucket Policy JSON Fix (30-second version): Disable the blocking flags at the bucket level, then attach a bucket policy granting public GetObject . Do not rely on object ACLs alone. Why This Happens: The Two-Layer Access Model S3 access evaluation is a sequential gate system, not a single check. Think of it like a building with two locked doors: even if you have a key to the inne...

TL;DR — Fix It in 60 Seconds An SSH Connection timed out error means your TCP packets are being silently dropped before reaching the instance. The most common culprit is a missing or misconfigured inbound rule in your EC2 Security Group . Here is the exact checklist: Check What to Verify Correct Value Protocol Security Group Inbound Rule TCP Port SSH daemon port 22 (or custom port in sshd_config) Source CIDR Your public IP or trusted range YOUR_IP/32 (not 0.0.0.0/0 in prod) Subnet Route Public subnet has IGW route 0.0.0.0/0 → igw-xxxxxxxx Instance State Instance is running & has public IP State: running, Public IPv4 assigned Why 'Connection Timed Out' — Not 'Connection Refused' This distinction is critical for fast diagnosis. Think of it like a postal system: Connection Refused = Your letter reached the building, but the mailbox slot is sealed. The OS received the packet and actively rejected it (port closed or no lis...

Hey there! Let’s be real—working with AWS can feel like magic when it works, but it’s incredibly frustrating when it doesn't. We’ve all been there: staring at a "Connection Timed Out" screen or scratching our heads over an "Access Denied" error that makes no sense. I’ve put together a list of 50 common AWS hurdles that I (and many others) have stumbled over. Whether you’re just starting your cloud journey or you’re already deep in the console optimizing architecture, this guide is here to save you some serious "googling time." What’s inside? The "Why can't I connect?" stuff: Fixing EC2 timeouts and tricky VPC networking. The "Permission denied" headaches: Sorting out S3 access and making sense of IAM Roles vs. Users. The "Save my wallet & sleep" tips: Setting up billing alarms, picking the right EBS types, and stopping RDS storage scares. The "Let’s automate" bits: Handling Lambda triggers without cr...