Cutting AWS bills without a rewrite

When an AWS bill gets uncomfortable, teams sometimes assume they need to re-architect. In our experience, the first meaningful savings usually come from simpler changes that don't touch application code.

Start with visibility

Turn on Cost Explorer and tag resources by team, environment and product. You can't reduce what you can't attribute. Even a rough tagging pass usually reveals forgotten environments and idle resources.

Remove what nobody uses

• Unattached EBS volumes and old snapshots
• Idle load balancers and elastic IPs
• Test environments left running overnight and at weekends
• Oversized log retention in CloudWatch

Right-size instances and databases

Many instances run at low CPU and memory use most of the time. Compute Optimizer and a few weeks of metrics will show candidates for smaller instance types or newer, more efficient generations. Apply the same thinking to RDS instances and provisioned storage.

Commit where usage is steady

For workloads that run all the time, Savings Plans or Reserved Instances can reduce compute costs substantially compared with on-demand pricing. Commit only to the baseline you're confident about, and review it every quarter.

Use the right storage class

S3 Intelligent-Tiering or lifecycle rules can move rarely accessed data to cheaper classes automatically. Backups and archives rarely need to sit in standard storage.

Watch data transfer

Data moving between regions, availability zones and out to the internet adds up quietly. A CDN in front of static assets and keeping chatty services in the same zone can make a visible difference.

Make it a habit

Set budgets and alerts, review costs monthly with engineering and finance together, and make cost part of design reviews. Savings tend to slip away unless someone keeps an eye on them.

Only once these basics are done does it make sense to look at deeper changes such as moving workloads to containers or serverless.