Cloud Cost Optimization Beyond Right-Sizing: Data Paths and Storage Design

Find architecture-level cloud costs in repeated reads, network paths and storage lifecycles. Compare alternatives without removing redundancy or weakening recovery.

Trace expensive work before choosing smaller machines

Right-sizing changes the capacity available to execute a workload. Architecture changes can reduce how often the work happens, how far data travels and how many copies remain stored. Investigate those mechanisms when the bill stays high despite reasonable instance utilization.

Start with one expensive user journey or batch job. Follow it through service calls, databases, object storage, queues and network boundaries. Repeated downloads, full scans and retained intermediate files can create charges that an instance-size change barely affects.

This article focuses on architecture-level cost drivers, using AWS networking and storage examples. It complements the broader cloud cost optimization guide, which covers baselines, unit economics, commitments and capacity decisions. It does not claim a typical savings percentage or prescribe the same architecture for every workload.

Build a billable-path inventory

A dependency diagram shows who calls whom. A cost investigation also needs to show bytes, requests, repetition and the service charging for each step.

| Path to inspect | Evidence to collect | |---|---| | Worker to object storage | Object sizes, reads per job, range reads, retry count and network route. | | Service to service | Payload size, fan-out, repeated fields, zone placement and call frequency. | | Application to database | Query count, rows examined, returned bytes, repeated aggregates and I/O. | | Data pipeline to storage | Raw, temporary and curated copies; replication; versions; retention owner. | | Application to telemetry | Events per operation, payload size, index retention and duplicate exports. |

Join those observations to billing usage types for the same period. Distinguish logical payload size from billed network volume: protocol overhead, compression, retries and return traffic can change the result. Identify fixed charges that remain after traffic falls and volume tiers or commitments that change marginal cost.

Record region, service, transfer direction, storage class and pricing date before applying a rate. There is no single AWS price for “cross-zone,” “egress” or “private endpoint” that can safely be pasted onto every arrow.

Worked example: remove duplicate object reads

Consider a hypothetical report worker that downloads the same immutable 2 MB reference object in three stages of each job. It completes 10 million jobs per month. Assume decimal units, no retries or compression, and that one job can safely reuse the downloaded object across its stages.

| Measure | Three downloads | One download reused | |---|---|---| | Object GET requests | 30 million | 10 million | | Payload read per job | 6 MB | 2 MB | | Monthly payload read | 60,000 GB | 20,000 GB |

The change removes 20 million GET requests and 40,000 GB of object-read payload. It does not automatically remove 40,000 GB from every billable network category. Confirm the actual route and usage types first.

Suppose, solely for this calculation, that the affected path has a marginal processing cost of $0.04 per GB. That is an illustrative input, not an AWS price quote. The avoided processing charge is 40,000 × $0.04 = $1,600 per month. If added scratch storage costs $300 and allocated ongoing operating effort is $400 per month, the modeled net recurring benefit is $900. A hypothetical $9,000 implementation cost would take ten months to recover at that unchanged benefit.

GET charges and any separate transfer charges are excluded from this simplified calculation. So are taxes, financing and demand growth. Replace each input with a dated estimate for the actual service and region. If the existing processing charge is not avoidable, the proposed benefit must be recalculated.

Conditions that can invalidate the design

The reference object must be the same version across the three stages. If stages need the latest mutable state, reuse changes behavior. Retrying a job must not reuse an incomplete download. Disk capacity, concurrency, cleanup and tenant isolation need explicit controls.

Start with job-local reuse when that meets the requirement. A distributed cache adds network calls, replication, eviction behavior and another system to operate. Shared caching may be justified across many jobs, but its benefit must exceed those costs while preserving authorization and freshness.

Measure GETs and bytes per completed job after the change. Also inspect job duration, failures and peak scratch-space use. Fewer reads caused by unfinished jobs are not an improvement.

Choose the network path without removing fault isolation

For eligible same-region S3 access from a VPC, a gateway endpoint can avoid the NAT path and has no additional endpoint charge. An S3 interface endpoint is a different mechanism with additional charges and connectivity capabilities. Gateway endpoints do not extend through a transit gateway or to on-premises clients. Check the S3 gateway endpoint documentation against the actual callers, DNS and route tables.

An endpoint does not make S3 storage and requests free. It also changes access-policy evaluation and routing. Test bucket and endpoint policies, including deployment and recovery tooling, before rollout. AWS notes that changing the endpoint route can interrupt existing TCP connections, so verify reconnect behavior.

AWS NAT gateway pricing guidance separates hourly availability and data-processing charges. Routing S3 traffic away from a NAT gateway may remove processing charges for that traffic while leaving the gateway's hourly charge because other destinations still use it.

| Change | Reliability boundary | |---|---| | Prefer local-zone service traffic | Keep the required replicas across zones, provide cross-zone fallback and test loss of the preferred zone. | | Give each zone an appropriate egress path | Compare added gateway or endpoint capacity with transfer charges and failure behavior. | | Reduce payloads or combine repeated reads | Preserve API semantics, authorization and latency requirements. | | Move processing nearer its data | Check data residency, recovery location, latency to consumers and the cost of new copies. |

Do not put all instances and data in one zone solely to reduce transfer. Locality and resilience can coexist, but locality-aware routing must tolerate uneven demand and failures. Test the remaining zones under failover load before counting retained redundancy as sufficient.

Reduce scans and repeated materialization

A report that repeatedly scans a large dataset may be expensive because the application requests more data than it needs. Inspect predicates, partition selection, column selection and duplicate transformations before adding database capacity.

Precomputed aggregates can reduce repeated work, but they introduce refresh cost, storage and a freshness contract. A report refreshed hourly cannot replace a live balance check without changing the product. Keep the raw or authoritative data required to rebuild the aggregate and test that rebuild at a realistic volume.

Compression and columnar formats can reduce storage or scan volume for suitable access patterns. The result depends on the data, query engine and workload. Rewriting JSON as Parquet is a format change, not a guaranteed compression ratio. Include conversion work, small-file behavior and the cost of reading only a few records.

Also inspect unsuccessful work. A retry loop, duplicate event or abandoned export can incur the same storage and network charges repeatedly. Fixing the cause may be more useful than moving every copy to a cheaper tier.

Design storage lifecycles from retrieval requirements

Age alone does not tell you whether an object can move to archival storage. Identify who reads it, how quickly it must be available and whether a recovery process needs many objects at once.

| Data class | Decision before changing its lifecycle | |---|---| | Active application objects | Can the application tolerate changed access latency or retrieval behavior? | | Rebuildable intermediate files | Is the authoritative input retained, and has rebuild time been tested? | | Incident evidence | Which investigations and access controls require retention? | | Recovery copies | Which recovery points, restore times and failure scenarios must remain possible? | | Contractual or held records | Has the responsible owner approved the applicable retention and deletion rules? |

Include transition requests, retrieval charges, object-size effects and minimum storage-duration charges. AWS's S3 Lifecycle considerations explain why a lower storage rate does not guarantee a lower total cost. A large number of tiny objects or early reclassification can change the economics. Test retrieval and restoration separately from the monthly storage calculation.

Deletion is a different decision from tiering. An old volume or snapshot may be a recovery point or an input to a retained image. Require an owner, a dependency check, an approved retention basis and a tested remaining restore path before deletion.

For EBS, deleting an incremental snapshot preserves data needed by other snapshots. This also means the saving is not necessarily the displayed logical size of the deleted snapshot. AWS documents snapshot deletion and retained blocks. Check image references and multi-volume recovery sets; do not apply a universal “keep the last three” rule.

Approve one architecture change with a recovery boundary

Choose the largest cost driver that has both a named owner and a testable mechanism. Write a short decision record containing:

1. The before-and-after data path, with bytes and requests per useful operation.
2. The exact billable usage expected to change, dated rates and charges that remain.
3. Added storage, network, engineering and ongoing operating costs.
4. Freshness, authorization, latency, availability and recovery requirements.
5. A bounded rollout with stop conditions and a way to return to the old path.
6. Verification using completed work, service health and reconciled billing.

A routing change may be reversible while deleted data is not. Disabling a lifecycle policy cannot restore objects that it already removed. Keep destructive cleanup out of an otherwise reversible experiment unless it has separate approval and recovery evidence.

Next action

Take the path inventory and decision record to the service owner before changing the topology. For implementation support across these cost and reliability boundaries, see cloud cost optimization.

Technical references checked September 20, 2026. All numerical examples are hypothetical. No vendor price or customer savings result is asserted.