This is the only correct way to do it: choose infrastructure provider that can help you deliver. AWS is good, just not for everyone. It stands somewhere between services like Heroku and bare metal, abstracting a lot of maintenance, but offering some control over scaling architecture. Which means that as a cloud provider it helps to scale, not to build the cheapest and simplest setup possible. If you have VC money and pitch growth, AWS might be a safe choice - 2 years of startup credits they offer via accelerator programs help you not to bother too much about your infra budget and build first 18 months before you start optimizing spending (and then you know it, have good forecasting etc). If you are bootstrapped or indie developer, choose what you can afford and choose something simple. Hetzner, DO etc will work fine.

AWS actually has a pretty good price calculator with some decent presets (but FFS, can I have an "uncheck all" button?) but of course it's an entirely separate app. Amazon naturally wants some friction to having this pricing information handy, though I suspect the main reason has to do with Conway's Law: AWS still ships their org chart.

So this project had a three month timeline and provisioning the cloud resources maybe took an extra hour or two because of crosschecking? I actually prefer the dedicated calculator pages and product pages because it gives you more insight into how things are billed. I think this is a strange thing to get hung up on, IMHO, especially as a lead / manager of developers.

That's one of the things I like about Azure, they don't overwhelm you with listing prices beside every individual item as you're creating it, but they seem to always present a price on things that could be expensive. It's a good balance, I have yet to be surprised by a charge.

Doesn't Amazon engineering culture have a very engineer-led product culture? Meaning, devs are often responsible for the UX and flow.

I remember many years ago we hired a junior developer who just finished his internship at AWS and he showed me the dashboard he shipped all by himself in the summer with no product or designer help. It looked horrible.

Some devs have a good product/UX sense but the vast majority are horrendously bad at UX.

My point is that maybe it was intentional, but just bad UX culture.

Edit: It wasn't intentional

I agree with you at some degree, but I would like to point out that AWS pricing is much more complicated that you can calculate how much will you pay from a static number showing up on the UI.

If it bothers you that you need to open two tabs for cross-checking the costs, you may want to avoid every cloud provider, not just AWS.

Once you have NAT gateways, CloudFront, S3, auto scaling, loadbalancers, etc, calculating the cost becomes an art rather than an exact science. And if you don't use these, there is no point of using AWS, there are plenty of "cheap" VPS providers.

>> The UI to fire up a new machine did not show me the price. I had to look up the price in another table that did not have the specs.

This is false. The price shows up right away when you select a machine. I dont work for AWS...

> They were using AWS, so I logged in the account to add a few more machines. Right there, in front of my eyes, were the signs of an adversarial, abusive relationship.

> The UI to fire up a new machine did not show me the price. I had to look up the price in another table that did not have the specs.

I don’t want to be the one defending AWS, but I don’t think that this is a valid reason not to like them. I mean, pricing depends on so many factors like reserved/dedicated/spot/on-demand instances have all different prices.

I don’t even think that using the UI to spin up the machine is the right way to do that in an enterprise setting, you should always do that through Infrastructure as Code, to know exactly what you have up and running, just by looking at that as you would with any program. I’d suggest to use the UI for simple testing, for which the costs are often (but not always) negligible.

Jeff Bezos if you see this please send me some cash.

I worked for a startup company - the founders were really nice people and had put their own money in - quite a lot of money - to get the software built for the vision they had.

By the time I joined, 18 months after development had started, a giant, complex, hideously tentacled software beast had been built that used every possible AWS service that the massive offshore team of developers could find to use.

It should have been built on a single Linux box by a single senior developer with Python and Postgres or nodejs or Ruby or whatever.

They went out of business after not too long and I couldn't help wondering if things might have been different if they hadn't spent a fortune building a giant money making machine for AWS, instead of making a web application on a Linux box.

Every AWS project I have worked on has had some significant work put into programming AWS instead of writing business functionality.

Grafana (and especially Loki) is hot garbage compared to what you get out of the box in GCP. I'm in a Grafana organization today and the sheer amount of developer and devops time it wastes is mind boggling.

You moved something from a single datastore to three different database technologies? I don't know your domain, but that sure doesn't sound like a complexity reduction.

This isn’t a like for like comparison though, is it.

You removed all of their logging and all of their redundancy and reliability and replaced it with shitters that will all explode if the small providers one data centre goes down.

And if someone penetrates this mega server, they’ll be able to wipe all your logs or tamper with them, to hide the attack.

If your storage servers go down, everything they have is gone. And these providers don’t offer the finest hardware. How do you know all of those drives aren’t from the same batch? They will be, because they’re a bulk buyer with a single data centre.

Credits. It wouldn't make sense without free credits. And when you are hooked, good luck in moving out.

I get why it's like this.

Some background. I work at an Amazon sub. This is a good UI for the way we work. We don't spin up a single machine pretty much ever unless it's a cloud dev machine, at which point the price is listed at startup on a custom internal UI. They should consider putting that UI in the ec2 console.

When I spin up machines I pick an instance class by looking through specs and the price chart and set it via AI into a cdk construct. Usually pick a relatively normal machine type digging through all the ilvarious enterprise discounts (which are not reflectedin the prices in the console). Then as I roll out or when I get resource limit alarms on the fleet I adjust the instance types. Or when accounting asks me about price. In those cases I usually look if it's worth it to optimize.

The enterprise discounts are a big consideration. Every year new hires make bad decisions because they don't know about the discounts. They wildly affect total cost. Some things are more expensive (lambda first few years), and others are very cheap so we dog food. The console price in no way reflects reality.

In 15 years we've had about 1k services stood up, around 700 are active. 2000 or total counting tutorials and tests. That means out of an eng org of 500, we've made those decisions maybe 10k times total.

That's how Amazon thinks about it as well. So yeah I agree that the UI isn't meant to be like one where your spinning up a host. I haven't spun up a single host in like 5 years, but I've made many clusters.

But that doesn't mean it shouldn't be better to work for a wider audience. Customer obsession and all

AWS UX isn't bad because engineers are bad at UX. It's because inside AWS it's every man for himself, and every team for itself. They don't collaborate, they don't talk, they compete to ship everything as quickly and cheaply as possible - quality, usability, and common sense be damned.

I would argue that the intentions don't matter at all, the end result is all that matters both for the buyer and seller. In systems design, it is often said that The Purpose of a System Is What It Does. Good intentions can produce very bad systems with bad outcomes, and neutral/bad intentions can create good systems that benefit everyone.

I think that applies both to Amazon's dev system and pricing system. From what I hear about the insides, alignment is chaotic neutral inside of Amazon, but that shouldn't affect how we judge the system itself.

Judging by how much things jump around on the screen when I navigate from one view to another I agree.

>If it bothers you that you need to open two tabs for cross-checking the costs, you may want to avoid every cloud provider, not just AWS.

On Google cloud compute, the ui shows an updated 'cost' as you start building your machine.

You’re reading “cloned and monetized” as “forked.”

But in context, it means “cloned/downloaded and offered as a hosted service.”

The fork came later, after the defensive license, which was in response to the clone+monetized hosting, eg ElasticSearch.

I lost my sympathy for many of the open source projects philosophy, the first time I sent a patch to Redis, one of the committers took as its own, never replying to my messages, and patched it in its name. They deserve Valkey.

And I still remember JBoss and ahole Marc Fleury ...

I really wanted to like Cloudflare Workers and I'm sure there's good technical reasons but the way you need to use a Wrangler project to do things like enabling email felt too much like I was about to get locked into the platform.

It seemed like the bindings you needed to set to allow email can't actually be set (or even seen once Wrangler sets them) from the console at all.

> Even though they were containerized with Docker, managing them was still troublesome

Did docker make it easier?

The only issue I have with PostgreSQL is a bit of migration effort moving to new major versions.

> I needed to pass various system and environment variables between services, which was very tedious.

Was docker making this harder?

We used DynamoDB pretty much exclusively at Tinder, cause it was the founders choice early on. Horrible horrible choice and after 4 years working on it I dont see why you would.

1. you have a limited number of global supported indexes, 5 iirc, which means your queries are very limited. If your use case ever expands beyond that you're pretty screwed. 2. You will have race conditions. Strong consistency is 2x the cost, and not supported on global indexes. 3. Data is split into 10GB partitions and all the read/write quotas are split evenly by the number of partitions. 100 reads you're paying for is actually 10 reads per partition if you have 10 partition. Hot sharding becomes a real problem.

Take your document data, stick it in a JSONB and you get the same performance way cheaper + query able/indexable columns. The only time Dynamo wins I think is it scales well globally, but you probably dont need it

Dynamo, and a lot of the other services mentioned (Lambda) have very specific use cases. Do not use happy fun key value store as your database.

Here to say the same thing.

I built an app a few years ago and needed some sort of DB to store around 50 million records that had ~10k reads+writes per month with 1 index. It cost me something like $50 to load it up initially, and then something stupid like 10 cents/month to maintain.

it's only a nightmare if you had not to deal with Azure

I switched to Cloudflare and it's been a breath of fresh air - everything I need and the pricing is reasonable.

AWS is aimed at enterprise, not personal projects. Personal projects wouldn’t give them any meaningful revenue because the only thing that matters is cost.

Elasticache is definitely one of the services to consider self-hosting.

AWS doesn't add much in terms of APIs or polish. On the other hand, Redis/Valkey is one of the most simple services to self-host.

Using Azure in 2026 should be a firing offense. How many cross-tenant incidents are enough for you? In 20 years of existence of AWS ( since 2006 and S3 ) show me ONE with AWS ... and I will publicly eat my hat here...

"Azure’s Security Vulnerabilities Are Out of Control" - https://www.lastweekinaws.com/blog/azures_vulnerabilities_ar...

You’ve got to be kidding. Azure is 10x the dumpster fire that AWS is. I have used both.

> My point is that maybe it was intentional, but just bad UX culture.

This may be valid, but even if it is someone (or a group of people) at Amazon are violating one of their core leadership principles - Customer Obsession

https://www.amazon.jobs/content/en/our-workplace/leadership-...

A useful (and hopefully delightful) UX is key to showing customer obsession.

That being said, I personally feel the UX at Amazon sucks overall, not just for pricing/packaging but even getting basic shit done. So perhaps Amazon (or at least AWS) doesn't think a good UX is a key ingredient to demonstrating Customer Obsession.

Personally I think the UI flow is geared towards the idea that engineers don't really see the costs, they just build stuff and then management pays at the end of the month.

Often I see something that's supposed to be leaner - like Fargate is leaner than renting a whole server to run docker, right?

So it's cheaper as well? - Well, no.

Also if you reach any appreciable level of complexity, you should move to IaC - configuring all that stuff on the UI, and getting it right is torture.

If they can charge me for it then they can calculate it and show it to me. Anything else is obfuscation.

A lot of these projects work on a business model where they open-source their core product, and provide advanced services, installation, maintenance or fully-managed services around their product. AWS was bypassing them by providing fully-managed services. On this, I am on the side of the people behind the projects. Basically AWS was eating their lunch. They had no choice but to change the licenses.

> it's really weird to say that the forks "resulted" in the license changes when those forks where a response to the license changes

But those license changes were a response to how AWS was monetizing their work in ways unsustainable for the upstream projects.

Sometimes I wonder how much it would hurt Amazon to pay the creators and maintainers of OSS software they sell 1 cent per billing period of use(1 hr?). I also wonder how much money that would offer an oss team. To contribute risk free to improving the product

Of course AWS didn't create the forks until the projects changed their license to disallow AWS from making money from their code! That's the whole point here.

Some internal perspective - IAM has maybe thousands of options but fundamentally it is "what does this role have access to doing (action + resource)" + "who has access to this role". That is really it from a 10k foot level.

IAM is great because it applies internally just like it does externally. The internal AWS team don't get more access than you do, and if we get access to do certain thing on your account to perform specific service that's because you have a service principle in your IAM trust relationship that allowed us access, that you can see, and audit. For instance, lambdas have lambda role because you don't want lambda service just reading your S3 buckets because "we're AWS we automatically get access", you can absolutely see and control access, even if it is internal to AWS.

> fought against X adoption because it was "too complex", only to slowly reinvent X badly

This is a surprisingly common pattern in technology and software. Some things are definitively the “standard” at this point yet so many people simply refuse to spend the time to properly learn them.

Another point is that while it can be more expensive than self hosting, the savings are dwarfed by the engineering costs. A decent infrastructure engineer working for 2 man months on your “money saving” ovh setup costs you more than you can possibly save by not just using fargate or rds whatever.

Yeah Cloudflare offering has become everything I wanted from AWS. So much simpler to deploy a basic full stack app + files. AWS has become considerably more difficult than self hosting.

That's pretty much what I came into this thread to say. The thing I'd add is, DynamoDB is pretty nice if you understand how it's meant to be used - a relatively dumb key-value store with good persistence and table-size scaling to the sky. Definitely don't attempt to use it as a SQL database.

The best way I can come up with to rack up a $75 bill for some prototype code is to vibe-code a thing that attempts to treat it like a SQL database with JOINs and GROUP BYs etc. Or similarly write code against it absent-mindedly with about as much understanding as a 2-year-old free AI tool.

Where it really shines is use-cases like I need like 1 or 2 simple relatively small tables of persistent storage and don't want to deal with a full RDBMS. Or I need 1 ridiculously huge table to be queried in a relatively simple way, and don't want to deal with fitting that data into a RDBMS.

You can just spin up a raw VPS on EC2 or Lightsail, give it a public IP, and call it a day. You aren't required to implement every enterprise pattern in the book.

What amazes me is how Heroku absolutely nailed what most web apps need nearly 20 years ago.

They didn’t comment on the entirety, just the billing transparency.

Maybe their customer obsession culture did not extend to their AWS department?

AWS services names are notoriously bad at communicating what they actually do: https://expeditedsecurity.com/aws-in-plain-english/

Just saying, you can be customer obsessed and still not have a good feel for UX...

Ask me how I know

Engineers are not entirely cost-oblivious entities.

I think AWS billing is quite complicated that they probably don't even know what did you get charged specifically for this machine.

You might have leftover reserve instance that applies, which make the listed price inaccurate. That reservation might even be in a different AWS account in the same organization that you don't have access to. That reservation might not even be there between the time you quote and the time you actually launch it if someone/something did launch before you.

Your organization might also have discounts. I believe some discount may also be very confidential. For example, my reseller policy is that the customer must not be able to see AWS Billing in the organization root account as supposedly the price in that console are the price AWS charged the reseller, while we pay listed price minus any discount we negotiated ourselves.

Finally, I suppose they don't want to have prices shown in multiple places as they will need to update it when prices changes. Doesn't want to risk forgetting one place and getting sued for it. You can see that AWS documentations often do not want to mention the price at all, even if that price is currently free.

Chinese clouds kinda make this simple by making reservation part of the buying machine itself - you have to mark that particular machine as monthly/yearly committed when you start it (or convert it later). The complicated part is recycling instances - if you delete a server before its reservation ends it ends up in a recycle bin that you need to look before making new reservations.

I don't think your comment hits like you think it does. I think your intent with "cheap" implies some level of being lesser. In my experience that is not the reality. Similar to opp I migrated a startup from 5x cost in AWS to DO years ago. In fact that "cheap" competitor was able to give them better performance, more reliability and more features for a lot less.

AWS is almost never required and almost never the best option. It's the Cisco of options, it's often the default but for no good reason other than someone on the team probably knows enough about AWS to make it work.

Almost every startup I've worked at has leveraged AWS as their primary but when not they end up using AWS for something. And in every startup there's always contention with AWS spend and all of these startups invest significant time and, funny enough money (via cost savings products or consulting), to reduce their AWS bill. And yet, they never seem to try anything else. Doomed to the cyclical cost savings cycle. Amazon knows this and the UI/UX is designed to keep companies in this money burning loop.

Finally, AWS isn't a silver bullet. For anyone in us-east-1, you know [0].

[0] https://mashable.com/article/amazon-web-services-outage-may-...

Not back when i was using AWS

It should 100% be fireable offense if you have a choice

They don't know in advance how much bandwidth will you use, how much traffic will you have, what auto-scaling rule will it trigger, etc. It's not obfuscation, it's billing based on your usage. And as with everything in life, there are tradeoffs.

Not showing the price was not "my problem". It was the sign of a product packed with traps, footguns and all kind of things that would go wrong and the blame goes to the user.

No thank you

You can upload an image to imgur and show us. I don't see this.

I must disagree so heavily with you here. Prices can depend on so many factors, but.... when that particular account is choosing that particular machine, AWS knows what it will cost, and they can show it to them dynamically. It's very difficult to be convinced in this day and age that you cannot have a dynamic price chart right beside the machine sellector which is showing or calculating prices in real time for that particular product.

About using IaaC to set-up the infrastructure, sure, but sometimes you just need to browse stuff before actually writing code to get a feel.

I've been in a similar situation - a surprising amount of companies really just click to create instances. Last time I've encountered that at a customer I improved things a bit by creating templates, and scripting instance creation based on those templates - but ideally we'd have had the templates themselves as well as the network side generated by ansible.

But that's the problem: The complexity of doing that properly is pretty much the same as just doing your own hardware (which is what I'm working with most of the time - handling stuff on physical servers). And at that point the question should be why you're paying AWS so much money and pay your people to automate AWS workflows when you could just pay them to automate workflows on physical hardware, which would be way cheaper to run than the AWS instances.

> pricing depends on so many factors like reserved/dedicated/spot/on-demand instances have all different prices.

Or you can have your own negotiated private pricing which is a whole different story in itself.

> I mean, pricing depends on so many factors like reserved/dedicated/spot/on-demand instances have all different prices.

If they know how to bill you then they obviously know how to consider and calculate all of these factors, they just choose not to show you up front.

the pricing “API” is also a joke so it’s not like they have tried pushing people to apis and away from the console.

i just use vantage (https://instances.vantage.sh/) now. their api is functional and reasonable.

It is pretty much unacceptable to have a domain bouncing emails, so I’d be out of the provider before the MX TTL even expires.

For outgoing emails, reputation is a huge issue, but at the same time it’s also fairly trivial to set up a (different) 3rd-party (gmail, outlook, sendgrid, whatever) with previous reputation so you can get back communicating.

I'm not running a spam business. I've been operating my own mailservers (and related infrastructure) for more than 25 years now, without issues.

There's a multibillion dollar industry that lives only because they managed to successfully convince an entire generation of "engineers" to become helpless and not be able to serve an HTTP response using their own hardware even if their life depended on it.

Stop with this "we" cliche already, please. I never agreed to it and I'm in the profession for 24 years. You don't speak for me.

Executives will always prefer to transfer liability and responsibility to someplace else.

Who's calling the shots in an organization? Engineers or executives?

Depending on the deployment and any SLAs, I either don't worry about it (just do a late night rollout when nobody is on the system) or rely on my deployment architecture's sibling checks (I can see when a given machine is still versioning and requeue subsequent rollouts to other machines).

How is this an issue in a world where load balancers exist? I was part of a Unicorn that ran prod on 8 boxes and literally never had customer facing outages due to infrastructure updates.

I’m pretty sure for most systems that does not matter in the slightest.

I do not trust a free-tier VPS with my data.

I have also used lambda at scale in professional environments. I would not use a lambda for a webserver at scale, but having an s3 object trigger processing via a lambda function is a really nice flow.

But the price per unit of measurement goes down, so no, it's not "their entire business model".

No you could rent virtualised servers way before AWS. AWS simply had good marketing.

The virtualised server thing was not a AWS thing, the thing that was were their other services. For example instead of renting a virtual server and installing a database on it. You could rent the database; that was sort of a new thing that AWS made in to thing.

It was never cheaper what you paid for was a promise of fire and forget. You would no longer need to worry about any responsibility to update the server or the database cause the AWS crew took care of that.

> I also used dedicated servers in the late ’90s (and they still offer great value today). But before AWS, provisioning new hardware typically took days, not minutes.

VPSes and non-custom configs for dedicated servers were pretty instant as far as I know, I think the advantage of AWS was more that you could scale up and down much more easily since you weren’t locked down in a monthly contract, and that you could automate server provisioning through an API.

It's remarkably zen and effective.

> Imo AWS support is pretty decent compared to other vendors.

yep, that's the point.

it used to be stellar on its own, now it's only good when you compare it to other vendors.

Many a big company migrated because they have those very same slow procurement problems with internal data centers. I saw multiple cloud migrations because internal friction was at a level that the price didn't matter: 6 months for the smallest VM kind of thing. Very adversarial relationships, often with very poor incentives, as the service setup costs for other business units were way inflated, but then the maintenance costs didn't pay enough. Paying 3x-4x more a year for just a semblance of reliability was seen as a big plus.

It’s flexible but slow. we ran our C++ CI/CD on AWS at a previous company, and we used spot instances with volumes attached and detached dynamically. The performance was absolutely abysmal because in effect you’re running compilation across a networked file system, no matter what AWS says your throughput is.

Our 64 core spot instances on windows were taking 8-10x longer than our developer machines with the same core count, and there was a bunch of engineering went into the scaling, queue management, etc. if we’d just had a single bare metal machine from hetzner we could have saved money _and_ reduced our iteration times.

>You moved something from a single datastore to three different database technologies? I don't know your domain, but that sure doesn't sound like a complexity reduction.

what's bad about graphana? it's simply used for some alerts and monitoring, i've used it for really long time and it has never failed me not even once.

it's much simpler to query postgres or mongo compared to duplicating data dozens of times on datastore.

>You removed all of their logging and all of their redundancy and reliability and replaced it with shitters that will all explode if the small providers one data centre goes down.

they'll never need it, a misconfiguration on those service ends up costing several grands.

>If your storage servers go down, everything they have is gone

It’s just logs for an app server, not some banking critical info that will cause a panic if lost. Most of what they are using for logging is for finding some errors, not for mission-critical things which must not be lost.

> How do you know all of those drives aren’t from the same batch?

Because it's explicitly something you can request when doing your server order from your vendor. In this particular case several years ago, Nutanix did good.

I mean this article is about AWS doing the exact same thing.

Give me a slider for bandwidth used or a formula where the variables are abstracted away. If a computer can tell me how much I owe, a computer can be made to show how it came to it’s conclusion.

They absolutely could calculate and put the price in the UI if they wished to. Other cloud vendors do.

Tell me how I can easily determine the price from my IaC deployment as well.

Heck, I even have a hard time telling the price I pay on an account by account basis; because we have savings plans, those get charged against the root account and then I see $0 spent on EC2 in the individual account because it's all covered with a savings plan.

And when I'm putting together that IaC and trying to decide which new instance type to upgrade to, I have to dig through multiple confusing interfaces to figure out that what I want is to upgrade from m8a.4xlarge to c8a.8xlarge and how much that is going to cost me.

The faster people realize AWS hates the need for a UI, the better.

It should really be a read-only layer for metadata and logs.

The only way that email is down for days for a competent sysadmin is if their DNS is also with AWS, so I assumed that was the case. Assuming that is true, what is weird to me is that, after deciding he hated AWS and left it, that he still kept his business DNS (the most important service there is) with AWS.

I'm with you. Nobody serious uses the UI to make changes with AWS. At the very least, use the AWS CLI. IaaS is the norm though.

I'm tired of people acting like complex infrastructure tooling is adversarial because it's not completely intuitive. Infrastructure is hard. AWS can give you tooling and docs with patterns to follow, but they can't read your mind. Neither can the PaaS providers - they just make choices on your behalf and hope it won't matter to you.

At my current team at a “bigcorp” I have noticed a similar pattern. We use aws not because it’s efficient in any way.

We use it because we don’t want to deal with slow procurement process. It kills all the momentum.

Have seen this repeatedly also.

Watched one company end up with a $250k AWS bill when their credits expired (which they could not pay).

> hideously tentacled software beast had been built that used every possible AWS service that the massive offshore team of developers could find to use

To be fair, if they had a AWS Solution Architect involved they heavily push you down this road and if they manage to get in management's ear they'll push the idea that server-less AWS features is vastly cheaper.

If you're only responding to a handful of requests that's true, but once things ramp up you get "nickel and dimed" for everything: API Gateway requests, lambda execution time, DynamoDB read/write units, CloudWatch logs, outgoing data, step function transitions, S3 requests.

I understand all those services cost money and they shouldn't be free, but I question if paying all those micro-transactions is worse then paying for your own VMs, especially once your customers complain about the cold starts and you think you can fix it with "lambda warming"

> many startups settle in on a ops solution before hiring ops

Sounds expensive

> if you have a choice

I just read:

> If I had learned one thing from my past life was that if you see the signs of an abusive relationship, you have the option to walk out, and you don't, all that follows is your own fault.

so... :)

Sure, but providing estimated costs based on reasonable pricing buckets alongside the options to add the new machine is something that every other vendor manages to do..

Now explain why they don't have a killswitch for a user defined spending limit.

Price simulators are fine. They also know the distribution of use. They can do cost plus pricing (many cloud providers do). You're defending deliberately obfuscated pricing when it need not be obfuscated.

Everything you describe is reinforcing the point of the person you are responding to.

> Taking software others made and using your monopoly eco-system and scale to drive the original creator out of the game kills the product

They took software that others gave away for free without restriction and did what they wanted with it. It took time but the community figured out this exploit path and patched it in subsequent license versions.

It's not just Amazon, it's also smaller providers like Dreamhost, which I've been using for 20 years. I feel like people are in favor of killing the hosting ecosystem so that we can support businesses that didn't have a working plan to monetize their open source offering.

Original creator business model relies on extracting free labor from community. It backfired and they changed the license. They abuse contributors by betraying their trust and changing the license after AWS abused their business model. No good guys here.

Arguably the town is at fault for choosing to permit Walmart to open in their town in that analogy. If you want to control the negative externalities of capitalism you can't just expect to not provide regulations and hope things will work out.

Even if it weren't AWS, someone else with enough determination could use the same open source code to create a compelling alternative taking away business from the original authors. Trying to use social norms to make people not do that is not effective. You need mechanisms that can be enforced via legal procedures to be effective.

Agree, as long as existing contributors agree the license should be changed, projects should feel free to do so, no harm, no foul.

If Claude looks at the code when it does it, then you can still sue them. I don't think there's a "Claude Clean Room" product that trains on everything except the code you might be accused of copying.

I can't just translate Harry Potter to Spanish and sell it.

Same experience here, hosting some small projects on LightSail. It was pretty smooth to set up and get running, and no real complaints so far.

Render has been excellent replacement, in my experience.

In completely unrelated pages to where you setup resources, yes. Ec2 pricing is in a random doc disconnected from the AWS console.

They absolutely could to you a base price on the ec2 setup page, but they don't. And I have been absolutely surprised by pricing. Services that do almost nothing could cost more than your ec2.

That's a risk they knowingly chose to accept when they opted for FOSS licensing. It's not as if people hadn't asked "Well, what if another party tries to fork our open source code for profit?" all the way back when FOSS was starting to gain traction in the 1990s.

There's a lesson there then, isn't there? Use GPL

This feels close to "felony contempt of business model".

https://www.eff.org/deeplinks/2019/06/felony-contempt-busine...

We are supportive of 3rd party ink cartridges, and there's little concern for the business model of the printer manufacturers. We instead care about the rights of the folks using the printers.

With Postgres, no one bats an eye that there are thousands of hosting companies providing Postgres as an offering, and they give nothing back to the project. Same with Apache, Nextcloud, Linux, Nginx, Sqlite, and thousands of other pieces of open-source software. Are folks against hosting companies like https://yunohost.org/?

It's only when (1) the software is open-source, and (2) the entity behind it doesn't know how to sustain itself with open-source, that we suddenly change positions and view the project as a victim. This doesn't happen with printers, it doesn't happen with other open source software. I'm not even against a change in the license, but claiming that AWS is evil for doing this doesn't track.

Maybe it is for the consumer. When Aldi opened in my nearest town my food bill dropped by 20%.

PostgreSQL is doing fine even with AWS having a multitude of hosted offerings.

Maybe the business model / community-governance model does matter after all...

That's fair, but forking the FOSS version is also an adequate response.

I think there's plenty of room for people to object to the "had to change licenses" framing. They chose to change licenses, same as they chose the original license.

That original license probably helped them with goodwill and to gain a community; when those benefits no longer exceeded the downsides of using that license, they changed licenses to one that suited them better.

Naturally, this change costs them some amount of goodwill, a portion of the very goodwill that they harvested by choosing an open-source license in the first place.

This sentence beautifully encapsulates my point. I know that this is just ordinary jargon, but wow that's a lot all at once. And it does seem like something I need to know before I start.

Digital ocean is the answer. You give it a container and off you go.

For which services?

Let’s look at Lambda for a second. Deploying a lambda function to AWS costs literally nothing. And yet, depending on how it’s used, it can cost an infinite amount of money. Which price should it show?

There are far more sevices like Lambda than EC2.

In cost explore, on the right hand side where filters appear, click the “more” button at the bottom then the first option that appears (which is “charge type” or something like that) and select “usage”. That will give you a view of what you’re using regardless of the savings plan, etc.

At this point I’m not using the UX much if ever. Everything I’m doing is via IaC or the CLI. It’s made working with AWS really smooth.

Exactly. I want to set up elastic search - I can either have procurement go through their sales, or be up and running via the marketplace in less time than it would take me to fill in the RFQ form to send to procurement.

To be fair that’s an AWS problem not a lambda problem. If you replace lambda with EC2 the only thing you save in is lambda and step functions(and maybe api gateway but now you need to pay for a load balancer or a public IP), the rest you need to pay for anyway.

Regardless of whether the metaphor stands up, this is a horrible thing to say. Abuse victims are not responsible for the abuse they receive.

IMHO it should be illegal to force consumers to have an infinite spending limit on a post-paid service with consumption charges. If I want to cap my unpaid expenditure at any amount, I should be legally entitled to do so.

You can set up cost-based alerts (actual or forecasted) that send notifications via email or SNS. Based on this you can set up automations, such as applying an IAM policy to prevent further resource creation, shut down resources, etc.

As I read through these comments I’m thinking about the dynamic range of AWS customers: from my little hobby account to my business account to some hyper-scaler’s account.

I think about the diversity in usage patterns: from generating giant video stream broadcast somebody trying to calculate yet another digit of pi. It’s wild.

Is true, probably, that AWS doesn’t know how much anyone’s use case will cost (even when it’s yet another version of something we’ve seen before). Too many variable.

If only there were some kind of software with a text based, natural language interface that we could ask a question like “how much would it cost to do XYNZ on AWS?”

> Price simulators are fine.

Yes, as long as you do not have seasonal traffic, auto-scaling, spot instances, burstable instances, saving plans, reserved instances, floor/custom pricing, etc. These are tools to optimize your spendings and spend less if you know what you are doing.

> defending deliberately obfuscated pricing

A bit contradictory that price simulators are fine, but then the pricing is deliberately obfuscated. Then which one?

Not unrelated pages. All AWS pricing is and has been for a very long time posted on predictable pages alongside the service marketing and documentation. The console is the console. I, for one, don’t want to see pricing in the console or in cloudformation or CDK documentation — because if in one then in all, right?

OSS licensing.

Free Software was designed to avoid this, and has become stricter as the technology changed. Open Source was deliberately designed to thwart this. The entire intention of it was to allow businesses to resell work that was done for free. When you fork Free Software, your fork is also Free Software.

The GPL has no effect on this issue. For service providers like AWS, who provide the service not the software, the GPL doesn't require them to do anything differently than with more permissive licenses.

*AGPL

That's the desired outcome of competition but the effects can go all over the place and the second-order effects in fragile towns can matter more than the price drop. As an extreme example, some people may lose their jobs, local spending may fall, some small shops may close and Aldi may pull out too, so everybody loses (here's [0] as an approximate example).

Usually a community can tolerate changes only when it's not already near the bottom. When you're near the bottom, almost any destabilisation can kill your little system.

[0] https://www.fox32chicago.com/news/aldi-closes-west-pullman-c...

PostgreSQL doesn't have a pro/officially supported version though.

Fly and Render are what heroku would be if they didn’t stop innovating. And neon db for Postgres.

Why? It is still up, and working just as it used to.

If you would have read the article, you would know that the writer had DNS hosted at AWS, would have read why he made that choice and would know of his plans to migrate off.

> I'm with you. Nobody serious uses the UI to make changes with AWS.

This is still hugely prevalent at some of the largest companies in the world

If you let it go that far then you were going to blow it one way or another - it’s not an excuse to totally ignore the cloud spend but it’s a n excuse to defer it to a later date. If your successful, fix it, if your not then AWS aren’t getting paid anyway!

Not really. It's cheaper than hiring an IT admin and sysadmin for a while.

Those tend to be tricky hires on the small end since you tend to want jack-of-all-trades who either demands a premium salary or doesn't exist.

When you have 10 software engineers, having 1 dedicate 10-20% of their time is cheaper than hiring 1-2 FTEs that aren't writing code.

...and AWS does it too. I can go right into an account and see an estimated cost per hour, and even pre-pay at a fixed discount for longer terms if I want to. They tell me right there what it will cost. They do this for everything that is reasonably a "fixed cost", like CPU time.

They cannot predict what my bandwidth consumption will be, or other such variable costs. For those, they tell you rates.

How many real applications actually want this behavior? AWS is not built around hobbyist needs. It’s built around being a platform to run most shapes of production use cases.

A lot of those projects are not companies selling software. They're effectively public infrastructure projects, often governed by non-profit foundations or community institutions.

Also, many of them predate hyperscalers and developed governance/economic structures that make them harder for AWS to capture or destabilize, whereas AWS free-riding a vendor-controlled project can destroy the economic engine sustaining the project itself.

Quite ironically, the only example from your list that doesn't predate hyperscalers (Nextcloud) is fundamentally a self-hosting/federation product. It exists largely as an alternative to hyperscaler-native platforms, not as a cloud primitive AWS can easily commoditise into its own stack.

So, treating PostgreSQL, Linux, Elasticsearch and Nextcloud as interchangeable "open source projects" ignores the completely different institutional and economic realities behind the projects.

Yes. But so would financially contributing to the folks who did the work.

I don't see this as an issue with the company. They were happy to release their code as OSS, as long as that allowed them to make enough money to develop the software. It was a win/win, and them AWS came and took advantage of that.

If you leave some apples at the side of the road, with a sign "$1 per apple" or whatever, and people largely pay enough for you to continue to pick apples, that's great. If someone starts coming every day and taking the entire crate, I don't blame you for discontinuing the convenient apple sales, I blame the thief.

> And neon db for Postgres.

For 90% of the time when they're up.

I assumed he just had DNS at AWS, but after re-reading I guess he has DNS _and_ domain registrations at AWS, which would be a special kind of stupid. That's something we were advising customers against already back when cloud wasn't a thing yet to enable fast transfers when stuff goes south

(to clarify: DNS+domain at the same service can be OK, as long as you have nothing else there. As soon as you start having other stuff, keep the DNS there, but move the domain registration away. Depending on which domain make sure you have auth keys, access to the admin domain or whatever would enable moving the domain without registrar cooperation. In my hosting days I did my fair share of emergency transfers and infrastructure to help companies get their basics online again after a SNAFU - totally doable to have first mail coming in again within a working day)

Not hugely, perhaps not even prevalent, but present, yes.

I get to see how a lot of companies use AWS. The console does make its appearances, but less and less often these days.

Yeah, they had an impossible to use number of credits (YC) until they expired, so every problem became a AWS solution.

As an example, they needed a lot of proxy servers. Instead of just using a proxy service, there was a fleet of ec2 instances.

Unless we're talking actual PaaS (Heroku, Render, Railway, etc), the cloud also needs a dedicated skillset, so "cloud" doesn't remove the need from a sysadmin.

If you can get (and trust they do it right) developers to do AWS or Kubernetes, you should be able to trust them to do conventional Linux sysadmin on a bunch of dedicated boxes.

No it's pretty bad. They show you the cost after all the resources are set up. Even setting up an ec2 instance, a really basic use case that has a fixed cost based on size, you have to go Google it and find their ec2 pricing table. It would take no space to just put the price per hour in the drop-down as you're picking an instance. But no, they obscure it on purpose.

That's just for ec2. Everything is like this. Super awesome when you're being brought onto a new project and trying to estimate costs for your client. And let's not forget the little tiny things that should cost nothing. A NAT gateway with no redundancy is $30/mo. That's a fun surprise.

This has been a feature request since AWS was a thing.

>AWS is not built around hobbyist needs

Yes, as if no startup teams are tasked to remain within hard spending targets when they're trying to build a POC with technologies that they are not initially experts in.

I mean, by the number of people that end up with 100,000 charges in a few hours posting on HN, I'd say a lot more than you're giving it credit for.

Indeed! I just don't think it's on Amazon to fix those institutional and economic realities when they decide to host a project that people find useful.

That won't last. https://www.heroku.com/blog/an-update-on-heroku/

I don't think companies want their bill run up either.

If those folks wanted money for their work, they should be charging a price for it.

This analogy falls apart because there wasn’t a price for the software.

It’s like someone said “free whole apples, or $2/lb for sliced apples.”

And someone came, took all the whole apples, cut them, and sold them themselves.

In this allegory, did AWS take all the apples in the crate while paying them $1 for every apple, thus becoming the bad guy?

It's very common for companies to have a $1M/year contract that depends on $100k/year in AWS resources. (and maybe they have 3+ such contracts.) They could lose a contract if their account gets shut down for nonpayment, it's hard to say how much of an overage they would prefer to having their account suspended, but AWS is optimized for these kinds of customers where every dollar spent on hosting drives some multiple of revenue.

That’s what they eventually did, yes.

But it’s ok to be voluntarily grateful for hard work.

Sure, but presumably you can engage with the spirit of the analogy?

Let's be pedantic, and say someone gave apples away in exchange for donations, and when everyone only got a few apples and donated, things are fine, but then someone decided they can just take all the apples and sell them elsewhere.

Is it the fault of the first guy for not offering free apples any more, or is the second guy why we can't have nice things?

Uhoh. I don't know what that means, but I unfortunately detect double-speak.

No. It took the entire crate and paid nothing.

No longer developing new features or offering new contracts, but eVerYtHinG iS FiNe.

2FA has been in place for years through email but this new requirement forces a phone.

I should have been more clear 2FA has been in place for years the phone requirement is new.

I think there's a massive difference between "paying what was required by the offer" and "paying less than was required by the offer" and only one of them makes you a thief.

Good. E-mail based 2FA is bad, and they appear to support TOTP too as an option, as they should. Wish they supported U2F though.

They use TOTP for 2FA (industry standard), which doesn't require a phone.

Their help page lists a bunch of 2FA app options, all of which run on phones, so it's understandable to think a phone is required. (I'm disappointed they don't list the app I use, which is Aegis Authenticator.)

But actually you can use any TOTP app, and they don't all need a phone. For example, macOS (desktop) has built-in TOTP 2FA as part of the password manager.

I think there's a massive difference between the letter of the law and the spirit of the law, and saying "but the letter of the law didn't say I couldn't!" doesn't make you any less of a thief.