SW BBANG

Comprehensive Guides for Cloud Architecture, Troubleshooting, and Optimization 💻 Compute & Load Balancing EC2 SSH Connection Timeout: The Exact Security Group Rules You Need to Fix It IAM User vs. IAM Role: Why Your EC2 Instance Should Never Use a User EC2 No Internet Access in Custom VPC: Attaching an Internet Gateway and Fixing Route Tables ALB 502 Bad Gateway: Why Healthy Targets Still Fail (And How to Fix It) EBS gp2 vs. gp3: Which General Purpose SSD Should You Choose? Route 53 Alias vs. CNAME Records: The Definitive Guide for Pointing Domains to an ALB ...

Running work and personal AWS accounts from the same machine is a common reality for engineers — and without a proper profile strategy, you risk deploying personal side projects into your company's production account, or worse, billing your employer for your weekend experiments. TL;DR Step Action File Modified 1 Add named credentials ~/.aws/credentials 2 Add named config (region, output) ~/.aws/config 3 Use --profile flag per command CLI invocation 4 (Optional) Set AWS_PROFILE env var Shell session How AWS CLI Profile Resolution Works The AWS CLI uses a layered credential resolution chain. Named profiles are stored across two files: ~/.aws/credentials (access keys) and ~/.aws/config (region, output format, and advanced settings). The default profile is used when no profile is explicitly specified. Every other named profile must be referenced explicitly — either via the --profile flag or t...

When your RDS instance starts showing high CPU utilization and query latency spikes during peak traffic, the root cause is often a flood of SELECT statements competing with write operations on a single database endpoint. Scaling reads with RDS Read Replicas is the standard architectural response — but knowing when to use a replica versus Multi-AZ, and how to wire your application correctly, is where most teams stumble. TL;DR: RDS Read Replicas vs. Multi-AZ at a Glance Dimension Read Replica Multi-AZ Primary purpose Read scalability High availability / failover Serves read traffic? Yes — dedicated endpoint No — standby is not queryable Replication type Asynchronous Synchronous Failover promotion Manual (or Aurora automatic) Automatic Separate endpoint? Yes No — same endpoint, DNS flips Cross-region support Yes No (same region, different AZ) How RDS Read Replica Scaling Works RDS Read Rep...

When traffic enters your VPC, two distinct filtering layers stand between the packet and your workload — Security Groups and Network ACLs. Engineers routinely misconfigure one while relying on the other, and the resulting behavior is often silent: traffic drops with no obvious error, or rules that look correct on paper fail in production because the stateless layer never saw the return path. TL;DR: Security Group vs Network ACL Dimension Security Group Network ACL Attachment level ENI (instance/resource) Subnet State tracking Stateful Stateless Rule evaluation All rules evaluated, most permissive wins Rules evaluated in order; first match wins Allow/Deny Allow only Allow and Deny Return traffic Automatically permitted Requires explicit outbound rule Default behavior Deny all inbound, allow all outbound Allow all inbound and outbound (default NACL) How VPC Traffic Filtering Works Every pac...

If you're storing compliance records, audit logs, or historical datasets that you access once a year or less, paying for S3 Standard is like renting a downtown office for a filing cabinet you open annually. AWS S3 Glacier storage classes are purpose-built for exactly this scenario — delivering durable, long-term archival at a fraction of the cost, with retrieval options tuned to your urgency requirements. TL;DR — Glacier Storage Class Comparison Storage Class Min. Storage Duration Retrieval Time Best For S3 Glacier Instant Retrieval 90 days Milliseconds Quarterly access, instant response needed S3 Glacier Flexible Retrieval 90 days 1–5 min (Expedited), 3–5 hrs (Standard), 5–12 hrs (Bulk) Annual audits, flexible retrieval window acceptable S3 Glacier Deep Archive 180 days Up to 12 hrs (Sta...

Triggering a Lambda function on a fixed schedule — say, every day at 8 AM UTC — is one of the most common serverless patterns, yet the permission model and cron syntax trip up engineers more often than the wiring itself. This post covers how scheduling Lambda with EventBridge works end-to-end, including the exact cron format, the resource-based policy that actually grants invocation rights, and the CLI commands to verify everything is wired correctly. TL;DR: Scheduling Lambda with EventBridge Concern Answer Trigger mechanism EventBridge Scheduler rule with a schedule expression Cron format cron(Minutes Hours Day-of-month Month Day-of-week Year) — 6 fields, UTC only Daily 8 AM expression cron(0 8 * * ? *) Required permission Lambda resource-based policy granting lambda:InvokeFunction to events.amazonaws.com IAM execution role Not required on the EventBridge rule itself for Lambda targets — the reso...