Amazon stopt met EC2-Classic-omgevingen in AWS

Amazon stopt met EC2-Classic in AWS. Het netwerk was onderliggend aan Elastic Compute Cloud, maar Amazon wil gebruikers overzetten naar modernere alternatieven zoals Virtual Private Cloud. Uiterlijk in augustus 2022 moet EC2-Classic helemaal verdwenen zijn.

Amazon schrijft in een blogpost dat gebruikers van EC2-Classic moeten migreren naar een alternatief. Vanaf 30 oktober van dit jaar worden alle inactieve EC2-Classic-omgevingen uitgeschakeld. Amazon stopt vanaf dat moment ook met het verkopen van nieuwe Reserved Instances. Op 15 augustus 2022 wordt EC2-Classic overal verwijderd uit ieder AWS-account.

Er is een migratiegids geschreven voor klanten die hun diensten willen overzetten naar een Virtual Private Cloud. Daarvoor moeten ze eerst een nieuwe VPC maken en bestaande EC2-Classic-omgevingen opsporen. Amazon heeft ook een migratiedienst opgezet, en een gids gemaakt voor het overzetten van bepaalde instance types die niet in VPC beschikbaar zijn. Met het migreren gaat 'minimale downtime' gepaard, zegt Amazon.

Amazon zegt niet waarom het van EC2-Classic af wil, maar vermoedelijk is dat omdat het nog maar weinig werd gebruikt. EC2-Classic was de derde dienst die in Amazon Web Services werd geïntroduceerd in 2006, naast Simple Storage Services en Simple Queue Service. Inmiddels zijn er modernere alternatieven zoals Virtual Private Clouds, die later de standaard werden voor alle gebruikers. EC2-Classic werd dan ook nog maar weinig gebruikt. Sinds december 2013 werden alle nieuwe AWS-accounts standaard VPC's, al was het mogelijk om specifiek een EC2-Classic-omgeving aan te vragen.

Reacties (27)

[djiwie]

Op zich wel logisch als de opvolger al 8 jaar beschikbaar is en deze instances nog maar weinig gebruikt worden.

[djwice]

Bij AWS is dat niet zo logisch. Runtimes met nieuwe versies uitfaseren: ja. Maar diensten of functies verdwijnen eigenlijk bijna nooit.

Amazon Web Services heeft een heel divers klant portfolio, hun services zijn vaak bouwblokken / fundament van een infrastructuur / applicatie.
Zie het als api's:: typisch blijven oude versies naast de nieuwe bestaan.

Normaal gesproken vervangt AWS simpelweg de onderliggende infrastructuur en vaak ook architectuur zonder dat functies uit de service zelf uitgefaseerd hoeven te worden.

Dat is in dit geval anders, dat is zeer zeldzaam. Een indicatie dat er niet een triviale migratie naar de moderne onderliggende architectuur bestaat.

Dat betekent voor bestaande gebruikers is migratie naar de 'opvolger' ook niet triviaal.
Als je 8 jaar geleden of langer als ondernemer iets hebt laten bouwen door een IT-er en het werkt nog prima, is er niet direct een aanleiding om opnieuw budget vrij te maken om opnieuw een (paar) IT-er(s) in te huren om systeem te veranderen. Zeker als je daarna verder geen 'extra' of 'betere' business value er voor terug krijgt.

[Reactie gewijzigd door djwice op 22 juli 2024 21:51]

[stoorzender292]

Wij gebruiken er nogal wat... word een leuk project

[Reactie gewijzigd door stoorzender292 op 22 juli 2024 21:51]

[djwice]

Wat is het voordeel voor jullie? Het fixed public IP-address dat je at launch time krijgt?

[Djerro123]

Dat kan je toch ook gewoon met een ELastic IP doen? (Mijn aws kennis is wat verstoft, maar die kan je toch koppelen aan een EC2 instantie?

[djwice]

Klopt en je hebt wat soft limits "There is a default limit of 5 Elastic IP addresses per Region per AWS account.", maar via een standaard formuliertje krijg je er binnen 15 minuten meer, indien nodig.

[Maxx007]

Was er een specifieke reden om de voorkeur te geven aan EC2? Of hebben jullie die al zo lang in gebruik?

[MMaI]

als je nogal wat EC2 Classic gebruikt loop je sws al wat jaren achter, misschien dit niet als project bekijken maar migratie naar nieuwste generatie / onderhoud structureel inplannen

[DennusB]

Je weet zeker dat je echt EC2-Classic gebruikt? Je hebt ze niet binnen een VPC draaien?

[klakkie.57th]

Dit is toch het grootste nadeel aan cloud voor mij .. “zij” bepalen wanneer iets niet meer voldoet en kunnen zomaar stoppen waardoor jij als klant weer moet investeren.

[Jeoh]

Volgens mij de eerste dienst die AWS echt stopzet. Veel (bijvoorbeeld SimpleDB) is alleen verstopt, maar is nog wel bruikbaar.

[bvdli]

Ze stoppen niet zozeer met een dienst, alleen met deze generatie van networking voor EC2 uit 2006.
Alle accounts sinds 2013 hebben niet eens de optie gehad om EC2 classic, dus het is al heel lang duidelijk dat dit wordt uitgefaseerd en dat VPC networking "the way to go" is.

[koen_92]

AWS stopt inderdaad echt zelden met een dienst, zelfs als er al een 'opvolger' is die net iets anders werkt.

In dit geval maken ze een uitzondering en faseren ze EC2 classic echt uit. Dit vereist acties/migraties van hun gebruikers naar EC2 VPC, dus lijkt mij wel echt dat ze stoppen met een dienst.

Aan de andere kant zullen er niet heel veel gebruikers meer zijn al deze dienst sinds 2013 al niet meer af te nemen is voor nieuwe gebruikers. Wel netjes dat ze het nog zo lang in de lucht hebben gehouden, kunnen andere partijen van leren!

[Frame164]

Je kunt je dan ook afvragen hoe groot de impact is. Eigenlijk gaat het alleen om gebruikers die voor 2013 al AWS gebruikte EN nog niet gemigreerd zijn. Aangezien AWS pas de laatste jaren flink is gegroeid zal de uiteindelijke impact wel meevallen. Een beetje vergelijkbaar voor softwaremakers die hun applicatie alleen maar voor Windows XP hebben gemaakt en getest en nu opeens naar een nieuwer OS moeten.

[well0549]

Lekker dit, is wel iets wat je mag mee nemen in je hele cloud migratie....

Maar wat nou als de cloud provider service xyz stop zet...

Waar gaat dat dan kosten.....

Leuk dat je 8 jaar na dato nog even geld mag gaan ophalen voor een migratie trajectje....

[SSH]

Normaal moet je je omgeving elke 4-5 jaar naar iets nieuws migreren. Dus als je daar al 8 jaar geen geld aan besteed hebt, heb je hopelijk een hoop reserves voor dit soort projecten.

[Frame164]

Om je hiervoor in te dekken moet je eigenlijk vanaf het begin zo min mogelijk services gebruiken die een hyperscaler aanbiedt. Betekent wel dat je zelf veel meer software moet bouwen. En dat de cloudkosten wellicht hoger zijn dan als je standaard services gebruikt. Maar je bent wel flexibeler als er een migratie nodig is, en je kunt ook makkelijker overstappen naar een andere provider.

[Mellow Jack]

Er is daarom veelal een onderscheid tussen Compute, Netwerk en Opslag.

Je netwerk moet (en is) flexibel zijn. Daardoor is plek van hosten (IaaS, SaaS en PaaS) niet heel relevant. Kan via het publieke internet is private routes.

Je opslag is vaak wel een dingetje (files en of databases). Hier zitten vaak migratie trajecten aan vast. Dit moet je gewoon oefenen en eens in de zoveel tijd doen.

Je compute zou niet relevant moeten zijn. Een applicatie server deployen op plek a of b is geen migratie maar opnieuw deployen. Dit zou allemaal gescript moeten gaan.

[Verwijderd]

Het is juist goed dat mensen iets leren over life-cycle management. De cloud forceert mensen om na te denken over het gehele traject (in en uit) in plaats van het maar te laten draaien, uit support te laten gaan en een ellendig legacy probleem te worden.

[CoreData]

Lifecycle management costs voorzien in het budgetplan? Welk serieus bedrijf houdt zich daar mee bezig.

[Snake]

Heeft dit impact op de classic ELBs?

[pe0mot]

Blij dat we eind vorige jaar al besloten hadden om AWS bij het grofvuil te zetten.
2 accounts, 6 locaties en heel veel EC2's en nog veel meer, dat was lachen toen we alle instances probeerden te vinden. Er is geen menu keuze om te zoeken over alle locaties. Wel een gepeperde rekening elke maand zonder heldere specificatie.
Ik zie dat er in dit artikel verwezen wordt naar Github voor code waarmee je ec2 kan opsporen, lachen dus.
Oftewel, alle software vanaf dit jaar netjes bij een klantvriendelijke providers geparkeerd. Iedereen hier weer gelukkig.
Vandaag dus ook maar de accounts opgeheven. Bye.

[mastair]

Welke cloud provider hebben jullie gekozen?

[pe0mot]

Onze klant vroeg KPN en wijzelf Digital Ocean.
Het eerste is inderdaad prima voor klanten, het tweede perfect voor een bedrijf wat software maakt.

[jkommeren]

Hebben ze de vindbaarheid van resources over verschillende locaties nog steeds niet gefixt?.. daar stond ik 5 jaar geleden ook al van te kijken, maar nog steeds? Oo

Ik herinner me nog dat we een AWS acc kregen waar de resources al "klaar stonden" en ik toen locatie voor locatie moest kijken of er wat onder hing

Wij gebruiken Azure, daar is dat goed geregeld

[Reactie gewijzigd door jkommeren op 22 juli 2024 21:51]

[well0549]

Maar wel weer lekker prijzig....

[SuperDre]

Je doet nu net alsof dit niet ook bij je nieuwe provider kan gebeuren.