Don’t Be Fooled by Misleading Data Egress Announcements

Text Size 100%:

Part 1: The Hotel California plan meets the European Commission

Recent announcements in response to the European Data Act have led some to conclude that major Cloud Service Providers (CSP) have eliminated Data Movement and Data Egress charges, but in the ways that matter most to companies running their business in the Cloud on an ongoing basis, that’s not true. Most CSPs still charge for data moved between Availability Zones / Domains in the same Region (which is free with Oracle), between Regions, and ongoing Data Egress from their Clouds. Oracle still allows you to move a lot more data before charges start, and the rates are *much* lower once they do. That hasn’t changed.

There are a lot of articles and blogs out there that refer to the common CSPs model of charging high fees for data egress as the ‘Hotel California’ plan, in reference to the old Eagles song that ends, “You can check out anytime you like, but you can never leave.” While I’ve always loved the song, the analogy is a bit strained. You could always leave a cloud provider, but it’s been a matter of paying a potentially very hefty bill when you did so – and the more data you have to move, the higher that bill.

Data Egress charges often come as one of the biggest surprises to an organization that’s relatively new to the cloud world. For a great explanation of what they are and why they exist, check out Cloud Data Egress Costs: What They Are & How to Reduce Them. As noted in that article, there are quite a few things you can do to help reduce the charges you incur, but many of them require extensive planning up front, and potentially making changes to the architecture of an application you plan to migrate to the cloud.

Different Types of Data Movement Charges

For this discussion, I’d like to differentiate between three different types of data movement charges. First, let’s look at (1) Data Movement charges which encompass transfer of data within the CSP’s ecosystem, e.g. from Availability Zone to Availability Zone or Region to Region within the same Cloud, and thus might not be truly considered to constitute Data Egress. Then, within the realm of true Data Egress charges there are those that occur (2) as part of normal ongoing business processes, or (3) on a one-time basis as part of a migration away from utilizing the CSP’s services altogether – perhaps in order to move instead to another Cloud where either the services available or the pricing model is a better fit for your needs. Let’s look at some examples.

Data Movement within the Same Cloud

As an example of Data Movement within the same cloud, if for Disaster Recovery purposes you wanted to keep a replica of a key database in another Region you’d need to move data from one region to the other to keep your DR copy in sync. This is a very common use case as companies spread their data across multiple cloud regions. This may be primarily to provide resiliency in the event of a region-level failure or service interruption, or just to reduce latency by making data available closer to where those who need to access it are located. In Part 2 of this blog we’ll look at a detailed comparison of data movement costs in that database DR scenario with the various CSPs.

As many of you are no doubt aware, many cloud Regions consist of more than one datacenter located in close proximity. Each of these is usually referred to as an Availability Zone (AZ) or Availability Domain (AD). In concert, they provide resiliency in the event of an interruption of service that impacts an entire datacenter. In order to get the benefit, a customer would need to distribute their data at minimum, and potentially the ability to process that data as well, across multiple AZs. But moving your data from one AZ to another, whether to keep multiple copies in sync or as part of your normal processing, may come with data movement charges.

While events that impact an entire cloud region are relatively rare, they do happen. As recently as June 13, 2023, AWS experienced failures in Lambda function invocations across the US-East-1 (Northern Virginia) region that also impacted several other services as a result. While the problem was resolved fairly quickly (most services were reported to be fully recovered in a little less than 4 hours), as the primary manager of a customer AWS environment at the time I was very happy we had complete redundancy in US-West-2 and had the option to shift our critical processing there for much of the afternoon until US-East-1 had recovered. In order to have this capability we maintained synchronized replicas of a couple of important databases that then resided in AWS in both Regions. Keeping them in sync in order to be able to shift processing during the service outage comes with an associated cost including not only the additional storage required, but also – you guessed it – data movement charges.

Data Movement Within the Same Cloud
Figure 1: Data Movement Within the Same Cloud

 

Unlike Amazon Web Services (AWS), Microsoft Azure, and Google Cloud (GCP), Oracle Cloud (OCI) doesn’t charge for data movement within the same Region, even between services. So, types (1) and (2) of Data Transfer as illustrated in Figure 1 are free with OCI.

Data movement between regions within the same cloud (Type (3) as shown in Figure 1 is typically billed based on amount of data transferred out from the source region, just like egress from the cloud to the public internet but often at lower rates. CSPs typically provide a monthly allowance of Data Egress before billing commences based on volume of data transferred out. AWS and Azure allow 100 GB/month, GCP gives 200 GiB/month, whereas OCI provides a whopping 10 TB/month for free. Once charges do kick in they’re often tiered and can also vary from region to region but Oracle consistently charges significantly less as shown here.

Ongoing Data Egress Charges

Next, and also very common, are ongoing Data Egress charges from the Cloud to either the public internet, or to the customer’s on-premises datacenter. Examples might include a webserver feeding data out to the browsers of all the users that visit the website over the internet (At scale this would often entail usage of a CDN or Content Delivery Network, in many cases another service from the CSP), or a bucket in cloud object storage where data is periodically deposited by one party and subsequently retrieved for processing either on-premises or in a different cloud by another.

In our Disaster Recovery example discussed above, if you wanted to go so far in your plan as to have redundancy across multiple Clouds, the data you moved between the CSPs to keep things in sync would typically incur Data Egress charges.

Data Egress from Cloud to Public Internet or Customer Data Center
Figure 2: Data Egress from Cloud to Public Internet or Customer Data Center

 

Just as with our Region-to-Region scenario above, when it comes to egress to the public internet, Data Transfer type (4) as illustrated in Figure 2, CSPs typically provide the same monthly allowance of Data Egress before billing commences based on volume of data transferred out. In this case AWS and Azure allow 100 GB/month, GCP gives 200 GiB/month, whereas OCI again provides a massive 10 TB/month for free. Once charges do start to accrue they’re often tiered and can also vary from region to region but once again Oracle consistently charges significantly less than the other CSPs as shown here.

An even greater contrast in pricing model can be seen in the case of private or dedicated line connectivity, as indicated by Data Transfer type (5) in Figure 2. Where the other CSPs have both port and data volume charges for this type of connection, the OCI FastConnect service has no volume charges, just the port fee. This results in much lower and more predictable cost.

One-time, Unidirectional Migration of Data

Finally, we have the one-time, unidirectional movement of data away from the CSP altogether. Compared to the other types of ongoing data movement we’ve discussed this is a rare occurrence. If a large customer were to decide they wanted to move all their data away from AWS, for example, to another Cloud, depending on the volume of data in question these costs could be quite significant and constitute a barrier to the ability for that customer to freely move from one CSP to another. As a result, these charges have been seen as a potential contributor to vendor lock-in, not only by customers but also by government regulators including the European Commission, the US Federal Trade Commission, and UK regulator Ofcom.

Regulation of Data Movement Charges: The European Data Act

On January 11, 2024 the European Commission issued a Press Release announcing the enaction of the European Data Act. One of the points referenced states “Furthermore, the Data Act will allow customers to switch seamlessly (and eventually free of charge) between different cloud providers.” The Data Act comes into force after 20 months, on September 12, 2025.

Also on January 11, 2024 Google Cloud issued an announcement stating that starting on that date “Google Cloud customers who wish to stop using Google Cloud and migrate their data to another cloud provider and/or on premises, can take advantage of free network transfer to migrate their data out of Google Cloud.” Coincidence? Seems unlikely.

On March 5, 2024, AWS appeared to follow the precedent with release of this blog post on “Free data transfer out to internet when moving data out of AWS”. This post explicitly states that the new policy “…follows the direction set by the European Data Act”, and, while it states, “We don’t require you to close your account or change your relationship with AWS in any way.” It also links to an FAQ which states that “After your move away from AWS services, within the 60-day period, you must delete all remaining data and workloads from your AWS account, or you can close your AWS account”.

The following week, on March 13, 2024, Microsoft also published an update titled “Now available: Free data transfer out to internet when leaving Azure.” This one also explicitly cites alignment with the European Data Act.

Worth noting is that if you dig just a bit deeper in the links provided in each of these announcements, you’ll find that getting credit to offset these Data Egress charges for migration requires the customer in question to contact either their Account Team or the CSP’s Support organization and request approval. That only makes sense as any business wants to retain their customers and will surely ask probing questions into why they’re migrating away. In most cases they’ll probably offer incentives in a final attempt to entice the customer to change their mind about leaving.

A (small) Step in the Right Direction

While the opportunity to have Data Egress charges that are incurred during a migration away from GCP, AWS, or Azure waived is a positive development for any customers who do want to migrate from one Cloud to another (and also allows those CSPs to proclaim their compliance with new regulations), there have been many indications that some may have interpreted these announcements as having broader implications than would appear to actually be the case.

Of the three types of Data Movement charges we defined above, these policy changes as described in their respective announcements apply only to the last, i.e. Data Egress on a one-time basis as part of a migration away from utilizing the CSP’s services altogether. They have no impact on either of the first two types of data movement charges, i.e. those incurred either within the same cloud or ongoing Data Egress charges as a result of conducting business in a hybrid or multicloud model.

In the great majority of cases these two types of data movement constitute a significantly larger volume than do those of actual migrations away from one of the major CSPs. In a previous role, I managed the operations of both the AWS and GCP environments used by my employer at the time, and I can attest that these changes would not have reduced our data movement charges from either vendor during the course of a normal month by so much as a single cent. I’d assert that this would also be the case for the vast majority of cloud customers during the course of their normal operations.

In summary, it’s nice that these large CSP’s are prepared to be more flexible and reduce the financial penalties they’ve historically assessed when customers want to stop using their platforms. But don’t read into this any more than that. If you’re skeptical, click through the links to the individual announcements provided above and read them closely, then follow the links they contain to additional documentation and FAQs from the respective vendors. If you still expect these announcements are going to bring any relief from the Data Movement charges you incur every month during your normal operations, have a discussion with your Account Team. I think you’ll find that the Hotel California model would appear to be as alive and well as it ever was. You can check out anytime you like. And now they won’t even charge you by the ounce for each piece of your own luggage you want to take with you. Well, actually they still will, but if you ask nicely and tell them why you’re leaving they might give you a credit back. Either way, for all the fees they charge you during your stay with them – nothing has changed.

In Part 2 of this post we’ll take a detailed look at the impact of data movement costs with the various CSPs for the scenario I mentioned earlier of maintaining DR copies of a database across multiple Regions. In the meantime, if you’d like to learn more about how Oracle’s cloud pricing model saves customers money compared to AWS, Azure, and Google Cloud in other areas, just click here.

Steve Kilgore

Principal Product Manager

Steve has over 30 years of IT experience dating back to the early 90’s at Sun Microsystems. He ran a successful consulting company for 16 years with several Fortune 500 clients, and managed global field operations for an ISV who partners with not only Oracle but also AWS, Microsoft, Google, and others. He’s also worked on the customer side managing cloud environments from multiple vendors. At Oracle, his focus is on Database Cloud Services and how they compare across all cloud platforms.