Cloud Pricing Model #

“Pay only for what you use” is the main slogan of cloud computing most heavily marketed by service providers. This pricing scheme promises maximum efficiency because we no longer need to buy expensive hardware upfront (Capital Expenditure / CapEx) and only pay monthly operational costs (Operating Expenditure / OpEx). However, in practice, cloud pricing models aren’t as simple as turning off the lights when leaving a room. Cloud bills are multi-dimensional and consist of hundreds of cost components often invisible to the naked eye, like outbound data transfer (egress) costs, per-API-call costs, storage capacity provisioning costs, and managed service fees. Without a deep understanding of these cost dimensions, we’ll often face cloud bill shock at month’s end that can harm our project’s profitability.

Main Cloud Cost Dimensions #

To design cost-aware architecture, we must understand that a service’s final bill is never single-dimensional. Every cloud service generally breaks its bill into the following six main dimensions:

1. Compute (Processing Costs) #

This dimension is calculated based on the active time of processing units (vCPU and RAM) consumed by our applications.

• Virtual Machine / VM: Billed hourly or per second from machine power-on to shutdown.
• Container (Managed): Billed based on allocated vCPU capacity and memory (GB RAM) consumed per hour.
• Serverless (FaaS): Billed based on function execution counts (invocations) combined with execution duration multiplied by memory allocation (GB-seconds).

2. Storage (Data Storage Costs) #

Cloud data storage costs have billing characteristics varying by storage media type used:

• Object Storage (like AWS S3 or Google Cloud Storage): Billed based on actual stored data capacity (per GB/month) and the selected storage tier.
• Block Storage (like AWS EBS or Google Persistent Disk): Billed based on provisioned capacity allocated, regardless of whether that storage space is empty or fully filled.
• File Storage (like AWS EFS): Billed based on average stored data volume per month, with optional additional costs for allocated throughput performance.

3. Network & Data Transfer #

Data movement costs are among the most frequently overlooked components yet can balloon enormously. Generally, inbound (ingress) cloud traffic is free, but outbound (egress) internet traffic, cross-region data transfers, and cross-Availability-Zone (cross-AZ) transfers are charged per gigabyte (GB).

4. API Requests #

Every interaction with cloud services via APIs (like reading files from object storage, writing data to NoSQL databases, or sending messages to queues) is charged based on request quantity. Examples are costs per 10,000 GET requests or per 1,000 PUT/POST requests.

5. Managed Services Capacity #

Managed services like Load Balancers and NAT Gateways include a combination of base hourly costs plus processed data volume costs. Modern Load Balancers also use dynamic capacity metrics like LCU (Load Balancer Capacity Unit) counting simultaneously active connections.

6. Support Plans #

For business and enterprise accounts, cloud providers charge fixed monthly fees or percentages of total monthly bills (whichever is larger) to provide technical support engineer assistance with fast response time guarantees (Service Level Agreement / SLA).

Data Transfer — The Hidden Cost Component #

One fundamental law of cloud networking we must remember is: data entering the cloud is free, data leaving the cloud is paid. This cost structure is designed by cloud providers to ease data migration into their systems (cloud lock-in), while charging high costs when data is moved out.

flowchart TD
    subgraph InternetZone ["External Internet"]
        User["Internet Users"]
    end

    subgraph RegionCloud ["Cloud Region (ap-southeast-1)"]
        subgraph AZA ["Availability Zone A (AZ-A)"]
            AppA["App Server A (VM)"]
        end
        
        subgraph AZB ["Availability Zone B (AZ-B)"]
            AppB["App Server B (VM)"]
            DB["Primary Database (Managed)"]
        end
    end

    subgraph RegionLain ["Other Cloud Region (us-east-1)"]
        Backup["Disaster Recovery Storage"]
    end

    User -->|"1. Incoming Request (Ingress)\n[FREE]"| AppA

    AppA -->|"2. Egress to Internet\n[PAID: ~$0.09/GB]"| User

    AppA <-->|"3. Cross-AZ Communication\n[PAID: ~$0.01/GB per direction]"| DB

    AppB <-->|"4. Same-AZ Communication\n[FREE]"| DB

    AppB -. "5. Cross-Region Replication\n[PAID: ~$0.02-0.08/GB]" .-> Backup

1. Comparative Network Cost Structure #

• Data Ingress (Free): Downloading files from external servers into our cloud virtual machines doesn’t incur network costs.
• Internet Egress (Expensive): Sending data from the cloud to internet users. Standard costs range between $0.08 to $0.09 per GB. If our application serves large image, video, or document files directly from VMs, this cost balloons quickly. We must use Content Delivery Networks (CDNs) to lighten this egress cost.
• Cross-Region Transfer (Medium): Sending data from one cloud region to another (e.g., from Singapore to Virginia). Costs range between $0.02 to $0.08 per GB depending on the geographic route.
• Cross-AZ Transfer (Cheap but Frequent): Sending data between Availability Zones within the same region. Costs are relatively cheap, around $0.01 per GB per direction. Although cheap, communication volumes can be very high if our micro architecture isn’t designed locally within one zone.

2. Case Study: The Cost of Poor Cross-AZ Communication #

Imagine building a web application where application servers sit in Availability Zone A (AZ-A) while the primary database sits in Availability Zone B (AZ-B).

• Every user request triggers a database query returning 50 KB of response data.
• Our application consistently serves 2,000 requests per second.

Let’s calculate the accumulated cross-AZ data transfer costs over one month (30 days):

$$\text{Data Volume per Second} = 2,000 \times 50 \text{ KB} = 100,000 \text{ KB} = 100 \text{ MB/second}$$

$$\text{Data Volume per Day} = 100 \text{ MB} \times 86,400 \text{ seconds} = 8,640,000 \text{ MB} = 8,640 \text{ GB/day}$$

$$\text{Data Volume per Month} = 8,640 \text{ GB} \times 30 = 259,200 \text{ GB/month}$$

$$\text{Cross-AZ Cost (2 Directions)} = 259,200 \text{ GB} \times $0.01 \text{ per GB} \times 2 = $5,184\text{/month}$$

Just to flow data between application servers and the database across AZs, we must pay around $5,184 per month.

Architectural Solution: We must ensure primary application servers communicate with primary databases or read replicas located in the same Availability Zone (local communication = free). Use cross-AZ replication only for asynchronous secondary database backup (failover) synchronization needs.

Compute Pricing Strategies #

Compute is the largest component in most organizations’ cloud bills. To optimize it, we must choose the right compute pricing model based on workload profiles:

Storage Pricing — Provisioned Capacity vs. Actual Storage Used #

Many engineers assume cloud storage is billed by stored data. This is an expensive misconception. We must distinguish billing methods between Block Storage and Object Storage.

1. Block Storage (Provisioning-Based Storage) #

With Block Storage (like AWS EBS gp3), we pay for capacity we reserve upfront, not what we use.

• ANTI-PATTERN: A developer creates a test database and allocates a 1 TB EBS volume reasoning “just in case the disk fills during testing”. However, actual test data is only 20 GB.
• Cost Impact: The company still pays the full bill for that 1 TB capacity. If the storage rate is $0.08 per GB/month, the monthly bill is $80, even though actual data only needs $1.60.
• CORRECT: Start with a small volume (e.g., 50 GB) and enable automatic volume expansion (auto-grow) features or manually resize disks when storage space reaches 80% full. Modern clouds support dynamic block storage expansion without downtime (zero-downtime).

2. Object Storage (Actual Usage-Based Storage) #

With Object Storage (like AWS S3), we only pay for actually stored data capacity. However, we must beware of data manipulation costs:

• API Operation Costs: Reading data (GET requests) and writing data (PUT/POST requests) have per-thousand-operation rates. Highly intensive API calls from micro applications can exceed the physical data storage costs themselves.
• Retrieval & Transit Costs: Cold storage classes (like Glacier) offer very cheap per-GB prices for long-term archiving. However, if we frequently read back that cold data (retrieval), we’re charged very expensive data withdrawal fees.

Serverless Pricing and Break-Even Scenarios #

Serverless FaaS services (like AWS Lambda) offer a very attractive billing model: we pay nothing while our code isn’t running (scale-to-zero). We’re billed based on invocation counts and execution durations multiplied by prepared memory allocations.

However, is serverless always cheaper than renting traditional virtual machines (VMs)? We must calculate the break-even point of both models.

1. High Traffic Case Simulation #

Suppose we have a microservice serving APIs with the following characteristics:

• Consistent traffic: 50,000,000 requests per month (about 19 stable requests per second).
• Function memory allocation: 512 MB (equivalent to 0.5 GB).
• Average execution duration: 200 ms (0.2 seconds) per request.

Let’s calculate the total cost using FaaS (AWS Lambda):

1. Invocations Cost: Standard rate: $0.20 per 1,000,000 requests.

   $$\text{Invocation Cost} = 50 \times $0.20 = $10$$

2. Duration Cost: Standard rate: $0.0000166667 per GB-second. Total GB-seconds per month:

   $$\text{Total GB-seconds} = 50,000,000 \times 0.2 \text{ seconds} \times 0.5 \text{ GB} = 5,000,000 \text{ GB-seconds}$$

   $$\text{Duration Cost} = 5,000,000 \times $0.0000166667 = $83.33$$

3. Total Serverless Cost:

   $$\text{Total Lambda Cost} = $10 + $83.33 = $93.33\text{/month}$$

2. Comparison with Virtual Machines (VMs) #

Let’s compare running the same workload on a single AWS EC2 t3.medium VM instance (2 vCPU, 4 GB RAM) that can easily handle 19 stable requests per second:

• t3.medium On-Demand Price: ~$0.0416 per hour.

  $$\text{Monthly On-Demand Cost} = 730 \text{ hours} \times $0.0416 = $30.37\text{/month}$$

• t3.medium Reserved Instance Price (1-Year Commitment): ~$0.025 per hour.

  $$\text{Monthly Reserved Cost} = 730 \text{ hours} \times $0.025 = $18.25\text{/month}$$

3. Architectural Decision Evaluation #

From the mathematical calculations above, financially directly, renting traditional VMs is far cheaper ($18.25 - $30.37) than serverless ($93.33) for workloads running consistently 24 hours a day with high traffic.

Compute Model Selection Criteria:

  CHOOSE SERVERLESS (FaaS) if:
  ✓ Workloads are sporadic (e.g., only busy during office hours, quiet at night).
  ✓ Needs scale-to-zero features to cut costs when applications are unused.
  ✓ Development teams want to focus fully on writing code without server operational burdens.

  CHOOSE VIRTUAL MACHINES (IaaS/PaaS) if:
  ✗ Application traffic runs stable, continuous, and predictable 24 hours a day.
  ✗ Applications need instant startup times (avoiding cold starts).
  ✗ Combined VM total costs are lower after passing break-even calculations.

Reading and Analyzing Billing Reports #

When managing large-scale cloud accounts, our monthly billing reports can contain thousands of confusing transaction lines. We must train our teams to systematically read and analyze billing reports to detect anomalies early.

1. Use Cost Explorer Services #

Use provider built-in software (like AWS Cost Explorer or GCP Billing Reports) to visualize our monthly spending trends.

• Anomaly Detection: Create automatic alarm rules sending Slack notifications if a service’s daily cost spikes more than 20% compared to the previous week’s daily average.
• Egress Analysis: Periodically monitor the “Data Transfer - Out” section to detect traffic leaks or abnormal external data withdrawals.

2. Apply Mandatory Tagging (Tagging Policy) #

We can’t control costs if we don’t know which service or team is responsible for the spending. We must enforce strict Tagging Policy rules (e.g., Owner, Project, and Environment tags mandatory on every new resource creation). Resources without standard tags should be automatically shut down by automated cleanup systems (cron cleaner scripts) to prevent wasteful cost burdens.

Summary #

• Cloud costs are multi-dimensional — Final bills aren’t only determined by compute, but also influenced by storage provisioning, API calls, and data transfer.
• Outbound data transfer (egress) to the internet is expensively charged — Design application architecture minimizing cross-region and cross-Availability-Zone data transfers to avoid cost leaks.
• Block storage is billed by capacity allocation — Avoid over-provisioning empty disk volumes; start with minimal sizes and expand dynamically as disks fill.
• Choose compute models matching workloads — Use Reserved Instances for stable baseline traffic, Spot Instances for batch processing, and On-Demand only for early experiments.
• Calculate break-even points before choosing serverless — Serverless is highly efficient for fluctuating workloads, but can become more expensive than traditional VMs on large-scale consistent traffic.
• Apply billing monitoring alarms (billing alerts) from day one — So we get early warnings before bills balloon uncontrollably at month’s end.

← Previous: Observability vs Monitoring   Next: Cost Allocation & Tagging →