Minister Adriaansens: verhuizing SIDN naar Amazon 'nog geen voldongen feit'

Demissionair minister van Economische Zaken Adriaansens heeft gezegd dat de verhuizing van SIDN naar Amazon ‘nog geen voldongen feit’ is. De minister maakt zich zorgen om de beslissing en wil nagaan of er geen Nederlands of Europees alternatief is.

Uit het antwoord op een Kamerbrief blijkt dat het ministerie van Economie niet schriftelijk geïnformeerd of geraadpleegd was over de beslissing van de Stichting Internet Domeinregistratie Nederland om de infrastructuur naar Amazon Web Services te verplaatsen. Demissionair minister van Economische Zaken Adriaansens zou ondertussen wel gesprekken met de bestuurders van SIDN hebben gevoerd en daarbij haar zorgen hebben geuit. Op basis van de gesprekken stelt de minister vast dat de verhuizing 'nog geen voldongen feit' is, maar dat SIDN wel toewerkt naar een situatie waarin de verhuizing naar Amazon Web Services mogelijk zal zijn. Dat zou in 2025 zijn. SIDN heeft wel aangegeven dat het ondertussen geen onomkeerbare stappen zal nemen.

Minister Adriaansens zou SIDN ondertussen ook op enkele wetten, regels en afspraken hebben gewezen. Ze vermeldt bijvoorbeeld de Wet beveiliging netwerk- en informatiesystemen, de Algemene Verordening Gegevensbescherming en een convenant. Dat laatste is een afspraak over de borging van de continuïteit van de dienstverlening, de binding met Nederland en het belang van goede betrokkenheid van de belanghebbenden van SIDN, waaronder de Rijksoverheid.

SIDN gaat een Digital Transfer Impact Assessment uitvoeren. Deze controle moet alle risico’s en mitigerende maatregelen wat betreft privacy in kaart brengen. Een eventuele verhuizing kan pas plaatsvinden nadat de controle is gebeurd en SIDN volgens de overheid voldoet aan haar zorgplicht. De minister wil ten slotte ook een 'quick scan' laten uitvoeren en nagaan of er geen Nederlands of Europees alternatief is dat voldoet aan de eisen van SIDN.

De Stichting Internet Domeinregistratie Nederland heeft begin 2024 aangekondigd dat het zijn infrastructuur wil verplaatsen naar Amazon Web Services. Dat doet de organisatie onder andere vanwege de kosten. Onder andere de energiekosten, de kosten van nieuwe hardware en het vinden van personeel om de infrastructuur te beheren, is erg duur. Het gaat om het domeinregistratiesysteem, maar niet om de resolver.

Update: in het artikel stond aanvankelijk dat het RDI een DTIA zou uitvoeren naar aanleiding van de Wet beveiliging netwerk- en informatiesystemen. Dat is onjuist: SIDN voert die DTIA uit, een vereiste vanuit de AVG.

Door Jay Stout

Redacteur

24-03-2024 • 13:25

210 Linkedin Whatsapp

Submitter: wildhagen

Reacties (210)

210
207
71
0
0
111
Wijzig sortering
De minister maakt zich zorgen om de beslissing en wil nagaan of er geen Nederlands of Europees alternatief is.
Als er geen Europees alternatief is qua webhoster die de gewenste/vereiste functionaliteit kan bieden zou je eventueel nog kunnen overwegen om niet naar AWS te gaan, maar naar Microsoft Azure. Die hebben een datacenter in Duitsland, waarbij de data dus ook in Duitsland, en dus de EU, blijft.

Wellicht niet ideaal, maar allicht beter dan naar Amazon, waar het over de hele wereld terecht kan komen.

Nog beter zou het zijn als er een Europese concurrent komt, zoals bijvoorbeeld Gaia-X, maar daar blijft het ook al een tijdje opvallend stil, dus in hoeverre dat nog een lopende ontwikkeling is...
Azure Germany is alleen nog voor bestaande klanten daar. Als nieuwe klant kom je er niet meer op. Die hele dienst is "opgezegd".

Maar er zijn genoeg Cloud alternatieven in de EU. De vraag is alleen of het kosten bespaard daarheen te verhuizen of dat het toch niet goedkoper is om het zelf te doen.

Ook is de vraag hoeveel duurder een .nl domein zo moeten worden als er niet naar de cloud wordt gegaan. Hebben we het hier over procenten of vele malen?
Mijn indruk is dat als het gaat om het domeinregistratiesysteem kan ik me voorstellen dat als ze dit serverless maken, de kosten een stuk lager zijn op AWS dan dat ze het zelf 24/7 op hardware moet hosten.

Voor mijn websites is dat een factor 30 ongeveer.

[Reactie gewijzigd door djwice op 24 maart 2024 16:23]

Maar dit zouden ze niet bij AWS hoeven te doen. Dat kunnen andere partijen ook.
Ok, welke partijen kunnen dat op vergelijkbare manier en tegen vergelijkbare kosten?

Mijn infrastructuur draait op ARM CPU's is event driven en gebruikt CloudFront, S3 (Blob storage), Lambda (Python en NodeJS code start in enkele milliseconden met executie na binnenkomst van request, schaalt naar honderden per minuut, betaal per milliseconde dat de code draait) , Glue Data Catalog (Apache Hyve), Athena (PrestoDB), SQS (queue), API Gateway (HAproxy), Route53 (DNS), Certificate Manager, KMS (DNSSec) en CloudWatch (log buiten de servers), en CloudTrail (acceslogs buiten de servers) en stricte rechten scheiding.
Ik hoef alleen mijn python en NodeJS code te schrijven, tabel definities te geven en de HTML/CSS/JavaScript. De rest alleen configureren dat ze met elkaar spreken.

Geen OS, geen Applicatie installatie of updates, niemand die de servers kan voorzien van een virus of een hack, geen crypo lock gevaar, geen renewal nodig, etc.

En dat voor heel weinig. Bij wie in Europa kan dat nog meer?

Bij mij prive draaien er regelmatig honderden machines tegelijk. Op het werk enkele duizenden en een paar minuten later helemaal geen. Het systeem in altijd paraat.

[Reactie gewijzigd door djwice op 24 maart 2024 16:41]

Maar leg je daar dan ook niet het pijnpunt bloot, wie kan dit zo goedkoop. Moet we onze veiligheid, souvereiniteit, zekerheid ten gunste voor de laagste prijs opzij zetten? Het is toch raar dat we eigenlijk ons daardoor laten sturen. Als bedrijf of prive is dit een ander verhaal maar als overheid mag duidelijk zijn dat er meer op het spel staat.

En dan stel ik nog niet eens de vraag, of we deze kennis niet zelf paraat moeten hebben of Amazon betalen in plaats van een Nederlandse partij die misschien iets duurder is, maar dan wel keurig in NL belasting betaald en mensen aanneemt.
Het andere pijnpunt: wie kan het zo betrouwbaar. Zelfs Azure en Google (Analytics) liggen veel vaker plat.

Je kunt in AWS je infra zo ontwerpen dat je letterlijk 100% delivery guarantee van je process kunt garanderen. Dat is geen afronding van vele negens, maar werkelijk alles, altijd.

Ik heb dat onderandere gedaan voor het systeem dat nieuwe data moet classificeren en op basis van de classificatie toegang geeft tot de bevoegde groepen (niet eerder).

En dit systeem schaalt 'oneindig' paralel op en blijft dezelfde performance en kosten per file houden.

Dit werkt ook zo met de virusscanner op basis van Lambda containers. Of we nu 1 of een paar 1.000 bestanden tegelijk (concurrent, in parallel) scanner, de totale afhandeltijd en kosten per bestand blijven gelijk aan die van een individueel bestand.
Die kacht zie ik graag terug bij een Europese partij, het liefst tegen een tarief dat concurrerend is met AWS.
Het andere pijnpunt: wie kan het zo betrouwbaar. Zelfs Azure en Google (Analytics) liggen veel vaker plat.
Dit is een onhoudbare uitspraak en komt neer op FUD.

Er is niet zoiets als "liggen veel vaker plat", alle 3 de diensten betreffen gigantische wereldwijde netwerken die nooit in hun geheel plat gaan. Er kan wel eens lokaal of regionaal iets uitvliegen, maar dat is dan vaak het gevolg van externe omstandigheden: brand, bliksem, kapotte zeekabels, etc. In nagenoeg alle gevallen wordt het verkeer dan gewoon tijdelijk gereroute, al dan niet met wat vertraging.

Amazon heeft hier net zo goed last van als Azure en GCP, zoals vorig jaar toen er een grote uitval was in US-East: Amazon’s server outage broke fast food apps like McDonald’s and Taco Bell

Om voor Google ineens specifiek Analytics aan te halen is onzinnig omdat je dan één specifieke service gaat vergelijken met het volledige scala van services van de andere aanbieders.
[...]
Om voor Google ineens specifiek Analytics aan te halen is onzinnig omdat je dan één specifieke service gaat vergelijken met het volledige scala van services van de andere aanbieders.
Ik haalde een product aan, niet een specifieke service, maar dat terzijde.
Wat ik in de praktijk ervaar is dat niet alle data uiteindelijk terecht komt in GA. Dat is netjes conform de SLA, maar je mist dan wel echt een gedeelte.
Ik heb dezelfde data ook naar een door mijzelf ontworpen oplossing met CloudFront, CloudFront Functions, Lambda@Edge, S3 en Athena laten lopen en dat weer naar QuickSight.Hiermee halen we een betere delivery garantie en een snellere verwerkingstijd tegen lagere kosten.
De indruk tot nu toe is dat er geen data mist, dit meten door de page request logs van de server te vergelijken met de data delivery.

Vandaar dat ik dat relevant vond.

Voor Azure had ik specifiek ook naar bijvoorbeeld forumtopic: Bijna heel Microsoft plat? (25/1/2023) kunnen verwijzen.
In de ruim 8 jaar dat ik met AWS werk heb ik niet vergelijkbaar gehad, anders dan nieuws: Storing bij Amazon S3 zorgt voor problemen bij veel websites en diensten , dit is nu zo opgelost dat bij een vergelijkbare storing de impact veel lager zal zijn. O.a. door aanpassing van de DNS van s3 en aanpassing van hoe IAM werkt.

Dus geen FUD, gewoon puur op wat ik zelf mee maak en ervaar. Gewoon meetbaar en herleidbaar tot op de impact op onze processen, business continuity en data kwaliteit.

[Reactie gewijzigd door djwice op 26 maart 2024 14:34]

Ik kan mij niet voorstellen dat SIDN de enige is in Europa die tegen deze problemen aanloopt. Dit is toch veel beter aan te pakken dan het nu gaat.
Soms negeren we de eerste tekenen dat SIDN financieel krap zit. SIDN gaat onderhandelen met AWS. Ik wist dat wel en de minister niet (ministerie). Nu moet er binnen en over de Nederlandse grenzen worden gekeken naar alternatieven. Zoiets had al een half jaar geleden of langer opgepakt kunnen worden en kijken welke Europese SIDN's ook naar een andere server uitkijken. Daar is nu precies de EU voor.
Geen OS, geen Applicatie installatie of updates, niemand die de servers kan voorzien van een virus of een hack, geen crypo lock gevaar, geen renewal nodig, etc.
Leuk dat je die marketingfolder opdreunt, maar hopelijk begrijp je dat de basis van alle diensten die je noemt nog steeds op 'domme' computer hardware draait. Natuurlijk kunnen die servers ook gehacked worden. Mogelijk kost het wat meer moeite maar als een vijandige mogendheid een gat vindt lijkt het me niet wenselijk dat alle belangrijke ICT van het hele land bij 1 cloud partij draait.
Heb je je verdiept in de virtualisatie lagen? En de aanvals vectoren? En hoe het werkt?
Of beweer je gewoon iets omdat je denkt in traditionele machines?

Uiteraard snap ik je andere gevoel: moet SIDN wel in zee AWS.
Sorry, of ik heb een complete technologische ontwikkeling gemist, of ik snap niet wat je bedoeld.

AWS draait toch gewoon Linux? Hoe bedoel je geen OS, geen installaties?
AWS Lambda functies zijn containers waar je alleen je code in deployed. Die zijn op basis van Linux, maar je hebt geen toegang tot die laag.

Je gooit er dus Python in, je code krijgt een JSON object als invoer (de trigger) en geeft JSON als response.
De logs worden buiten de Lambda runtime in CloudWatch opgeslagen, dat is een API over een Blob storage laag buiten je account.
Hierdoor kan de runtime direct uit als de response gegeven is, en heb je altijd toegang tot je logs. De logs worden door een CPU buiten je runtime verwerkt, zodat dit geen impact heeft op je applicatie en je applicatie load geen invloed heeft op het wel of niet wegschrijven van de logs.


Glue Data Catalog is een managed Apache Hive, waarin je externe data structuren vast legt. Je hebt alleen API toegang tot die structuren.

Athena is een managed shared hosted, PrestoDB. Je query komt op een queue en wordt uitgevoerd als er capaciteit beschikbaar is. De resultaten worden geschreven naar een blob storage binnen je account. En dit kan een event afvuren, waardoor je automatisch nadat de resultaten zijn weggeschreven een Lambda kan opstarten die de query resultaten verwerkt.

Ook dat kan via een queue of een message service. Dat zijn allemaal managed services. Die JSON objecten van de een naar de andere service sturen en logs in CloudWatch schrijven.

Toegang tot instanties van services wordt buiten het account geregeld, dus kan niet van binnen het account worden gecompromitteerd. De logs daarvan komen in CloudTrail.

Dingen van buiten die een instance van de service in jou account proberen te benaderen worden dus al buiten het account tegen gehouden, en dus niet een geïnformeerd of ze wel of niet bestaan.

[Reactie gewijzigd door djwice op 24 maart 2024 19:23]

Duidelijk. Gewoon een Linux server dus die containers draait en waarbij de code event driven is.

Dit kun je echt bij alle cloudplatformen.. azure, Google, red hat.

Omdat jij containers draait betekend het niet dat je geen os hebt, geen applicaties etc.. je bent net zo kwetsbaar als ieder andere website. Mooi dat jij blij bent met deze oplossing, maar dat hele AWS is zo speciaal verhaal mocht je best weglaten.
Ik denk dat je te kort door de bocht gaat. De container heeft geen http endpoint bijvoorbeeld. En de instance is na de operatie al weer weg (stateless).
De container binary draait niet in jouw context, dus is die niet door jou of een hacker benaderbaar vanuit jou account.

En je hoeft die container dus ook niet te bouwen. Je hebt daardoor dus ook geen mogelijkheid om hem perongeluk onveilig te compileren.

Zeg maar waar in Europa ik dat ook heb.
Microsoft Azure, maar dat vind ik nog vrij amerikaans.

https://cleura.com/
https://www.transip.nl/public-cloud/
https://www.cloudsigma.com/

Wat ik bedoel te zeggen is dat alles wat je bij AWS kan, je praktisch overal kan met bijvoorbeeld openstack met Qinling. Ik zeg zeker niet dat AWS slecht is, of wat dan ook maar. Maar jij doet het met je hele betoog klinken alsof het wiel daar is uitgevonden en wat zij doen nergens anders kan. Terwijl je gewoon een website draait met Faas.
Jij (als betalende gebruiker) mag dan geen mogelijkheid hebben om iets fout te doen, dat betekent niet dat het onmogelijk is om foute zaken in je processen te bouwen/zetten/krijgen.

AWS zal vast een boel personeel in dienst hebben die daar zicht op hebben. Of huren elk kwartaal een goep personen in die hun systemen auditen. Of allebei. Wie weet. Reputatieschade mag vervelend zijn voor een bedrijf als AWS, ze komen het wel te boven. Jij als betalende klant zit echter wel met de gebakken peren, zodra er 1 f.ckup plaatsvindt. En of je het leuk vindt of niet, er werken nog altijd mensen bij AWS, dus fouten zullen worden gemaakt.

AWS is geen onneembare vesting net zoals je Azure omgeving, GWC of je on-premise omgeving dat niet zijn. Het is een risiko-afweging. Voor jou valt die blijkbaar uit in een AWS oplossing. OK. Zelf denk ik altijd dat een groot "doel" als AWS alsmaar aantrekkelijker wordt om aan te vallen, omdat er zoveel buit te halen valt.

Je onneembare vesting werd in 1 keer waardeloos, omdat luchtaanvallen in zeer korte tijd mogelijk waren. In het begin waren deze zeer kostbaar, dus alleen ingezet voor "onneembare" vestingen in de fysieke wereld. Jouw "onneembare" vesting in AWS/Azure/GWC mag "onneembaar" zijn op dit huidige moment. Maar door de enorme buit kun je er zeker van zijn dat er wordt gewerkt aan een manier om deze net zo waardeloos te maken als hun fysieke tegenhangers.

Dat is de aard van het menselijke "beestje" voor ruim 10.000 jaar. Gaat voorlopig ook niet veranderen. Niet omdat ik dat niet zou willen, begrijp me goed, maar omdat er nu altijd personen zijn die zo snel mogelijk zo veel mogelijk geld en macht te willen verzamelen zonder daar alteveel (fysieke) moeite voor te hoeven te doen.

Azure Duitsland is al een hele tijd nog maar een schim van wat het was (op legaal gebied bedoel ik). Was het niet Facebook waar de gehele globale omgeving als een kaartenhuis in elkaar stortte, omdat er 1 detacenter in de V.S. om was gevallen? Verwacht dat er net zulke koppelingen zijn in de andere cloud-omgevingen. Waarom? Winstmaximalisatie is absoluut heilig in de V.S. en dat leidt tot op papier zeer redundante systemen. Totdat er daadwerkelijk in de praktijk word getest.

Nu zal dat bij Europese bedrijven niet beter zijn. Maar wetgeving is in de EU geen papieren tijger, dus een Europese toko zal wel moeten testen en daarop aanpassingen moeten maken. Welke toko dat mag zijn, dat weet ik niet, ben geen grote fan van cloud-only oplossingen. Word wel regelmatig daaraan blootgesteld en kan niet zeggen dat ik er bijzonder van onder de indruk ben.
dus jouw argument is, omdat Amazon toevallig al iets doet, moet de hele wereld overstappen naar Amazon. het idee dat we een aantal Europese bedrijven oprichten die hetzelfde kunnen en die bijvoorbeeld worden ingericht om onze Europese kritieke systemen op een zelfde manier in te richten zodat we zelf in staat zijn te bepalen wat er mee gebeurt, waar ze worden gehost en wie er toegang toe krijgt, is compleet ondergeschikt aan de eventuele technische implementatie.

dat doet me een beetje denken aan de vader die zijn dochtertje als seksslaaf verkoopt zodat hij haar kanker behandeling kan betalen en dus haar leven kan redden.

ik weet eerlijk gezegd niet of dat nou wel zo'n verbetering is.

ik denk dat @djwice gewoon een beetje te veel fan is geworden van één specifieke technische implementatie en daarmee nu van mening is geworden dat het de cure-all op it-gebied is
AWS Lambda functies zijn containers waar je alleen je code in deployed. Die zijn op basis van Linux, maar je hebt geen toegang tot die laag.
Ja dus? ECS geeft je ook containers as a service waar je geen toegang hebt tot de onderliggende laag. Zelfde met Kubernetes, maar dan met iets meer toegang.

Onder water is het allemaal EC2 en dat is weer gebaseerd virtualisatie in de linux kernel. Onder water draaien lambdas gewoon op on demand EC2. Misschien spot instances, scheelt weer in de kosten.

Uiteindelijk hoeft er maar ergens 1 CVE te zitten die de hardware laag volledig ontsluit tot user space en dan ben je de sjaak.

Neemt niet weg dat een aantal teams aan doorgewinterde engineers er waarschijnlijk vele malen meer verstand van hebben dan jij en ik dus ik geloof wel dat zij het beter zullen/kunnen regelen dan wij dus echt bang ben ik er niet voor. Maar het kan wel degelijk.
Heb je je verdiept in de virtualisatie lagen? En de aanvals vectoren? En hoe het werkt?
Of beweer je gewoon iets omdat je denkt in traditionele machines?
ESXi breached
Docker breached
HyperV Breached
Een stapel CVEs mbt Xen (waarvan AWS een afgeleide draait)


Virtualisatie is geen security oplossing, ook nooit geweest. Sterker nog, meerdere dingen op 1 systeem draaien is inherent onveilig omdat je CPU, memory and cache deelt, en hoe goed je OS ook is, dit lekt regelmatig door, kijk bijv. naar GoFetch op Apple en recent Meltdown en Spectre.
VMs hebben over het algemeen een betere separatielaag tussen VM's als de host meerdere VMs tegelijkertijd draait. Containers zijn stukken efficienter, omdat er veel minder maatregelen te nemen zijn voor een soortgelijke separatie. En als je de container wel met dezelfde separatielagen uitrust, dan is zo'n beetje alle efficiency winst over VMs verdwenen. Als het uberhaupt al lukt.

Je hebt echter compleet gelijk, virtualisatie is geen beveiliging. Gaat dat ook nooit worden. Je doet aan zoveel mogelijk separatie om er zekerder van te zijn dat data gescheiden blijft. Dus iets minder van een aanvalsvector. Dat moet je echter nooit scharen onder 'beveiliging', maar onder 'verantwoordelijk(er) met data omgaan'.

Beschouw je het wel als beveiliging, dan krijg je een vals gevoel van beveiliging en dat is vaker wel dan niet veel gevaarlijker.
Alleen zie die jij noemt geen onderdeel van de stack én zijn de visualisatie lagen niet bereikbaar vanuit het account.

Ik heb ooit 1 aanval op de virtualisatie laag ontworpen, een afgeleide van de hammer techniek, netjes gemeld en is zonder ruchtbaarheid opgelost.
is zonder ruchtbaarheid opgelost.
ahhhh security through obscurity

lekker verzwijgen tot we een oplossing hebben

bovendien maakt het ook niet uit of de genoemde problemen in de stack zitten of een laagje dieper

virtualisatie is geen beveiliging, is dat nooit geweest en zal dat nooit worden
AWS gebruikt nauwelijks nog Xen, alleen voor oude meuk, Nitro is op basis van KVM
Ik hoor je anders niets tegenspreken van wat hij zegt. Een virtualisatieplatform is ook te hacken, vaak heb je dan al drie risico's: OS / firmware laag, hypervisor laag, guest laag. Ook kubernetes en andere container platformen moeten zelf ergens op draaien.

Vanuit genoeg guest level intergratie drivers en zo meer zijn verschillende soorten en maten hypervisors en containerdiensten gehacked. Tuurlijk heeft AWS allemaal heel goed beveiligingsmaatreglen net als Oracle, Azure en de rest, maar uiteindelijk is alles te hacken.
Als de virtualisatie laag niet in je account aanwezig is, kan jij en de hacker er simpelweg niet bij.

Bij Azure heb ik meer issues gehad dan bij AWS qua beschikbaarheid en qua security issues. En over Oracle zal ik maar zwijgen..

Maar goed, de vraag was, welke Europese partij biedt dit ook met vergelijkbare kwaliteit?

En de isolatie van services is bij AWS vele malen beter dan bij Azure. Je kunt op elk API niveau alles dicht of open zetten voor elke instance van elke dienst. En dat per specifieke instance die iets wil benaderen.

Dat is echt anders dan ik bij andere cloud providers ben tegengekomen tot nu toe.
Als de virtualisatie laag niet toegankelijk is in klant accounts kunnen wij er niet bij, maar die hacker misschien wel. Juist infrastructuur wil je overeind kunnen houden als zoiets gebeurd. Stel de boze dag komt dat AWS lowlevel onderuit gaat een etmaal lang, en tegelijkertijd kun je precies dan een etmaal lang geen SIDN wijziging op je domeinen uitvoeren, die combi is redelijk dodelijk. Voor Amazon ideaal natuurlijk dat niemand weg kan migreren buiten hun schuld om want SIDN beslissing, maar niet voor de klanten.
Zo dat is me wat ruim 100 data centra en meer dan 600 pop locaties 24 uur down.

Dan ligt meer dan 40% van het internet plat, incl. Netflix, X en een groot deel van GoDaddy.

Dan is er heel wat meer aan de hand dan dat SIDN niet bereikbaar is.

Je suggereert dat een hacker er misschien wel bij kan, dat betekent dat de core laag van AWS gecompromitteerd moet worden, het IAM gedeelte bijvoorbeeld.
Dat is een hack zijn waar je in de VS de doodstraf voor zal krijgen.
Als je dit kan, kun je er ook voor kiezen een bounty op te strijken, als je het een beetje goed aanpakt ga je de geschiedenis in als de redder van het internet en is je bankrekening zo dik dat je nooit meer over geld hoeft na te denken.
Overdrijven is ook een vak, maar belangrijk vooral blijft dat SIDN beschikbaar is voor changes, juist wanneer zoiets groots aan de hand is. Ik denk dat we wel een dagje zonder Netflix, X en GoDaddy kunnen persoonlijk. Er zullen wat belangrijkere .nl sites zijn met informatievoorziening voor kritieke sectoren en zo meer, plus je wilt je .nl site kunnen omleiden naar een eigen hosting fallback of een informatiepagina of iets op een andere cloud. Haast alles is beter dan een tijdelijk nutteloos AWS publiek IP in je DNS.

Om in zo een situatie terecht te komen is het vaak al mis als er twee of zelfs maar één cloud regio binnen de EU uitvalt, als in dat je een externe DNS aanpassing nodig hebt om weer online te komen. Liever dat SIDN een paar dubbeltjes meer kost per domein per jaar, en het zelf host, dan dat juist zij als internet infra club zelf cloud hosted gaan. Dat is met alle achterliggende internet services zo als ISP, DNS provider, Internet Exchange, zelfs een front-end load balancer als CloudFlare wil je niet dat die zelf weer op een andere cloud hosted gaan draaien want die zaken wil je juist beheerbaar houden om dingen om te leiden als je onderliggende cloud applicaties problemen hebben.
Volgens mij was jij de gene die overdreef:
Stel de boze dag komt dat AWS lowlevel onderuit gaat een etmaal lang,
Ik schetste slechts wat het betekend wat je schreef.

GoDaddy is de DNS provider voor meer dan 84 miljoen TLD (domeinnamen).

SIDN heeft ongeveer 6 miljoen domeinnamen geregistreerd staan.
En gaat niet de DNS verhuizen, slechts de API infrastructuur.

Dus snap ik je bagatellisering niet dat je 24h zonder GoDaddy kan, maar niet 24h zonder de API van SIDN.
Haast alles is beter dan een tijdelijk nutteloos AWS publiek IP in je DNS.
Ik krijg - net als elke klant - op AWS voor elke website 12 IP adressen per regio. De DNS serveert deze dynamische uit op basis van de lokatie van de gebruiker, je krijgt automatisch het IP adres van de locatie met de laagste latency voor jouw internet segment. Als een Pop locatie een hogere latency krijgt (door een aanval bijvoorbeeld), veranderd binnen 1 minuut de lijst met IP adressen voor die regio, zodat de load naar een minder zwaar belaste Pop locatie gaat. Dit gaat automatisch.

Als er 36 Data Centra en 39 Pop locaties in 12 Europese landen allemaal tegelijk plat liggen, wordt het verkeer naar buiten de EU geleidt en is mijn website nog steeds niet down, en heeft nog steeds geen waardeloos IP adres in de DNS.

Daarom is mijn indruk dat het scenario dat je schetst zeer onwaarschijnlijk is. In iedergeval onwaarschijnlijker dan dat de alternatieve hosting oplossing die jij voorstelt geen 24h downtime zal krijgen.

[Reactie gewijzigd door djwice op 26 maart 2024 14:47]

https://techcrunch.com/20...fhYuQMYio3zQfJxD1jESvy-pH

Godaddy lijkt hun dns infra bij uitzondering juist niet op AWS te hebben. Nog weer een argument voor SIDN om dat dus ook qua dns management en niet enkel nameservers gescheiden te houden.

Je bent duidelijk verliefd op AWS, dat ook heel veel goed doet. Maar staat je er alsjeblieft niet blind op. Multicloud en hybrid cloud bestaan niet voor niets om risico's te spreiden. Backup minimaal buiten AWS voor missiekritieke systemen. Kost niet veel en geeft nog iets van een lifeboat als het eens inherent stuk gaat bij AWS.

112 is ook urenlang onbereikbaar geweest, zou op basis van specificaties ook niet voorstelbaar zijn...
AWS Route53 (de DNS service van AWS) draait (deels) bij GoDaddy, dat was denk ik onderdeel van die deal.

Wat wel grappig is aan Route53 is dat je per requesting IP-range een ander antwoord kunt configureren - in dezelfde zone file. Bijvoorbeeld interne resolvers wel A en AAA record serveren voor intranet.bedrijfsnaam.nl en extern simpelweg geen. Terwijl het record in je publieke DNS staat.

Maar ik ben het met je eens dat het verstandig is om altijd een exit plan te hebben, dan wel een noodplan voor als er iets extreem geks gebeurt. In het geval van AWS, als IAM om wat voor reden er uit ligt, gebeurt er niets meer (of is alles volledig open). Want alles op AWS - op slechts heel recente overnames na - is daarmee beveiligd. En die fungeren dan wellicht direct als backdoor..

[Reactie gewijzigd door djwice op 27 maart 2024 08:35]

Als de virtualisatie laag niet in je account aanwezig is, kan jij en de hacker er simpelweg niet bij.
Is het hele punt van hacks niet juist dat er toegang verkregen wordt tot dingen waar je 'simpelweg' niet bij mag? Er worden regelmatig hypervisor lekken gevonden dus je kan nooit garanderen dat er niet toch ergens een weg is.
Ik zeg ook niet dat het nu per definitie stuk en een slecht idee is, alleen dat je je niet blind moet staren op de marketing die net doet of iets waar jij je niet druk over hoeft te maken ook helemaal niet bestaat.
Serverless betekent niet dat er ineens geen hardware meer nodig is...
Maar goed, de vraag was, welke Europese partij biedt dit ook met vergelijkbare kwaliteit?
Als we onze miljarden maar naar US cloud partijen blijven overmaken gaan die er ook niet komen.
Jij vindt Azure en Oracle al niet goed genoeg, dus denk ik dat je genoeg redenen kan vinden om iedere partij af te kraken. Voor veel soorten gebruik, zeker voor Nederlandse partijen, heb je lang niet alle functionaliteit van een AWS nodig.
Een virtualisatieplatform is ook te hacken, vaak heb je dan al drie risico's: OS / firmware laag, hypervisor laag, guest laag. Ook kubernetes en andere container platformen moeten zelf ergens op draaien.
Daarnaast krijg je ineens te maken met een derde partij (Amazon) met heel veel werknemers en buitenlandse jurisprudentie waar je allemaal geen controle over hebt. Alles bij elkaar ga je dus allerlei extra risico's introduceren.
Ik lees dit als iets moois maar ook als een mes op een keel.

Ik lees hier zoveel afhankelijkheid. Dat als AWS de prijzen omhoog gooit jij ineens veel geld kwijt bent. Zowel voor ombouwen van de stack naar niet AWS en de kosten van runnen van de stack in de tussentijd.
Geen OS, geen Applicatie installatie of updates, niemand die de servers kan voorzien van een virus of een hack, geen crypo lock gevaar, geen renewal nodig, etc.
Een hack kan altijd nog, hetzelfde met een virus of wat dan ook. De kans is altijd groter dan 0. Misschien is het maar 0.001% maar de kans is er wel.
Er zullen genoeg mensen, privé, zakelijk en overheden zijn die er alles aan doen om een stack als AWS of Azure(of wat dan ook) volwaardig binnen de dringen. Het hoeft het er maar een te lukken.
Het voordeel is dat de AWS API ook beschikbaar is voor self hosted oplossingen. En dat de meeste services gebaseerd zijn op OpenSource tools.

Denk aan HAProxy, PrestoDB, Apache Hive, etc.

We hebben getest hoe snel we Lambda functie stack van AWS naar IBM konden cross deployen. We kozen IBM omdat die toen het miste vergelijkbare functionaliteit bevatte.
Dat was binnen 24h werkend.

Juist daarom kiezen we dus serverless. En de infrastructuur configuratie volledig in Cloud formation in Yaml, zonder custom extensies of custom code. Op die manier weten we zeker dat het porteren, mocht dat nodig zijn, succesvol zal verlopen.
Ook de SQL queries worden apart buiten de applicatie opgeslagen, de applicatie laad ze in, zodat deze makkelijk naar elke andere database kunnen worden overgezet, zonder grote applicatie aanpassing.
Idem voor de pattern detection library, did wordt apart in YAML onderhouden.
Zo hebben we business logica van runtime en programmeertaal gescheiden.

[Reactie gewijzigd door djwice op 26 maart 2024 01:18]

waar hebben we het nu over? Een paar DNS servers, dat mogen de kosten toch niet zijn tov privacy?
De laatste regel van het artikel:
Het gaat om het domeinregistratiesysteem, maar niet om de resolver.
Het betreft dus juist niet de DNS servers, maar het systeem om de aanvragen en verlengingen van nieuwe en bestaande .nl domeinnamen te verwerken.
Als je kijkt naar de statistieken pagina van de SIDN:
https://stats.sidnlabs.nl/nl/registration.html

Dan zie je dat er per maand zo'n 175000 mutaties zijn elke maand. Gemiddeld 4 per minuut. Nou hoor. Poe poe. Tuurlijk zul je met de spitsuren meer dan 4 per minuut doen. Maar daar heb je dus echt geen hele bijzondere hosting voor nodig om dat te kunnen trekken met 24/7 systeembeheer, ondersteuning en al.

Dat een hosting partij als AWS nodig zou zijn is echt onzin.
Heb je ook gekeken naar uptime garanties enzo? Best lullig als je net je naam veilig wil stellen, systeem down, en een concurrent die er geruchten van hoort je daarna voor is.

Of je root zones wil updaten, etc.

Dus 24/7 uptime lijkt me wel belangrijk. En goede aanval protectie, zodat er toch gegevens aangepast kunnen worden tijdens een aanval - maar niet door de aanvaller.

[Reactie gewijzigd door djwice op 24 maart 2024 18:05]

24/7 is een non-functional van de applicatie, niet van het platform waar het op draait. Je hebt geen hyperscaler nodig om five-9s te garanderen.
Dat is wellicht ook afhankelijk van wat voor een type attacks je krijgt?
Maar in kan me voorstellen dat een 100% delivery guarantee architectuur wenselijk is voor SIDN.
En dat qua kosten het nuttig kan zijn om een goed schaalbaar platform te hebben waar je een maar microcent per call betaald, in plaats van standaard over provisioning.
Dus 24/7 uptime lijkt me wel belangrijk. En goede aanval protectie, zodat er toch gegevens aangepast kunnen worden tijdens een aanval - maar niet door de aanvaller.
Dit kan ook allemaal in een private cloud.
Volgens mij niet. Volgens mij beheer je dan ook je containers, en hebben die containers IP-adressen.

Dat is echt anders dan python script voor je berekening maken, sql query schrijven en gaan.

En je containers hebben geen IP-adres, kosten niets zolang je ze niet aanroept. En starten binnen milliseconden en sluiten direct af als de berekening gedaan is. Dan is de runtime weer weg, niets van over.

Mijn beeld is dat je in je eigen VPC toch echt met IP-adressen enzo aan de gang moet en routines enzo. en met een base coat ook als je geen gebruik maakt van je infra. Wellicht zelfs certificaten en keys die je moet genereren etc. En een build proces, dat wellicht wat langer dan een paar milliseconden duurt voor den update.

Maar ik kan het mis hebben. Hoe zou jij dit doen in een VPC zonder al dat beheer?

En waarom in een VPC, op AWS gebruik je public cloud, zonder al dat IP-gebaseerde routing die nodig is in een VPC. Geen subnetten, etc.

[Reactie gewijzigd door djwice op 24 maart 2024 22:08]

Dat jij het niet ziet zegt niet dat het er niet is.
Dat jij het niet beheerd zegt niet dat het geen beheer behoeft.
Dat jij er niet bij kunt zegt niet dat niemand er bij kan.
Dat jij denkt dat er 100% uptime-garanties zijn zegt niet dat dat niet kan met de onderliggende technieken.
Dat jij denk dat in een paar milliseconden een proces opstarten efficiënt is wil niet zeggen dat dat zo is.
Dat er geen ip-adres is wil niet zeggen dat er geen communicatielaag is die adressering nodig heeft.

The cloud is just other peoples computers.
The cloud is just other peoples computers.
Klopt. En dus net zo eng als elke andere hosting partij, maar dan met de verschillen die ik aan gaf.

Bij veel andere hosting partijen kun je de boel onderuit trekken - ook voor andere klanten - vanuit je account, zonder extra hostingkosten voor jezelf.
Bij veel andere hosting partijen kun je als hacker lekker lang mee kijken en dingen injecteren en die later gebruiken. Bij een Lambda service instance kun je als maker heel simpel zorgen dat dit potentiële window nog geen seconde duurt. En dat het daarna letterlijk verwijderd is. En dat dit hack potentieel slechts de data van 1 type interactie en 1 klant omvat.

Bij veel andere hostingpartijen kun je de limieten van de omgeving opzoeken en bereiken. Hackers ook. Zelfs op Azure NL kun je dat als gewone klant hebben we ondervonden. We konden niet meer verder schalen, de servers waren op.

Trouwens de CTO van AWS is een Amsterdammer die nog steeds in Amsterdam woont. Prettige man die de techniek die zijn enorme team neerzet echt begrijpt. En niet vies is van de handen uit de mouwen steken.

[Reactie gewijzigd door djwice op 26 maart 2024 07:38]

Kubernetes (k8s) is een "datacenter in a box". Je spint een paar VMware/EC2 VMs met een uitgeklede Linux distro (talos.dev bvb.) op, doet een absoluut minimum aan OS config (als het al hoeft), installeer een k8s distro, join de node aan de k8s cluster en al de rest (DNS, Ingress, etc.) neemt plaats binnen k8s. Niets te klooien met IP adressen; die zijn ephemeral. Een k8s Service kan altijd via naam aangesproken worden, ongeacht het IP adres dat momenteel is toegekend. Je kent een subnet doe aan je k8s nodes en de CNI (Container Network Interface) of Service Mesh (uitgebreide functionaliteit) doet alles netwerk-gerelateerd binnen k8s (DHCP, encryptie, load balancing, fail-over, mTLS, etc.). De enige "externe" infrastructuur die je echt nodig hebt zijn de firewalls/load-balancers om verkeer in de k8s cluster te krijgen.
En je containers hebben geen IP-adres, kosten niets zolang je ze niet aanroept
Het aantal bedrijven die volledig of grotendeels serverless kunnen draaien en de financiële voordelen kunnen halen van on-demand scaling zijn wss nog steeds een extreme minderheid. Elk bedrijf waarvoor ik gewerkt heb reserveert nog steeds een massale hoeveelheid aan IaaS omdat de limieten van serverless producten ze ongeschikt maken voor een hele resem workloads. Ja fijn, je kan Lambda die paar functies laten aanroepen maar ondertussen zit nog 50%+ van de Application stack op IaaS voor allerlei redenen.
En starten binnen milliseconden en sluiten direct af als de berekening gedaan is. Dan is de runtime weer weg, niets van over.
Daar heb je binnen k8s Operators voor. Die kunnen ook Pods (enkele container of verzameling van) aanmaken, wachten tot workload uitgevoerd is en dan weer verwijderen. In AWS kan je dan ook via ASG i.c.m. de k8s horizontal auto-scaler er ook voor zorgen dat je cluster schaalt met workload.

Er worden met k8s zoveel infrastructuur-lagen overgenomen dat wat je in je VPC doet echt minimaal is. Enfin als je toch op AWS zit kan je evengoed EKS gebruiken, ik had het er meer over dat de punten waarover jij het had evengoed in de private cloud kunnen.
Mwah. Aangezien het máár 4 mutaties per minuut zijn kan dat prima goedkoper door lambdas en on demand compute.

Kan mij namelijk voorstellen dat er tussen kantoortijden veel meer verkeer is dan midden in de nacht. Als ze dus tussen 23:00 en 04:00 geen zaken verwerken staat die hardware nu nog wel gewoon stroom te vreten en software te draaien. Ik snap wel dat er een leuke kostenbesparing te realiseren is in dat opzicht.
En 24/7 systeembeheer
En 24/7 systeembeheer
Ga je naar AWS dan betaal je daar nog steeds voor, bovenop de kosten die je hebt voor je eigen personeel. Je hebt nog steeds een afdeling met (AWS) specialisten nodig die ook gewoon nachtelijk piketdiensten moeten draaien. Daarnaast blijft SIDN (gelukkig) haar eigen DNS servers draaien en beheren, dus ik zie ze al helemaal niet snel kosten kunnen reduceren. Je hebt al snel een man of 5 a 6 nodig om die servers te beheren, bovenop de kosten van servers en netwerk.

Daarnaast voorzie ik al helemaal niet dat SIDN kosten (en dus tarieven) gaat verlagen. De tarieven zullen alleen maar omhoog gaan onder het mom van indexatie en dergelijke. Wij als 15+ jaar SIDN deelnemer vinden dit helemaal niet zo erg. Als een .NL-domeinnaam te goedkoop is dan verliest het ook zijn waarde. Wij betalen bovendien graag een beetje extra als SIDN zelfstandig en autonoom kan voorzien in de continuïteit van het platform, zonder Amerikaanse hosting.
De kosten zouden normaal gesproken alleen maar lager worden, want volledig geautomatiseerd and het stelt qua data niets voor. Gewoon drogredenen van een andere pipo die zijn plasje wil achterlaten. Bij SIDN heerst bureaucratie en dus mist t efficiëntie. Laat t aan de NL markt over. Dan verliezen de pennenlikkers hun fijn baantje.
Wow wat een fijne inhoudelijke post op basis van super veel aannames. Niveautje hoor
Laat het aan de markt over en dan stijgen de prijzen en daalt de kwaliteit, zoals je kunt zijn bij iedere hoster. Allemaal worden e één voor één opgekocht en uitgekleed door twee of drie grote Nederlandse hostingbedrijven. Een .nl kan prima voor vijf euro, maar toch moeten bedrijven als Versio daar blijkbaar 30 euro voor vragen.

Ik snap de obsessie van SIDN met Amazon niet helemaal, maar als we dit soort dingen aan het bedrijfsleven hadden overgelaten stond die data tien jaar geleden al bij de Amerikanen en waren alle domeinen dubbel zo duur.

[Reactie gewijzigd door GertMenkel op 24 maart 2024 21:21]

Waar haal je dat? Mijn bedrijf gaat dit jaar naar Azure met als hoofdregion France Central en failover naar Germany West.
De regios zijn er wel, maar de aparte cloud die juridisch en qua data compleet los staat van de rest van Azure is dood. Er zijn alleen nog regio's waarvan Microsoft beweert dat het niet door de Amerikaanse overheid is in te zien. Alleen mag de overheid uit de VS dat prima vragen aan Microsoft en tegelijk een gag order opleggen.

Even voor de goede orde het ging dus over https://learn.microsoft.c...e/germany/germany-welcome
Welke als entiteit volledig los stond van de rest van Azure. Het bedrijf erachter had een "volledige" licentie op Azure, maar stond juridisch compleet los van Microsoft.
Precies mijn gedachte. De prijs voor een .nl domein is nou niet iets waar je van wakker hoeft te liggen en wellicht valt daarmee wat te doen. Ik weet niet of dat de enige inkomsten zijn van SIDN en in hoever dat zoden aan de dijk zet maar persoonlijk maak ik me niet druk om een verdubbeling als daarmee de infra in NL kan blijven.
AWS heeft ook gewoon een regio in Frankfurt.
zinloos, alles kunnen ze zo naar de VS halen, een nederlandse host is de uitkomst die geen banden heeft of gaat krijgen met de VS enzo.
zinloos, alles kunnen ze zo naar de VS halen
Contract breuk en daarmee verliezen ze miljarden aan inkomsten. De gemaakte afspraken zijn dat de data in de EU blijft als je dat als klant voor kiest. Dit is pure bangmakerij.

Edit:typo

[Reactie gewijzigd door david-v op 24 maart 2024 16:36]

Het blijft een Amerikaans bedrijf. Als de tijden veranderen en er andere belangen gaan spelen, zit je met de gebakken peren.
Als de tijden veranderen en de US besluit om maar geen hardware te leveren heb je helemaal niks aan je Nederlandse datacenters. Waar denk je dat alle racks, opslag, routers en dergelijke vandaan komen?

Nogmaals, bangmakerij die al een decennia lang speelt. In de tussentijd hebben we in Europa geen dienst die kan concurreren en dat is het grootste probleem.

Edit:typos

[Reactie gewijzigd door david-v op 24 maart 2024 16:33]

Waar denk je dat alle racks, opslag, routers en dergelijke vandaan komen?
China :Y)
Huawei is hard bezig onder andere in Europa, dus je kan naar de huawei cloud ;)
Als je bang bent dat je data weglekt, lijkt me China geen bijzonder interessant alternatief...
Het was als cynische reactie bedoeld ;)
Ik denk dat bang zijn voor lekkende data niet de vraag is, maar aan wie is dit het minst erg. Je kan er vanuit gaan dat elke partij (behalve zelf) de data ergens op slaat en als de overheid van dat bedrijf komt de data zullen overhandigen, al dan niet openlijk of in het geheim.
Naja. Je hoeft er dan in ieder geval niet meer bang voor te zijn. :+
Ik denk dat hardware zonder de V.S. overleven is. Doffe ellende natuurlijk als Intel, AMD en Nvidia niet meer te koop zijn, maar je kunt bijvoorbeeld prima een server bouwen met de Fujitsu A64FX-processor. Er is desondanks een land dat essentieel is om computers te kunnen maken en dat is niet de V.S., maar Taiwan.
Fujitsu is Japans, en de gebruikte ARM architectuur is van een Brits bedrijf dat voor 90% in Japanse handen is. Dan kan je ook zeggen dat je niet om Japan heen kan. Intel heeft trouwens ook best competitieve fabs buiten Taiwan, ze zijn misschien niet net zo goed als de beste fabs van TSMC, maar lopen ook weer niet giga ver achter.
Het gaat erom dat de mogelijkheid er is, er is de mogelijkheid om bij Japan aan te kloppen en daarmee is de macht van de V.S. niet absoluut (nog steeds heel groot). Een computer zonder Taiwanese kennis is onmogelijk. TSMC is op zichzelf vervangbaar, alleen de vele honderden kleine chips die in een computer zitten, daar zitten veel chips van Taiwanese ontwerpers gemaakt worden en/of in een Taiwanese fab gemaakt en die honderden kleine chips allen vervangen en dan tot een werkende computer komen gaat je niet lukken. Verder zit er in een computer ook nog veel Taiwanese kennis en kunde op het gebied van moederborden: Ook al kun je de onderdelen voor je computer kopen, even een moederbordje ontwerpen doe je niet zomaar.
Bedenk je wel dat die vele Taiwanese chips die er inderdaad zijn vaak met Amerikaanse software gemaakt worden. De hele chip industrie is een grote internationale keten en de VS is een zeer belangrijke spil in het geheel, Taiwan zeker ook maar Taiwan heeft niet alles in-house (de VS ook niet).
Onzin, hardware koop je, maar de datacenter dienen in dit geval gewoon in Nederland te blijven en in handen van NL cq EU organisaties. Er komt meer dan voldoende geld binnen, dit soort bedrijven hoefen geen winstverwachting maken. Maak ervan een stichting van.
Waar denk je dat de S voor staat in SIDN?
Juist, het was ook meer als een reminder bedoeld, dus geen noodzaak om naar Amazon te gaan, gewoon dit in eigen beheer houden. Dus niet naar de US of China of een ander land. Anders maak van de stichting weer een overheidsorganisatie.
En hardware koop je, daarna heeft de leverancier geen enkele aanspraak meer, moet je natuurlijk niet gaan huren, dat is gewoon dom.

[Reactie gewijzigd door MacD007 op 25 maart 2024 09:15]

Wie doet er nu aan bangmakerij?

Het niet leveren van racks heeft pas jaren later invloed, bovendien is die kans zeer klein.

Als Amerikaans bedrijf zal Microsoft gewoon de data moeten leveren op verzoek van de Amerikaanse overheid. Of die data nu ergens anders of in Europa staat, maakt voor hen niets uit.

De kans dat dit gebeurt en de impact daarvan is vele malen groter dan die van wat hardware die minder goed leverbaar is.
Als we ons in hypothetical-land begeven, waar om zijn we dan niet bang dat alle Amerikaanse hardware vendors een overheids-gemandateerde killswitch in hun producten hebben gebouwd?
Omdat je dat kan controleren? Je kan gewoon zo'n apparaat inspecteren en fysiek zien dat het niet aanwezig is.
Het niet leveren van racks heeft pas jaren later invloed, bovendien is die kans zeer klein
Klopt, net zoals dat er data van bepaalde burgers aan de vs wordt geleverd. De kans is zo klein dat het in Europa nog niet is voorgekomen.
De kans dat dit gebeurt en de impact daarvan is vele malen groter dan die van wat hardware die minder goed leverbaar is.
Dat is dus de bangmakerij. Velen malen groter als in 100x0 is nog steeds 0.

Je doet het voorkomen alsof de vs de data op gaat vragen van alle Nederlandse burgers. Dat zal niet gebeuren.
Klopt, net zoals dat er data van bepaalde burgers aan de vs wordt geleverd. De kans is zo klein dat het in Europa nog niet is voorgekomen.
Bla bla.

Ooit gehoord van het EU-VS Data Protection Shield?

Zeker nergens voor nodig omdat de VS zo lief is met onze data?
Dat is dus de bangmakerij. Velen malen groter als in 100x0 is nog steeds 0.

Je doet het voorkomen alsof de vs de data op gaat vragen van alle Nederlandse burgers. Dat zal niet gebeuren.
Ik raad je aan geen job in risk-assessment te nemen. Je hebt totaal niet door wat een risico nu inhoudt.

Je begrijpt namelijk duidelijk het woord impact niet.

Een risico is de kans dat het gebeurt maal de impact die het heeft.

En de impact is dus mega groot.

Het risico is dus heel wat groter dan jouw “als de Amerikanen geen hardware meer leveren”. We hebben in dat geval namelijk jaren de tijd om andere wegen te vinden. Het is niet alsof alle hardware opeens uitvalt.

De kans is klein en de impact gebeurt pas op een tijdsvak van vele jaren. Dat is dus veel minder risico.

Maar je had niet door dat de wereld verandert, dat je roept dat het bangmakerij is?

Je had nog niet door hoe afhankelijk we zijn van de VS en ook nog niet dat daar binnenkort verkiezingen zijn waarbij er iemand meedoet die het werkelijk allemaal geen zak kan schelen wat er in de rest van de wereld gebeurt, als hij zijn zakken maar kan vullen?

[Reactie gewijzigd door White Feather op 24 maart 2024 23:24]

Routers? Deciso B.V. (het bedrijf achter OPNSense levert soft- en hardware voor networking en komt uit Nederland).

Racks? Deze zijn niet bepaald complex om na te bouwen door eenderwelk staalbedrijf.

Opslag? Dat is wel een probleem....op de korte termijn. De tech, die verantwoordelijk is voor chip-productie...de know-how en apparatuur, ook Nederlands. Op de lange termijn is dat dus een heel wat minder groot probleem dan jij je voorsteld. Technisch in ieder geval. Qua prijs zal de gebruiker wel dieper in de buidel moeten tasten, want hoogwaardig werk kost een heleboel, net zoals de faciliteiten om dat hoogwaardig werk uit te voeren.

De wens is er misschien wel, maar de wil niet. En dat zal altijd een probleem zijn in de EU. Op de korte termijn is het een heel dure grap en met de enorme hoeveelheid aan 'bean counters' in de EU, dus een probleem. Vandaar dat bijna iedereen wel wenst, maar uiteindelijk niet wil.
maar dan is er eigenlijk dus geen verschil tussen AWS en MA?
Ook niet met een Nederlands bedrijf wat Amerikaanse CPU's, netwerkapparatuur en software gebruikt. Je kan ook niet aangeven hoe de tijden precies gaan veranderen, maar een computer hardware en software infrastructuur zonder enige relatie met het buitenland zijn we als Nederland domweg te klein voor of we moeten genoegen gaan nemen met een fractie van de huidige functionaliteit tegen de hoofdprijs.
Dat ben ik niet met je eens: Een onafhankelijke infrastructuur hebben betekent niet dat je alles zelf moet maken, je moet de ultieme macht over de infrastructuur hebben. Dat betekent dat je die infrastructuur op eigen bodem bouwt, maar ook dat je fabrikanten dwingt broncode te publiceren en documentatie mee te leveren. Daarvoor zijn we beslist niet te klein.
MA Heb je ook in NL aws niet.
Tja in dat geval krijgen ze ook geen machines meer van ASML.

Blijft me verbazen dat we dit probleem al een jaar of 30 erkennen en er geen Europees alternatief wordt opgezet.
Als de overheid meer druk gaat uitvoeren op ASML dan zullen ze spoedig mogelijk vertrekken uit Nederland.

De rode loper ligt in vele landen voor ze uit. Er gaan al langer geruchten dat wanneer ze hun productie in Nederland niet kunnen verdubbelen. Ze dat elders zullen doen.

Dus geen machines meer voor hun zou een behoorlijke deuk voor onze economie opleveren.
Dus geen machines meer voor hun zou een behoorlijke deuk voor onze economie opleveren.
Wat denk je dat er gebeurd als Azure of AWS data massaal gaan overzetten naar de vs (wat dus echt niet mag zomaar), een behoorlijke deuk in die partijen. Dat zullen echt niet zomaar toelaten en dat hebben ze in het verleden al laten zien dat ze het aanvechten.

[Reactie gewijzigd door david-v op 24 maart 2024 20:10]

Moet je wel alle kennis van mensen ook verhuizen naar een ander land. Want niet alle Nederlanders verhuizen zomaar mee.
Amerikaanse bedrijven zijn blootgesteld aan de Cloud-Act, ook wat betreft data die ze in de EU hosten.

Zie www.ncsc.nl/actueel/weblog/weblog/2022/de-werking-van-de-cloud-act-bij-dataopslag-in-europa

Amazon zal idd niet snel zomaar je data waar je een regio afspraak heb gemaakt naar de USA kopiëren (vraag me wel af wat er in de kleine lettertjes staat over derdelijn support en backups), ze zullen wel gevolg moeten geven aan vorderingen van USA opsporings- en inlichtingen diensten.
USA opsporings- en inlichtingen diensten.
Dat gaat om individuen. Niet om het onderbrengen van alle data van een datacenter naar de US.

Bovendien, denk je nou echt dat de aivd geen contacten heeft met de cia of nsa en dat je data in een Nederlandse datacenter niet alsnog via de aivd bij de Amerikanen terechtkomt?

[Reactie gewijzigd door david-v op 24 maart 2024 16:38]

Het gaat erom als staat te voorkomen dat data bij de Amerikanen komt als je het niet wil. Als de AIVD het doorspeelt wilt de overheid juist dat het bij de Amerikanen terecht komt en er dus niets aan de hand. De V.S. is gevaarlijk vanwege hun economische spionagepraktijken, dat is de reden dat je hun inlichtingendiensten buiten de deur wilt houden.
Daarom is het ook zo ongelofelijk dom dat in de nieuwe 'tijdelijke' sleepwet de AIVD en MIVD ook grote datasets ongefilterd met buitenlandse inlichtingen diensten mogen delen.
Het is fijn dat je een bron vermeldt, maar geef dan alsjeblieft ook even het punt dat je wilt maken. Uit jouw reactie valt niet eens op te maken of je de reactie waarop je reageert wilt ondersteunen of juist tegenspreken.
Ik weet het ook niet wat hij hiermee wilt zeggen. Juridisch gezien is het zeer complexe materie. Dit gaat ook over individuen en niet zo zeer over de data van bedrijven.

Hoe dan ook, gevoelige data versleutel je altijd met een eigen key, iets wat databases en storage in de cloud gewoon ondersteunen. Cloud aanbieders kunnen de data wel beschikbaar willen stellen, maar het is allemaal encrypted.
Zodra je ook maar iets zinnigs met een database wil doen (zeg het uitvoeren van een query) zal je die data moeten decrypten en is die key ook in handen van de beheerder van de hardware. Encrypted werkende hard- en software is een research topic waar nog geen praktische implementaties van zijn.
Dus als je de hardware partij niet kan vertrouwen moet je daar gewoon geen vertrouwelijke data heen sturen.
Kijk eens naar https://cryptpad.fr/, dat zijn end2end versleutelde cloud diensten, waarbij de server beheerder geen toegang tot de keys heeft. De encryptie gebeurd met je eigen key in je eigen browser. Zijn nu wat super handige online samenwerkingsdiensten, nog lang geen cloud alternatief, maar wel veel meer dan een research topic.
Leuk voor een speelgoed applicatie waarvan alle data binnen een browser bewerkt kan worden, maar als ik zoekacties over een 10Tb index moet doen is dat zo lang downloaden...
Met research topic bedoel ik dingen als homomorfe encryptie die daar een oplossing voor bieden.
Cloud faciliteerd dat idd maar wel met een backup key managed by die provider.

Of te wel ze kunnen er altijd bij. Alleen MS kde is uniek
In Azure zijn eg maar weinig diensten die HYOK ondersteunen. BYOK haalt niets uit want zie stockeer he weer gewoon in efn azure Keyvault.

En al zou je HYOK overal kunnen implementeren dan ben je er waarschijnlijk nog aan voor de moeite want zij (microsoft, amazon, ..) beheren de hardware en kunnen de keys gewoon uit het geheugen lezen en als we nog een stapje verder gaan hebben ze platformen waarbij ze probes hebben die rechtstreeks de cpu cache/registers kunnen uitlezen.

Op het moment dat je de hardware niet zelf meer beheert Weet je gewoon dat , dit kan en zal gebeuren …

[Reactie gewijzigd door klakkie.57th op 24 maart 2024 21:28]

Amazon contract zegt ook dat ze om wat voor reden dan ook alles mogen opzeggen, en precedent is er, ook voor geheel legitieme bedrijven.

Het is absoluut een risico. Zorg voor een backup die online kan in minuten. Maar of je dan goedkoper uit ben is de vraag.
Amazon contract zegt ook dat ze om wat voor reden dan ook alles mogen opzeggen, en precedent is er, ook voor geheel legitieme bedrijven.
Ik ben best benieuwd naar de precedenten, heb je links die ik kan nalezen?. Maar volgens mij heeft elke datacenter een dergelijke clausule, al zal dat niet zomaar gebeuren en alleen bij zeer specifieke gevallen.
Zorg voor een backup die online kan in minuten
Onmogelijk in minuten, dat kan wel in een dubbel uitgevoerde omgeving met data sync (wat vrijwel alle cloudaanbieders als dienst aanbieden). Maar een backup elders herstellen in minuten is niet mogelijk, tenzij je een hele kleine workload hebt.
Er zijn wel een aantal bedrijven in Nederland met eigen datacenters. Vraag mij alleen af of wij aan de eisen kunnen voldoen die er gevraagd worden. Daarbij ook in de prijs kunnen concurreren.

Een datacenter van Amazon of Microsoft koopt alles zo veel goedkoper in en biedt meer mogelijkheden door de meerdere locaties.
Laat Sidn anders gewoon een euro meer vragen. ze zijn goedkoop. en probleem opgelost.
Dat is waar maar dat geldt voor Microsoft net zo. Wat dat betreft heeft @Jay-v zeker een punt.

Ik snap alleen niet dat ze niet naar een europese clouddienst gaan zoals bijvoorbeeld Scaleway. Die zijn nog een berg goedkoper dan AWS ook.
Over Gaia-X. Uit ervaring met grote EU-projecten wordt eerst alle moeite gestopt in een politiek gevecht om het gratis geld. Ook worden rare partijen toegelaten, zoals veel Amerikaanse bedrijven waarmee juist de concurrentie wordt aangegaan. Dan is er een fase dat er iets wordt gebouwd dat aan de minimale eisen voldoet, maar nooit zal concurreren - een typische "operatie gelukt, patiënt overleden". Het doet me elke keer weer pijn, dat "moonshot" een Amerikaans woord is en alleen goed vertaalt naar Chinees.

De grootste Europese spelers in public cloud zijn T-Systems en OVHcloud, en die zijn grote spelers in Gaia-X! Maar het ziet er somber uit: https://www.theregister.com/2024/01/08/gaiax_future/ waar blijkt dat de "iedereen is welkom, als ie maar lobbyt" de oorzaak lijkt te zijn.
However, then came the discussion on whether the hyperscalers should be invited to join. Karlitschek tells us that for a long time, he was very much a fan of the free market. "It's a good thing to open up to everybody, and everybody can participate and follow the rules."
De grootste Europese spelers in public cloud zijn T-Systems en OVHcloud, en die zijn grote spelers in Gaia-X! Maar het ziet er somber uit: https://www.theregister.com/2024/01/08/gaiax_future/ waar blijkt dat de "iedereen is welkom, als ie maar lobbyt" de oorzaak lijkt te zijn.
Is het probleem met Gaia-X niet gewoon dat niemand binnen de Commissie weet wat nu precies het doel van het project is, waardoor je een vaag verhaal over interoperabiliteit hebt zonder dat er ook maar één clouddienstprovider ontstaat?
Och, een makkelijke sabotage-techniek is om in een samenwerking te pushen om net iets te veel naar iedereen te luisteren - noem het maar: over-polderen. En de saboteurs zullen dan de kleine meningen blijven steunen om daadkracht te ondermijnen, of anders zelf blijven zeuren over een klein detail. Gebeurt vaker dan je denkt, ook in de Tweede Kamer nadat iets is "goedgekeurd met tegenzin".

Als ik zo het verhaal van Nextcloud zo lees, dan is dat wat zij vinden dat dit de Amerikaanse hyperscalers hebben gedaan. Ik denk dat het goed nieuws is dat de slechte verhalen naar buiten komen, omdat er dan vaak krachtigere beslissingen gemaakt worden.

Als je het interessant vindt om je er tegen te wapenen, zoek de "Logical Fallacies" op, en kijk "Yes, Minister".
Dat is waarom we Amerika niet moeten ver-Europesen of té dikke boetes opleggen.

Zij moeten de producten maken. En dat kan alleen met praktisch slavenarbeid en bakken met geld van de echt grote jongens, gejat van de kleine.

En dat mag hier niet waardoor geen enkel bedrijf hier echt groot kán worden. De regels zijn te verstikkend en de regels daat niet. Dan ga je dus aan de andere kant opereren.

Let wel, dit komt juist door de verschillen. Mochten we allemaal met dezelfde regels spelen zal het niet meer zo heftig verlopen. Alleen denk ik wel dat er weinig grote jongens meer zijn. Goed of niet, laat ik in het midden.
geen enkel bedrijf hier echt groot kán worden. De regels zijn te verstikkend en de regels daar niet.
Oef, nog nooit zoveel regels tegen gekomen als in projecten waarin amerikanen de hoofdrol speelden. Als er één land is waar bureaucratie hoogtij viert, dan is het de VS wel, ook binnen bedrijven zelf

[Reactie gewijzigd door divvid op 24 maart 2024 22:24]

Met AWS kan je ook kiezen om je data & services in de EU te houden, dat moet vaak ook vanwege GDPR. Amazon is ook bezig met een cloud waarbij de alle services in Europa zijn en de cloud compleet los staat van de bestaande AWS regions. Neemt niet weg dat ik ook voorkeur zou hebben aan Azure!
AWS heeft ook datacenters in Duitsland (eu-central-1 in Frankfurt).
Als er geen Europees alternatief is qua webhoster die de gewenste/vereiste functionaliteit kan bieden zou je eventueel nog kunnen overwegen om niet naar AWS te gaan, maar naar Microsoft Azure. Die hebben een datacenter in Duitsland, waarbij de data dus ook in Duitsland, en dus de EU, blijft.
In Duitsland heb je AWS, bijvoorbeeld in Frankfurt. Azure heeft dan wel West Europa, en dat is wel volledig in Nederland.
Als er geen Europees alternatief is qua webhoster die de gewenste/vereiste functionaliteit kan bieden zou je eventueel nog kunnen overwegen om niet naar AWS te gaan, maar naar Microsoft Azure. Die hebben een datacenter in Duitsland, waarbij de data dus ook in Duitsland, en dus de EU, blijft.
Maar dat schiet niet op, want het probleem is niet dat de data in de VS staat (Amazon heeft ook datacenters in de EU, waaronder Ierland, Frankrijk en Duitsland, maar ze weigeren naar Nederland te komen) maar dat Amazon een Amerikaans bedrijf is en dus onderhevig is aan de grillen van de Amerikaanse overheid die elke vier tot acht jaar compleet van richting veranderen.
Op 30 januarie 2024 hadden ze bij BNR de Techoloog het al over dit onderwerp. https://www.bnr.nl/podcas...na-en-dat-is-een-probleem
Je kan nog dichter bij huis, want Microsoft heeft ook een data center in Middenmeer. Dit is de regio "West Europe". Hiermee staan de servers en dus ook de data in Nederland en niet in Duitsland. Microsoft heeft trouwens ook een service waarmee ze garanderen dat de data altijd in de EU blijft staan. Zie hier: https://www.microsoft.com...ropean-data-boundary-eudb
Microsoft Azure zit gewoon in Nederland (de West-Europe region zit in Middenmeer en Schiphol Rijk), waarom dan Duitsland?
Duitsland? Als je regio West-Europe kiest, komt je data in Nederlandse datacenters van Microsoft te staan. Die hebben ze staan in Amsterdam en Middenmeer.

https://datacenters.micro...re?info=region_westeurope

[Reactie gewijzigd door SupaHotFire op 24 maart 2024 19:32]

Amazon heeft net zo goed infrastructuur voor de clouddiensten in de EU. Daar gelden in principe de zelfde regels voor.

Het probleem is niet Amazon of Microsoft maar hoe dit soort niet-EU bedrijven onder bestuur en controle staan vanuit het buitenland. Niet voor niets is er eerder al gesteld dat de overeenkomsten niet genoeg zijn. Niet voor niets tikte de toezichthouder de EC op de vingers om toch de Microsoft cloud te blijven gebruiken. Niet voor niets worden er serieuze waarschuwingen gegeven dat hopen dat overeenkomsten een oplossing zijn tegen risico's die wettelijk niet de bedoeling zijn. En zeker niet als daar heel zware afhankelijkheid vanaf hangt, zoals dat van miljoenen personen bedrijven en organisaties met enorme belangen.
Het argument van SIDN om zelf vooral kosten te willen besparen en minder moeite te hoeven doen verbleekt dan al snel. Er hoeft geen alternatief te zijn voor de situatie die er al was en zelfs als men dat wel anders wil hoeft dat niet in de cloud.
Gaia-X is geen concurrent van AWS! AWS is een onderdeel van Gaia-X. Net als Microsoft, Google, Snowflake, IBM en andere Amerikaanse spelers. Ook Chinese spelers als Alibaba en Huawei zijn onderdeel van Gaia-X.

Gaia-X is voor veel betrokken partijen een kans om invloed te kunnen hebben in Europa en om aan Europese (gratis) geld te komen.
Zo ingewikkeld is het allemaal niet wat ze willen.

Je moet dit gewoon niet willen, juist het SIDN zou dat moeten snappen.
Er zijn plenty EU alternatieven, echt meer dan genoeg die alles wat ze willen kunnen. Daarvoor hoeven we niet voor het burocratische beeste Gia-X te wachten want dat kan nog eeuwen duren...

https://european-alternat...cloud-computing-platforms
Al die US-EU data dingen zijn een wassen neus gebleken, dat zal nu ook wel weer zijn voor de AWS variant...

Lees even in over Schrems 1&2, ik verwacht ook 3 eigenlijk binnenkort

https://mopinion.com/nl/wat-je-moet-weten-over-schrems-2/
AWS heeft ook gewoon servers die specifiek voor de EU zijn, om zo aan AVG voor bedrijven wetgeving te kunnen voldoen.
Er zijn Europese concurrenten.

Zelf prettige ervaringen met OVH en Scaleway.

Bieden allemaal de basic componenten die je van een moderne cloud provider mag verwachten. Van bare metal instances tot server less functions tot managed Kubernetes clusters.

Zonder Amazon of Microsoft specific niche features waarmee je opeens aan een cloud provider vast zit. En zonder marketing afdeling die deze niche features heel graag pusht.
Had Lidl of Aldi niet een alternatief voor AWS?
Er is toch ook een datacenter in Nederland van Azure? Ik zou mijn data hoe dan ook uit Duitsland proberen weg te houden. En waarom AWS only? Juist dit soort diensten wil je toch spreiden over AWS en Azure?
TransIP hier in Nederland boodt ook iets soortgelijks aan geloof ik.
Blijft dat echt in de EU? Iets met de patriot act e.d. Voor zover ik dat begrijp, moet microsoft het dan doorgeven.

Al met al, zolang het niet Europees is, vertrouw ik niet dat het binnen de EU blijft. Als het EU is, verwacht ik nog steeds dat het niet binnen de EU blijft, want the 14 eyes.

Maar ja, de vraag is wat dan wel een goed alternatief is.
Hou toch eens op met deze onzin. Dit moet gewoon Europees geregeld worden. Er zijn mensen genoeg met kennis van zaken die dit kunnen regelen. Denk aan NLnet etc. Wil je nu je eigen cybersecurity in de hand houden? Een strategisch goed? Of het aan de markt overlaten? Een imperfecte markt omdat we veel te veel het in de handen van een paar monopolisten geven? Geopolitiek heb je nu de Amerikanen, De Russen, De Chinezen, en dan geen EU? Onbestaanbaar. En stupide op de koop toe, in een Europees continent met oorlog. Of hoe dacht je dat je afgeluisterd kan worden als je dit soort zaken in de cloud gaat laten afspelen? Of hoe dachten we dat we secure DNS gaan regelen en veilige certificaten? En dan ook nog met de voorspelling dat wellicht volgend jaar al Quantum Computers de beveiliging kunnen kraken? Ik snap niet eens dat je op het idee komt. Maar wellicht zegt het meer over politici en bestuurders. Hun oren die regelmatig in digibeet standje Oostindisch Doof staan...? Geld als de universele blinddoek voor alles ten dienste van efficiëntie. Dan moet je wel eerst stupide dingen gaan zeggen voordat iemand wakker wordt. Typisch Nederland? Defensie heeft een Cyber Commando. De tranen moeten daar dan toch in de ogen schieten? Waarvoor is dat dan nog nodig? Je ben alles aan het weggeven...

[Reactie gewijzigd door oks op 25 maart 2024 12:04]

Sterker nog, Azure West Europe == Nederland ;) dus dat is ook een optie. Maar de vraag is of het alleen maar gaat over "waar" het staat, het gaat allicht meer om 'de kleine lettertjes' ;)
Een deel van hun oplossing zat volgens mij ook in Azure, maar ook dan ontkom je niet aan het datagraaien van de VS, middels de nieuwere CLOUD-Act, hieronder een artikel van het Nationaal Cybersecurity Center over de gevolgen hiervan:
https://www.ncsc.nl/actue...-bij-dataopslag-in-europa

Het lijkt me dat de EU-lidstaten hier best de handen ineen kunnen slaan om een Europees alternatief op te zetten. Autonomie op dit soort data lijkt me van (inter)nationaal belang, hier mag best wat meer energie en geld in gestoken worden.

Dat het in eerste instantie achterloopt zal wel, maar de enorme diversiteit aan tools en mogelijkheden zoals in AWS/Azure hoeft ook niet vanaf dag 1 beschikbaar te zijn.
Ben benieuwd naar de eisen van het sidn die aws specifiek zijn. Sidn doet zulke speciale dingen dat het niet een kwestie is van Amazon module z aanzeten op aws en gaan. Vermoedelijk is het alleen ijzer en uitwijk die ze nodig hebben en dat kan op meer plekken.
Ik vermoed dat ze geen hardware afnemen maar eerder services. Puur hardware draaien kan je wel op welke willekeurige datacenter. Maar als je bijvoorbeeld een hele Kubernetes cluster wel draaien en een cloud provider levert dat voor jou zodat jij je kan richting op het uitrollen van je oplossing dan scheelt dat natuurlijk in de hoeveelheid onderhoud die je zelf moet plegen.
Maar dat is wel een onderschatting van de Nederlandse IT sector. Er zijn genoeg grotere en kleinere dienstverleners die dit zouden kunnen en willen verzorgen als dienst. Inclusief eigen datacenters.
Ongetwijfeld en ik denk niet dat de SIDN die overweegt, omdat geen van ze kan concurreren met de economie van schaal tegen AWS.

Amazon zal ongetwijfeld een aanbod hebben gedaan, die zo ver onder de normale marktprijs ligt, dat SIDN geen andere keuze kan verdedigen. En natuurlijk verdwijnen die voordeeltjes na verloop van tijd.
Mijn ervaring is dat de schaalgrootte ervoor zorgt dat een lokale partij vrijwel nooit goedkoper zal zijn én dezelfde flexibiliteit kan bieden. Lokale partijen zijn juist bij uitstek geschikt voor specialistische op maat gemaakte oplossingen. Denk bijvoorbeeld aan de resolver die wel in Nederland wordt gehost.

De pijn heeft niks te maken met beter/slechter of duurder/goedkoper, maar vooral dat een "Nederlandse" instantie zoals SIDN voor een big tech bedrijf gaat. Zou het zelfde probleem zijn opgetreden als ze bij bijvoorbeeld T-Systems de administratieve systemen zouden plaatsen?
Ik ben het helemaal eens met je reactie, ik heb ook niet het idee dat ik jouw punten heb tegengesproken.

De SIDN heeft op dit moment een strikt economische beslissing te nemen, welke altijd in het voordeel van een van de grote drie zal uitvallen (AWS, Microsoft of Google), de Nederlandse overheid moet nu beslissen of ze de SIDN de middelen willen geven om die keuze niet te hoeven maken en te kunnen kiezen voor een meer lokale partij.

Uiteindelijk is het aan onze overheid om te beslissen of we bereid zijn een stukje kritische infrastructuur te laten vallen onder de wetgeving van een vreemde mogendheid of dat we liever zelf volledige controle houden en daarvoor bereid zijn extra te betalen. De SIDN heeft hierin alleen de steek laten vallen dat ze niet geïnformeerd hebben voor zover ik kan zien.
Ik ben het helemaal eens met je reactie, ik heb ook niet het idee dat ik jouw punten heb tegengesproken.
Ik wilde je ook niet tegenspreken, dus volgens mij zijn we het met elkaar eens ;) . Alleen wat de voordeeltjes betreft van aws denk ik dat dat nogal meevalt. Ik heb ervaring in Azure en dat zie ik dat dat gebeurd. Door die schaalgrootte kunnen ze een lage prijs blijven aanbieden en door het bieden van meer functionaliteit trekken ze juist meer workloads aan.

Ik denk dat we er vooral moeite mee hebben dat we in de EU niet een vergelijkbaar alternatief hebben. Overigens gaat dit nog steeds om de administratieve delen van SIDN, de resolvers (specialistisch werk) blijft in Nederland. Dat is dan weer de kracht die lokale partijen wel hebben.

[Reactie gewijzigd door david-v op 25 maart 2024 08:50]

Ok, geef mij dan eens een voorbeeld van een Nederlandse partij die qua cloud dienstverlening in de buurt komt van Azure/ AWS en GCP? Dan bedoel ik niet alleen een beetje Storage en Compute maar vooral Cloudnative diensten.
KPN of Ordina. De Nederlandse takken van Cap of CGI, dat soort spelers.

Ook daaronder zijn er nog middelgrote partijen die ik niet allemaal zo goed ken, maar ook eigen DC’s hebben.

Ze hoeven niet een retail cloud portal te hebben a la Azure of Microsoft, je besteedt het in die constructie uit als Managed Service.

[Reactie gewijzigd door Keypunchie op 24 maart 2024 14:54]

Lol, KPN werkt zelf helemaal in de USA cloud. Microsoft en O365 op de werkplekken, MS-SSO om "Het netwerk van Nederland" te kunnen beheren, en alle provisioning en support systemen gaan naar AWS. Het enige wat nog overblijft in NL is de Ericsson 5G core en wat routers. (waar ze alleen met toestemming van Microsoft op in kunnen loggen.)
Ik denk dat je aan een andere tak denkt (de mobiele telefonie). KPN heeft ook een zakelijke dienstverleningtak met eigen datacenters, zoals bijvoorbeeld die van het overgenomen Getronics.

[ed.] Schijnt tegenwoordig KPN Internedservices te heten.

[Reactie gewijzigd door Keypunchie op 24 maart 2024 16:39]

Dat onderdeel ken ik. Soevereiniteits-washing is dat aka een wassen neus. Klanten die zich zorgen maken mogen meer betalen, krijgen dan idd servers die in KPN datacenters staan. Maar het wordt beheerd en geprovisioned vanuit de USA cloud en ook daar zijn alle werkplekken O365. Dus als je ze bijvoorbeeld een mailtje stuurt over jou "soevereine" cloud gaat dat via Microsoft.
Nee joh, die hebben hoogstens wat IaaS en containers. Wil je beetje Managed infra dan kun je dat prima lokaal halen. Wil je geavanceerde clouddiensten/ microservices in combinatie met globaal (Enterprise) gebruik dan lopen de grote drie lichtjaren voor.

[Reactie gewijzigd door Highlands op 24 maart 2024 16:42]

Er zijn inmiddels best al een aantal bedrijven die (managed) Kubernetes aanbieden. Vanuit eigen DC’s. Zelf werk ik ook voor zo’n partij en we waren dan ook onaangenaam verrast door het besluit van de SIDN. De VrR (vereniging van registrars) hebben ook vraagtekens gezet bij de argumentatie van de SIDN. Het lijkt namelijk op dat ze aan het doelredeneren zijn geslagen waarbij van te voren al was bepaald dat AWS het doel was.
De keus heeft mogelijk ook te maken met het partnerschap dat ze aangegaan zijn met de Canadese registrar (CIRA). Ik weet niet hoe de Canadezen tegen een "EU-only" datacenter oplossing aankijken, waarschijnlijk maakt het ze niets uit als het technisch 1 op 1 inwisselbaar is en financieel gelijk.

Ik vrees echter dat AWS/Azure/Google dit soort partijen gemakkelijk een dealtje kunnen gunnen waar een kleinere hosting partij niet tegenop kan.

Ik vrees echter dat SIDN op dezelfde manier gaat leren hoe "goedkoop" de cloud is als vele andere bedrijven die klagen dat ze nu meer kwijt zijn dan toen ze de boel in-house/via managed services hadden draaien.
De dienstverleners zijn er misschien wel, maar is de zekerheid er ook? Van een AWS of Azure is de kans veel kleiner dat het bedrijf er achter failliet zal gaan. Bij een puur nederlandse oplossing is die kans aanzienlijk groter, naast waarschijnlijk ook nog hogere kosten.
Hou op. Moeten we tegenwoordig een hyperscaler zijn om faillisementsrisico af te dekken?

We hebben het hier over bedrijven met een track record van tientallen jaren (pre-dotcom), of als je de wat kleinere neemt zijn het degene die de eerste dotcom-shakeout hebben overleefd en ook de financiële crisis van 2008.

Dit zijn bedrijven die ook (al jaren) een hele hoop vitale infrastructuur verzorgen (denk aan financiële, logistiek, energie-sector).

Met alle respect voor SIDN, maar die dienst is misschien gespecialiseerd; maar voor de sector niet buitengewoon groot of complex vergeleken met wat andere techbedrijven doen.
Dat kan zeker zo zijn, maar als die diensten vele malen duurder zijn dan bv AWS of Azure, waar zeker nu steeds betere integratie is met een hoop andere services, waarom zou je dan kiezen voor een nederlandse oplossing? En mijn ervaring met een zwik van die groten, gezien bij oa belastingdienst en menig pensioenuitvoerder, is dat het daar toch vaak genoeg helemaal niet zo denderend is als men doet voorkomen.
De dienstverleners zijn er misschien wel, maar is de zekerheid er ook? Van een AWS of Azure is de kans veel kleiner dat het bedrijf er achter failliet zal gaan. Bij een puur nederlandse oplossing is die kans aanzienlijk groter, naast waarschijnlijk ook nog hogere kosten.
Met die redenering valt er geen speld tussen de drie te krijgen. En dat is zeer zorgelijk.

Het is schandalig dat we als Nederland zijnde cruciale belangrijke applicaties en infra buiten de EU laten hosten
Wie zegt dat je buiten de EU laat hosten? Zowel Microsoft Azure als Amazon AWS hebben gewoon de mogelijkheid om je applicaties and infra in de EU te laten hosten.
Wie zegt dat je buiten de EU laat hosten? Zowel Microsoft Azure als Amazon AWS hebben gewoon de mogelijkheid om je applicaties and infra in de EU te laten hosten.
En dat weet ik, alleen nog steeds in het bezit van een non-eu bedrijf. Dat zou niet moeten voor zulk cruciale zaken. En ik weet dat het risico niet heel groot is, maar het is belachelijk om overgeleverd te zijn aan partijen uit bijv. de VS.
Tja, uiteindelijk ben je altijd overgeleverd aan een bedrijf, het is niet alsof een nederlands bedrijf dan zoveel betrouwbaarder/veiliger is als een amerikaans bedrijf. Maar niets mis mee als jij liever (onnodig?) meer geld uit wilt geven om bij een nederlands bedrijf te zitten, moet je natuurlijk helemaal zelf weten, maar zodra zuur betaalde belastingcenten uitgegeven gaan worden moet er verstandiger met geld omgegaan worden en niet denken 'ach de belastingbetaler betaalt het toch'.
Als je geen cloud gebruikt kan je cloudaanbieder niet failliet gaan.
tja, en alles zelf doen kost natuurlijk helemaal niets, de kosten om een eigen datacenter op te zetten zijn al zo gigantisch dat je daardoor al failliet kunt gaan of dus geen zin heeft om je bedrijf op te zetten.
Kennis is de sleutel: Als je iets slim bouwt, heb je helemaal geen dure infrastructuur nodig. Dat is ook het verdienmodel van de cloudaanbieders, ze kunnen je een duur maandelijks abonnement verkopen omdat "slim zelf doen" niet iets is wat je in een webwinkel kunt bestellen. Ik zou als ik overheid was dat evenwel keihard afdwingen, omdat de gemakkelijke weg betekent de kennis in ons land niet aanwezig gaat zijn en als overheid wil je een hoogwaardige kenniseconomie.
Als je het vorige bericht hierover bekijkt op tweakers (en dan de comments) dan lijkt het meer op een nieuwe CTO die erg graag AWS wil doen en daar verder geen onderbouwing voor nodig heeft...
TransIP doet ook Kubernetes hosting. Werkt als een trein.
Hey, dat was vorig jaar nog niet. Ik zie nu dat ze dat geïntroduceerd in de zomer. Wist ik niet. Goed om te weten, bedankt voor de tip!
Ik vermoed dat ook de systemen van SIDN voornamelijk uit een database en enkele services / onderhouds sites bestaat. Zo speciaal zal het niet zijn.
Ik denk dat je het lichtelijk onderschat. Er zijn maar heel weinig diensten die uit één enkele database bestaat en wat services. Zelfs de meest simpele websites/diensten blijken vaak alleen het topje van de ijsberg.
Ik praat over systemen, niet over diensten. Het kunnen best in totaal meerdere databases zijn , maar bij een goed gebouwd systeem, heeft dat maar toegang tot 1 database en komt de rest uit andere services, die ook weer een database hebben.
Onder andere de energiekosten, de kosten van nieuwe hardware en het vinden van personeel om de infrastructuur te beheren, is erg duur. Het gaat om het domeinregistratiesysteem, maar niet om de resolver.
Wat is "erg duur" vertaald naar euro per geregistreerd domein?
De kosten per domein wegen in elk geval niet op tegen de totale kosten, die blijven alleen maar stijgen immers, omdat mensen graag betaald willen worden zonder het gevoel te hebben dat werken bij een werkgever geld moet kosten.

Personeel is daarnaast lastig te vinden, zeker in de huidige markt, dat drijft de prijs nog verder op. Al met al is het in dat op zicht waarschijnlijk goedkoper om 'bij iemand' in de cloud te zitten. Je bespaart op personeel en het personeel dat er is, loopt er toch ook al en is vooral bezig de cloud draaiende te houden voor meerdere klanten (en dus gedeelde kostprijs voor de klanten).
De kosten per domein wegen in elk geval niet op tegen de totale kosten,
Het gaat specifiek om de kosten van het domeinregistratiesysteem en alles dat daarbij komt kijken. Hoeveel zou het registreren van een nieuw domein of het verlengen van de registratie van een bestaand domein per jaar meer kosten als daarmee alle voorziene hogere kosten door het niet kiezen van AWS vergoed moeten worden? 2 euro? 5 euro? 20 euro?

[Reactie gewijzigd door The Zep Man op 24 maart 2024 16:05]

Ik heb het vermoeden dat het juist bij AWS een flink stuk duurder zal zijn dan wanneer ze het zelf hosten. Ik heb nog nooit gezien dat bij AWS hosten kostenvoordelen opleverde (op specifieke projecten na, bijvoorbeeld projecten die enkele dagen per jaar enorm moeten schalen, of die het hele jaar door weinig resources gebruiken)
Hoi Kees,

SIDN, die weet waar ze precies over praten heeft uitgebreid naar de zaak gekeken en denkt dat het bij AWS stukken goedkoper zal zijn.

Bedankt voor je input.
Bij 1 partij lijkt mij onwenselijk voor zo’n belangrijke organisatie.

Dan minimaal een multicloud oplossing.
Hebben ze dat nu ook? Hebben ze meerdere datacenters van verschillende aanbieders in gebruik?
Men wil net de kosten omlaag brengen, niet verhogen door werk dubbel te moeten gaan doen. Uieindelijk is kiezen voor 1 cloud provider of meerdere ook weer een risico analyse en een kosten/baten analyse.

Ja, het kan voorvallen dat een AWS een storing heeft waardoor je virtuele infra onbereikbaar is. Maar hoe vaak valt dat voor? Hoe lang is op zo een moment de downtime en wat zijn de gevolgen van dei downtime? Want uiteindelijk werkt heel DNS ook gewoon op caching. Is een half uur onbereikbaar zijn rampzalig?
Ik denk dat de kans op downtime op AWS een stuk minder groot is als bij een nederlandse speler, tenminste als we naar prijsverschil zullen kijken. Denk dus dat een nederlandse aanbieder met gelijke up-time wel een 2 a 3x zo duur zal zijn. Dan weet ik het wel, dan ga ik echt niet zomaar kiezen voor dat nederlandse bedrijf puur omdat het een nederlands/europees bedrijf is, immers kun je het geld maar 1x uitgeven.
Het is wat genuanceerder dan wat ik in bericht lees. Antwoord van demissionair minister is wel volledig, maar erg politiek geschreven (had niet anders verwacht).

Ten eerste SIDN heeft twee grote delen van het geheel systeem:

- domain registratie
- domain zone / nameservers

SIDN overweegt het eerste, registratie systeem naar AWS over te zetten. Mocht deze ook vandaag uitvallen zal er geen domain resolving/dienst raken en alles wat er nu is zou gewoon blijven draaien.

Ten tweede, SIDN wil graag nieuwe registratie systeem samen met Canadese collegas in gebruik (en verdere ontwikkeling) nemen. Ongetwijfeld speelt dat ook in deze beslissing mee.

Er zullen vast ook andere oplossingen dan AWS zijn. Ik denk dat een deel van het probleem is, dat het complexiteit en omvang van het technische gedeelte van registratie applicatie tegelijkertijd te groot en te klein is.

Te groot, qua belang van de dienst en gewenste beschikbaar. Maar te klein qua omvang en benodigde aantal servers. Hiermee aan de ene kant worden er veel eisen aan de operationele beschikbaarheid gesteld, maar het kost (relatief) te weinig om eisen te kunnen stellen richting providers.

Vergeet ook niet dat prijs van een domain erg laag is (wat goed is), maar dat het groei er niet meer zo veel in zit afgelopen paar jaar.

To be continued...
Maar elk jaar komt er wel abonnementsgeld binnen dus ruim 10/15 miljoen. Daar kan je wel wat mee toch?
Absoluut hoor, maar er dient wel rekening gehouden te worden dat er weinig groei meer in zit.

Tegelijkertijd zijn er wel extra initiatieven en strengere regels van kracht welke nageleefd dienen te worden.
Maak daar 22 miljoen per jaar van, de jaarcijfers kan je zelf opvragen.

SIDN heeft geld zat.
Er zijn vele wegen om iets te bereiken. Operationele beschikbaarheid kun je bereiken door extreem sjieke enterpriseapparatuur te gebruiken waar alles redundant is. Of je pakt het totaal anders aan, ontwerpt het gedistribueerd en installeert het op wel 1000 Raspberry Pi's, waar niets redundant aan is, die je verspreid over Nederland aansluit.

Ik denk dat men iets teveel inzet de faciliteiten die de cloud biedt voor beschikbaarheid en die cloudfaciliteiten daarom opeens héél noodzakelijk worden en daardoor Amazon de enige reële optie wordt.

Dan moet iemand keihard "njet!" gaan roepen, gezien dat niet acceptabel is, en dan terug naar de basis: Andere strategie gaan gebruiken voor hoge beschikbaarheid die niet leidt tot een systeem wat van boven tot onder afhankelijk is cloudfaciliteiten.
Ik vraag mij af waarom dit soort bedrijven volledig naar de cloud willen en of ze het verschil met IAAS diensten snappen (op bestuurlijk niveau dan). De meeste bedrijven bouwen nog steeds een Windows omgeving in de cloud, dat is niet echt naar de cloud gaan en ben je goedkoper af met een IAAS dienst. Er zijn volledig Nederlandse IAAS spelers zoals Uniserver, waardoor we nog enige autonomie kunnen behouden.
Als sidn eerst eens stopt met catch diensten faciliteren op api en hun onnodige projecten stopt. Dan mogen ze pas zeuren over budget of over overheidssubsidies of over systemen verplaatsen naar een Amerikaans bedrijf
Vind dit zeker geen goede zaak dat SIDN naar een commerciele grootmagnaat als Amazon gaat verhuizen. Vind dat iets als SIDN zelfstandig moet blijven en onafhankelijk dan van wie dan ook. Dat de EU dan maar in springt en geld beschikbaar stelt voor SIDN dat ze zelfstandig kunnen blijven.
Artikel van De Correspondent over dit onderwerp: https://decorrespondent.n...0a-0ea5-31fe-1dd56676093e
Bedankt, mooi artikel om met de leek te delen.
Kijk en nu kan SIDN tegen het ministerie zeggen "ok, nou geef maar funding dan".
SIDN heeft genoeg mogelijkheden om rendabel te zijn en een goede infrastructuur te houden dat er geen reden is om op publiek geld te kunnen rekenen.

Hun kernactiviteiten op kosten van domeininkomsten zien ze al lange tijd veel breder dan het beschikbaar houden van de modernste dns-basisvoorzieningen. En wat betreft die inkomsten stellen ze de kosten per domein op net geen 4 euro per jaar inclusief inflatie (financieel jaarverslag 2022) Wat een scheintje is voor de belangen per domein.

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee