Inside AWS Pricing - How Per-Second, Per-Millisecond, and Per-Request Billing Actually Works
Discover how AWS's diverse billing granularities, including EC2's per-second billing, Lambda's per-millisecond billing, and S3's per-request billing, are measured, aggregated, and invoiced through the metering system.
The Evolution of Billing Granularity - From Hourly to Per-Millisecond
AWS billing granularity has become finer over the history of its services. When EC2 launched in 2006, it used hourly billing. Even if you used an instance for just one minute, you were charged for a full hour. In October 2017, AWS changed EC2 billing to per-second (with a 60-second minimum). This change meant that for short batch jobs or spot instance interruptions, you are charged only for the actual usage time. Lambda went even finer, changing from 100ms increments to 1ms increments in 2020. With 100ms billing, even a 1ms execution was charged for 100ms, but with 1ms billing, that rounding up no longer wastes billable time. How much your bill actually drops depends on the distribution of your functions' execution times, so check the Duration of your own functions to judge the effect. Fargate uses per-second billing (1-minute minimum), RDS uses per-second billing (10-minute minimum), and S3 uses request count and data volume-based billing. Each service has different billing granularity. This diversity is a design decision to provide the optimal billing model for each service's usage patterns.
The Metering System - How Usage Is Measured
Behind AWS billing lies a metering system that collects and aggregates enormous volumes of usage data. Each service records usage events (instance starts/stops, API requests, data transfer volumes, etc.) as metering records. For EC2, the time from instance start to stop is measured in seconds (with a 60-second minimum), and the difference is recorded as usage seconds. For Lambda, function execution time is measured in 1ms units. The internal components that perform this measurement are not publicly documented, but the billable granularity is stated on each service's pricing page. For S3, each request is logged and counted by request type (GET, PUT, DELETE, etc.). These metering records are aggregated through AWS's internal pipeline and ultimately provided to customers as the Cost and Usage Report (CUR). Each row in the CUR corresponds to a single usage record, and for large-scale AWS environments, this can reach hundreds of millions of rows per month. Since metering accuracy directly affects billing fairness, AWS maintains the reliability of its metering system at an extremely high standard.
The Complexity of Data Transfer Pricing - Why It's Hard to Understand
The most difficult part of AWS pricing to understand is data transfer charges. Data transfer pricing varies based on the direction of data movement, the source and destination regions, the source and destination services, and data volume tiers. As a basic rule, data transfer into AWS (ingress) is free, while data transfer from AWS to the internet (egress) is charged. However, data transfer within the same AZ is free, while data transfer between different AZs in the same region is charged ($0.01/GB) (as of August 2026). Data transfer between different regions is even more expensive, and because the rate varies by region pair, check the official pricing page for the pair you are estimating. Data transfer through CloudFront can sometimes be cheaper than transferring directly from EC2 to the internet. This is because CloudFront's pricing structure is set separately from EC2's data transfer pricing. For example, data transfer from us-east-1 to Japan costs $0.09/GB directly from EC2, while CloudFront charges $0.114/GB (for Japan). Two conditions decide the total, however. One is that origin fetch from S3 is free, and the other is that requests served from the cache generate no origin transfer at all. For workloads with a high cache hit ratio, the volume leaving the origin itself drops, so the total comes out lower than serving directly from S3. Conversely, for dynamic content that goes back to the origin every time, the difference in unit price applies as is and the total is higher.
The Behind-the-Scenes Pipeline Before Your Invoice Arrives
AWS monthly invoices are closed at the end of the month and finalized in the first part of the following month. The exact date shifts with your billing cycle and seller of record, so it cannot be treated as a fixed day. Note that the unit prices in this section are as of August 2026 for US East (us-east-1). Before the invoice is finalized, enormous metering data is aggregated, discounts are applied (Savings Plans, RIs, volume discounts), taxes are calculated, and currency conversions are performed. Cost data displayed in Cost Explorer is not real-time and has a delay of up to 24 hours. This is because there is a time lag in collecting and aggregating metering data. Data transfer charges and third-party marketplace charges tend to take longer to aggregate. Savings Plans and RI discount application is not done in bulk at month-end but applied in real-time as usage occurs. For Savings Plans, the commitment amount and actual usage are compared hourly, with discounted rates applied to usage within the commitment and on-demand rates applied to the excess. When using AWS Organizations' Consolidated Billing, usage across all accounts in the organization is combined to calculate volume discounts. For example, S3 storage pricing is tiered at $0.023/GB for the first 50TB and $0.022/GB for the next 450TB, and consolidated billing determines the tier based on the total across all accounts, making it more favorable than individual billing.
Practical Strategies to Prevent Unexpected Bills
Due to the complexity of AWS pricing, unexpected high bills are not uncommon. The most frequent cause is forgotten resources. EC2 instances, NAT Gateways, Elastic IPs, and RDS instances launched for development and testing are left running, resulting in bills of hundreds to thousands of dollars at month-end. Setting up alerts with AWS Budgets lets you receive notifications when you reach 80% of your budget. Furthermore, AWS Budgets Actions can automatically apply IAM policies to restrict new resource creation when budgets are exceeded. Cost Anomaly Detection uses machine learning to detect abnormal cost increases, alerting you to spending that deviates from normal patterns. However, detection is not real-time. Even when S3 charges that are normally $100/month suddenly jump to $1,000, it takes time before the jump is flagged as an anomaly, because Cost Anomaly Detection uses the cost data of Cost Explorer as its input and inherits that data's update delay. Treat it as a mechanism that lets you notice by the next day rather than one that stops a spike on the spot. Another often-overlooked cost is CloudWatch Logs data ingestion charges. When Lambda or ECS outputs large volumes of logs, CloudWatch Logs ingestion charges ($0.50/GB in us-east-1, as of August 2026) can grow beyond expectations. The ingestion rate differs by region, so estimate with the rate of the region you use. Setting appropriate log levels and shortening retention periods for unnecessary logs are effective countermeasures.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
- AWS Cost Explorer official page
- AWS Budgets official page
- AWS Cost and Usage Report official page
- AWS Documentation (official)
If this page and the official documentation disagree, treat the official documentation as authoritative.