Cutting Cloud Costs: Right-Sizing, Spot, Scaling, Regions, Egress

The problem

A typical cloud bill grows faster than the traffic it serves. Instances sized for a launch-day peak keep running at a few percent CPU, development and staging environments run around the clock, and a line item for outbound data transfer appears that nobody budgeted for. The bill shows totals per service, but not which decisions caused them.

Common symptoms:

• Average CPU on most instances stays far below what the instance type provides.
• Compute cost is flat across the day, although traffic is not.
• Non-production environments cost almost as much as production.
• Data transfer out and cross-region transfer rank among the top usage types.

The cause

The causes are structural, not a single misconfiguration:

• Capacity is chosen once and never revisited. Instance sizes are picked from guesses, then left alone because resizing feels risky.
• Billing follows provisioned capacity, not used capacity. An idle instance costs the same as a busy one of the same type.
• On-demand pricing is the default. Fault-tolerant work such as batch jobs, CI runners and stateless workers is run at the most expensive purchase model.
• Prices differ by region. The region is often chosen for habit or latency alone, without comparing price.
• Data leaving the provider is usually metered. Many large providers charge per GB for outbound traffic, so traffic-heavy services (media, downloads, backups, replication) can cost more in transfer than in compute. Terms differ between providers; some include a traffic allowance or do not charge for egress, which has to be verified in the provider's current price list and fair-use terms.

Source of truth

The Spot claim in the original list needs the provider's own wording. The AWS documentation page Best practices for Amazon EC2 Spot confirms three points:

• Spot Instances offer savings of up to 90% compared with On-Demand prices. This is an upper bound, not a guaranteed rate.
• The only difference from On-Demand Instances is that EC2 can interrupt a Spot Instance if it needs the capacity back.
• The interruption comes with a two-minute notice, and an instance rebalance recommendation can signal an elevated interruption risk earlier.

So Spot is suited to workloads that tolerate interruption, which is a stricter criterion than the original's 'non-critical'. A critical service built to survive instance loss can run on Spot; a non-critical single instance holding the only copy of its data should not.

Current per-region prices, data transfer rates and discount programs are published in the provider's pricing pages and change over time. Treat any number from an article, including this one, as unverified until checked there.

Fix options

Right-size instances

Compare observed CPU, memory, disk and network use over a representative period with the instance type, then move to a smaller or differently shaped type. Memory is not reported by the hypervisor, so a monitoring agent is needed for that metric on most platforms.

Use Spot or preemptible capacity

Move interruption-tolerant work to the discounted capacity pool. The work must checkpoint, retry or be stateless.

Scale capacity with demand

Reduce the number of running instances when demand falls. Two forms exist: scheduled scaling (predictable daily or weekly patterns) and metric-driven scaling (target tracking on CPU or request count). Stopping non-production environments outside working hours is the simplest variant.

Compare regions

Check the price of the same instance type and storage in each region that meets latency and legal requirements. Cross-region traffic is itself a cost, so placing tightly coupled services in different regions to save on compute can backfire. Data residency rules (for example GDPR-related requirements) can rule out cheaper regions entirely.

Measure and reduce egress

Find which usage types generate transfer charges, then reduce volume (compression, caching, a CDN, keeping traffic inside one zone or region) or move high-volume traffic to a provider whose terms suit it.

Why this fix

The order that follows is: measure, right-size, schedule, then use Spot, and review region and egress last. The reasons:

• Measurement comes first because every other method depends on knowing real usage and which usage types dominate the bill.
• Right-sizing is the lowest-risk change and lowers the baseline that scaling and Spot discounts are then applied to.
• Scheduling needs no application change when the service is stateless or can be stopped safely.
• Spot yields the largest discount but needs the workload to handle interruption, so it follows the cheaper, simpler steps.
• Region moves are expensive to carry out and constrained by latency and law, so they are reserved for new deployments or planned migrations.

Step by step

No commands were executed while preparing this article, so no output is shown. The commands below use the AWS CLI as a representative example; names, IDs and dates are placeholders to replace. Equivalent tooling exists on other platforms. Try each command in a non-production account first.

1. Measure usage

List instances, then fetch daily CPU statistics for each one:

aws ec2 describe-instances --query 'Reservations[].Instances[].[InstanceId,InstanceType,State.Name]' --output table

aws cloudwatch get-metric-statistics --namespace AWS/EC2 --metric-name CPUUtilization --dimensions Name=InstanceId,Value=i-0123456789abcdef0 --start-time 2025-11-01T00:00:00Z --end-time 2025-11-15T00:00:00Z --period 86400 --statistics Average Maximum

Read the Maximum value as well as the Average: an instance with a low average but a high maximum may need its current size for peaks. Install a monitoring agent to collect memory figures before shrinking anything.

2. Resize an under-used instance

Changing the type of an EBS-backed instance requires stopping it, so plan a maintenance window:

aws ec2 stop-instances --instance-ids i-0123456789abcdef0
aws ec2 wait instance-stopped --instance-ids i-0123456789abcdef0
aws ec2 modify-instance-attribute --instance-id i-0123456789abcdef0 --instance-type Value=t3.small
aws ec2 start-instances --instance-ids i-0123456789abcdef0

Watch CPU, memory and latency afterwards. If the smaller size struggles, reverse the change the same way.

3. Schedule capacity

For an Auto Scaling group with a daily pattern, add two scheduled actions. Recurrence uses cron syntax; set a time zone explicitly so the schedule does not drift from local working hours:

aws autoscaling put-scheduled-update-group-action --auto-scaling-group-name web-asg --scheduled-action-name evening-scale-down --recurrence "0 20 * * *" --time-zone "Europe/Oslo" --min-size 1 --max-size 2 --desired-capacity 1

aws autoscaling put-scheduled-update-group-action --auto-scaling-group-name web-asg --scheduled-action-name morning-scale-up --recurrence "0 7 * * 1-5" --time-zone "Europe/Oslo" --min-size 2 --max-size 6 --desired-capacity 2

Scheduled actions only fit a predictable load. Add a target-tracking policy for unexpected peaks so the minimum size is not the only protection.

4. Run interruptible work on Spot

Request a Spot Instance with the market options flag, and let the workload watch for the two-minute notice described in the source above. The instance metadata endpoint returns the pending action only when an interruption is scheduled:

aws ec2 run-instances --image-id ami-0123456789abcdef0 --instance-type c5.large --instance-market-options '{"MarketType":"spot","SpotOptions":{"SpotInstanceType":"one-time"}}'

TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/spot/instance-action

Poll the second request every few seconds from a small agent on the instance. When it returns an action, the agent should finish or checkpoint the current job and deregister the instance from any load balancer. For fleets, prefer an Auto Scaling group with a mixed instances policy over single one-off requests, so replacement capacity is requested automatically.

5. Find where the money goes

Group a month of cost by usage type to see whether transfer, storage or compute dominates, and to check the effect of a region comparison:

aws ce get-cost-and-usage --time-period Start=2025-10-01,End=2025-11-01 --granularity MONTHLY --metrics UnblendedCost --group-by Type=DIMENSION,Key=USAGE_TYPE

If transfer usage types lead the list, reduce volume first: enable compression on the web server, set cache headers, and put static assets behind a cache. Only then evaluate whether the traffic belongs on a platform with different transfer terms.

Limits and alternatives

• Only the Spot claim was checked against documentation here. Prices, discount percentages and transfer allowances differ by provider and change; confirm them in the current price list before deciding.
• Right-sizing depends on the metric window. Two quiet weeks hide a month-end or seasonal peak. Use a period that includes it.
• Spot is not a fit for stateful single instances. Databases without replication, or jobs that cannot resume, should stay on regular capacity.
• Scaling to fewer instances does not cut fixed costs such as storage volumes, reserved IP addresses and load balancers, which accrue while the instances are stopped or removed.
• Steady workloads may be cheaper under a commitment (reserved capacity or savings plan) after right-sizing, or on fixed-price virtual servers with included traffic. Commitments lock in a size, so they come after right-sizing, not before.
• Region choice must respect latency and data residency before price.

A recurring review, for example monthly, of utilization and the usage-type cost breakdown keeps the savings from eroding as the environment changes.