There were only a few instance types, and they were all slow and small (by todays standards). Everyone's EC2 instances were mostly publicly pingable/ssh-able from the internet. EBS was horribly horribly slow (our DBAs set up a super convoluted RAID 0+1 configuration for our MySQL databases and even then we needed massive sharding to keep up with growth). EC2 instances were, in general, very unreliable (I recall something like 1 in 500 instances failing _per week_), and especially so in the leadup to Christmas (where the rumor was AWS kept the best instances for themselves).

This is pretty much the first time I've heard of AWS really deprecating something, so I have a feeling it will _hugely_ simplify things on their end. From reading the post I also get the idea that it won't be _that_ hard of an operation from their side. I bet few people (by AWS standards) are still using EC2 classic heavily.

https://www.youtube.com/watch?v=AyOAjFNPAbA

It'll tell you lots about how AWS is built

I know Amazon went the route of building their own smart NICs with both network and IO capabilities early (The same thing Nvidia is doing and calling revolutionary since last year)

They rack more servers per day than I could afford in a lifetime.

Full exact technical details aren't shared, but there are some videos on Youtube which touch on it their customized x86 and ARM server racks:

https://www.youtube.com/watch?v=q6WlzHLxNKI

https://www.youtube.com/watch?v=ukWig2QLCWM

Amazon has deprecated several things, they tend not to actually retire them (just reduce thei public profile so people aren't tempted to build new instances, while supporting the existing users indefinitely.)

By default. You could still request it to be enabled on your account by contacting support.

I think the only other service that was ever deprecated was SimpleDB, which was replaced with DynamoDB.

So yeah, you're right, it's still there.

Amazon has deprecated and then put to the grave multiple payment services. Torrent support in S3 is being killed off with little notice.

Did anyone ever seriously use it? It never made much sense to me -- if you're trying to optimize for performance, S3 is already pretty good and a CDN can make that even better; if you're trying to optimize for cost, you wouldn't be using S3 in the first place.

1) Universal torrent support is prerequisite to broad adoption. Having S3 be part of that network is nice.

2) It gives a fallback to exploding costs if something I do goes viral. I have the option of a weekend hackathon.

... and so on.

It's one of those features I like even if I don't use.

(And no, that's not actually common of features -- most of AWS, I wouldn't mind if it was not there)

Kind of crazy honestly? They were kind of famous for NOT doing this sort of thing - at all.

GCP just announced enterprise API's I see with some (pretty vague) promises about longevity.

> All AWS accounts created after December 4, 2013 are already VPC-only, unless EC2-Classic was enabled as a result of a support request.

There were announcements made at the time, but I don't remember if they explicitly called it a deprecated product at the time (hence why I hedged my wording in GP comment).

Amazon/AWS has deprecated and then put to the grave multiple payment services. I made that same comment when SimpleDB was deprecated and someone said the same thing. More recently, torrent support in S3 is being killed off with little notice.

"Amazon SimpleDB (N. Virginia) Service is operating normally" is their current status page, but their marketing materials doesn't show any SDB stuff. So if you had some old workload ticking over - you could just leave it usually.

I actually used SimpleDB in a light use case wildly past the point at which it disappeared from all marketing. I kept on expecting an email like the EC2-classic one, but it never came even though simpleDB didn't show up anywhere really

just one of those fun things that gets thrown in to make sure nobody ever fully understands the english language.

Ordnance and ordinance I don't even know the difference between though.

Were you storing PANs then?

Thats part of what people love about AWS compared to Google Cloud. Google is quick to kill off services it finds no longer convenient for it to run. AWS has historically gone out of its way to keep old services running even as it releases new, better alternatives.

Update: it looks like we're executing a migration plan this year by building seemingly-full parity between Mobile Hub and Amplify (https://docs.aws.amazon.com/aws-mobile/latest/developerguide...) such that "if you don't migrate your project to Amplify, your app will continue to function, and all your related cloud resources will continue to be available". This seems like a great solution for existing Mobile Hub customers.

Google has been doing it's best to make my life miserable. It recently killed Google Voice in the free edition, so my younger child can no longer get a phone number. With zero warning.

I've been through this each time I've (tried) to use Google for anything critical, so I've stopped.

I mentioned a family example since B2B would be confidential. But I can count at least a half-dozen instances of Google discontinuing something an employer has relied on, leading to a world of pain.

My general cloud policy is AWS, Azure, or anything-but-Google. I have a similar anti-Oracle policy too. Once you're burned a few times, you find that some companies are too expensive to do business with.

https://cloud.google.com/products/ https://cloud.google.com/blog/products/workspace

But it's a moot point in either case, if you want long-term support.

* Internal corporate lines shift with re-orgs

* Culture is shared and common

* I've had issues across Google. I listed the ones I can talk about.

My lesson, each time, has been:

Never Use Google For Business.

Ever.

The transition from Amazon Linux to Amazon Linux 2 on Elastic Beanstalk was pretty rough. The migration took a full week, and there was really only a six month window where it could be done.

One bad day, it took like 18 hours from deploy attempt started to AWS resolving the situation by fiddling knobs on their side.

Our deploys on ECS take like 15 minutes.

Would you recommend to invest time learning how ECS works or had your company hires that managed that?

My one compliant is around having fallback to on-remise providers / capacity provider etc support - doesn't seem fully fleshed out across ECS/Fargate/ECS anywhere but I may not have read docs properly yet.

Unlike Google.

From what I hear MMS stopped working a few months ago for iPhones on Google Fi.

I've been on Fi for years and its great.

Whenever I read anything about networking on AWS, I feel glad by having switched to GCP. On Google Cloud, you can put a project into production without having to fumble with networking at all (off course, the options are there if you need it).

I feel more productive by only having to split my cloud resources by projects - which is a high-level concept, and a good abstraction - instead of security groups - which is a low-level implementation detail.

At this point AWS desperately needs higher level abstractions with sane/safe defaults. They seem to be heading in that direction, example Amplify, but they still have a long way to go.

I suspect AWS has now gotten so huge that there is no one PM to take a holistic look and build something to ease the pain of developers. I think a few startups are trying to fill this void.

The accounts and Organization model is a slightly clunkier abstraction than projects, but on the other hand the security boundaries between accounts are harder than those between projects, which has its benefits.

<LIST OF AWS BILLIABLE RESOURCES>

I'm not sure if this was unintentional or done as a tongue-in-check joke, but "you yourself must FIND what you're using in our services" indicates to me that they're fully aware of how hard it is to easily see what exactly you're paying for when using AWS.

Whenever I see this kind of deprecation at a company not normally known for deprecating things, I'd tend to guess it's being removed to make way for something else. I look forward to new network functionality being unlocked or optimized or simplified by not having to worry about how it interacts with non-VPCs.

> Option 4: Migrate manually to a Classic Load Balancer in a VPC

> The following information provides general instructions for manually creating a new Classic Load Balancer in a VPC based on a Classic Load Balancer in EC2-Classic. You can migrate using the AWS Management Console, the AWS CLI, or an AWS SDK. For more information, see Tutorial: Create a Classic Load Balancer in the User Guide for Classic Load Balancers.

> I miss EC2 Classic :/. It always feels like the entire world of VPCs must have come from the armies of network engineers who felt like if the world didn't support all of the complexity they had designed to fix a problem EC2 no longer had--the tyranny of cables and hubs and devices acting as routers--that maybe they would be out of a job or something, and so rather than design hierarchical security groups Amazon just brought back in every feature of network administration I had been happily prepared to never have to think about ever[] again :(.

There were some responses:

https://news.ycombinator.com/item?id=25988915

Honestly and likely overly-frankly, I have absolutely nothing positive to say about VPC or any of the engineers who worked on or with it: it seems like it is uninspired and creates complexity out of whole cloth with absolutely no benefits I have ever heard of to redeem its existence. For a long time, instances could not have multiple security groups, which limited the mechanism... but that was fixed long ago; security groups should simply have been made hierarchical instead of forcing everyone to think about network layout and address space limitations as part of manually laid-out networking in what should be a purely cloud resource capable of infinite extension... all of that networking equipment and subnet numbering exists in the real world to solve problems virtual hardware does not and should not have. EC2 Classic was "fun" to work with and yet had no limits... VPC is "work" and offers nothing in return.

The "RFC 1918 private range" is "private".

A publicly routeable range that is firewalled off is "private".

There is no practical difference in the level of privacy. There's a difference in naming only.

And of course, there is one other difference: The RFC1918 range is worse, because it can never be routed. You have no choice in the matter, it's not an option.

So you have two kinds of "private networking":

- Private by choice.

- Private with no choice.

Which do you prefer? To have choices, or to have those choices taken away from you?

If you want a totally private subnet to put your back end app servers on so they are not routable from the world as an extra layer of safety, then you can do that too. Or, if you'd like to boot up EC2 instances with only non-routable IP addresses for security, yet be able to have the instances reach out to the world, you can create private subnets and then route the traffic out of NAT Gateways.

VPC's offer the best of both worlds, rather easily too once you wrap your head around how all of the VPC objects and software defined networking work.

Which is AWS's way of printing money. Straight up, no lie.

Instead with the advent of IPv6 and everything getting a publicly routable IP address anyway, you no longer can rely on a machine having a "private" IP address.

I recently stood up infrastructure where each machine in the VPC got a public IPv4 and IPv6, and used security groups to set up permissions for what systems can access what other systems.

This way I protect the instances, and don't pay the NAT Gateway fee because the public IP is a 1:1 NAT and doesn't cost anything.

Maybe folks are just annoyed at the complexity and want something more plug and play which is understandable. The default vpc usually is fine enough for most everyone out of the box.

In addition, that product didn't exactly make big bucks for the company so there was not much incentive to improve things.

We just launched EC2 generational upgrades on Vantage that autodetects when there are chances for you to upgrade from older generation EC2 instances to get both cheaper costs and better performance.

You essentially get a summary of all your older generation EC2 instances that are candidates for upgrades and what the associated savings will be.

Very relevant with this news :)

Applying 1990s NATting to next gen cloud service? Gotta give the greybeards something to do.

The purpose of NATting is to deal with limited IP addresses, a problem that has been solved for a long time now.

AWS makes me create a VPC, but I certainly don't set up some central-point-of-failure NAT or pay AWS to do it.

https://www.internetsociety.org/resources/deploy360/2014/cas...

https://toreanderson.github.io/2016/02/22/ipv6-only-data-cen...

There are still too many rough edges going V6 only though, like if I set my own DNS servers, will they resolve A records to NAT64 AAAA records? And how will the regular Windows sysadmin deal with registering DNS records?

DJB saw all this with crystal clarity almost twenty years ago:

http://cr.yp.to/djbdns/ipv6mess.html

Note that when he wrote this, NAT64 didn't even exist. NAT64 is basically standardization of "make IPv6 work the way DJB said it should".

It doesn't make sense to have NAT64 on every router, because NAT64 is stateful and needs to be properly engineered into a network. There are also alternatives like DS-Lite and MAP, with different design tradeoffs.

(And mandating NAT in routers would be a pretty radical departure from the current internet architecture).

When there was only IPv4 there was no reason for backwards compatibility. Caring about backwards compatability doesn't become radical simply because it becomes necessary.

Nat Gateway has been around for ~6 years now and is highly available and a managed service so you just need to click a couple of buttons. https://aws.amazon.com/about-aws/whats-new/2015/12/introduci...

AWS accounts and VPCs are free, so NAT gateways can form a significant part of the per-account/VPC base cost, which can be a significant part of your total cost for a small project/environment.

If the NAT gateway was a service, then it could be multi-AZ transparent to the VPC.

But I also work with a lot of people that don't.

But if you use IGW, then your "public" subnet is still actually a private subnet: all networking to hosts inside the VPC occurs with private IPs. The public IPs are 1:1 NATed by the IGW. Your instances never see packets with their public IP. And you can launch instances in the "public" subnet without a NAT mapping if you want. For IPv6, you can have an egress only IGW.

So you can do "traditional" NAT if you want, or you can do "modern cloud" NAT using IGW. It is really your choice. I'm not saying one is better than the other. I'm just letting OP know that there is a non-1990s option. =)

Because AWS initially had poor IPv6 support and they didn't include it as "cloud native". Customers build things the way AWS encourages them to.

You mean by nat'ing?

[0] Not that they were ever actually dead. There's mainframes around from decades ago, and HPC continued to be required for a variety of applications, specifically research. But in terms of day-to-day computation needs, things shifted from mainframes to desktops, and centralized systems tended to be servers dedicated to a specific purpose instead of general compute needs.