Originally published on lavkesh.com
AWS is huge, with over 200 services. If you're trying to understand what's available, it's overwhelming. The key is knowing that there's probably a service for whatever you're building, and figuring out which one makes sense for your constraints.
Compute options solve different problems. EC2 is virtual machines, where you control everything, which means you manage everything. Lambda is serverless, where you pay per invocation, good for event-driven work. ECS and EKS run containers, sitting between EC2 and Lambda in terms of control and responsibility. Lightsail is simplified EC2 for people who want less complexity. You pick based on your tolerance for operational work and your usage patterns.
When you move from a proof‑of‑concept to a production workload, the choice of provisioning tool can make or break your rollout. In my team we migrated a 50‑node microservice fleet from CloudFormation to Terraform because the state‑locking feature in Terraform Cloud gave us deterministic rollbacks during a weekend upgrade. The same code base that spun up EC2 Spot instances for batch jobs also launched Lambda functions for the event‑driven side, but we kept a separate Terraform workspace to avoid accidental drift. We saw a 30 % reduction in deployment time after introducing module reuse, and the cost of Spot instances dropped from $0.045 per hour to $0.015 after we added a capacity‑optimized allocation strategy.
Storage is more than just S3. S3 is object storage, used for everything from backups to static websites. EBS is block storage for EC2 instances. EFS is managed file storage. DynamoDB is key-value. RDS is managed relational databases. Choose based on access patterns and consistency requirements, not just convenience.
Networking has real gotchas. VPCs isolate your infrastructure. Security groups are your firewall. NACLs add another layer of network control. VPN and Direct Connect give you private connections. If your application is slow or unreliable, network misconfiguration is often the culprit. Get this right first.
A common source of latency spikes is an asymmetric route table that sends traffic from a private subnet through a NAT gateway that sits in a different AZ. In one production environment we traced a 200 ms tail latency to a mis‑configured route that forced all database calls to cross the AZ boundary, incurring $0.045 per GB NAT data charges and a noticeable jitter. The fix was to consolidate the NAT gateway in the same AZ as the RDS instance and enable VPC Flow Logs with a CloudWatch metric filter that alerts on >100 ms latency. We also added an AWS Network Firewall policy to block unexpected ports, which cut the number of security incidents by half.
Database choice has long-term consequences. RDS for relational databases, DynamoDB for key-value, ElastiCache for caching, DocumentDB for document stores. Each has different scaling characteristics and costs. Migrating between them is painful. Think through your access patterns before you commit.
If you start with DynamoDB on‑demand and later need predictable throughput, the migration to provisioned capacity can be tricky. We ran a load test that peaked at 12 k read units and 6 k write units, and the on‑demand cost was $1.44 per hour versus $0.90 after we switched to provisioned with auto‑scaling thresholds at 70 % utilization. For relational workloads we kept a warm replica in a different region using RDS cross‑region read replicas; the replica lag stayed under two seconds, which let us fail over in under a minute during a regional outage. The only downside was the extra $0.025 per GB‑month for inter‑region replication traffic, but the business continuity payoff was worth it.
Cost management is not optional. AWS is pay-as-you-go, which is good for flexibility and bad for surprise bills. Reserved instances, savings plans, careful architecture, resource tagging - these aren't nice to have, they're necessary. If you're not monitoring costs, you're leaving money on the table.
Top comments (0)