[HN Gopher] AWS's anti-competitive move hidden in plain sight
___________________________________________________________________
AWS's anti-competitive move hidden in plain sight
Author : mooreds
Score : 185 points
Date : 2023-03-18 14:43 UTC (8 hours ago)
(HTM) web link (www.lastweekinaws.com)
(TXT) w3m dump (www.lastweekinaws.com)
| andrewmcwatters wrote:
| Who are these engineering suckers who are spending all of this
| dollar-labor on solutions YOU KNOW full well at every opportunity
| will they want to find a way to lock you in, or to obscure
| engineering costs to you to make a deal look cheap, and then not
| knowing that leaving the lock-in costs more than writing a cloud
| independent solution to begin with?
|
| I blame this lazy attitude of not knowing how to use your tools
| and instead asking cloud providers to know how to do things for
| you. Every single time I see an engineering team fail to
| understand how to use their tools and do their homework, they
| take the easy and long-term expensive way out. Oh and by the way,
| those solutions engineers you talk to barely know any better
| either. You will STILL eventually have to learn how to actually
| use the infrastructure you chose.
|
| I write solutions for enterprises that are entirely independent
| of cloud specific offerings and then make sales engineers fight
| for volume business knowing they have no leverage.
|
| Oh, you price hiked on us without notice? We already had
| deployment scripts to move providers and perform db redirections
| same-day and had already gone through procurement with other
| providers for insurance. Oh darn. Guess you shouldn't screw
| around with your customers.
|
| As soon as you enter the pool, they WILL pull the ladder from
| you.
| vasco wrote:
| > I blame this lazy attitude of not knowing how to use your
| tools and instead asking cloud providers to know how to do
| things for you.
|
| If you want to have such a strong attitude towards people who
| use Aurora instead of running Postgres on an EC2 instance maybe
| you should be collecting some silica sand instead of worrying
| about cross-cloud compatibility.
| semicolon_storm wrote:
| If you fully believe this, why are you even using a cloud
| provider? Why not buy your own hardware and set up your own
| server racks?
|
| Of course it's because you agree on some level that DIY and
| "knowing how to use your tools and instead asking cloud
| providers to know how to do things for you" is simply not worth
| it. Companies who use these premium managed services are just
| setting the bar 1 level higher than you do.
|
| Even if these premium services end up costing $200K/year more
| than doing it yourself on commodity VMs, that's not even the
| salary of 1 FTE engineer at many companies. It's simply not
| worth the time and opportunity cost to care about those things
| if it's distracting engineers from working on the core product.
| [deleted]
| rwalle wrote:
| Yeah, I thought this conversation was open and shut many
| years ago and the business model of cloud provider is very
| clear.
| hibikir wrote:
| It's typically people whose incentives in no way align with
| lowering long term costs for their organization. When you are
| building something new, the incentives are often on speed of
| delivery, plus whatever you can learn for yourself. Evaluating
| whether you'd be saving a lot of money 3 years from now is
| something that't rarely going to lead to raises or bonuses. You
| might not even be working at the same place by the time the
| problem is visible. And even if you do, it's often far better
| for yourself to build something that will catch fire and then
| put it out than to build something better in the first place.
|
| This happens in basically every organization out there, even in
| the best ones. I've saved millions a month in AWS costs that
| came from decisions of people that are major tech leaders
| today. The original architect is now a CEO in a company you
| know, and I looked great for my efforts: Everyone won, other
| than the largest shareholders, who weren't looking into the
| decisions at all, as they had bigger fish to fry.
|
| If incentives are such that the extra effort to be more cloud
| portable are useless to the person spending the effort, of
| course they are going to be "lazy". I've never worked at a
| place where I couldn't massively cut hardware or cloud costs by
| trying a little bit. It's just rarely been something that was
| anywhere near the top of the priority list.
| dilyevsky wrote:
| We've been also living in a qe bubble for 15 years. While it
| doesn't look like qt is gonna hold much longer we also
| probably unlikely to return in the "spend $$$ as fast as you
| can" mode for a while so we might see (actually already
| seeing) a resurgence of cloud expatriates
| fnordpiglet wrote:
| TLDR "Aws networking costs are a racket"
| zokier wrote:
| The argument would carry more weight if it included data on
| pricing; how much more do AWS managed services cost vs bare ec2,
| and what are typical amounts of bandwidth costs for the non-aws
| managed options. Just because AWS rolls the pricing under single
| pricetag doesn't automatically make it anti-competitive
| untitaker_ wrote:
| I have a suspicion that cloud vendors are using bandwidth pricing
| as a way to deter abuse. Can't use them for ddos, tunneling, file
| sharing or mass scraping that easily anymore. The lock-in is a
| nice side effect.
|
| Though Corey is talking about internal network use and I am
| talking about bandwidth to internet
| saurik wrote:
| I correctly guessed this would have to do with bandwidth pricing,
| but I didn't successfully anticipate which specific aspect of
| bandwidth pricing; this quirk had never occurred to me before,
| but yeah... that sucks :(.
| viraptor wrote:
| I'm up for AWS bashing more often than not, but I don't get what
| this post is proposing. Should AWS overcharge for the RDS traffic
| that is handled differently than generic customer connections? Or
| should they do deep packet inspection on all traffic to pick out
| MySQL replication streams and bill them at lower rate because...
| reasons? Or something else?
|
| What does the better version of this situation look like?
| lamontcg wrote:
| The traffic between AZs is probably being priced
| anticompetitively and they should reduce that cost. It is very
| likely marked up enormously over the cost of the circuits.
| simplotek wrote:
| > I'm up for AWS bashing more often than not, but I don't get
| what this post is proposing.
|
| The discussion topic is about anticompetitive practices.
|
| AWS charges a premium on intra-region traffic, when other cloud
| providers do not. The thesis is that these arbitrary charges
| are designed to force users to consume their managed services
| which further leads to vendor lock-in.
|
| Can these arbitrary intra-region traffic charges be interpreted
| as anticompetitive practices? I believe there's a good case to
| be made. Don't you agree?
| wmf wrote:
| _RDS traffic that is handled differently than generic customer
| connections_
|
| Is this documented anywhere? I would assume it's handled the
| same.
| Jensson wrote:
| It isn't a coincidence that they take their margins on
| bandwidth instead of compute. Makes you do the computations
| locally at AWS instead of sending it to some other datacenter.
|
| The better version that will never happen is that AWS makes
| their margin evenly on all purchases. But that wont happen
| since by pricing bandwidth so highly encourages people to do
| everything at AWS instead of sending data between providers.
| watermelon0 wrote:
| Compared to pricing of non-cloud providers, I'm sure AWS also
| takes their margin on compute. It might be a magnitude less
| than for bandwidth, but it's still there.
| bushbaba wrote:
| Why do you think they make huge profit on bandwidth. Larger
| customers all have PPA agreements with very large discounts.
| Smaller customers get the benefit of a stellar network with
| elasticity in the Tibps plus range for a small $/GiB fee.
| Jensson wrote:
| > Smaller customers get the benefit of a stellar network
| with elasticity in the Tibps plus range for a small $/GiB
| fee.
|
| Are you AWS sales? This seems unrelated to the discussion
| to me.
| eropple wrote:
| _> Why do you think they make huge profit on bandwidth._
|
| Because I have a rough idea of what bandwidth costs _me_ at
| a data center, I can make some conservative extrapolations
| for their economies of scale, and I can read the AWS price
| page.
|
| (I have also negotiated discounted bandwidth fees for AWS,
| and while they can be substantial, AWS is not going
| hungry.)
| sidlls wrote:
| I don't see how this is anti-competitive. It's a crappy business
| practice designed to promote lock-in, but Google Compute and
| Azure both exist and are run by large, well-known companies that
| have the marketing and technical prowess to compete with AWS (and
| they do, even if not as effectively as they--or the consumer--
| would like).
| akira2501 wrote:
| A market dominated by three large players is not particularly
| competitive, especially since all their offerings are mostly
| the same, cost mostly the same, and there's very little to
| differentiate between any of their services.
| gnur wrote:
| If only that was true, the only way to remain cloud agnostic
| seems to be to use Kubernetes and some kind of managed sql
| database. Once you factor in some things like pubsub, SNS,
| dynamodb or firebase you quickly lock yourself in. Running
| the same server less application across clouds gets even more
| complicated
| scarface74 wrote:
| Anyone who thinks that using K8s and running everything on
| your own makes "cloud agnosticism" realistic has never
| dealt with large scale migrations and the institutional
| complexity behind it. (Yes I'm agreeing with you)
|
| Yes I work for AWS Professional Services now. But I've seen
| the same with Azure and on prem in previous jobs. It hardly
| ever makes business sense not to go all in on whatever your
| infrastructure decisions are.
| AndrewKemendo wrote:
| >It's a crappy business practice designed to promote lock-in
|
| Making it harder to switch is by definition anti-competitive
|
| The whole point is that companies should not be trying to trick
| or stifle customers in any way from making a rational decision
| that is in their own best interest, including leaving their
| service.
|
| The whole game here is "what can we get away with" and playing
| that game to start with is unethical.
| danw1979 wrote:
| Intra-region traffic (i.e. inter-AZ) being free would make way
| more sense to a customer.
|
| I'd really love to know what the marginal cost to AWS for this is
| though. I reckon there's a very healthy margin in that 2c/GB.
| simplotek wrote:
| > I'd really love to know what the marginal cost to AWS for
| this is though.
|
| I'd wager that AWS's marginal cost for intra-region traffic is
| zero. They own their infrastructure and other than maintenance
| and upgrades they have no cost linked with traffic volume.
|
| Some cloud providers charge a round zero for intra-region
| traffic, and they don't have anything resembling AWS's scale. I
| doubt it's a loss leader.
| tuetuopay wrote:
| > Some cloud providers charge a round zero for intra-region
| traffic
|
| That's likely a selling point to attract people to the
| competition. "Look, our bandwidth is free!"
|
| Also there is quite a lot of cost for internal, inter-zone,
| traffic. You need all the routing equipment and the fiber
| links for that. And such traffic does not go through the same
| links as the public one, because you'd be paying the cost of
| public bandwidth trough transits or peerings. You want your
| own backbone, but this has a cost that needs to be amortized.
| Furthermore, properly designing such a network has a cost in
| engineers.
| eropple wrote:
| It's not just a selling point, it's a reflection on how
| providers see customers. I've been struck when using other
| platforms (OCI, some PaaSes) that it feels a lot more like
| a partnership, where everybody makes money when I succeed,
| than a short-horizon extraction machine. And sure, maybe
| they'd change their minds in AWS's position...but they're
| not, and maybe _nobody_ should be allowed to be as big as
| AWS?
|
| OCI also doesn't charge for NAT gateways, which makes sense
| because it's a configuration in a router that already
| exists and is already doing things. AWS, on the other hand,
| brings out the knives for you.
| js4ever wrote:
| Do you think OCI would keep that pricing if they where
| the leader? Just check Oracle history for milking
| customers
| bauruine wrote:
| A single 800Gbit/s port can do 259200000 GB a month. That's
| 5'184'000$ a month. Their traffic prices are ridiculous and
| there is no excuse for it.
| piyh wrote:
| You're not buying the gigabytes, you're buying the
| systems engineering that carries those gigabytes.
| bauruine wrote:
| AWS engineers must be horrible because others are able to
| do it for at least an order of magnitude less.
| simplotek wrote:
| > That's likely a selling point to attract people to the
| competition. "Look, our bandwidth is free!"
|
| But bandwidth is free in intra-node traffic, isn't it? I
| mean, in some scenarios this traffic doesn't even leave the
| server. What does localhost traffic cost you?
| sitkack wrote:
| ssssh! If the FTC did their job, the way Cloud providers
| priced bandwidth would drastically change across the
| board.
|
| How much does Google pay for bandwidth? What percentage
| of the backbone do they own/lease/run?
| lozenge wrote:
| What's the cost of _not_ having routing equipment and a
| backbone? At that point they would just be two separate
| regions which are too geographically close to actually
| offer redundancy.
| PaulDavisThe1st wrote:
| You think amzn pays zero for inter-AZ transfer costs over
| fiber/whatever they don't own?
| mtnGoat wrote:
| If I understand correctly, the author is upset that a business
| offers various pricing models to drive consumers towards certain
| decisions?
|
| Doesn't like, every company do this?
| bhammack wrote:
| That's how I also interpreted the article. The author makes a
| decent argument for how this is an anti-consumer practice, but
| doesn't highlight how the very intentional business design
| decision to invite consumers into a walled garden for a lower
| cost is anti-competitive.
| vasco wrote:
| > 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.
|
| The author acknowledges they know they are already paying a
| premium for the managed service. With that premium you are also
| paying for the traffic between instances. If the price was the
| same I'd see how this is anti-competitive but like this I don't
| understand the argument.
| simplotek wrote:
| > With that premium you are also paying for the traffic between
| instances.
|
| No, you aren't. You're paying for the service following an
| arbitrary pricing model that bears no relationship with their
| business costs.
| imwillofficial wrote:
| You have no idea how that's calculated.
| mixedCase wrote:
| You could've shortened that to: You're paying for the cloud
| integration and the management software*
|
| Most paid software has no relationship between its price and
| business costs. That's what makes software special from the
| business perspective.
| jasonhansel wrote:
| I believe locking customers in to proprietary services is called
| "going full IBM."
| oneplane wrote:
| I wonder how much of this is a primary goal or just a nice side-
| effect for AWS. I imagine the custom internal forks of all this
| stuff, and their own data management systems are simply not
| compatible with the native variations that the products
| themselves have. From AWS's perspective it might seem wasteful to
| pro-actively support outbound data, and as a nice side-effect it
| makes it harder to leave or host an alternative.
|
| For us, this is just part of the calculation; if we have special
| cases we run it ourselves, but the case also has to justify the
| inter-AZ replication and other side-effects.
|
| The way we use AWS services also assumes migration paths outside
| of what you would normally do (binlog or CDC options) where we
| don't migrate 'the database' but 'the service' that relies on the
| persistence offering. This is of course much harder if some of
| your functionality relies on AWS-specific things, but for the
| average persistence system (ES, RDBMS, NoSQL, Redis, Memcache,
| object storage, Kafka, MQ) it really isn't all that exciting and
| the AZ cost is hardly a significant factor of the showstopper
| kind.
|
| Perhaps this also is due to the way we designed our persistence
| systems; we only allow single-owner persistence, so no shared
| redises, databases or tables or schemas. We also don't do any
| binlog PITR, we use Kafka rewinds in between RDBMS snapshots
| since the database isn't the only factor in our consistency and
| partition tolerance conundrum. And Kafka itself is so 'thin' on
| the server side that binary exports/imports are only tied to the
| major version and highly dependant on what the client does (which
| is something AWS does not control - if they would their MSK
| offering would be useless).
|
| Using AWS as a 'virtual datacenter' or 'managed version of the
| thing you already have' is bound to turn into a PITA. That
| applies to GCP as well, but almost 10x for Azure. Ironically,
| you're better off not using the big three if that is what you
| want, you don't get a lot of the features, but you also pay a
| fraction of the cost. And if you're not using the features anyway
| (or see them as a problem), Linode, Vultr, DO, even Scaleway are
| all a much better fit anyway.
|
| In my cases where we use AWS, it's almost always for the same
| reasons: - We use enough of it to get discounts
| - We use enough of it to allow us to do 10x with the same people,
| it is a very significant force multiplier - We require some
| of the cross-service facilities like IAM, KMS, ACM, Security
| Groups
|
| In a small number of cases it's also for compliance reasons, but
| I try to stay away from that since that usually comes with a
| checkbox clipboard manager/auditor regime as well, and I don't
| enjoy managing or working for those.
| kobalsky wrote:
| another victim of the ridiculous prices for egress traffic that
| most vps providers impose.
| viraptor wrote:
| He's not a victim - he mostly benefits from them. He runs
| https://www.duckbillgroup.com/
| mikesabbagh wrote:
| How many services were saved by HA? The cost of HA is loss of
| performance and increased complexity in addition to monetary
| cost. If your application is not highly critical, I am not sure
| you are benefiting from HA. Is hackernews HA? nope
| JCM9 wrote:
| The author makes some glaring assumptions that these managed
| services are just sort of managed EC2 with no further
| optimizations. I find it very hard to believe that this is the
| case. Just on networking (which is his focus here) there's a ton
| of opportunity to optimize networking between physical locations
| if you're running a managed database service. It's very
| reasonable for AWS to pass those savings onto their customers.
|
| Corey likes to bash AWS for sport. Sometimes he has a point and
| other times he's off the mark. Here he's missed IMHO. He's
| swatting in the air trying to find a controversy where there
| isn't one.
| tuetuopay wrote:
| AWS spawned off with Amazon realizing the value of dog-fooding,
| which is using their own products to build other products, and
| to sell all the steps. That is, the base premise was Amazon
| Retail being a client like any other of AWS. It is not a
| stretch to imagine the same goes for many AWS manages services
| to be built atop EC2. There are many products that are prime
| candidates for this: API gateway, Kubernetes, Lambda (which is
| likely built atop the managed kubernetes), etc
|
| Heck, you can look at other cloud providers, and in some cases
| they are very open about stuff "being build atop public
| compute". One example that comes to mind is the VPC
| interconnect of GCP to get reachability between serverless and
| the rest of the VPC: it uses plain old compute to route the
| traffic; you can even pick which type and how many to
| provision.
| mdaniel wrote:
| > Lambda (which is likely built atop the managed kubernetes)
|
| https://news.ycombinator.com/item?id=34964197 (Firecracker
| internals: Inside the technology powering AWS Lambda (2021))
| may interest you, but the short version is no, not on top of
| kubernetes
|
| Cloud Functions from GCP run on top of knative, one can see
| it in the metadata: keys, but unknown if it's "vanilla"
| knative or they have their own knative provider that does
| further trickery under the hood
| supriyo-biswas wrote:
| Lambda was built on top of crosvm, which has been known for
| very long but only acknowledged recently in their 2021
| paper.
| iampims wrote:
| GCP doesn't run knative on top of k8s. They implemented the
| API on top of their own multi-tenant virtualization
| software.
| scarface74 wrote:
| You've said so many things that are factually incorrect it's
| hard to know where to start.
|
| There are very few services on AWS that started based on what
| Amazon Retail used. Even today, much of Amazon's
| infrastructure is not on AWS.
|
| Lambda is also not built on top of Kubernetes.
|
| The one service that I can think of that came from Amazon
| Retail is Amazon Connect. It was originally used as Amazon's
| own call center. You can tell it wasn't built specifically
| for AWS because there was no public API for automated
| provisioning and no IAC support for years.
|
| Google's infrastructure is also not built on top of GCP. Very
| little of Google uses GCP and it's mostly unimportant things.
| imwillofficial wrote:
| Bro there is not a lot of dog fooding, from Apollo to LPT to
| CDO, retail is not just another customer.
|
| It's changing though, slowly
| daneel_w wrote:
| In my opinion there are better examples, such as how AWS' managed
| products are deliberately hobbled and handicapped to make it
| complicated to migrate _away_ from them once you 're in. Two
| examples that I have first-hand experience with:
|
| It's easy to set Aurora up as "slave" for accepting replication
| data from an external MariaDB/MySQL server in order to make a
| smooth low-downtime migration into AWS, but there are... oddly
| peculiar kludges... when wanting to set Aurora up as "master" and
| have it feed its binlog _outside_ in order to migrate away in the
| same smooth fashion.
|
| For their managed Redis ("Elasticache") they have intentionally
| disabled a few functions that relate to exporting/migrating live
| data from one Redis instance to another. In particular the
| "MIGRATE" function, which is used specifically to make a fast and
| accurate dump of all data when you want to supplant (read:
| migrate) a Redis instance. Instead you have to hack manual
| outbound migration together yourself, key by key, database by
| database.
| cma wrote:
| Free ingress, expensive/hard egress.
| simplotek wrote:
| > Free ingress, expensive/hard egress.
|
| Let's call AWS's "Free ingress, expensive/hard egress"
| business model as the AWS roach trap pattern.
| marcosdumay wrote:
| "Roach trap pattern" is actually a great name.
| bargle0 wrote:
| I've heard it called the Hotel California pattern.
| daneel_w wrote:
| "The first one's on me, friend."
| charcircuit wrote:
| Pretty much every single network provider offers free ingress
| or egress. That is the industry standard pricing model for
| paying for bandwidth.
| watermelon0 wrote:
| IMO these two examples might just be cases they were not
| optimizing for, and didn't want to invest engineering time (and
| future support) into something seldomly used.
| georgyo wrote:
| They are seldomly used because they are difficult to use.
|
| They are difficult to use because using them means loss of
| money.
|
| Combined with other entrapping features means the all
| features that help escaping the ecosystem are seldomly used.
| So any individual products off boarding features are even
| less used.
|
| These are also features that don't use more than once.
|
| So of course when a product manager looks at usage metrics
| they see this feature is seldomly used and continue to
| deprioritize improving it.
|
| Self-fulfilling prophecy.
| User23 wrote:
| "Made it easier for customers to migrate to our
| competitors" isn't a great look on your review.
| veleek wrote:
| "Made our customers happy by allowing them to easily
| migrate to a self-hosted redis instance in AWS so they
| were able to build their business and brought in twice as
| much traffic".
|
| Your comment echos the crux of the article. Yes, this
| probably wasn't an explicit goal for AWS, but the end
| result is that people aren't using Amazon's products
| because they're the best, they're just using them because
| it's harder to change or more expensive not to (when it
| could be cheaper if the playing field was level).
| hobs wrote:
| When you see the same case across many cloud providers, data
| easy to get in and hard to get out, you start to get the
| point.
| jzb wrote:
| It's "data gravity," as Dave McCrory put it a long time
| ago. Make it easy to put your data and workloads on a
| cloud, the "gravity" makes it hard to escape. The more you
| have the harder (more expensive) it is to break the pull.
| dilyevsky wrote:
| See also: egress fees
| nova22033 wrote:
| You have the choice of running redis on an EC2 instance.
| daneel_w wrote:
| Yes, which we're doing these days. It's how we ran into this
| "enterprise feature".
| brycelarkin wrote:
| Some other things:
|
| 1. Depreciation of NAT instance ami in favor of managed NAT
|
| 2. No EKS free tier
| roncesvalles wrote:
| How are these anti-competitive?
| Uvix wrote:
| Both AWS and Azure's managed SQL Server database solutions are
| hobbled like that. They can be replication _targets_ but not
| _sources_.
|
| At least RDS for SQL Server lets you do native backup/restore,
| so while it's slow there's still a good way to get your data
| out. Azure SQL, you're stuck with something like the
| Elasticache solution. (Or theoretically BACPACs, but they
| aren't transactionally consistent and don't work for large
| databases.)
| durkie wrote:
| speaking of Elasticache -- I noticed that the "append-only
| file/AOF" feature for recovering from crashes/reboots is only
| available on AWS redis up to version 2.8.22, and we're now at
| like redis version 7 in the rest of the world..
| daneel_w wrote:
| I'm convinced that, too, is disabled deliberately, in order
| to coerce you into buying one more overpriced Elasticache
| instance to use as fail-over. This type of "funneling" design
| pattern is recurring across their managed products.
| lopatin wrote:
| What kinds of kludges are you referring to about reading Aurora
| binlog? I've been using Debezium to read the binlog to
| transition off of aurora and it works as expected.
| SomeCallMeTim wrote:
| Ummm...
|
| Quick back of the envelope [1] shows that the EC2 pricing is
| still only about 60% of the Aurora price, and something less than
| half of the RDS/PostgreSQL price, even counting the intra-region
| transfer.
|
| There may be some transfer patterns and database sizes that cause
| the Aurora implementation to end up less expensive, but I think
| under most use cases Aurora is _more_ expensive, and RDS _much
| more_ expensive.
|
| Just because the intra-region transfer isn't itemized doesn't
| mean that you aren't paying for it. Heck, the fact that the mark-
| up is so _low_ is pretty impressive, to be honest.
|
| [1] Assumptions: [db.]r6g.large, x3 for ec2 instances, 1 year
| reserved capacity with monthly payments, 100GB storage, 1TB of
| intra-region transfer/month.
| ericbarrett wrote:
| At a former gig, the Prometheus server cost 10% of the total AWS
| bill in cross-AZ bandwidth charges alone. We were in a single
| region.
|
| I have long thought it would be interesting to build a highly
| economical workload that is cross-region, but which only uses a
| single AZ in each. Inter-region bandwidth costs a little more,
| but if all your heavy traffic (monitoring etc.) is local you will
| save a ton. And since your only failover is cross-region, it
| should be easier to maintain the ability to do so as an
| organization. Also no extra exposure to whole-region failures :)
| saurik wrote:
| This is why their new load balancer variants are insidious, as
| they _require_ you to have instances in multiple availability
| zones : /.
| EamonnMR wrote:
| They did this with managed Kafka too.
| playingalong wrote:
| But you don't need to enable cross-AZ traffic. Or to be
| precise you can disable it (if you give up on some features
| like stickiness).
| dilyevsky wrote:
| Only helps if your instances don't need to talk to each
| other
| rescbr wrote:
| Instances can still do cross-AZ traffic, this just
| prevents the incoming load balanced traffic from crossing
| AZs.
| tyingq wrote:
| It's fairly easy for them to defend though. They can offer "free"
| data transfer on products they control for good reason. Meaning
| they can tweak how efficient the synchronization is, what network
| paths it takes, predict when they need to scale it, etc.
|
| Offering the same cost for customer managed tech would mean they
| take on risk where they have fewer controls and less visibility
| to manage and mitigate it.
| [deleted]
| prepend wrote:
| You're still paying for transfer, it's just not itemized like
| hand rolled solutions.
|
| The article should cover this, so maybe the author just isn't
| knowledgeable enough to realize.
|
| It's like complaining that a buffet doesn't charge for dish
| washing fees.
| redeux wrote:
| The author in this case is an expert in AWS billing and runs
| one of the most well known and respected AWS finops consulting
| firms in the world.
| prepend wrote:
| I was assuming best intent, so maybe the author knows and is
| purposely not mentioning it to mislead readers into agreeing
| with their point.
| api wrote:
| The actual cost of transfer is a minuscule fraction of what
| they charge, especially inside the region where it's very near
| free. Cloud bandwidth markup is absolutely massive and is
| definitely strategically applied, such as the classic free
| ingress and expensive egress.
|
| It's all designed to get you in and then herd you into lock in.
| Why would they build it differently?
| ikiris wrote:
| If you've seen the graphs, you'd understand why in is free
| and out costs money. Because it's almost all out already.
| It's also not nearly as free as you think to run massive
| clouds.
| thinkingkong wrote:
| As far as a list of moves by AWS that seem fishy, this one really
| isnt. This to me is closer to artificial scarcity pricing that
| matches a customers need and willingness to pay. Its no different
| than putting SAML in the "enterprise" column of SaaS pricing.
|
| AWS had way more advantages and while this price is much higher
| than what the costs are, it's sort of run of the mill business.
| ginger-hot-tea wrote:
| Agreed, the article a stupid take. AWS must be able to
| differentiate their services, otherwise, what reason would one
| have to buy vs. build yourself?
| saurik wrote:
| I mean, if you are building it yourself but on top of their
| cloud, why does it matter to them? And, if you are building
| it yourself and you _aren 't_ using their cloud, then you are
| already being charged egress bandwidth fees as your awkward
| differentiator (which is an entirely different issue).
|
| Like, the premise of these offerings has absolutely no need
| to try to compete with stuff running _on_ AWS as they are
| clearly barely taking any excess margin over running it
| yourself. I would always have said the goal of these
| offerings was to make it easier to use AWS so you didn 't
| have to build it yourself (and some of this stuff is complex
| to get right).
| Uvix wrote:
| Maintenance overhead. If I buy, they manage configuration,
| updates, backups, etc.
| eropple wrote:
| _> what reason would one have to buy vs. build yourself_
|
| I dunno--AWS's could be _better_ without spending effort on
| it? The same way every other cloud provider incentivizes
| using their managed services?
|
| Don't get me wrong--a number of managed AWS services are very
| good. RDS is, even, for a lot of use cases. But AWS forces
| you to consider cost versus _quality_ when you fall in the
| RDS gaps, and that 's a shitty way to do business. AWS relies
| on being _the only network transit provider in town_ to
| incentivize continued use of horizontally related offerings.
|
| This is _literal_ anti-competitive behavior, just as browser
| bundling was for Microsoft. Like that 's the definition of
| it.
| temptemptemp111 wrote:
| [dead]
| [deleted]
| JackSlateur wrote:
| This is not an "anti-competitive mode"
|
| This is called a bundle
|
| On the third-party side, we have: Compute + aws compute margin +
| network + aws network margin + storage + aws storage margin +
| software management + third-party margin
|
| AWS is able to lower each margin parts, because they know you
| take a bundle
|
| Why would you even think doing a cheaper but overall equivalent
| service in someone else's infrastructure .. THAT does not make
| any sense.
| sitkack wrote:
| They lower the price because they own the whole pie? Sounds
| anti competitive to me.
|
| https://www.ftc.gov/advice-guidance/competition-guidance/gui...
| scarface74 wrote:
| You did see the part about it only being relevant if the
| company is a "monopolist"?
|
| There are 5 cloud providers in the US and according to Jassy
| (my skip * 7 manager) in public statements, less than 5% of
| all IT spin is on any cloud provider.
|
| Did you even read your own citation?
| sitkack wrote:
| > Did you even read your own citation?
|
| -1, violates hn discussion guidelines.
|
| I did. AWS is being anti-competitive, this isn't a board
| game with narrow definitions.
|
| EU Monopolist or Chicago School Monopolist?
|
| I won't respond.
| stale2002 wrote:
| The point being that you have misunderstood what a
| monopolist is, even according to your own source.
|
| No, it is not a singular company, but yes it does require
| significant market power.
|
| If there are 5 major cloud providers then this is pretty
| strong evidence against having significant market power,
| and yes the FTC definition and US court systems agrees
| with this definition, and disagrees with you.
| scarface74 wrote:
| It violates the HN guidelines to ask did you read the
| _submitted_ article. You posted your own citation they
| didn't say what you seem to think it says.
|
| "Words mean Things". A "monopoly" isn't something that
| have 4 major competitors and when another alternative
| that 95% of all IT spend is not on any major cloud
| provider.
|
| And just because you don't like the legal definition
| doesn't mean it isn't the real definition.
|
| And since the citation is from the American Federal Trade
| Commission. The EU definition is meaningless.
___________________________________________________________________
(page generated 2023-03-18 23:01 UTC)