AWS Cost Optimization Overview

Find The Baseline

This is going to be a high level overview into many of the facets of cost optimization in AWS, with future posts diving deeper into some of the more nuanced or interesting ones. So sit back with a nice scoop of cookie dough ice cream and get ready to crunch some numbers!

The first step is understanding where your spend is. High level, you can find this out on a default setup in Cost Explorer. But you’ll usually want to go deeper by having tag based cost reporting enabled to easily differentiate between apps, teams, environments, etc. Going in detail through your Cost Explorer and CUR will tell you a lot, but it's also a dark art that can be hard to wrangle without practice.

Start with a basic look in cost explorer to get a high level familiarity with trends for top spend services before trying to find reasons and solutions for the spend. The highest cost services are often a good place to start, but aren't necessarily the easiest wins, so take at least a quick look through every meaningful category.

Now lets dig into some slightly more specific topics

LLM Agents

If you want to skip this section, you’re probably the one it's for.

Especially when prototyping, it can be fun and efficient to have your favorite agent spin up resources for you so that you just describe a general environment so you don’t have to think about the details of how each service works. And even if you're not, SOMEONE probably is, or will be soon, so plan for it now.

The obvious potential issue I think most people worry about at first is the agent creating something huge, like a U instance with 24TB of RAM for a dev environment website. That’s less likely, since the LLMs have plenty of examples of ‘normal’ test setups. The biggest issue is, as always, the human instructions. Did you tell it this was a dev environment? Or to take down the resources because you’re done? Make sure you have a plan (or better, automation) for all that. Not to say there aren’t issues the Agent can and will cause. More on this in a future post, but for now the short and simple list of guidelines I have are:
- Always tell the agent to run things through CDK/terraform/etc. There’s no reason not to, and it will more reliably lead to everything getting torn down when the experiment is done.
- Have a rule in your agents.md file to require tagging, and have tags for the agent environments so you know how much to attribute to which experiment.
- SANDBOX EVERYTHING. The agent gets access to a single account. That account gets strict billing alarms, and maybe even wiped clean nightly/weekly.
- Locked down IAM policies, at least at the service level, so that the agent doesn’t accidentally decide your crossword puzzle app needs to be run on ElastiCache through Direct Connect with Sagemaker analysis of the analytic metrics.
- Make sure to have an MCP service with AWS docs.

Performance Optimization

Performance optimization is part of cost optimization

The simplest version is a tradeoff between the 2. “My app runs faster on a 32xl C instance instead of a Large T family one”. This is the quickest place to start, and builds a baseline for the second phase. Figure out your actual business requirements. “It should be fast” isn’t a requirement.
Better: “Our users expect a normal response in less than 3 seconds”.
Best: “a queue item should be processed in 500ms at p90 and 2s at p99.99. Slower then P90 for consecutive messages and our helpdesk gets calls, which costs money. Slower than p99.99 our SLAs and client trust are broken.” is a business requirement.

The ‘best’ example mixes SLAs and SLOs. How often, for how long, and by how much you can be past your normal SLO or SLA is important, as well for how much unused buffer you want to have in place. Paired with how often you expect request spikes, this lets you come up with a scaling strategy to manage cost and performance.

Going deeper into the application and environment though, you can find ways to improve cost and/or performance without hurting the other. This is often trickier (technically, or worse, changing business norms and policies), but obviously gives a much better payoff. The main cost here is time, which is why working with an outside expert can be helpful. Let your team focus on delivering your core value, while someone who specializes in these optimizations review the best ROI options for your environment.

Next up, some actual examples where you gain on cost, performance, or both

Actual recommendations

1. The cloud is elastic, don’t treat it like a sunk-cost datacenter. Turn things off or scale them down when they aren’t in use (Dev, weekends, nights)
2. Look into Compute Optimizer recommendations for potential easy wins on EC2, EBS, Lambda, and many more services
3. EC2:
   1. Try Graviton, or at least AMD. You can often run fewer/smaller instances for the same workload.
   2. If you’re not trying to eek every ms of latency from an application and aren’t often close to maxing out CPU, try Flex instances, or for even less CPU intense applications, consider T family instances.
   3. Turn off instances at night/weekends w/ instance scheduler; or terminate when not in use via ASG to also remove EBS/public IP costs
   4. Remove public IPv4 IPs where practical
   5. GP3 volumes vs GP2
   6. Pick the right instance family (Memory vs CPU balance) and instance suffix (network optimized, etc)
   7. CSP (Compute Savings Plan) for long term, base level load; OD and/or Spot for the rest (don’t bother with instance specific plans unless you HAVE to use that one for a compliance requirement. Freedom to upgrade is worth the few percent)
      1. I used to say its possible to run prod on 100% spot, I wouldn’t say that anymore
   8. Containerizing multiple applications to run on a shared cluster of instances vs each small application needing its own instance(s). Helps with HA, fault tolerance, and cost.
4. Lambda
   1. Also CSP
   2. Sometimes a larger function runs faster enough to actually be cheaper vs a smaller one
5. Database (RDS/ElastiCache/DDB/etc)
   1. There are now Database Savings Plans as well!
   2. Shutdown/scale-down when not in use

Now Go Do It!

1. Check out your CUR and Cost Explorer
2. Enable tag based cost reporting for your standardized tags like Environment
3. After finding orphaned resources, put methods in place to keep them from happening again
4. Reach out to your favorite cost optimization experts to see what savings are being missed in your environment today. A Cloud Above Us will be happy to be your experts if you don’t already have one!