Understanding AWS Egress Cost When You Migrate Off AWS

A 40TB exit from us-east-1 is a one-time line item on the final invoice, and most teams see it for the first time after the migration has already finished. That is the worst possible moment to discover it.

That single number is the whole reason "egress cost aws" gets typed into a search bar at 11pm. It is a one-time tax on leaving, not a monthly bill, and it is calculated on bytes pulled out of the region. Not on how clever your migration tool is. Not on how many parallel workers you spawned. Bytes out, dollars owed, invoice at the end of the month.

The last AWS invoice is the one nobody plans for

AWS egress is priced as a per-gigabyte meter on traffic leaving a region, and the shape of that model is the only thing you need to forecast. Historically the public internet rate from us-east-1 was around $0.09/GB, with the first 100GB per month free, and everything after that billed on bytes, aggregated across most services, on the source side. Rates change. The model doesn't: you pay per gigabyte, and the free tier is small.

Nobody gets surprised by the per-gigabyte model itself. They get surprised by the multiplication.

Run the arithmetic before you run the migration. 40TB is 40,960GB. Subtract the free tier, apply your current rate, and you land somewhere around a few thousand dollars. A 200TB archive lands in the tens of thousands. A 1PB media library, well, you can do that one in your head and then sit down.

The number to put in your capacity plan is a one-time line item equal to bytes moved, not a recurring fee. This distinction matters more than it sounds. If you budget egress as a monthly cost, you'll over-provision and panic. If you budget it as a project cost, you can compare it against the annual savings that justified the migration in the first place. Most exits pay back the tax in a few months. Some do not, and you should know which one you are in before you start.

There is a second thing to internalise. Egress is billed by the source provider, so it does not care which tool you use. rclone, our console, a hand-written Go program, a fleet of EC2 instances piping through the public internet, all of it produces the same meter reading. The tool changes your operational risk and your audit trail. It does not change the invoice.

Which means the migration tool is not the lever. The lever is knowing exactly which bytes you are moving, and being able to prove later that you moved them once.

Egress fees are one-time, the bill that follows is not

The per-GB internet rate is the headline, and it is almost never the whole story. If you forecast only on that number, you will be wrong in a specific direction: low.

Here is where the money actually goes.

• Cross-AZ traffic. If your migration reader runs in a different availability zone than the bucket's endpoint resolves to, you pay for the hop between zones before you pay for the hop to the internet. Usually a few cents per GB, but it stacks on top and it is easy to miss because it appears as a separate line.
• Internet versus inter-region rates. Moving data from us-east-1 to eu-west-1 is not the same rate as moving it to your laptop. Inter-region has its own price. If your destination is another AWS region, you are paying a different meter, and the free tier does not apply the way you think it does.
• NAT gateway charges on the source side. This is the one that ruins afternoons. If your migration runs from a private subnet and reaches S3 through a NAT gateway, you pay NAT data processing on top of egress. Both meters spin. The fix is a VPC gateway endpoint for S3, which is free, and which a surprising number of teams do not have configured when the migration starts.
• S3 request charges for millions of small objects. Egress is per gigabyte. Requests are per thousand. A bucket holding 40 million 1KB files is almost nothing in bytes and a serious bill in GET requests. If your dataset is small files, the request line can exceed the egress line.
• Versioning and non-current versions. You are billed for what is actually stored and what is actually read. If versioning is on and a lifecycle rule never pruned the old versions, your byte count is larger than the number you got from aws s3 ls --summarize on the current objects.

The fee is a gate, not a subscription. You pay it once, you leave, and the meter stops. That is genuinely good news, and it is why the panic is usually misplaced. The panic belongs on the operational side, not the financial one.

Because here is the failure mode that costs more than the egress. You run the migration. You verify. You delete the source bucket. Three weeks later, someone finds a bucket, or a replication target, or a Glacier restore job, that was pulling bytes from the old region the whole time. Now you are paying egress on a source you thought was gone, and you have no clean way to prove what moved and when.

Which is the actual thesis of this post. On a migration off AWS, the tool matters less than the audit trail. You need to be able to answer, months later, with evidence: these bytes left, they arrived intact, and nothing has been billed twice.

A checklist for the day you stop paying AWS to leave

This is the part you run before the migration, not after. It is boring and it is the whole job.

1. Inventory bytes. Not object count from the console summary. Real bytes, per bucket, including non-current versions and any incomplete multipart uploads sitting around accruing storage charges. aws s3api list-object-versions if you want the truth.
2. Inventory object counts separately. Because request charges scale with objects, not bytes, and a bucket with 10 million tiny files is a different migration than a bucket with 10 large ones.
3. Read every lifecycle rule. Expiration, transition to Glacier, abort-incomplete-multipart. A rule that transitions objects to Glacier mid-migration will change your byte math and possibly your restore costs.
4. Check versioning state. Enabled, suspended, never on. Each one means something different for what you are actually copying.
5. Check object lock and retention. If a bucket has a compliance retention policy, you may not be able to delete the source until it expires. Plan the overlap.
6. List cross-region replication targets. Replication keeps copying. If you leave it running while you migrate, you are paying egress twice on the same bytes.
7. Get the egress estimate from the source console in writing. AWS Cost Explorer and the pricing calculator both produce a number. Save the PDF. When finance asks why the final invoice has a large one-time line, you have the forecast.
8. Pick the destination and confirm its ingress is free or cheap. This is where the choice of destination does more for your bill than the choice of tool. Several S3-compatible providers charge nothing for ingress.
9. Run a dry-run sync. Whatever tool you use, make it list what it would move without moving it. Compare that list against your inventory from step one. If they disagree, you have found a bug in your inventory, not your tool.
10. Verify byte-for-byte checksums. Not object counts. Not sizes. Checksums. ETags lie on multipart uploads, so use the provider's checksum metadata or compute your own.
11. Keep the old bucket read-only for a full billing cycle. Do not delete it. Remove write access, keep read access, and watch the invoice for a month. If something is still reading from it, you find out now, cheaply, instead of after the data is gone.

That last item is the one people skip, and it is the one that catches the replication job nobody remembered.

Now the part where we tell you not to use us.

If your budget for this is zero, the conversation is over and rclone wins. It is free, permanently, with no account and no vendor. It supports 70+ backends, including the consumer clouds we deliberately do not touch. It mounts. It is scriptable. It runs inside your own security boundary, which means your credentials never leave hardware you control. It has been maintained for over a decade. For a large number of people reading this, the honest answer is: use rclone, and use it today.

We do not mount storage as a local drive. There is no FUSE surface. If you want remote buckets appearing in Finder or Explorer, we cannot do it, and rclone mount or Mountain Duck can. We connect the S3-compatible family and any custom S3 endpoint, and nothing else. No Google Drive, Dropbox, OneDrive, SFTP, WebDAV or Box. If the job is Drive-to-bucket, we are the wrong tool and MultCloud or rclone is the right one. Your credentials sit encrypted in our database, not on your own hardware. The encryption is real, AES-256-GCM with per-namespace keys, and AWS can be connected keylessly by IAM role assumption, but "the keys never left my laptop" is a stronger answer than ours and it would be dishonest to pretend otherwise. We are a console, not a command. We do not compose with cron, systemd, CI pipelines, shell scripts and Makefiles the way a binary does. If your workflow is code, a CLI fits it natively and a web UI never will. We are a small team and Storafleet started in 2026. On the question "will this still exist in five years", a decade-old open-source project has a better answer than we do.

So, plainly: who should not use us for this migration.

• Budget is zero. Use rclone. The conversation is over and rclone wins.
• You need storage mounted as a filesystem. Use rclone mount, Mountain Duck or ExpanDrive.
• You need Google Drive, Dropbox, OneDrive or SFTP. Use rclone or MultCloud.
• Credentials must never leave hardware you control. Use rclone, or our IAM-role connect if the job is AWS only.
• Everything lives in one cloud and always will. That provider's own console is free and more current than we are.
• The workflow is entirely code and always will be. A CLI composes and a console does not.

For everyone else, the reason to use us is narrow and specific. You are moving a large dataset between two S3-compatible providers, you want a checksum-verified audit trail, you want per-bucket cost visibility so the egress line stops being a surprise, and you would rather click through a console than maintain a shell script. That is the job. It is not every job.

If you want a console to run the sync and the verification against 50+ S3-compatible destinations, that is what we built, and the migration walkthrough lives at storafleet.com/migrate-off-aws. We never charge per gigabyte to move data. Migrated bytes are unmetered on every tier, including Free. That pricing model exists because per-GB egress is exactly the thing we think is broken, and charging the same way would make us hypocrites.

The egress bill is a gate you pay once. The audit trail is the thing you keep.