Live data from Hacker News

Amazon EC2-Classic Is Retiring

aws.amazon.com

81–90 of 155 posts

Re: Amazon EC2-Classic Is Retiring

#81
post #37

Earlier quoted context omitted.

But would such a VPC be able to make outgoing connections to IPv4-only servers?

You could use a NAT64 gateway to do that. At that point you're trading one form of NAT for another so there's less value in going IPv6-only.

Well not having to dualstack is still just nice. No more DHCP4, and so on – e.g. you can have SLAAC as the one and only very simple way of auto-assigning addresses (in a client setting, obviously not what you'll use with servers that have their addresses listed in DNS :D)

Re: Amazon EC2-Classic Is Retiring

#82
A decade without interruption is better than most enterprise IT departments manage despite considerably higher costs. I still have a couple of instance which have been upgraded a number of times over the year but aren’t quite ready to turn off yet.

Re: Amazon EC2-Classic Is Retiring

#83

Earlier quoted context omitted.

Creating completely private networks in a public cloud, and also being able to link these networks across the WAN to other private networks in different regions seems the opposite of nothing to offer IMO.

This is a common error of conflating the name of something with a property that that name typically has. 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 hav…

The default VPC setup in each region just has a two public subnet configuration by default. You boot up an EC2 instance and it has a public IP address reachable from the internet (if you open up the security group) and a private IP address.

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.

Re: Amazon EC2-Classic Is Retiring

#84

> In order to fully migrate from EC2-Classic to VPC... 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…

[deleted]

Re: Amazon EC2-Classic Is Retiring

#85
post #14

Hijaking this to say I hate VPC. I hate VPC. 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.

Except with IPv4... it hasn't been solved because there just isn't enough addresses. And most organisations I have worked with on AWS is still predominately IPv4.

most organisations I have worked with on AWS is still predominately IPv4.

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.

Re: Amazon EC2-Classic Is Retiring

#86
post #74
post #24

Earlier quoted context omitted.

FYI, "depreciate" != "deprecate" — I also used to think it was the former once upon a time :)

My favorite similar mixup is ordinance vs ordnance. Though I suppose they're not mutually exclusive. I'm sure that printed copies of some bylaws are hefty enough to cause serious damage if you lob them at the enemy.

This was hilarious when I saw local businesses put up signs requiring masks due to local "ordnance". I had to wonder what kind of masks they expected us to have

Re: Amazon EC2-Classic Is Retiring

#87

As someone who first used AWS in mid-2009 (just a few weeks before VPCs were announced!), but hasn't used an EC2 Classic enabled AWS account now since around 2012, it's hard to remember just how far the service has come. 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 horri…

> This is pretty much the first time I've heard of AWS really deprecating something 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 that metric, then, EC2-Classic has been for nearly 8 years. Accounts created after 2013 couldn't create classic instances.

Re: Amazon EC2-Classic Is Retiring

#88

I'm glad to see this. 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.

Toward that end, I wonder if this announcement and the new VPC IP prefix list announcement are related: https://aws.amazon.com/about-aws/whats-new/2021/07/amazon-vi...

Re: Amazon EC2-Classic Is Retiring

#90

Earlier quoted context omitted.

> is this one of the first actual depreciation and get off service things AWS has done? 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.

EB is kinda a mixed bag. Is there much production on EB? It’s great for q&d stuff you don’t want to get into specifics but I couldn’t imagine explaining my architecture with a big “EB does what EB wants to do here” bubble

Notion (my employer) was 100% Elastic Beanstalk until about a month ago, now we’re 100% ECS. We migrated once our 1200 box cluster started stalling deploys randomly while saying everything was healthy in the API. At that many instances, the some pages in the dashboard would hang the browser.

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.

Post reply on HN