Building cloud Systems

Deciding Requirements My first system on AWS had everything planned from day one. Authentication, notifications, retry logic, multiple user roles. It took weeks to build something I could barely test because nothing worked independently. Everything was connected before anything was verified. The right question before picking any service is: what does this system have to… Read →

CloudWatch is the monitoring layer that most AWS workloads eventually depend on, whether the team planned for it or not. EC2 sends CPU metrics to it, Lambda writes logs to it, API Gateway exposes error rates through it, ECS services can be watched through it, and almost every production incident ends with someone opening CloudWatch… Read →

S3 is the storage layer underneath almost every AWS workload. Static websites serve assets from it, Lambda functions write results to it, CloudFront pulls content through it, RDS snapshots land in it. It shows up in every architecture diagram as a box with an arrow pointing at it, and most teams never look past that… Read →

If you have ever put a Lambda function or an EC2 instance inside a private subnet and then tried to reach S3 or DynamoDB from it, you already know the problem. The request just hangs. There is no internet gateway, no NAT device, no route out — so the traffic has nowhere to go. The… Read →

An Application Load Balancer operates at Layer 7 — the HTTP layer. Unlike a classic load balancer which distributes traffic purely based on connection-level information, an ALB understands HTTP. It can read the request path, inspect headers, evaluate query strings, and make routing decisions based on what is actually in the request. That is what… Read →

Serving files directly from S3 works, but it has two problems that surface quickly in production. The first is latency — an S3 bucket lives in one region, and a user in Singapore hitting a bucket in us-east-1 feels that distance on every request. The second is cost — S3 data transfer rates are higher… Read →