Cloudshipped

Blog

AWS Cost Optimization in 2026: A DIY Playbook for Startups

· 18 min read

For a Seed to Series C startup, the AWS cost changes that matter in 2026 are Database Savings Plans, NAT Gateway and EBS cleanup in Compute Optimizer, a Cost Efficiency score in Cost Optimization Hub, cheaper Bedrock tiers, and Graviton5. Most are settings your team can turn on itself. Start with visibility, then cleanup, then commitments.

I'm Seth. I run Cloudshipped, and I do AWS cost work for SaaS companies that don't have a FinOps team. This guide is written so you can do the work yourself: what each change does, how to switch it on, and where I'd skip it.

A few of these shipped in the weeks just before re:Invent 2025 rather than at the show. I've grouped them as one cycle here, since that's how they landed on most teams' radar.

Prices, discount rates, and dates below are accurate as of this writing. AWS changes pricing and features and rolls them out differently by Region and account, so confirm current details in your own console before you act on any of them.

What changed in AWS cost optimization since re:Invent 2025?

Here's the short version, filtered for a company spending $10k or more a month with no one whose full-time job is the bill.

Change Who it matters for Effort Typical impact
Cost Efficiency metric in Cost Optimization Hub Every account over $10k/month Low: one opt-in Visibility. Shows what share of optimizable spend has open savings
Unused NAT Gateway recommendations Teams with several VPCs or leftover environments Low $32.85/month per idle gateway in US East (Ohio)
Compute Optimizer Automation (EBS) Anyone with orphaned or previous-generation volumes Low to medium Removes unattached volume spend, upgrades old volume types
Database Savings Plans Steady Aurora, RDS, DynamoDB, or ElastiCache for Valkey spend Medium: needs sizing Up to 35% serverless, up to 20% provisioned, up to 18% DynamoDB on-demand
Bedrock Flex, Batch, and prompt caching Any product with an LLM feature Medium: code changes Flex and Batch at 50% off Standard; caching up to 90% on supported models
Bedrock cost allocation by IAM principal GenAI features owned by more than one team Low Visibility by team or feature
Split cost allocation with Kubernetes labels EKS shops running shared clusters Medium: CUR plus Athena Per-service cost on shared nodes
18-month forecasting and Amazon Q explanations in Cost Explorer Anyone doing runway planning Low Planning input, no direct savings
Graviton5 (M9g, C9g) Teams already on ARM Medium to high Per-hour price is 9% above M8g; pays only if performance lets you cut capacity

Two enterprise-leaning items get one line each. Bedrock's Reserved tier sells tokens-per-minute capacity on one- or three-month terms, which is overkill for most startups. And AWS pitched the 18-month forecast horizon at enterprise fiscal cycles.

What should I set up first?

Commitments go last. A Savings Plan locks in whatever you're running today, so you want the waste gone and the instance generations current before you buy one. Here's the order I'd follow in the first 30 days.

  1. Day 1: opt in to Cost Optimization Hub and Compute Optimizer for the whole organization, then record your Cost Efficiency score as a baseline.
  2. Days 2 to 5: delete idle NAT Gateways and unattached EBS volumes by hand. Add free S3 and DynamoDB gateway endpoints to every VPC.
  3. Days 6 to 10: fix gp2 and io1 volumes in your Terraform or CloudFormation. Create Compute Optimizer automation rules for non-production only.
  4. Days 11 to 15: tag the IAM roles that call Bedrock. Move background LLM work to Flex or Batch. Turn on prompt caching where prompts repeat.
  5. Days 16 to 20: rightsize databases and move them to latest-generation instances.
  6. Days 21 to 25: size Database Savings Plans and Compute Savings Plans against your new, lower floor, and decide what to commit to from there.
  7. Days 26 to 30: turn on split cost allocation if you run EKS. Build a forecast from Cost Explorer's baseline plus your known changes.

Graviton5 testing comes after this list. It's the only item here that needs real engineering time.

How do I turn on Cost Optimization Hub and read the Cost Efficiency score?

Open the Billing and Cost Management console, go to Cost Optimization Hub, and enable it for your organization. Do the same in Compute Optimizer, since the Hub pulls its recommendations from there. From the CLI:

aws cost-optimization-hub update-enrollment-status --status Active --include-member-accounts
aws compute-optimizer update-enrollment-status --status Active --include-member-accounts

The score shows up on the Hub homepage within 36 hours. It's calculated as 1 minus potential savings divided by total optimizable spend. AWS's own example: $100,000 of optimizable spend with $10,000 of identified savings scores 90%. Across AWS customers, the median was 83 and the mean 79 as of May 2026.

Here's where common advice goes wrong. People treat a high score as proof the bill is healthy. It isn't. The score only counts spend on services where Cost Optimization Hub makes recommendations, and only the savings its tools can detect. NAT data processing, cross-AZ traffic, and architecture choices sit mostly outside it. A team can chase the number into the 90s while an avoidable data-transfer line keeps growing underneath it.

Use the score as a to-do list for the waste AWS can see. Don't use it as your definition of efficient.

How do I find idle NAT Gateways, and is that the NAT cost that matters?

Compute Optimizer now flags NAT Gateways with zero active connections and zero incoming packets across a 32-day window. It also checks route table associations, so it's more cautious about gateways that look like standby capacity. Once you're opted in, the recommendations show up within 24 hours.

Deleting an idle gateway saves its hourly charge. In US East (Ohio), that's $0.045 an hour, or $32.85 a month at 730 hours. A leftover three-AZ staging VPC is $98.55 a month for nothing. Before deleting one, confirm nothing depends on it and check whether it's declared in Terraform or CloudFormation, so your next apply doesn't recreate it or your next plan doesn't flag drift.

That's real money. It's usually not the big NAT number, though. Every GB through a NAT Gateway also costs $0.045 in processing, even when the destination is S3 in the same Region. If your app pushes 5,000 GB a month to S3 through NAT, that's $225 a month in processing alone. AWS's own pricing page recommends a gateway VPC endpoint for exactly this case, and gateway endpoints have no hourly or data processing charge.

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0123456789abcdef0 \
  --service-name com.amazonaws.us-east-2.s3 \
  --route-table-ids rtb-0aaa rtb-0bbb rtb-0ccc

Repeat it with dynamodb in place of s3 if you use DynamoDB. To see how much traffic each gateway handles, pull the BytesOutToDestination metric from the AWS/NATGateway CloudWatch namespace for the last 30 days.

Should I let Compute Optimizer change things automatically?

Compute Optimizer Automation launched in November 2025. Today it supports two actions. The first snapshots and deletes EBS volumes that have been unattached for 32 or more days. The second upgrades previous-generation volume types to newer ones like gp3 and io2. You can apply up to 10 actions at a time by hand, or create rules that run daily, weekly, or monthly, scoped by Region and resource tag.

My setup:

  1. Opt in to Automation from the Compute Optimizer console.
  2. Open Recommended actions and apply a handful by hand so you can see what they do.
  3. Create a weekly rule scoped to a tag like env=dev or env=staging.
  4. Check the automation events dashboard after the first run. You can reverse actions from there.

I would not point a rule at production volumes managed by Terraform or CloudFormation. When Compute Optimizer deletes a volume your template declares, the IaC tool reports drift. A property change like a volume type upgrade can get reset by your next deploy. Put gp3 in the template itself and let automation handle only what nobody manages in code.

Two practical notes. Snapshots created since February 24, 2026 carry the tag aws:compute-optimizer:automation-event-id, so you can find them later. Those snapshots cost money too, so set a lifecycle policy on them.

Should I buy Database Savings Plans or Reserved Instances?

Database Savings Plans arrived December 2, 2025. You commit to a dollar-per-hour amount for one year with no upfront payment; that's the only term and payment option. In exchange, AWS discounts eligible usage across Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, and DMS. OpenSearch Service and Neptune Analytics were added in March 2026.

The rates vary by usage type. Serverless gets up to 35%, provisioned instances up to 20%, DynamoDB and Keyspaces on-demand throughput up to 18%, and their provisioned capacity up to 12%. For RDS for SQL Server, licensing charges stay at on-demand rates.

The common advice is that these plans replace Reserved Instances. That's incomplete. The plan's strength is that it follows your usage: you can move from db.r7g to db.r8g, change Regions, or migrate RDS to Aurora and keep the discount. If a provisioned database won't change for years, a Reserved Instance can still be the deeper discount. You also can't stack both on the same workload, though you can use RIs for one database and a Savings Plan for another. I compare the two side by side in Database Savings Plans vs. Reserved Instances.

The math, with assumptions stated. Say an Aurora provisioned cluster on a latest-generation instance runs $4,000 a month on-demand. If your instance's rate is the full 20%, fully covering it means committing about $3,200 a month, or roughly $4.38 an hour. The ceiling on savings is $800 a month, $9,600 a year. Your actual rate may be lower, so check the table on the pricing page.

The way I think about the order: rightsizing and generation upgrades come before buying a plan, not after. Database Savings Plans only cover Generation 7 and newer instances, so if you're still on db.r5 or db.r6g, that usage won't get the discount until you migrate. Committing before upgrading discounts spend you were about to cut anyway. To size it, use Savings Plans recommendations and the Savings Plans Purchase Analyzer in the Billing and Cost Management console as a starting point, and weigh that against the hourly floor you hit every hour, not your average.

This is the step where general advice runs out. The right commitment depends on your hourly floor, your roadmap, and which databases might move in the next year. If you'd rather have someone pull those numbers from your account, you can book a free discovery call for the Cloudshipped Cost Audit for AWS.

How do I keep Bedrock and GenAI spend under control?

If your product calls an LLM, Bedrock is now a cost line that deserves the same attention as EC2. Three levers came out of this cycle, plus one older one.

Service tiers let you choose per request. Standard is the default. Flex is priced at a 50% discount to Standard for work that can wait. Priority is a 75% premium for latency-sensitive traffic. You pick one by setting the service_tier parameter on the runtime call. Not every model supports every tier, so check the model's pricing entry first.

Batch inference runs at 50% below on-demand for select models. Prompt caching, generally available since April 2025, can cut costs by up to 90% on supported models when long prompt prefixes repeat.

The math: say you spend $3,000 a month on Standard, and 40% of it is background work like nightly summaries, evals, and enrichment. Moving that $1,200 to Flex cuts it to $600, a saving of $600 a month, assuming your model supports Flex.

I wouldn't default anything to Priority. It's 1.75 times Standard. Use it only for the one or two user-facing paths where a slower response would cost you something measurable.

For visibility, Bedrock added cost allocation by IAM user and role in April 2026, and extended it to the bedrock-mantle endpoint in August. Tag the IAM roles each feature uses with something like feature and team. Activate those tags under Cost allocation tags in the Billing console. Then create a CUR 2.0 export with "Include caller identity (IAM principal) allocation data" selected, or filter by tag in Cost Explorer.

How do I see what each service costs on a shared EKS cluster?

Since October 30, 2025, split cost allocation data can import up to 50 Kubernetes labels per pod as cost allocation tags. Labels are sorted alphabetically, and anything past the first 50 is dropped. Some AWS-managed add-ons add labels that count toward that limit.

The setup:

  1. In Billing and Cost Management, open Cost Management preferences and enable split cost allocation data for Amazon EKS.
  2. Create a CUR 2.0 export in Data Exports with split cost allocation data included. Hourly granularity with resource IDs gives you the most detail.
  3. Activate the imported labels under Cost allocation tags in the management account.
  4. Query the export with Athena, grouping on your label columns.

One catch: split cost allocation data isn't available in Cost Explorer. It lives in CUR only. If you have one team and one cluster, I'd skip this entirely. It starts paying off when two or more teams share nodes and you need to show each team its number. I cover the label and cost-per-workload setup in more detail in migrating EKS to Graviton with Karpenter.

Can I trust Cost Explorer's forecast for runway planning?

Cost Explorer now forecasts up to 18 months out, up from 12, and trains on up to 36 months of history instead of 6. AI explanations of the forecast launched in preview, console only. In 2026 AWS added natural-language queries (April) and an "Analyze with Amazon Q" button that explains any report you configure (June).

I wouldn't put the raw forecast in a board deck. It projects from your history. A startup's next 12 months usually depend on things history doesn't contain: a big customer onboarding, a GenAI feature launch, a region expansion. Use the forecast as a baseline. Then add your known changes on top in a spreadsheet, line by line, with an owner for each.

Is Graviton5 worth migrating to?

M9g went generally available on June 10, 2026, and C9g on June 30. M9g expanded to Ireland, Singapore, Sydney, and Tokyo on September 3. AWS cites up to 25% better compute performance than Graviton4.

The part the launch coverage underplays: in us-east-1, M9g on-demand pricing runs about 9% above M8g at every size. An m9g.xlarge is $0.19568 an hour against $0.17952 for an m8g.xlarge. Ten of them run 730 hours a month at $1,428.46 versus $1,310.50, about $117.96 more for the same fleet. You only come out ahead if the speedup lets you drop capacity. Nine M9g instances cost $1,285.62, which beats ten M8g by $24.88 a month.

So my position is simple. If you're on M8g, benchmark your own workload before switching, and only move if you can shrink the fleet by roughly a tenth or more. If you're still on x86, whether your stack runs on ARM at all is a bigger question than which Graviton generation to pick. Both families are covered by Compute Savings Plans, so a commitment now doesn't block a later move. I walk through the fuller arm64 migration math, including where the per-hour gap has narrowed generation over generation, in migrating EKS to Graviton with Karpenter.

When does DIY stop being enough?

Everything above can be done in-house by one engineer with admin access and a few afternoons. The hard part is judgment, and it shows up in three places. Committing a dollar amount you'll owe every hour for a year. Deciding which architectural changes are worth the engineering time against your roadmap. Turning all of it into a runway number your CFO and board will trust.

That's what the Cloudshipped Cost Audit for AWS covers. It's fixed-scope: I go through your account, rank the changes above by effort against payoff for your specific setup, and size commitments against your real hourly floor, then hand back a written plan you can act on without me.

If you'd like a second pair of eyes before you commit, book a free discovery call.

FAQ

What changed in AWS cost optimization for startups in 2026?

The biggest changes are Database Savings Plans, Compute Optimizer recommendations for unused NAT Gateways, automated EBS cleanup, a Cost Efficiency score in Cost Optimization Hub, Bedrock Flex and Priority tiers with IAM-based cost allocation, 18-month Cost Explorer forecasts, and Graviton5 instances. Most are settings a startup team can enable without a FinOps hire.

Are Database Savings Plans better than RDS Reserved Instances?

They're more flexible, not always cheaper. Database Savings Plans offer up to 35% on serverless and up to 20% on provisioned instances, with a one-year, no-upfront term. They follow usage across engines, instance families, and Regions. For a provisioned database you won't change for years, compare Reserved Instance rates before committing.

Does Compute Optimizer find idle NAT Gateways automatically?

Yes, after you opt in. It flags NAT Gateways with no active connections and no incoming packets over a 32-day window, and checks route table associations to avoid flagging backup gateways. It won't reduce data processing charges on busy gateways; those need VPC endpoints or architecture changes.

Is Graviton5 cheaper than Graviton4?

Not per hour. In us-east-1, M9g on-demand pricing is about 9% higher than M8g at every size. AWS cites up to 25% better compute performance, so Graviton5 saves money only if that gain lets you run fewer or smaller instances. Benchmark your own workload before migrating.

Disclaimer

This article is general information, not financial, tax, or legal advice for any specific AWS account. AWS pricing, discount rates, features, and availability change over time and vary by Region and account, so confirm current details with AWS before acting. You're responsible for testing and validating any change, including deletions, automation rules, and instance migrations, in non-production before applying it to production. Cloudshipped isn't liable for costs, outages, or losses from actions taken based on this article, and isn't affiliated with or endorsed by Amazon Web Services.

Sources

Free discovery call

Find the savings your AWS bill is hiding

Book a free discovery call to see how Cloudshipped can help save you money on AWS spend.

  • Fixed price
  • 1-week target
  • Fee refunded if under 10%
Book a free Discovery Call

Prefer email? Write to support@cloudshipped.co