Understanding AWS Pricing for EC2, S3, EBS, RDS, and More

AWS runs on a simple promise: pay only for what you use, but that simplicity hides real complexity. Every service is metered on different dimensions: EC2 on compute time, S3 on stored gigabytes and requests, EBS on provisioned capacity, RDS on instance hours and storage. Understanding those dimensions is the difference between a predictable bill and a nasty surprise, and it is the first step toward cloud cost optimization.

This guide breaks down how AWS prices its most-used services, EC2, S3, EBS, and RDS, plus the ones that quietly add up, and shows the pricing models and levers that keep spend under control.

How AWS Pricing Works

At its core, AWS is pay-as-you-go: no upfront hardware, no fixed monthly fee, just metered consumption. What varies is the meter. Most services price along a few common dimensions: compute time, storage volume, requests or operations, and data transfer. Region matters too, prices differ by 10 to 30 percent between Regions, as do operating system and tenancy. This variable, usage-based model is exactly why FinOps exists, and why cloud cost forecasting is harder than traditional IT budgeting.

The four ways to pay for compute

Before the per-service detail, the most important pricing lever on AWS is how you buy compute. The same instance can cost wildly different amounts depending on the purchase model.

Commitments are the biggest single savings lever on AWS. For how they work and how to manage them without over-committing, see our cloud pricing models explained and discount manager guides.

EC2 Pricing (Compute)

Amazon EC2 is the foundation of most AWS bills. It provides resizable virtual servers, and you pay for the compute time they run. Linux instances bill by the second (with a 60-second minimum); most others bill by the second or hour depending on the OS.

Four factors drive the price: the instance type and family (general purpose, compute, memory, storage, or accelerated), the Region, the operating system (Linux is cheaper than Windows or RHEL, which carry licensing), and the purchase model above. Graviton (ARM-based) instances are typically 10 to 40 percent cheaper than comparable x86 instances at similar performance, which makes migrating to them one of the highest-leverage moves available.

Two billing nuances catch teams out. A stopped EC2 instance incurs no compute charge, but its attached EBS volume keeps billing. And matching the instance to the actual workload, rightsizing, is where most EC2 savings hide. Helping engineers understand cloud costs at provision time prevents the over-provisioning that inflates compute spend in the first place.

S3 Pricing (Object Storage)

Amazon S3 charges on four dimensions: how much you store (per GB-month, by storage class), how many requests you make (PUT, GET, and others per 1,000), how much data you transfer out, and optional management features. Inbound transfer is free, as is transfer to other AWS services in the same Region; egress to the internet is where transfer charges appear.

The largest lever in S3 is choosing the right storage class for how often data is accessed.

EBS Pricing (Block Storage)

Amazon EBS provides the persistent disk volumes attached to EC2 instances. Its pricing has one crucial catch that surprises almost everyone: you are billed for the provisioned size of a volume, and for some types the provisioned IOPS and throughput, whether or not you actually use them. Unlike S3, which charges for data stored, EBS charges for capacity allocated. That makes unattached volumes and oversized disks pure waste.

Choosing the right volume type is the main cost decision.

RDS Pricing (Managed Databases)

Amazon RDS runs managed relational databases, and its bill has several components: DB instance hours (priced by instance class and database engine), storage (per GB-month), provisioned IOPS where applicable, backup storage beyond the free allocation, and data transfer. Licensed engines such as Oracle and SQL Server cost more than open-source engines like MySQL, PostgreSQL, and MariaDB, and running Multi-AZ for high availability roughly doubles the instance cost because it runs a standby replica.

As with EC2, RDS offers Reserved Instances (1 or 3 years, up to roughly 69 percent off) for steady database workloads, and Aurora Serverless v2 bills by capacity unit for spiky ones. The common RDS overspends are idle instances left running, over-provisioned storage that never shrinks, and Multi-AZ enabled on non-production databases that do not need it. These are exactly the patterns a dedicated FinOps platform surfaces automatically.

Beyond the Big Four: Lambda, Data Transfer, and CloudWatch

Plenty of smaller line items add up. Three deserve special attention:

• Lambda is billed per request plus compute measured in GB-seconds (memory allocated times duration). It is cheap for infrequent, event-driven work and can be cost-effective versus always-on EC2, but high-volume functions with generous memory settings can surprise you.
• Data transfer is the most underestimated cost on AWS. Inbound is generally free, but egress to the internet is tiered (around $0.09/GB, dropping with volume), cross-AZ traffic is charged each way, and a single NAT Gateway adds an hourly fee plus roughly $0.045 per GB processed. Transfer often runs 20 to 30 percent of a real bill.
• CloudWatch Logs charges for ingestion (around $0.50/GB) and storage, so a verbose application or a chatty Lambda can generate meaningful log costs on its own.

The Hidden Costs That Inflate an AWS Bill

The estimate you build rarely matches the invoice, because AWS bills for things that are easy to forget. The usual culprits:

• Idle and orphaned resources: stopped instances still paying for EBS, unattached volumes, old snapshots, and unused Elastic IPs (which are charged when not attached to a running instance).
• Data transfer and NAT Gateway, as above, frequently the single largest surprise.
• Over-provisioning: instances, databases, and volumes sized for peak that run at a fraction of capacity.
• Untagged spend that cannot be attributed, which quietly hides all of the above.

Catching these requires visibility and accountability, which is why cost allocation and tagging matters so much. Strong tagging best practices make waste visible instead of letting it hide in an unattributed bucket.

How to Estimate and Optimize AWS Costs

Understanding the pricing is step one; acting on it is step two. The practical playbook:

• Estimate before you deploy using the AWS Pricing Calculator, and add a margin for data transfer and overhead.
• Right-size continuously with AWS Compute Optimizer and consolidate recommendations in the Cost Optimization Hub.
• Cover stable baseline usage with Savings Plans or Reserved Instances, and use Spot for interruptible work.
• Clean up relentlessly: delete unattached volumes, old snapshots, idle databases, and unused IPs.
• Move to Graviton and gp3 where you can for immediate, low-risk savings.

For the native tooling and the operating practice around it, see our guides to AWS Compute Optimizer, the AWS Cost Optimization Hub, and AWS cost optimization with FinOps. A fuller strategy list lives in our cloud cost optimization strategies guide.

Where AWS Pricing Fits Into FinOps

Knowing how each service is priced is the foundation of cloud financial management, but the real value comes from tying that spend to business outcomes. That means attributing cost to teams and products, tracking unit economics like cost per customer, and comparing options across providers, as in our AWS vs Azure pricing and AWS vs Azure vs GCP comparisons. For the complete picture, our cloud cost management guide and FinOps guide put AWS pricing in the wider context of visibility, allocation, and governance. And as AI workloads grow, the same discipline extends to GPUs and tokens, covered in FinOps for AI.

Conclusion

AWS pricing is not one model but many, each service metered on its own dimensions. EC2 charges for compute time, with four purchase options that swing the price by up to 90 percent. S3 charges for storage class, requests, and egress. EBS charges for provisioned capacity whether used or not. RDS charges for instance hours and storage. And the hidden costs, data transfer, NAT Gateway, idle resources, are where bills quietly balloon. Understand the dimensions, buy compute the right way, clean up waste, and attribute every dollar, and AWS becomes a predictable, optimizable line item rather than a monthly surprise. If you want help turning that understanding into governed, optimized spend, that is exactly the discipline Opslyft brings.