Measuring cloud egress before you commit: method, tools and worked calculations

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

Egress is data leaving a cloud provider's network or moving between its billing locations. Estimate it by mapping every path your workload will use after the move, measuring today's bytes on each path for at least a full business cycle, then applying the provider's tiers in its own unit.

The trap is to measure only what crosses your internet link today. Traffic between users and servers on your own network is free and often invisible on that link. Move the server to the cloud and the same traffic can become metered.

Rates below were read on 10 November 2026, are in US dollars and exclude tax. Commands come from vendor documentation or were written for this article where labelled. None was run in a lab.

Why it matters

Compute and storage are easy to price because they follow a size you choose. Data transfer follows behaviour: who downloads what, how chatty the application is, and where each tier sits.

A monthly total alone is not enough. One gigabyte can cost nothing, or be charged twice, depending on its path. So the model needs a separate line for each path.

What is actually metered

These are vendor facts for AWS, Azure and Google Cloud. Your region and agreement can change them.

Other charges sit on top:

• NAT gateways. AWS charges per gigabyte processed, regardless of source or destination, and standard data transfer also applies. Google lists $0.045 per GiB processed, inbound and outbound, and data transfer charges also apply.
• Private links. Direct Connect has its own usage types. Azure says other transfers are covered by ExpressRoute, CDN or peering pricing. Google prices Cloud Interconnect traffic separately.
• Routing choice. Azure publishes a lower internet rate through routing preference over a transit ISP. Google has Premium and Standard tiers, and Premium is the default.

Watch the unit. Azure states 1 TB = 1,000 GB. Google prices per GiB, which is 1,073,741,824 bytes. AWS labels its unit GB, and its Sydney price list sets the first tier boundary at 10,240, which suggests 1,024 GB per TB. Check how a real bill counts before you rely on the difference.

Step 1: Draw the paths after the move

Write every flow as source, destination and path. This is editorial method, and it decides which lines the model needs.

Consider which way each byte flows. Uploads from an office to a server are ingress after the move. Reads from that server are egress. So you need both counters, split by direction.

Step 2: Measure totals with interface counters

Use counters from routers, firewalls or switch ports to get reliable totals by direction.

For network devices, poll the 64-bit ifHCOutOctets counter and its inbound partner. RFC 2863 says a 32-bit octet counter can wrap in 34 seconds at 1 Gbit/s, which is why the 64-bit version matters. It also says the count includes framing characters, so it reads slightly higher than IP bytes. Counters can have discontinuities after a device reinitialises, so handle resets in your tool.

Choose ports with care. The internet edge gives you today's internet traffic. The switch ports facing servers that will move give you the LAN traffic that may become egress. On a server's own interface, the out-counter shows what that server sent, which estimates its future egress. A switch sees the same port from the other side: its ifHCInOctets counts what the server sent, and its ifHCOutOctets counts traffic towards the server. That reversal is an editorial warning.

On a Linux host, vnStat keeps five-minute, hourly, daily, monthly and yearly totals per interface. It reads kernel counters rather than capturing packets, so it is light. It reports totals, not destinations. The vnstat command only queries the database, and the vnstatd daemon is "responsible for data retrieval, caching and storage", so keep it running for the whole measuring period.

vnstat -m -i eth0
vnstat --json m -i eth0

The JSON form reports bytes. The interface name is a placeholder.

Step 3: Split totals by destination with flow records

Totals do not tell you which traffic moves. Flow records do. NetFlow and IPFIX exporters on routers and firewalls send per-flow summaries to a collector.

nfdump can then rank them. This example adapts the manual's statistic and filter syntax for this article, with placeholder paths and networks:

nfdump -r FLOWFILE -s dstip/bytes -n 20 'src net 192.0.2.0/24'
nfdump -r FLOWFILE -s record/bytes -A srcip,dstip 'src net 192.0.2.0/24'

The first lists the top destinations of traffic sent by a server subnet. The second shows which pairs exchange most data. Classify results into office, internet, other site and internal.

Check whether the exporter samples flows. If it does, scale with care and compare the result against the interface counters from Step 2. A large gap means the flow data needs fixing before you trust it. That comparison is editorial.

Measure across a period that includes month-end processing, full backups, patching and any quarterly peak. A single quiet week can understate the bill. This article suggests at least one full month, and preferably a quarter.

Step 4: Run a pilot and read flow logs

A pilot shows protocol behaviour that estimates miss. All three clouds offer flow logs, and they count different things.

Payload-only and header-included numbers will never match exactly. Google advises aggregating over longer periods or more resources for accuracy.

On AWS, use a custom format with flow-direction, traffic-path and pkt-dst-aws-service. The traffic-path field describes egress records only. A value of 8 means an internet gateway, 7 a gateway VPC endpoint, 2 either of those, and 1 another resource in the same VPC. By that definition, a private instance sending to a NAT gateway shows 1, so also log the NAT gateway's interface. That reading is an inference from the field definition.

AWS gives a Logs Insights example for top destinations, shown with its subnet as a placeholder:

filter isIpv4InSubnet(srcAddr, "192.0.2.0/24")
| stats sum(bytes) as bytesTransferred by dstAddr
| sort bytesTransferred desc
| limit 15

Flow logs have their own cost. Azure charges per gigabyte collected after 5 GB a month per subscription, and storage is separate. AWS applies ingestion and archival charges. Include them in the pilot budget.

Step 5: Reconcile against the bill

The bill is the final measure. Reconcile the flow data to it before you extrapolate.

AWS Cost Explorer can group usage by usage type. This command was written for this article with placeholder dates. The end date is exclusive:

aws ce get-cost-and-usage \
  --time-period Start=YYYY-MM-01,End=YYYY-MM-01 \
  --granularity MONTHLY \
  --metrics UsageQuantity UnblendedCost \
  --group-by Type=DIMENSION,Key=USAGE_TYPE

For Google, this query was written for this article against the standard usage table. SKU wording is not a stable interface, so review what it returns:

SELECT FORMAT_TIMESTAMP('%Y-%m', usage_start_time) AS month,
       sku.description, usage.pricing_unit,
       SUM(usage.amount_in_pricing_units) AS quantity
FROM `PROJECT.DATASET.gcp_billing_export_v1_BILLING_ACCOUNT_ID`
WHERE LOWER(sku.description) LIKE '%data transfer%'
   OR LOWER(sku.description) LIKE '%egress%'
GROUP BY month, sku.description, usage.pricing_unit
ORDER BY month, quantity DESC

The AWS report shows two line items for inter-Availability Zone traffic, one for each direction. For inter-Region traffic, the charge is on the outbound line and the inbound line has none. Do not sum both and treat it as doubled inter-Region cost.

Worked calculations

Google's internet line is left out, because its rate depends on the source and destination you select on its pricing page. Read it with your own selection before you compare the three clouds.

These are arithmetic examples for this article. The traffic volumes are hypothetical. The rates are published list rates. Your agreement, tax and exchange rate will differ.

Example workload after the move: 20,000 GB a month out to the internet, plus 5,000 GB replicated between zones and 8,000 GB between regions within Oceania.

Internet out: AWS Sydney

Apply the 100 GB allowance first, assuming no other account usage. The price list describes the first tier as beyond that allowance.

Internet out: Azure Australia

Azure sets the next tiers at 10 TB and 40 TB, with 1 TB as 1,000 GB.

Internal paths

The Google figure treats the 5,000 as GiB for simplicity. The AWS inter-zone figure assumes each gigabyte is metered on one sending and one receiving resource, as the billing page describes for a resource. Confirm the count on a pilot.

The AWS figure assumes the traffic is charged. AWS says to confirm the service's pricing page, because some services have in-Region traffic at no cost. Check this for database replicas between zones.

What the unit does

Suppose a device counted 20 × 10¹² bytes. That is 20,000 decimal GB, or about 18,626 GiB. On the AWS tiers above, the second reading gives about $1,979, which is roughly 6% less. If a model mixes units, the error can exceed the difference between providers.

Add margin

Multiply each path by expected growth, then add any known events. A full restore of 10,000 GB out of Sydney, in a month already past the first tier, adds $980 at the $0.098 rate. Budget for restore tests at the rate that applies in that month's tier.

What to choose and why

These are editorial recommendations.

Leaving a provider is a different case. AWS, Azure and Google each describe free data transfer for eligible customers moving out. These are conditional programmes, not a general discount, so read the terms.

Risks and limits

Warning: Do not enable full packet capture, broad flow exports or SNMP changes on production network devices without a change record and a check of device load and data handling. Flow records show who talks to whom and can identify individual users and systems.

• Published rates change. Google's pricing page records past changes to internet transfer rates. Date every rate in your model.
• Google's Sydney internet rate is not quoted here. Its table changes with the selected region, so read it with Sydney selected.
• The AWS NAT rate is not quoted here. Take it from the VPC pricing page for your Region.
• The flow data is not the bill. Fields count differently, and some traffic is excluded or sampled.
• Encapsulation is not modelled here. VPN and overlay headers add bytes that inner flow records may not show.
• Application behaviour changes. Latency can change caching, retries and chunk sizes, so the pilot may not match a simple byte copy.
• Egress is one line. Load balancers, firewalls, API requests and storage retrieval have separate charges not covered here.
• Not tested here. All behaviour comes from documentation opened on 10 November 2026. No command was run.

Sources

Opened 10 November 2026. Sources behind the corrections reopened 10 November 2026.

• Understanding data transfer charges, AWS
• AWSDataTransfer price list, Sydney
• Amazon EC2 On-Demand pricing
• Amazon VPC pricing
• Pricing for NAT gateways
• Logging IP traffic using VPC Flow Logs
• Flow log records
• Flow log limitations
• CloudWatch Logs Insights sample queries
• aws ce get-cost-and-usage
• Bandwidth pricing, Azure
• Virtual network flow logs, Azure
• Understand usage details fields, Azure
• Network pricing, Google Cloud
• Cloud NAT pricing
• VPC Flow Logs, Google Cloud
• Flow log records, Google Cloud
• Billing export tables, Google Cloud
• Standard usage cost table, Google Cloud
• Applying for free data transfer when exiting Google Cloud
• RFC 2863: The Interfaces Group MIB
• RFC 7011: IPFIX protocol
• vnStat manual
• nfdump manual

This article was originally published on 10 November 2026.