Last week, Amazon Web Services (AWS) announced plans to remove egress fees when migrating data to another cloud provider or on-premises. This announcement follows Google Cloud’s (GC’s) plans of ridding its egress fees, announced in January (leaving Microsoft Azure as the last major cloud provider without a zero egress fee policy). Unlike Google, however, AWS doesn’t have the same caveats. It won’t require the customer to fully exit, close their account, or change their relationship in any way. But AWS does require a 60-day exit, full removal of all data and workloads, and cautions that repeated requests for migration away from AWS will face “additional scrutiny.” Either way, both AWS and GC messaging imply that these are one-way movements.

Zero Egress Fees Aren’t New To AWS — Sort Of

The cloud giant hasn’t been completely against free egress. AWS has been providing 100 gigabytes in free data egress per month since 2021 except in AWS GovCloud and AWS China regions. This new announcement would allow data migration from any AWS region — provided that the AWS account team approves. If given the green light, “no egress fees” will come in the form of free data transfer out (DTO) via AWS credits. This resembles the same credit approach GC has taken for its customers yet doesn’t awkwardly require a full exit (i.e., you must close your account in GC) as an AWS customer to get them.

What Should You Know?

Zero egress charge does not mean free and easy portability:

  • Even one-way migrations will still have issues. Removing the networking cost of the movement doesn’t mean that apps can readily move. Some elements are easier than others. The data itself can migrate easily to like/homogeneous databases. Simple applications running on basic compute and storage can also relatively easily migrate with minimal changes, but networking, specialized compute, developer and application services, and even basic architectural principles can vary drastically between vendors. This makes migration and the concept of more frequent movement — i.e., portability — challenging.
  • Egress isn’t just important for migration. Companies face egress charges whenever they leave the cloud — whether that’s migration, a recovery, or frequent communication between clouds or back on-premises. Reimbursed egress credits from Google Cloud is a one-time move, however, where you must completely exit and close your account within a 60-day migration period. AWS’s approach is more open-ended, but the same caveat of a 60-day exit period and all data and workloads needing to be deleted from that account also exists. Furthermore, AWS states that additional scrutiny may occur for multiple migration requests. Both represent one-way migration requests for massive data movement. Neither address frequent communication back and forth between your data center and public cloud, recovery scenarios, or portability nirvana — cloud-bursting scenarios.

What Should You Do?

There’s not a lot to do based off of these announcements. For many, this serves more as marketing that might check some boxes in an RFP or even to meet portability requirements outlined in the US Department of Defense’s Joint Warfighting Cloud Capability policies. For the everyday company, here’s what to consider/do:

  1. Cloud migration from a cloud just got a little cheaper, so explore your options. Keeping in mind that egress is only one part of migration costs, there’s still personnel resource hours, changing standards, new skills, and adopting similar but new services. AWS users can isolate expensive or latency-sensitive heavy compute traffic to one account or a few specific accounts and migrate these off of AWS cost-free using DTO credit. This would mean a full migration off of AWS and to another cloud provider or environment that can provide better performance or cost. GC users will need to think more holistically about their migration decisions, rather than for certain workloads. For both, pay attention to the other costs associated with this migration. Many will migrate only the most painful/costly workloads (in the case of AWS) or will choose to stay simply because it’s easier, more efficient, and ultimately more productive.
  2. Fine-tune your approach to data movement, considering network physics limits. If you’re rethinking your approach to data movement, take basic network physics into consideration. The higher the data volumes, the more time it will take for the data to be copied over, as the laws of physics apply. Your use case will determine the constraints and whether you need more bandwidth to move large data sets, more input/output operations per second (IOPS) for transactional workloads, or less latency for better user experience. Bandwidth, IOPS, and latency are driven by connection size, network protocols, and network path length (physical distance, hops). Be aware that your estimations do not include the data governance activities (time to validate the data integrity, quality, and so on), so this needs to be accounted for when leveraging data egress from the hyperscalers in your designs. Service tier is the last major consideration.

Note: Later in the day after this blog post published, Microsoft Azure also announced the removal of its own data transfer fees when canceling/deleting an Azure subscription.