API Response Size Transfer Calculator

What response size should include

• Payload bytes: JSON/HTML/media returned by the endpoint (usually the dominant part).
• Compression: measure the compressed bytes over the wire if you use gzip/brotli.
• Headers: often small, but can matter if you have many small responses.

How to measure average response size (without guessing)

• From access logs: average bytes sent by route (p50/p95 is better than mean).
• From APM: sample response body sizes for hot endpoints and exclude outliers (large downloads).
• Separate small API and large download endpoints; mixing them produces an average that fits neither.

Common multipliers (why bandwidth is higher than payload math)

• Retries/timeouts: incident windows can multiply responses per user action.
• Cache misses: if every request hits origin, your origin bandwidth follows the full request volume.
• Pagination: chatty clients that pull many pages inflate transfer quickly.

How to get your inputs

• GB/month: start from billing exports/flow logs; if you only have throughput, convert Mbps to GB/month.
• Boundaries: separate cross-AZ vs cross-region vs internet egress as separate line items.
• Effective rates: use your blended $/GB for the traffic mix you expect.

Result interpretation

• Requests and response size multiply; one growing while the other stays flat still raises transfer quickly.
• If transfer dominates, focus on caching and response compression first.

Common mistakes

• Mixing boundaries and applying the wrong $/GB rate.
• Ignoring retries/timeouts that multiply traffic during incidents.

Scenario planning

Validate after changes

• Validate the top transfer paths and AZ/region locality after architecture changes.
• Re-check during peak windows (that's when hidden multipliers show up).

Next steps