How AWS Billing Works: Free Tier, On-Demand, Savings Plans and Budgets
Learn how AWS billing works, from metered usage and the Free Tier to Savings Plans, Spot Instances, budgets and the charges that catch teams out.
AWS billing is usage based: almost every service meters something (instance hours, GB stored, requests, data transferred) and you pay for what was consumed at the end of each month. Understanding how the Free Tier, On-Demand rates, Savings Plans and budgets fit together is the difference between a predictable bill and an unpleasant surprise.
What actually generates a charge #
Each AWS service publishes its own pricing dimensions. A single application often touches several of them at once, which is why bills can look more complicated than the architecture diagram suggests.
- Time-based resources: EC2 instances, RDS databases, NAT gateways and load balancers are billed while they exist or run, typically per second or per hour depending on the service and operating system.
- Capacity-based resources: EBS volumes, S3 storage and snapshots are billed per GB-month, whether or not anything reads them.
- Request-based resources: Lambda invocations, API Gateway calls, S3 requests and DynamoDB on-demand reads and writes are billed per request or per unit of work.
- Data transfer: Inbound traffic from the internet is generally free, while outbound traffic to the internet, traffic between Regions and some traffic between Availability Zones is charged.
- Public IPv4 addresses: AWS charges for public IPv4 addresses, including those attached to running instances, so they appear on bills even for small setups.
Charges accrue in near real time and are totaled on a monthly invoice. The Billing and Cost Management console shows month-to-date spend and a forecast, though the data can lag actual usage by several hours.
The AWS Free Tier #
The Free Tier is not a single allowance. It is a set of offers that differ by service, and AWS changed its structure for new accounts in July 2025. Always check the official AWS Free Tier page for the terms that apply to your account.
Accounts created from mid-2025 onward
At the time of writing, new AWS customers receive promotional credits at sign-up, with additional credits available for completing guided activities in the console, and they choose between a free plan and a paid plan. The free plan is time-limited and credit-limited: when either runs out, the account must be upgraded to continue, and some services are not available on the free plan. The paid plan applies credits against eligible usage and then bills normally. Confirm the current credit amounts and plan duration on the official page, as these are promotional terms that can change.
Accounts created before the change
Older accounts were placed on the previous model, which combined 12-month free offers (for example, a limited number of hours per month on certain small EC2 instance types) with always-free offers and short trials. Those accounts continue under the terms that applied when they were created.
Always-free offers
Some services include a monthly free allowance that does not expire, such as a set number of Lambda requests and DynamoDB storage. Usage above those allowances is billed at normal rates.
Pricing models compared #
Once you are past experimentation, the main lever on compute cost is the purchasing model. The same EC2 instance can cost very different amounts depending on how you commit to it.
| Model | Commitment | Best for | Trade-off |
|---|---|---|---|
| On-Demand | None | New workloads, unpredictable or short-lived usage | Highest per-unit rate |
| Savings Plans | A fixed spend per hour for 1 or 3 years | Steady baseline compute across EC2, Fargate and Lambda | You pay the commitment even if usage drops |
| Reserved Instances | Specific capacity for 1 or 3 years | RDS, ElastiCache, OpenSearch, Redshift and some EC2 cases | Less flexible than Savings Plans |
| Spot Instances | None | Fault-tolerant batch jobs, CI runners, stateless workers | Can be interrupted with a two-minute warning |
How Savings Plans work
A Savings Plan is a commitment to spend a certain amount per hour (for example, a fixed dollar figure every hour) for a one-year or three-year term. Usage up to that amount is billed at discounted rates; anything above it is billed at On-Demand rates. You can pay all upfront, partially upfront, or with no upfront payment, and larger upfront payments generally earn a larger discount.
There are three types. Compute Savings Plans apply across EC2 instance families, Regions, operating systems, Fargate and Lambda, which makes them the most flexible. EC2 Instance Savings Plans are tied to an instance family in one Region in exchange for a deeper discount. SageMaker Savings Plans apply to eligible Amazon SageMaker usage. Full details are on the official Savings Plans page.
Sizing a commitment
Cost Explorer produces Savings Plans recommendations based on your recent usage history. A cautious approach is to commit only to the baseline you are confident will persist, let On-Demand cover peaks, and add further plans later. Committing to a figure you later cannot use is the most common Savings Plans mistake.
Setting up billing guardrails #
These steps take under an hour and cover most of the risk for a new or small account.
- Create a cost budget in AWS Budgets. Set a monthly amount and alerts at, for example, 50, 80 and 100 percent of actual spend, plus an alert on forecasted spend. Budgets notify you; by default they do not stop resources.
- Enable Free Tier usage alerts in the billing preferences if your account uses Free Tier offers.
- Turn on Cost Anomaly Detection so unusual spending patterns trigger a notification even when they stay under your budget.
- Activate cost allocation tags such as
project,environmentandowner. Tags only appear in cost reports after you activate them in the billing console, and they are not applied retroactively. - Grant billing access deliberately. IAM users and roles cannot see billing data until the root user enables IAM access to billing, and then only if their policies allow it.
- Use consolidated billing through AWS Organizations if you run several accounts, so volume pricing and Savings Plans can apply across them.
Budget actions can go further, for example applying a restrictive IAM policy or stopping specific EC2 or RDS instances when a threshold is reached. These need careful testing, since stopping production resources automatically is rarely what you want.
Common sources of unexpected charges #
Resources left running
Test instances, idle RDS databases, unattached EBS volumes, old snapshots and Elastic IPs are frequent culprits. Stopping an EC2 instance stops compute charges, but attached EBS volumes are still billed.
NAT gateways and data transfer
NAT gateways carry an hourly charge plus a per-GB processing charge. Architectures that route large volumes of traffic through them, or that move data across Regions or Availability Zones, can generate significant costs. VPC gateway endpoints for S3 and DynamoDB can reduce NAT traffic.
Logs and metrics
CloudWatch Logs ingestion and storage add up quietly, especially with verbose debug logging and no retention policy. Set a retention period on every log group.
Other Regions
Resources created in a Region you rarely look at are easy to forget. Cost Explorer can group spend by Region to reveal them.
Reading and analyzing your bill #
Cost Explorer is the quickest way to answer “what changed?” Group by service, then by usage type, to see whether a spike came from compute hours, storage or data transfer. For detailed analysis, Data Exports can deliver the Cost and Usage Report to S3 for querying with Athena or loading into a BI tool.
The AWS documentation includes the Billing and Cost Management user guide, and the AWS Pricing Calculator lets you estimate an architecture before building it. For provider-neutral habits such as tagging strategies and right-sizing, see our guide to cloud cost management with budgets, tagging and right-sizing. If you are still getting oriented, our walkthrough of AWS core services explains the resources behind each line item, and the AWS overview page covers the platform at a higher level.
AWS billing: frequently asked questions #
Can I set a hard spending limit on AWS?
AWS does not offer a simple account-wide hard cap. AWS Budgets sends alerts and budget actions can apply IAM policies or stop selected instances, but you should treat these as safeguards and still review resources regularly.
Do Savings Plans apply automatically?
Yes. Once purchased, a Savings Plan is applied automatically to eligible usage each hour, starting with the usage that gives the highest discount. You do not assign it to specific resources.
What happens when my Free Tier offers end?
It depends on your account’s plan. On the newer free plan, you must upgrade to a paid plan to keep using the account once credits or the plan period run out. On paid accounts and older Free Tier accounts, usage simply starts being billed at standard rates, so review running resources before the end date.
Are Spot Instances safe for production?
They are suitable for production workloads that tolerate interruption, such as stateless web tiers behind an Auto Scaling group with mixed instance types, or queue-driven workers. They are a poor fit for single-instance databases or anything that cannot handle a two-minute shutdown notice.
