All Articles
AWS
Cloud Costs
FinOps
Indian Startups
Startup Engineering

AWS Cost Optimization Best Practices for Startups: A Ranked List for 2026

Ten AWS cost optimization best practices for a seed stage startup, ranked by effort against what AWS documents each one saves, with India billing notes and a link to every AWS price.

Avinash S
March 26, 2026
14 min read
Prefer us on Google
Illustration for AWS Cost Optimization Best Practices for Startups: A Ranked List for 2026, covering AWS, Cloud Costs, FinOps

These are the AWS cost optimization best practices a seed stage team should run, ranked in the order that returns the most money for the least risk: see the bill, delete what nobody owns, fix the defaults, schedule what sleeps, and only then commit to discounts. Each practice below carries the effort it takes and what it saves in the terms AWS itself documents, with a link to the AWS page that says so.

The list is written for a startup of five to thirty engineers, often in India, with an AWS bill that has grown faster than anyone planned and nobody whose job is to watch it. Most published lists of AWS cost tips are written for companies with a FinOps team and a seven figure annual spend. They lead with Savings Plans and Reserved Instances because at that size commitments are the biggest lever. At seed stage the order is close to the reverse, because a commitment made before the architecture settles is the one cost mistake no console change can undo.

Every list price below is quoted for us-east-1 from the AWS pricing page linked beside it, unless stated otherwise. Where the post gives judgement rather than a documented fact, it says Practitioner opinion.

What are AWS cost optimization best practices?

AWS cost optimization best practices are the habits and configuration changes that make an AWS account deliver the same workload for less money, without slowing the team down. AWS groups them in the Cost Optimization Pillar of the Well-Architected Framework into five areas: practise cloud financial management, build expenditure and usage awareness, use cost effective resources, manage demand and supply, and optimise over time. A ranked list turns those five areas into an order of work.

The pillar is written for any organisation; the ranking is what changes with size. A seed team has more waste than commitment opportunity and an architecture that will change within six months, so the first practices are the ones that need no forecast.

Quick context: the India billing reality first

If your AWS contact and billing address is in India, your agreement is with Amazon Web Services India Private Limited and your invoice total is listed in INR, as AWS documents in its guide to managing accounts in India. Add your PAN so the tax invoice supports a GST input credit claim; that is money recovered before any engineering work starts.

Two more India specifics shape the list. AWS now runs two Indian regions, Mumbai (ap-south-1) and Hyderabad (ap-south-2), the second opened in November 2022, and hourly prices differ by region, so read every pricing page with the region selector set to where you actually run. And AWS Activate lists a Founders tier of up to $5,000 for self funded startups and a Portfolio tier of up to $200,000 for startups backed by a participating accelerator or investor. Credits are issued in USD even on an India billed account. Apply before you optimise anything, because credits cut the bill with zero engineering hours.

For the India specific version of this work at a bill under Rs 5 lakh a month, how to reduce cloud costs for a seed stage startup in India goes deeper. This post is the ranked, general list.

The ranked list of AWS cost optimization best practices

1. Make the bill readable before you change anything

Effort: one hour, then a day of waiting. Saves: nothing directly. It is what makes every later saving attributable.

Apply three tags to every resource (environment, service, owner) and activate them as cost allocation tags. AWS documents that tag keys can take up to 24 hours to appear and up to 24 more to activate, so do this the day before you start. Then set two guardrails. AWS Budgets charges nothing for budgets without actions, and the first two action enabled budgets each month are free, with $0.10 a day for each one after that. AWS Cost Anomaly Detection is offered at no additional cost and reads from Cost Explorer, which is why its alerts can lag by up to a day.

The Well-Architected pillar calls this expenditure and usage awareness, and it ranks first here because without it every later step produces a total nobody can assign to a team or a service. If the bill has already jumped and you need answers this week, use the AWS bill doubled triage runbook instead, then come back to this list.

Takeaway: tags, one budget at 80 percent of plan, and anomaly detection on. Nothing else on this list gives a useful number without them.

2. Delete what nobody owns

Effort: an afternoon. Saves: the full cost of each resource, with no performance trade.

This is pure waste: charges with no workload behind them. Since 1 February 2024 AWS bills $0.005 per hour for every public IPv4 address, attached or idle, which is about $3.60 a month each. An unattached EBS volume is billed at the same $0.08 per GB-month for gp3 or $0.10 for gp2 as an attached one, and snapshots at $0.05 per GB-month for as long as they exist.

Start with one command that lists every volume attached to nothing:

aws ec2 describe-volumes --filters Name=status,Values=available

Snapshot anything you are unsure about, then delete the volume.

Takeaway: this is the only practice where the right action is almost always deletion. Do it first and bank the result before anything that needs a debate.

3. Move every gp2 volume to gp3

Effort: minutes per volume. Saves: 20 percent of the per-GB storage price.

The gp2 volume type is still the default in plenty of older templates and AMIs. On the EBS pricing page gp3 costs $0.08 per GB-month against $0.10 for gp2, a flat 20 percent less, and gp3 starts at a baseline of 3,000 IOPS regardless of size, where gp2 scales IOPS with the size of the volume. On the small volumes a seed team runs, gp3 is usually both cheaper and faster.

The change does not need downtime. AWS documents modifying the type of an attached volume with Elastic Volumes, so the instance keeps running while the volume converts. The one check worth making is on very large gp2 volumes that were sized up specifically to buy IOPS: confirm the IOPS and throughput you set on gp3 match what the workload actually uses.

Then fix the source, not just the volumes. Change the default in your Terraform modules, launch templates and any AMI pipeline, or the next environment arrives on gp2 again.

Takeaway: a twenty percent cut on block storage for a change that takes minutes and no downtime. Few AWS cost optimization best practices have a better ratio.

4. Schedule non-production to sleep

Effort: half a day. Saves: AWS documents up to 70 percent on instances needed only in business hours.

A week has 168 hours. A development environment used during one team's working day is needed for roughly 50 of them. Everything billed by the hour in a non-production account is therefore paying for about three times the hours anyone uses.

AWS ships the fix as a supported solution rather than a service. Instance Scheduler on AWS uses resource tags and Lambda to stop and start EC2 instances, Auto Scaling groups and RDS databases across accounts and regions, and AWS states it can save up to 70 percent on instances only needed during regular business hours. For a team in Bengaluru or Chennai, set the schedule in Asia/Kolkata.

Are you overpaying for cloud?

Take the 2-min cost quiz →

Two cautions keep the schedule alive. Stopping an instance stops compute charges, not storage charges, so the volumes keep billing. And a database that takes several minutes to start will annoy someone exactly once before the schedule is quietly switched off, so start it before the first stand-up, not at it.

Takeaway: schedule the development account first, leave staging until the pattern has survived two weeks.

5. Take S3 and DynamoDB traffic off the NAT gateway

Effort: an hour of Terraform. Saves: the $0.045 per GB NAT processing charge on that traffic.

A managed NAT gateway bills twice: $0.045 per gateway-hour plus $0.045 for every GB processed. The hourly charge is roughly $32 a month per gateway and easy to see. The per-GB charge scales with traffic nobody is watching, such as private subnet services pulling objects from S3 or writing to DynamoDB.

Those two services have a free path. AWS documents that gateway endpoints for S3 and DynamoDB carry no additional charge, and traffic routed through them never touches the NAT gateway. Adding them is a route table change.

Read the gateway's processed bytes metric first; it tells you in one number whether this is a rounding error or one of your largest lines. While you are on the network, check cross zone traffic too: data moving between availability zones in the same region is billed per GB in each direction. If internet egress itself is your biggest line, the rates by provider are in cloud egress costs across AWS, GCP and Azure.

Takeaway: gateway endpoints are free and remove a per-GB charge entirely for the two services most backends call constantly.

6. Rightsize compute, and test Graviton

Effort: a day, spread over a fortnight. Saves: the gap between what you provisioned and what you use, plus up to 20 percent on instance price for compatible workloads.

Rightsizing is the best known practice on this list and the most often skipped, because somebody has to accept a performance change. The analysis is free. AWS Compute Optimizer reads utilisation history and returns per-resource recommendations, including idle instances. Cost Optimization Hub gathers those recommendations across accounts and regions and deduplicates the savings, so an instance flagged both idle and oversized is not counted twice.

The second lever is the processor. AWS states that Graviton based instances cost up to 20 percent less than comparable x86 instances. That is a ceiling for workloads that already run on ARM, and most interpreted language services do; compiled binaries and some native dependencies need a rebuild and a test first.

Takeaway: the recommendations are already in your console. The work is deciding which are safe this quarter and writing down why the others are not.

7. Set a retention on every log group

Effort: an hour. Saves: storage on logs nobody reads, and up to half the ingestion price on logs you keep for incidents.

Observability spend is generated by code and billed by volume, and nobody revisits the settings after the service ships. CloudWatch Logs bills Standard ingestion at $0.50 per GB for the first 10 TB a month, with storage at $0.03 per GB-month after that. Retention is set per log group and the default is never expire, so a debug log from two years ago is still on the bill.

There is now a cheaper class for logs you keep but rarely read. AWS launched the CloudWatch Infrequent Access log class in March 2026 at $0.25 per GB ingested, half the Standard rate. For India based teams, check your retention against your own obligations before you shorten it: CERT-In's directions require some logs to be kept for 180 days, which the early stage AWS account security guide covers.

Takeaway: list every log group with its retention next to its monthly ingested volume. The two columns together are the finding.

8. Put lifecycle rules on S3 from day one

Effort: an hour per bucket pattern. Saves: the difference between the Standard price and a colder class on data nobody reads.

Build artefacts, exports and logs land in S3 Standard and stay there. A lifecycle rule moves them to a colder class on a schedule, but the colder classes carry minimum billable durations on the S3 pricing page: 30 days for Standard-IA and One Zone-IA, 90 days for Glacier Instant Retrieval and Glacier Flexible Retrieval, and 180 days for Glacier Deep Archive. Delete or move an object before that and you pay the remainder anyway.

When access patterns are unpredictable, S3 Intelligent-Tiering moves objects between tiers automatically for a monitoring charge of $0.0025 per 1,000 objects a month, with no monitoring charge for objects under 128 KB. Practitioner opinion: the arithmetic follows object count, not bytes. It is close to free money on a bucket of large cold artefacts and a new line item on a bucket of ten million thumbnails.

Takeaway: set the rule when the bucket is created, and check object counts before switching on automatic tiering.

9. Use Spot for work that can be interrupted

Effort: a day per workload. Saves: AWS states up to 90 percent against On-Demand.

EC2 Spot Instances sell spare capacity at up to 90 percent off On-Demand prices, in exchange for AWS being able to reclaim the instance with a two-minute interruption notice. That trade is excellent for CI runners, batch jobs, data pipelines, queue workers and test environments, and wrong for a single instance database or anything that cannot be restarted cleanly.

The practice that makes Spot safe is diversification: ask for several instance types across several availability zones, so one pool being reclaimed does not take the whole workload down.

Practitioner opinion: at seed stage the CI fleet is often the easiest first target, because a build that is interrupted simply runs again and nobody outside engineering ever notices.

Takeaway: move one interruptible workload to Spot with at least three instance types, and watch interruption rates for a month before moving the next.

10. Commit last, and only to the floor

Effort: an hour, after two stable quarters. Saves: up to 72 percent on the committed usage.

AWS Savings Plans trade a dollar per hour commitment over one or three years for up to 72 percent off On-Demand prices, with the flexible Compute Savings Plan reaching up to 66 percent and applying across instance families, regions, Fargate and Lambda. This is the largest single lever on the list, and it sits last for a reason: it is a contract.

Practitioner opinion: a seed team that commits a month before moving off a monolith, changing its database or adding a region for a customer has bought a discount on infrastructure it is about to stop running. Every practice above also lowers the floor you would commit to.

When you do commit, cover the steady minimum you are confident about, not the average, and prefer the Compute plan over the EC2 Instance plan while the architecture is still moving. The question of whether a team this size needs a formal practice around this is answered in does a startup need the FinOps Framework.

Takeaway: commit to the floor after two stable quarters, and put the remainder on a calendar reminder rather than a contract.

Summary table

RankPracticeEffortWhat AWS documents it saves
1Tags, Budgets, Cost Anomaly Detection1 hour plus a day of waitingNo direct saving; makes savings attributable. Budgets without actions are free
2Delete unowned resourcesAn afternoon$0.005 per public IPv4 per hour; $0.08 to $0.10 per GB-month per idle volume
3gp2 to gp3Minutes per volume20 percent per GB, 3,000 IOPS baseline
4Schedule non-productionHalf a dayUp to 70 percent on business hours instances
5Gateway endpoints for S3 and DynamoDBAn hourRemoves $0.045 per GB NAT processing on that traffic
6Rightsize and test GravitonA day over a fortnightGraviton up to 20 percent less than comparable x86
7Log retention and Infrequent AccessAn hour$0.50 to $0.25 per GB ingested
8S3 lifecycle rulesAn hour per patternColder class price, minus minimum duration traps
9Spot for interruptible workA day per workloadUp to 90 percent against On-Demand
10Savings Plans on the floorAn hour, after two stable quartersUp to 72 percent; Compute plan up to 66 percent

Which practices to run at your stage

Pre-seed, bill under about $1,000 a month. Claim Activate credits, then run practices 1 to 3. They take a day between them and need no forecast. Practitioner opinion: below this size every further hour is usually better spent on the product.

Seed, five to fifteen engineers. Run 1 to 8 in order over a month. Assign one named owner for the monthly review of the budget alerts and anomaly findings, because waste comes back the moment several engineers can launch resources on their own.

Series A, or two stable quarters behind you. Add Spot for CI and batch work, then a Compute Savings Plan sized to the steady floor. This is also the point where a one-off pass stops being enough and the review needs a standing owner. What a cloud cost audit finds shows what that review reads.

Where to start this week

Practices 1 and 2 fit in one working day and need nobody's approval. If the review needs a standing owner and nobody on the team has the hours, that ownership is what MatrixGard provides as a fractional DevSecOps retainer covering cost, security and reliability together; the published Starter tier on matrixgard.com/pricing is $2,500 a month. Either way, start with the free checklist: open the cloud security and cost checklist.

Avinash S is the founder of MatrixGard. Fractional DevSecOps for early-stage startups, funded or bootstrapped across India, the GCC, the UK, and the US. Almost a decade of building, breaking, and securing cloud infrastructure for fintech, healthtech, and SaaS workloads.


Methodology note. This post answers the search for AWS cost optimization best practices as a ranked order of work for a seed stage team. The five practice areas are from the AWS Well-Architected Cost Optimization Pillar. Every price, percentage, free allowance and minimum duration is quoted from the AWS pricing page, documentation, What's New post or AWS blog linked beside it, for us-east-1 unless stated, and checked in October 2026; prices in ap-south-1 and ap-south-2 differ, so confirm them with the region selector. The ranking, the effort estimates and the stage advice are practitioner opinion. This version replaces an earlier draft of the page and removes every unsourced figure it carried. No client outcome, testimonial or price other than MatrixGard's published one appears in this post.

MatrixGard

Ready to cut your cloud bill?

MatrixGard is a fractional DevSecOps practice: one senior engineer who runs your cloud, infrastructure and security together on a monthly retainer. Industry surveys put 20-40% of cloud spend on resources nobody owns, and MatrixGard goes and finds yours. We are a Google Cloud Partner Advantage member and registered in the AWS Partner Network. Fixed price, money-back guarantee.

Book a free review

The notes, not the newsletter

One practical thing a week about running cloud infrastructure without a security team. Written by me, not generated.

Not an email person? One click, no signup: Google shows you our posts first.

Add MatrixGard as a preferred source