Cloud Cost Optimization: How to Reduce AWS Costs Without Breaking Things

What makes it hard to reduce AWS costs safely is that a cloud bill does not measure consumption. It measures capacity a provider committed to you. AWS stops charging for a stopped instance, but charges continue for its Elastic Block Store volumes and for any Elastic IP address still attached. That gap between provisioned and used is where nearly all cloud waste sits, and it exists because a Region is a building full of racks bought, powered and cooled long before anyone asked for a virtual machine.

What is cloud cost optimization?

Cloud cost optimization is the practice of lowering what an organization pays for cloud services without lowering the performance, availability or delivery speed they support. The AWS Well-Architected cost optimization pillar states the target plainly: a cost-optimized workload fully utilizes all resources, achieves an outcome at the lowest possible price point, and meets your functional requirements. Most teams work on the price point. Few measure the utilization, which is where the larger number hides.

• Cloud bills price reserved capacity rather than consumption, which is why a stopped EC2 instance still costs money for its storage volumes and its Elastic IP address.
• Overprovisioning is the largest source of waste: a 2025 study of about 48,000 production virtual machines at SAP found over 80% using less than 70% of the resources provided.
• Rate changes are safer than architecture changes. AWS Savings Plans cut compute rates by up to 72% against on-demand pricing without any change to application code.
• Data transfer is billed by the gigabyte even though providers buy network capacity by the port, which is why egress is the least predictable line on most bills.
• Kubernetes sizes nodes from the resource requests engineers declare rather than measured usage, so a cluster can be full and idle at once.
• FinOps is an operating model rather than a tool: the FinOps Foundation defines it as a practice that creates financial accountability across engineering, finance and business teams.

Why is my AWS bill so high?

Amazon Web Services prices infrastructure against capacity because capacity is what it bought. Before an instance launches, someone specified a server, a rack position, a power feed sized to a breaker, cooling to carry the heat away, and ports at the top of the rack. That is paid for in advance and depreciates on a schedule. Charging hourly for a reservation is what recovers it, which is why AWS will not charge for a stopped instance but will keep charging for the storage behind it.

The overheads are larger than most software teams assume. Uptime Institute put the industry average annual power usage effectiveness at 1.58 in 2023, falling to 1.47 when weighted by installed capacity, so roughly half a watt of facility overhead accompanies every watt reaching a processor. A rack has a fixed power and cooling envelope, and a provider earns the building back only by filling that envelope with paying load. Your bill is a slice of that envelope, priced to stay profitable whether you use it or not.

This is also why efficiency shows up as price. AWS states that Graviton-based instances cost up to 20% less than comparable x86-based EC2 instances and use up to 60% less energy for the same performance. That discount is a power and cooling saving passed partly to the customer.

How do you find the waste before you change anything?

Nothing can be cut safely until spend has an owner. AWS cost allocation tags come in two kinds, AWS-generated and user-defined, and both must be activated separately in the billing console before they appear in Cost Explorer or a cost allocation report. Start tagging in week one, because the report groups only what was tagged and activated when the cost was incurred.

Three AWS cost optimization features then do most of the discovery work. AWS Compute Optimizer analyzes CloudWatch utilization metrics from the last 14 days across instances, Auto Scaling groups, storage volumes, Lambda functions, Fargate services, databases and NAT gateways, then reports whether each is optimal, over-provisioned or idle. Cost Optimization Hub consolidates rightsizing, idle resource deletion, Savings Plans and Reserved Instance recommendations into one view and deduplicates them, so two cannot claim the same dollar. AWS Cost Anomaly Detection runs machine learning monitors over service, account, tag or cost category dimensions and names the top root cause for each spike.

AWS also publishes its own list of ten things you can do today to reduce AWS costs. The first six are deletion rather than optimization: low-utilization instances and volumes, objects in the wrong storage class, idle database and warehouse instances, unmanaged table capacity, and idle load balancers. Clear those before touching anything a customer can see.

How much does rightsizing save, and what breaks?

Rightsizing is changing a resource’s size or type so that its provisioned capacity matches measured demand plus a stated amount of headroom. The second half is the part teams skip, and skipping it turns a cost project into an incident.

That same SAP measurement study found memory requests tracking real usage far more closely than CPU. Processors idle quietly, so nobody notices the waste. Memory runs out loudly, so everyone pads it.

Two cautions before acting on a recommendation. First, the default lookback in Compute Optimizer is 14 days, extendable to 93 days with the paid enhanced infrastructure metrics preference. Any workload with a monthly close, a quarterly batch or a seasonal peak needs the longer window, or the tool recommends a size that fails in week five. Second, it reads CPU by default and can ingest external memory metrics from observability products. Without memory data, a recommendation is half-blind.

Two adjacent wins belong in the same pass. Non-production environments rarely need to run overnight, and AWS documents Instance Scheduler and EventBridge rules for scheduled stops and starts. Storage follows the same logic: S3 Intelligent-Tiering moves objects untouched for 30 days to an Infrequent Access tier and, after 90 days, to Archive Instant Access, for a per-object monitoring fee and no retrieval fees. Objects under 128 KB are never monitored, so a bucket of tiny files gains nothing.

Reserved Instances, Savings Plans or Spot: which discount should you buy?

Rate optimization changes the price of what you already run, so it is the lowest-risk lever available. It is also the easiest to get backwards: buy commitments before rightsizing and you have contracted to keep paying for waste. AWS Savings Plans trade a commitment measured in dollars per hour, over one or three years, for savings of up to 72%. A Compute Savings Plan applies regardless of instance family, size, operating system, tenancy or Region, and covers Fargate and Lambda as well as EC2.

• Savings Plans first, for the steady baseline. AWS now recommends Savings Plans over Reserved Instances for compute, as more flexible at the same headline discount.
• Reserved Instances where the attributes really are fixed. A reservation is a billing discount tied to instance type, Region, tenancy and platform. Standard reservations discount most but cannot be exchanged, Convertible ones discount less but can, and none can be cancelled once purchased.
• Spot for anything interruptible. Spot Instances use spare capacity at up to 90% off on-demand prices, with a two-minute interruption notice and an earlier rebalance signal when a Spot Instance is at elevated risk. Spot spend is not covered by Savings Plans and does not draw down a commitment.

In change-management terms, a three-year all-upfront commitment is an irreversible decision with a three-year blast radius, taken on a forecast. Cover the baseline you are confident about, leave growth uncommitted, and revisit quarterly. A partial commitment that is fully used beats a large one that strands.

Why is data transfer such a large part of an AWS bill?

Egress is data leaving a boundary that carries a charge, and it is the line teams predict worst. AWS charges nothing for inbound transfer and nothing for traffic within a single Availability Zone, charges for cross-zone traffic, and gives 100 GB of free outbound transfer each month, aggregated across services and Regions. Everything past that is per gigabyte, at rates that vary by Region.

Network address translation is the quiet one. A NAT gateway costs about $0.045 an hour plus about $0.045 per gigabyte processed in the US East (Ohio) Region, so it bills before a byte moves and bills again for traffic to AWS services you could have reached privately. Gateway-type VPC endpoints carry no hourly or data processing charge, which makes routing S3 and DynamoDB traffic through one the cheapest change here. AWS also waives data transfer between CloudFront and AWS origins, so public traffic belongs behind the content delivery network.

The structural reason egress stays expensive is worth knowing before you try to negotiate it. Providers buy transit as committed capacity, a port and a monthly commit, then resell it by the gigabyte. Cloudflare’s 2021 analysis noted that wholesale transit prices fell about 23% a year over a decade, leaving bandwidth 93% cheaper than ten years earlier. AWS egress fees fell 25% over the same period, and did not fall at all in North America and Europe after 2018. The cost of the port changed. The price of the byte did not. Architecture is the lever, not procurement.

How do you reduce Kubernetes costs without causing outages?

Kubernetes is where cloud cost optimization gets counterintuitive. A CNCF microsurvey run from June to November 2023, with just over 100 responses, found Kubernetes had driven cloud spend up for 49% of respondents. Over-provisioning led the causes at 70%, and 38% had no Kubernetes cost monitoring at all.

The mechanism is in the scheduler. Kubernetes places pods using the resource requests you declare, so requests, not usage, decide how many nodes you pay for. The documentation also explains why engineers inflate them: CPU limits are enforced by throttling while memory limits are enforced reactively by out-of-memory kills. Too little CPU makes a service slow. Too little memory makes it die. Faced with that asymmetry every team pads, and the padding is billed as whole nodes.

• Measure per-namespace and per-team cost before changing any request, so the conversation is about a team’s own number, not a cluster average.
• Set CPU requests from observed percentiles and keep CPU limits generous, since throttling degrades quietly.
• Keep memory requests close to real peak usage and set memory limits deliberately, because that setting decides whether a pod survives a spike.
• Let a node autoscaler reclaim the slack. Karpenter consolidation removes empty nodes, moves workloads that can run elsewhere, and replaces nodes with cheaper equivalents.

What is FinOps, and does a small team need it?

The FinOps Foundation framework defines FinOps as an operational framework and cultural practice which maximizes the business value of technology, enables timely data-driven decision making, and creates financial accountability through collaboration between engineering, finance and business teams. It sets out three phases, Inform, Optimize and Operate, across four domains of practice.

It is a serious discipline at scale. The State of FinOps 2025 report drew 861 respondents representing about $69 billion in public cloud spend, and workload optimization and waste reduction was their top priority by a clear margin. For a team of ten, the framework is heavier than the problem. A small team needs something narrower: one named owner for the bill, tags that resolve to a team or product, an anomaly alert in a channel people read, and a monthly review. Adopt the phases once more than one team can spend without asking.

Sigi Technologies has no published cloud cost reduction engagement, so nothing here is offered as a client result. What Sigi has is delivery experience with these services. The 3DLogistiX warehouse platform runs on AWS and is provisioned with CDK. API Gateway and Lambda absorb spiky integration traffic at the edges, S3, CloudFront and Amplify serve the web bundle and facility model assets, and persistent services hold the WebSocket connections. Cost work of this kind sits inside Sigi’s DevOps and cloud engineering service, which covers infrastructure as code, cloud security and optimization, and advisory engagements for teams whose cloud costs are growing without clear governance.

In what order should you reduce AWS costs?

1. Turn on cost allocation tags and a tagging standard, then wait a full billing cycle so later steps argue from data, not memory.
2. Delete what nobody owns: unattached volumes, idle load balancers, stale snapshots, orphaned Elastic IP addresses and environments that outlived their project.
3. Schedule non-production environments off outside working hours, the largest saving available that cannot affect a customer.
4. Rightsize against a 93-day window with a written headroom policy, one tier at a time, starting with the widest gap between provisioned and used.
5. Fix data transfer: private endpoints for AWS service traffic, a content delivery network in front of public traffic, and a review of every cross-zone hop.
6. Only then buy commitments, covering the baseline you are confident about, with a quarterly review to extend coverage as that baseline settles.
7. Wire up anomaly detection and a monthly review so the savings do not quietly reverse over the next two quarters.

Related reading

Tenancy decides how much of a bill each customer is responsible for, covered in multi-tenant SaaS architecture, and the AWS build behind these examples is the 3DLogistiX warehouse platform case study. For budgeting a build rather than an estate, see how much it costs to build a mobile app. Teams moving an existing estate should read cloud migration services and CI/CD automation. Infrastructure work sits with DevOps and cloud engineering, product platforms with SaaS development or custom software development. To put an engineer on this, talk to Sigi.