Increased Network Bandwidth for EC2 Instances
aws.amazon.com
aws.amazon.com
> Enhanced networking cannot be managed from the Amazon EC2 console. [1]
AWS (and other cloud providers) charge a huge premium compared to smaller dedicated and VPS providers and yet the customers need to suffer things like this and that too when the product has been available for around 11 years.
The complexity of AWS billings system is astounding. Setting the billing alarms is somewhat easy now (using the budgets features), but still needs some careful reading about the options available.
It seems like the ease of use is near to the bottom for AWS product managers.
[1] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced...
Other cloud providers may have a 1-click UX to deploy a load balancer, but they lack features Amazon has, like logs... once your app needs to scale you don't care about 1-click UX, you care more about how easy it is to debug & scale your platform...
Also, I think AWS can have both. Great CLI and APIs to deploy complex infrastructure, and great visual UX to operate, monitor and manage it. I think we as customers should demand it. If we won't let them know of our pain, how will they know? I hope they are listening.
Those using the APIs for repeatable infra are on the side of the angels. :-)
Compare this to GCP that shows a live price updated on the side of the page as you configure different aspects of the instance.
The price you pay for an instance not only depends on what you've already spent up to that moment in your account, and all accounts attached to the same organization, but also any reservations in those accounts which may /float/ into your account should they not be used in their home account, and crucially, _the price varies according to what you use, and every associated account uses, in the future_.
Finally at month end, your entire account receives a bulk tiering discount that cannot be calculated until your full usage is known.
If you have 1x t2.medium reservation and there is already a t2.medium machine running in the account, the price displayed would likely be the on-demand price. However, if after starting your new t2.medium you kill the old one, the price _applied_ will likely be the reserved price -- so long as both instances did not use more than 60 minutes runtime in that hour.
You can however, get a reasonable preview of your daily spend with 24 hours lag using Cost Explorer, which I think is more than resonable considering it is a meaningful, comprehensive account view, and not some tiny datum associated with a single item on your bill. For anyone spending serious money with either Amazon or Google, there should be a large upfront modelling step involved before stuff starts to get purchased, no per-item price preview can avoid that.
Meanwhile I wonder if Google's display price reflects sustained use discounts or committed use discounts. Given how underbaked most of Google Cloud is, I suspect (before ever having to look!) the answer to that is a resounding "no".
So the question becomes, would you prefer no information, or information that may be off by in excess of 70%?
Parent attributes that to Amazon's age, which I agree has merit. But if Amazon has become inflexible and impenetrable with age, then we should up and leave for better platforms.
AWS billing model is not only antiquated but hostile to their users.
- instance type - Google schedules you on whatever random CPU they have at hand unless you specify otherwise, with no ability to reserve capacity ahead of time, never mind tying it to a particular hardware architecture.
- placement - Google does not offer single tenant or dedicated placement instances
- scope - Google does not offer capacity-reserving discounts
- convertibility - Google does not offer reservation of particular hardware types, so this option makes no sense
But give it another a few more years, and let's see what their billing offering looks like then
The one thing it looks like Google really did nail here, though, is decoupling bundled licensing from their discounts. With AWS when you buy a RHEL reserved instance, it's a RHEL reserved instance.
https://cloud.google.com/compute/docs/sustained-use-discount...
https://cloud.google.com/compute/docs/instances/signing-up-c...
Meanwhile thanks for those links - I didn't realize Google, despite having such a youthful billing system already has the mess that is Instance Size Flexibility, they just call it "inferred instance sizes" instead, nor did I realize their discounting scheme is in fact _more complex_ - committed use discounts are mutually exclusive to sustained use discounts.
That's even harder to model upfront than AWS' offering!
What kind of hardware architecture do you want? You can reserve CPU type easily (https://cloud.google.com/compute/docs/cpu-platforms), including if you need it to be "Anything newer than <x>".
Also, sustained use discounts AUTOMATICALLY discount you (including binpacking a bunch of machine, so let's say you ran 4 machines for 7 days at the beginning of the month, you'd get the discount of running 1 machine for 28 days).
You're misinterpreting the documentation- as long as the AMI you are using or are basing your own images off has support for this high speed networking you will end up using it without taking any additional steps.
If you read their instructions for enabling it on ubuntu it starts off with this-
> The latest Ubuntu HVM AMIs have the module required for enhanced networking with ENA installed and have the required enaSupport attribute set. Therefore, if you launch an instance with the latest Ubuntu HVM AMI on a supported instance type, enhanced networking with ENA is already enabled for your instance.
That being said I don't disagree with your premise, as the AWS Console is not exactly known for being user friendly.
Even though they've got the validation, you only can tell once you submit and it complains.
It just isn't clear to me what the job of a user interface is to EC2 other than as a kind of fallback / emergency dashboard for when your software loses track of what you have running; it is essentially the Task Manager / Activity Monitor of AWS: a tool you only use when you screwed something up or have to fix something by hand. The kinds of workloads that you do with EC2 just don't map well to a UI without some kind of deep framework integration (such as "understand enough about my database server stack to determine that I've run out of connections in order to trigger an autoscaling event"; the way you'd normally do that is by building a custom CloudWatch metric with a daemon on your database server, at which point the software you wrote is probably handling that <- if what you are looking for is so specific, you usually want to be using a more dedicated/SaaS part of AWS or using a service like Heroku that is built on top of AWS).
I guess maybe the disconnect is that you seem to feel like "smaller dedicated and VPS providers" are a competitor to EC2, when in my mind the entire reason someone would use EC2 is because they need to do something you fundamentally could never do before using those existing services: automatically provision as many machines as you want, all of which become available within minutes, and where you can turn off machines you don't need and be build in by-the-hour increments. That was just fundamentally never possible before, which meant for the kinds of use cases for which EC2 was designed (workloads with high variance, whether temporary high-throughput batch jobs against data stored in S3 or services that have periodic or even unpredictable usage) they could be charging three or four times as much as their competition and you'd still use them, as to use their competitors you'd have to have five times as many servers constantly all doing nothing but burning cash.
I happened to be on the front row at re:Invent listening to Andy Jassy’s keynote with another AWS Customer Advisory Board member who has used EC2 since launch.
We joked it might be dangerous to drink a shot every time Jassy said “just click” or “with a click of a mouse”.
As believers in the value of repeatable declarative “infrastructure as code”, we were dismayed at the increasing tendency to prioritize “AWS Console” web UIs over APIs for a number of AWS capabilities.
AWS makes money from usage over consulting, and the stock value multiple on recurring usage revenue is many times the stock value of consulting billings.
AWS is relatively straightforward to developers who know infra or sysadmins who can code. But now AWS is rebalancing the API-first model and prioritizing GUIs because that drives sooner usage from traditional enterprises with ITIL IT guys who don’t want to code.
These are the same enterprises spending money on consultancies (mostly not on AWS consulting, even a decade after launch AWS still has a tiny fraction of the professional services that an IBM or an HP has) to decipher an API-driven infra and make it palatable to the mouse jockeys rather than replace dozens of manual admins with a developer or spend money training their admins to code. (Then the consultants leave and the company has no idea how to use infra-as-code.)
The enterprises are doing it wrong, AWS is accommodating them because otherwise enterprises will mess around for four or five years and never manage to move any significant percentage of workload and AWS won’t have usage revenues.