Cloud egress: Azure Blob vs AWS S3 bandwidth matrix
Azure Blob bandwidth and AWS S3 egress are not labeled the same. Align Internet, private-endpoint, paired-region / CRR replication, CDN origin, and archive-restore path classes before any $/GB — Unknown until verified on dated Azure and AWS pages.
Updated
Bandwidth on Azure and egress on AWS are not labeled the same — this matrix aligns path classes before rates.
Dated starting points only — Unknown until verified means no invented $/GB. PipeToll does not scrape private consoles or guarantee figures. Region/zone pairs vary; cite the destination on each pricing page before Mode A arithmetic.
Path-class vocabulary: path template, Unknown until verified. Azure often says bandwidth; AWS says data transfer out. Normalize vocabulary before arithmetic. PipeToll keeps Honest Unknown cells rather than inventing list prices.
Path templates to model
Client ← Internet ← Blob/S3 — public download; zone/region free grants matter.
VNet/VPC compute ← private endpoint — private path fees replace some Internet meters.
GRS/CRR replication — background meters distinct from user reads.
CDN / Front Door / CloudFront origin — two-bill risk on miss.
Archive rehydrate then download — restore SKU + bandwidth/egress.
Common traps
Comparing only “Internet $/GB” ignores private endpoint fees and replication. Archive restores surprise teams that budgeted egress alone. Cross-cloud copy bills the source. No scorecrowns across Azure vs AWS from partial public pages.
Internet $/GB only — Azure Bandwidth and AWS S3 Internet DT-out are one path class. Private Endpoint / VPC-endpoint fees, GRS/CRR replication, and CDN origin fill are others. A cheap Internet headline with an expensive restore or replication cliff is not a win — keep ledgers separate.
Bandwidth ≠ egress vocabulary — Azure often says bandwidth; AWS says data transfer out / egress. Align on path class (Internet user downloads, private pulls, replication, CDN origin) before arithmetic; never paste an Azure Bandwidth SKU into an AWS Internet DT-out cell.
Archive restore skipped — Cool/Archive rehydration and S3 restore often fire before bandwidth/egress. Model two steps; sibling literacy on cold-tier surprises in the FinOps checklist below.
Paired-region / GRS conflated with user downloads — GRS/GZRS and S3 CRR are durability/replication meters, not Internet client downloads. Keep them on their own lines — see S3 CRR.
CDN origin blended into Internet — Front Door / Azure CDN / CloudFront origin fill is miss-driven and may bill the origin owner separately. Use Mode C for fill; twin with CDN origin fill.
Cross-cloud copy bills the source — Blob→S3 or S3→Blob moves still egress from the source cloud. Do not assume “same object store family” erases DT-out.
Worked example (educational): 500 GB archive restore + 2,000 GB Internet + 300 GB geo-replication
Split meters: 500 GB archive/cool rehydrate/restore (often outside pure bandwidth) vs 2,000 GB Internet bandwidth/egress vs 300 GB paired-region / GRS-style replication — never one blended $/GB.
Azure bandwidth cell — Unknown until cited from Azure Bandwidth pricing for the zone.
Second educational stack (bandwidth vs egress labeling): same 2,000 GB Internet-bound downloads — Azure invoices may say Bandwidth while AWS says Data Transfer Out / egress. Align on path class first (Internet user downloads), then place free-tier cliffs beside each cell via multi-cloud free-tier cliffs and AWS free-tier cliff. Sibling multi-cloud templates: AWS vs GCP egress. Private-path twin remains: 800 GB VNet/Private Endpoint pull (Azure) vs 800 GB same-region VPC-endpoint S3 pull (AWS) — private fees replace some Internet meters; do not paste Internet $/GB. Synthetic only — rates Unknown; no savings guarantee.
Hold the 2,000 GB Internet + 500 GB restore + 300 GB replication baseline and walk three path / cliff runs. Every unit rate stays Unknown until dated Azure Bandwidth / Blob / AWS S3 cites — literacy arithmetic, not a quote.
Run A — Internet-heavy: 2,000 GB Internet bandwidth/egress + 500 GB archive restore + 300 GB GRS/CRR sibling. Split three meters; open Mode A (?path=azure-s3). Apply each cloud’s free-tier cliff beside the Internet cell only.
Run B — private-path twin: same objects as 800 GB VNet/Private Endpoint (Azure) vs 800 GB same-region VPC-endpoint S3 (AWS). Private fees replace some Internet meters — do not paste Internet $/GB. Re-run Mode A with the private-path volume.
Run C — CDN origin on miss: same 2,000 GB client month behind Front Door / CloudFront at mid CHR (e.g. 0.70) → origin fill ≈ 600 GB on the origin owner. Keep fill on Mode C; twin with CDN origin fill and S3 direct vs CloudFront. Replication stays off the fill line.
Vendor vocabulary differs. Align on path class (Internet user downloads, private VNet/VPC pulls, replication, CDN origin fill) before comparing numbers — then apply each cloud's free-tier cliff and keep Azure Bandwidth SKUs off AWS Internet DT-out cells. See also AWS vs GCP egress for the same discipline across three clouds.
Do paired regions bill like user downloads?
Replication/read patterns can differ from Internet bandwidth. Keep replication meters separate.
What about archive tiers?
Rehydration/restore charges often fire before bandwidth/egress. Model two steps.
How does Azure GRS relate to S3 CRR?
They are sibling multi-region durability path classes — not identical meters. Map Azure GRS/GZRS and AWS S3 CRR separately with dated cites; never paste Internet bandwidth $/GB into either replication cell.
Trademarks: Amazon Web Services, AWS, Microsoft Azure, Google Cloud Platform, GCP, and Cloudflare are trademarks of their respective owners. PipeToll (Ameti One LLC) is not affiliated with, endorsed by, or sponsored by those companies. Educational comparisons may be outdated — verify current rates with each provider.
