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, costs for fast functions can be reduced by up to 99% in some cases. 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 Nitro System hypervisor precisely records instance start and stop times, calculating usage seconds from the difference. For Lambda, Firecracker micro-VMs record function execution start and end times with millisecond precision. 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, data transfer between different AZs in the same region is charged ($0.01/GB), and data transfer between different regions is even more expensive (approximately $0.02/GB). 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). However, since CloudFront's origin fetch from S3 is free, the S3 + CloudFront combination is often cheaper than serving directly from S3.
The Behind-the-Scenes Pipeline Before Your Invoice Arrives
AWS monthly invoices are finalized 3-5 days after the end of the month. During this period, 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. For example, if S3 charges that are normally $100/month suddenly jump to $1,000, an alert is sent within hours. 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) can grow beyond expectations. Setting appropriate log levels and shortening retention periods for unnecessary logs are effective countermeasures. To systematically learn cloud cost management techniques, specialized books (Amazon) can be helpful.