https://www.lastweekinaws.com/blog/awss-anti-competitive-move-hidden-in-plain-sight/ * Skip to primary navigation * Skip to main content Last Week in AWS LogoLast Week in AWS Logo Lower My AWS Bill Mobile Navigation IconMobile Navigation Icon Close Mobile Navigation IconClose Mobile Navigation Icon * AboutSubmenu Down ArrowSubmenu Down Arrow + Community + Contact + Contribute * Blog * Newsletter * PodcastsSubmenu Down ArrowSubmenu Down Arrow + AWS Morning Brief + Screaming in the Cloud * Merch * ResourcesSubmenu Down ArrowSubmenu Down Arrow + AWS Job Board * Sponsorships [svg][177030887_l_normal_none] 03.15.2023 AWS's Anti-Competitive Move Hidden in Plain Sight By Corey Quinn Folks have been making noises for a while that Amazon is anti-competitive in a variety of ways. I don't disagree with the overall sentiment, but there's one particular aspect of how AWS... FacebookTweetLinkedInReddit Home Blog AWS's Anti-Competitive Move Hidden in Plain Sight Prev Folks have been making noises for a while that Amazon is anti-competitive in a variety of ways. I don't disagree with the overall sentiment, but there's one particular aspect of how AWS advantages its own offerings that I don't see folks talking about-and strikes me as particularly egregious. Let's say I want to run something open-source in my AWS account; call it MySQL for this thought experiment. I can set up MySQL on an EC2 instance, or I can use AWS's own managed service (in this case, RDS) to do it for me. I'll pay slightly more for RDS, but that's fair; there's value in having AWS's operational expertise applied to running infrastructure for me. A bit of background that'll help make this diatribe make sense: AWS regions are broken into Availability Zones, or AZs; these AZs are physically distinct facilities, separated out by some relatively low number of miles. One of the tenets of AWS's global infrastructure is that both regions and AZs are designed to constrain the blast radius of failures; an outage in one AZ shouldn't also take out another AZ in the same region. By and large this works; as a result the sensible thing to do for workloads that need to be highly available is of course to provision those workloads in multiple AZs. The problem that I want to highlight today is that if I spin up MySQL myself on EC2 instances, I'll have to pay 2C/ per GB that I replicate between AZs, whereas I will pay nothing if I use RDS. At first, this seemed like a nice benefit that AWS offered as a part of its managed services-but over time I've seen a number of scenarios where people are using AWS's managed service offerings rather than what they really want to be using specifically because this cross-AZ data transfer fee becomes ever more burdensome as workloads continue to scale. This problem goes beyond just RDS's MySQL implementation; we see it again and again across their ever-growing catalog of first-party offerings. It hits their other RDS offerings as well, including PostgreSQL, MS SQL Server, and all the rest. If you want to run OpenSearch yourself, you'll pay a fee to do it; replication traffic is free for AWS's managed OpenSearch service. If you want to run MongoDB yourself, you're once again paying that 2C/ per GB fee on going about your business, whereas if you run Amazon DocumentDB (with MongoDB compatibility) you're giving up a lot of flexibility, in return for not being taken to the cleaners with replication traffic charges. It's Also Not Just Open Source Projects This is annoying and obnoxious in its own right, but where I'm surprised it hasn't become more of a public issue is when this is applied to other vendors-regardless if they're an AWS Partner or not. If I want to run OpenSearch myself, or have Elastic run Elasticsearch on my behalf, I'll be paying for cross-AZ replication traffic because AWS has taken advantage of its position as "the only data transfer option in town" in their environment to benefit their own competitive offering. The same applies to services from a veritable universe of database vendors, Confluent if I want to have them manage Kafka for me, Redis if I don't want to use Amazon's ElastiCache or MemoryDB offerings, etc. There is no third party vendor that's exempted from the tax on cross-AZ data transfer; and yet there is no first-party managed service that AWS offers in a "cloud hosted" configuration that I'm aware of that doesn't include free cross-AZ transfer. If you were to ask me to point at something anticompetitive that the AWS division of Amazon does, this would be my first port of call; no other company can do anything to avoid this tax on customers, whereas AWS "bakes in the cost" to how they price their own services. The Third-Party Tax I'm not saying that AWS's managed services don't add value to customers; of course they do. I'm also not saying that this is some kind of mustache-twirling conspiracy on behalf of AWS to advantage their own services; I suspect this arose organically over time. What I am saying is that customers now face the difficult decision to bias for cost savings vs. reliability in a particularly pointed way. "Stop using those pesky third parties and use us instead and this pain goes away" is only a fair statement when the first-party option wins on its own merits, rather than its uniquely privileged position as the sole network provider to the entire environment. I'd like to see more adoption of AWS services due to their own merits, rather than rent-seeking value that's built upon ways in which others aren't fairly allowed to compete-and charging for replication traffic between everything that isn't a managed service with "Amazon" on the label is exactly that. Corey Quinn HeadshotCorey Quinn Headshot by Corey Quinn Corey is the Chief Cloud Economist at The Duckbill Group, where he specializes in helping companies improve their AWS bills by making them smaller and less horrifying. He also hosts the "Screaming in the Cloud" and "AWS Morning Brief" podcasts; and curates "Last Week in AWS," a weekly newsletter summarizing the latest in AWS news, blogs, and tools, sprinkled with snark and thoughtful analysis in roughly equal measure. More Posts from Corey Back to the Blog [svg][193781870_l-350x200] AWS is Asleep at the Lambda Wheel By Corey Quinn Countless volumes have been written about the various benefits of serverless, a task made even easier by it being such a squishy, nebulous term that's come to mean basically whatever the author wants it to mean. This has been a boon for AWS's product teams, who've gone from creating services that are clearly serverless such as DynamoDB, Route 53, IAM, and others to instead slapping the "serverless" moniker on things that are clearly not very serverless at all, like OpenSearch and Aurora. Read More about AWS is Asleep at the Lambda Wheel Amazon Snowball device sitting on Corey's dining tableAmazon Snowball device sitting on Corey's dining table Amazon's Snowball Edge Frustrates This User By Corey Quinn A friend who happens to work at AWS recently had reason to send me about 500 GB of data. This friend is a business user. Now, say what you want about AWS's hiring practices, they certainly don't hire people who aren't intelligent. This intelligent person made the very reasonable determination that the best solution they had available to send me that half terabyte of data was to mail me a hard drive. Read More about Amazon's Snowball Edge Frustrates This User AWS piece not fitting into the Community puzzle.AWS piece not fitting into the Community puzzle. The AWS community isn't for Amazonians By Corey Quinn If you work for a company with a platform or tool that fosters a community around it, you are not a part of that community. Read More about The AWS community isn't for Amazonians Billie Holding Mail Email Subscribe IconBillie Holding Mail Email Subscribe Icon Get the newsletter! Stay up to date on the latest AWS news, opinions, and tools, all lovingly sprinkled with a bit of snark. Email [ ] Hidden rgsid [ ] Phone [ ] This field is for validation purposes and should be left unchanged. Sign Me Up! The world of cloud takes itself far too seriously. We aim to change that. Lower my AWS bill, please! * Newsletter * Podcasts * Blog * Merch * Contribute * About * Contact * Sponsorships * Disclosures Billie FooterBillie Footer (c) 2023 The Duckbill Group. All Rights Reserved. Privacy Policy Cookie Policy