Cloud Pricing Basics — Pay-as-You-Go Model
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
Cloud pricing is a collection of service-specific meters, not one universal pay-per-use rule. Compute may be billed by provisioned time, requests, execution duration, memory, or reserved capacity. Storage may charge for GB-months, operations, retrieval, and backup. Network pricing depends on direction, zone, region, service, and destination.
For example, a low-CPU service can still be expensive if it runs oversized instances all month or transfers large responses across regions. A function with no idle execution charge may still have request, logging, database, and provisioned-capacity costs.
As a developer I tag resources, set budgets and anomaly alerts, choose retention policies, measure unit cost, right-size from telemetry, cap autoscaling, and remove unused resources. I do not use fixed dollar examples or assume ingress is always free. Cost is an architecture quality alongside reliability and performance, and the exact provider calculator is the source for a decision.
Cloud Pricing Basics — Pay-as-You-Go Model
Direct Answer
Cloud bills combine resource quantity, duration, request counts, provisioned capacity, storage, operations, support, licenses, and network transfer according to each service's price model. Ingress is often free but not universally, and egress/region/AZ rules vary. Developers influence cost through architecture, data movement, retention, right-sizing, scaling limits, tags, budgets, and deletion of unused resources.
Code Example
// Spring Boot configuration with resource tags for cost tracking
@Configuration
public class AwsResourceConfig {
@Bean
public AmazonEC2 ec2Client() {
return AmazonEC2ClientBuilder.standard()
.withRegion(Regions.US_EAST_1)
.build();
}
// Tag resources with team and environment for cost allocation
public void tagInstance(String instanceId, String team, String env) {
var ec2 = ec2Client();
var tags = List.of(
new Tag("Team", team), // Track which team owns this cost
new Tag("Environment", env), // Identify dev vs prod
new Tag("AutoShutdown", env.equals("dev") ? "yes" : "no")
);
var request = new CreateTagsRequest()
.withResources(instanceId)
.withTags(tags);
ec2.createTags(request); // AWS Cost Explorer groups by these tags
}
}
Common Mistakes & Pitfalls
- Leaving dev resources running 24/7: Freshers spin up an EC2 instance for testing, forget about it, and get a 200-dollar bill a month later when the instance sat idle for 90 percent of the time—always tag resources and set up auto-shutdown.
- Over-provisioning for fear of slowness: choosing a db.m5.4xlarge RDS instance (16 vCPU, 64 GB RAM, 320 dollars per month) for a personal project because it sounds fast, when a db.t3.micro (2 vCPU, 1 GB RAM, 15 dollars per month) would handle the actual 50 requests per day load.
- Ignoring data transfer costs: building an API that returns entire database tables as JSON responses without pagination, then wondering why the AWS bill shows 100 dollars in data transfer charges—egress is expensive, always paginate large result sets.
Check your understanding
Answer these without looking back at the article.
- What are Reserved Instances and when should you use them?
- What is AWS Cost Explorer and how do you use it?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.