Werken in de Amazon EC2-cloud

Intro

Van de drie grote cloudleveranciers is Amazon de enige die echt platformonafhankelijke IT-resources aanbiedt. Gebruikers kunnen op afstand virtuele machines configureren, starten en beheren. Daaromheen zijn allerlei aanvullende faciliteiten voor de veiligheid, beschikbaarheid en schaalbaarheid georganiseerd. In dit artikel laten we zien hoe de gebruikersinterface van Amazons Elastic Compute Cloud er uitziet.

Als het gaat over cloudcomputing, dan worden Amazon, Google en Microsoft meestal in één adem genoemd, maar alleen die eerste biedt echte infrastructure-as-a-service. De andere twee leggen zich toe op platform-as-a-service. Googles App Engine biedt gebruikers de mogelijkheid om Java- en Python-programma's te uploaden en te runnen, en Microsoft levert met Azure een op de cloud gebaseerde Windows-omgeving. Amazon daarentegen laat zijn gebruikers complete virtuele machines draaien op zijn EC2-infrastructuur.

Volledige controle

Het verschil tussen PaaS en IaaS lijkt misschien een detail, maar is dat geenszins. Cloud computing op basis van IaaS geeft de klant namelijk de volledige controle over zijn omgeving. Bij Google maakt een gebruiker zich al gauw afhankelijk van de App Engine-libraries en bij Microsoft zit de gebruiker nog steeds vast in diezelfde lock-in waar velen al zo lang van af willen. Dat terwijl de transitie naar cloudcomputing bij uitstek een gelegenheid is om je minder afhankelijk te maken van leveranciers van proprietary-omgevingen. Dat kan door 'de knip' niet op platformniveau, maar op infrastructuurniveau te zetten.

Voor deze bespreking hebben we een account geopend en twee virtuele Linux-machines geactiveerd. Vervolgens hebben we die twee machines voorzien van een load balancer en aan een publiek internetadres gekoppeld. Daarbij hebben we ook gekeken naar de mogelijkheden voor beveiliging en beheer.

Aanmelden en de eerste stappen

Management Console

Werken met EC2 begint met het openen van een account voor Amazon Web Services (AWS). Naast je persoonlijke gegevens vul je ook je creditcarddata en eventueel een btw-nummer in. Daarna krijg je een pincode op je scherm en word je gebeld door een computer. Op die manier controleert Amazon of je telefoonnummer klopt. Daarna kun je direct aan de slag in de AWS Managament Console.

Het gemakkelijkst is het om in eerste instantie de bestaande AMI's te gebruiken. Dat zijn voorgebakken images die direct kunnen worden gestart.

Een AMI bestaat uit een bootpartitie en gegevens over de virtuele machine. De technologie is gebaseerd op Xen-virtualisatie, dus AMI's zijn ook prima zelf te maken. Dat doe je door een bestandssysteem met een virtuele machine te bundelen. Amazon levert de tools daarvoor. Ondersteund worden de belangrijkste Linux-distributies, Sun Solaris en Windows Server. Maar let op: bestaande Windows-licenties mogen niet in de cloud worden gebruikt.

Regio's

Voordat je de virtuele machines (Instances) in de lucht brengt, kies je eerst nog een Regio. Amazon heeft EC2-clouds aan de Amerikaanse oost- en westkust, in Azië (Singapore) en in Europa (Ierland). Je moet je dus wel afvragen of de interactie tussen cloud en gebruiker nog snel genoeg is. Elke honderd kilometer voegt immers minstens één milliseconde aan een web-klik toe.

In de Europese EC2-cloud zijn meer dan 1700 kant-en-klare AMI's beschikbaar, vergelijkbaar met virtuele appliances. En die kun je maar beter gebruiken ook, want de basisimages zijn sterk verouderd: Fedora 8 en Windows Server 2008.

Service level

Voor een hogere beschikbaarheid kun je de Instances nog over verschillende Availability Zones binnen de regio verdelen. Availability Zones zijn datacenters die compleet onafhankelijk van elkaar zijn wat power-backup, koeling en rampen betreft. Zo kun je bijvoorbeeld je databasereplicatie organiseren. Daarbij draai je op veilige afstand een tweede databaseserver die in realtime een actieve kopie van de primaire server bijhoudt.

De sla van Amazon zelf is verder heel simpel. Het bedrijf heeft alleen een inspanningsverplichting. Zit de uptime onder de 99,95 procent (een halve dag per jaar), dan krijg je tien procent korting. Het grote verschil met traditionele dienstverleners is natuurlijk dat je niemand kunt bellen. Cloudcomputing is in dit geval een commodity business zonder dienstverlening. Dat maakt dat deze manier van werken voor echt belangrijke zaken niet voor de hand ligt.

Configuratie en virtuele machines

Configuratie

Na het kiezen van de AMI geef je aan welk Instance-type je wil gebruiken en hoeveel je er wil starten. De kosten voor een Instance zijn afhankelijk van het soort virtuele server. Amazon biedt daarvoor een tiental verschillende configuraties. De gebruiker kan kiezen voor meer of minder processoren, elk met een tot vier kernen, 32 of 64 bits, extra veel geheugen, en tussen verschillende hoeveelheden local storage. Om de (virtuele) processoren met elkaar te kunnen vergelijken, heeft Amazon op elk Instance-type een andere EC2 Compute Unit-waarde geplakt.

Daarna kan je eventueel nog een specifieke Kernel en RAM Disk uitzoeken, en CloudWatch Monitoring aanzetten. Die laatste feature biedt een eenvoudig overzicht van processorbelasting, netwerkverkeer en disk I/O. Om veilig met je servers te kunnen communiceren, genereer je een Key Pair. Daarmee is via ssh op virtuele machines in te loggen. Op die manier krijg je als beheerder een cryptografisch versleutelde ingang op je serversysteem.

Naast de beveiliging van de servers zelf met behulp van een firewall, zijn de virtuele servers ook op netwerkniveau te beschermen. Dat gebeurt door Instances in aparte groepen (Security Groups) te plaatsen. Elk daarvan heeft weer zijn eigen firewallinstellingen (vergelijkbaar met een screening router). Op die manier kun je er bijvoorbeeld voor zorgen dat de databaseservers wel door de webservers kunnen worden benaderd, maar niet door de buitenwereld. Zo wordt bijvoorbeeld een getrapte LAMP-infrastructuur opgebouwd (Linux met Apache, MySQL en PHP/Perl/Python).

Virtuele machines

Als laatste krijg je van Amazon nog een overzicht van de gekozen instellingen en dan is het alleen nog een kwestie van de startknop indrukken. Binnen een paar minuten zijn je virtuele machines online. En wie onderweg CloudWatch Monitoring heeft aangezet, kan zijn servers nu in wat simpele grafieken volgen.

Amazon geeft publieke webadressen terug, zodat de buitenwereld je servers kan bezoeken, maar stop je een virtuele machine, dan ben je zijn ip-adres kwijt. Om dat te voorkomen, kun je Elastic IP-adressen aanvragen en die aan een Instance koppelen. Als het later nodig is om een andere server in de lucht te brengen, dan kun je datzelfde adres weer aan de nieuwe Instance toewijzen. Zo kun je die ip-adressen in je eigen DNS-server opnemen. Amazon heeft zelfs een formulier om de reverse DNS in stellen. Maar gebruik je ze niet, dan kost elk ip-adres wel een dollarcent per uur.

Heb je zo veel verkeer dat een enkele webserver niet meer voldoende is of wil je een redundante infrastructuur opzetten, dan gebruik je de Elastic Load Balancer. Net als de Instances zelf zijn deze heel gemakkelijk in een wizard aan te maken.

Opslag en capaciteit

Permanente opslag

Voor wie verder geen statusinformatie op zijn virtuele machine bijhoudt, hoeft het bestandssysteem niet te worden bewaard bij het afsluiten van een Instance. Verander of bewaar je gegevens op disk, dan moet je partitie wel worden bewaard. Amazon biedt daarvoor de Elastic Block Storage. Die wordt gesaved en weer gemount als een AMI opnieuw wordt gestart. Gebruik je geen EBS, dan staat het bestandssysteem in de local instance store en die gaat verloren zodra een Instance wordt uitgezet. Een alternatief is om data op te slaan in S3, een andere clouddienst van Amazon, die ook wordt gebruikt om de AMI's zelf in op te slaan.

Je kunt ook snapshots van een EBS-partitie maken, zelfs terwijl de virtuele machine loopt, maar het is beter om te unmounten, zodat ook de caches van applicaties en besturingssysteem worden bewaard. Gaat het om een root device, dan kun je het beste een shutdown geven. Die snapshots zijn weer terug te halen door ze naar EBS te kopiëren, maar ze kunnen ook tussen gebruikers onderling worden uitgewisseld.

Capaciteit reserveren

Naast de gewone (On-Demand) Instances zijn er ook Reserved Instances. Deze worden op dezelfde manier geconfigureerd, maar nog niet daadwerkelijk gestart. Ze kunnen voor een of drie jaar worden ingekocht en draaien dan tegen een gereduceerd tarief. Op die manier kan Amazon hardware inkopen en inplannen voor gereserveerde, en deels betaalde, capaciteit. Omdat Microsoft in de tussentijd de prijzen kan verhogen, kan Amazon de kosten voor Windows Instances echter niet voor de gereserveerde periode garanderen.

Tenslotte zijn er nog de Spot Instances. Daarbij kun je bieden op beschikbare capaciteit en wordt jouw Instance gedraaid zolang je bod het hoogste is. Deze manier van werken is vooral interessant voor niet-interactieve batchklussen. Hoe meer de gebruiker betaalt, des te eerder het werk is gedaan.

Om de controle over zijn resources te houden, heeft Amazon het aantal On-Demand Instances tot maximaal twintig per regio beperkt. Het aantal Spot Instances is maximaal 100. Er zijn wel formulieren om meer Instances aan te vragen.

Na de kennismaking

Betalen voor Instances gaat per uur. Een gebruiker betaalt dus niets zolang hij geen virtuele servers heeft draaien. Om een idee te geven: de prijs voor een standaard Linux-machine ligt tussen de twee en zeventig dollarcent per uur. De prijzen voor Windows zijn gemiddeld anderhalf keer zo hoog.

Het dataverkeer binnen een Availability Zone is gratis. Verkeer met de buitenwereld en andere Availability Zones wordt in rekening gebracht. Dat kost ongeveer tien dollarcent per gigabyte voor zowel inkomend als uitgaand verkeer.

Het gebruik van EBS kost tien dollarcent per Gigabyte per maand. Een Load Balancer kost drie cent per uur en CloudWatch Monitoring kost anderhalve cent per Instance per uur.

Alles bij elkaar gaat het toch om een behoorlijk ingewikkeld prijsmodel. Dat maakt vergelijken lastig. Volgens analisten is het voor systemen die je continu gebruikt goedkoper om zelf te kopen. Zij verwachten dat dit soort clouddiensten vooral door grote organisaties en start-ups zullen worden ingezet. Die eerste doen dat als reservecapaciteit en voor (tijdelijke) projecten, die tweede vanwege de schaalbaarheid en omdat ze dan geen eigen investering in hardware hoeven te doen.

Even een snel sommetje voor wie overweegt zijn eigen serversysteem door een virtuele machine in de cloud te vervangen. Dertig dollarcent per uur is meer dan 2500 dollar per jaar. Uitgaand van een afschrijvingstermijn van drie jaar kan van dat geld een mooie server worden gekocht en gehost.

Automatisch beheer

De interface voor EC2 is drieledig. Alles is via de webinterface te bedienen. Dat zullen de meeste gebruikers ook zo doen, maar wie de uitrol en het beheer van virtuele servers wil automatiseren doet dat via de Web Services API of door de CLI-commando's in zijn scripts te integreren. Er zijn ook interfaces voor PHP, Ruby, Java en Windows.

Juist voor wie snel wil kunnen opschalen of al veel systemen te beheren heeft, verdient automatisering de voorkeur. Op dit moment worden de automatische uitrol en het beheer op hybride cloudinfrastructuren in de bestaande beheeromgevingen van de grote leveranciers ingebouwd. Voorbeeld daarvan is Redwood, een uitbreiding op de VMware-beheerstack, waarbij externe clouds met de interne gevirtualiseerde infrastructuur kunnen worden geïntegreerd. De software is nu in bèta en verschijnt in dit najaar. Amazon zelf biedt Auto Scaling als onderdeel van CloudWatch Monitoring.

Getting Started

Een eerste kennismaking met EC2 op basis van de Getting Started Guide is prima te doen. Daarna kun je verder met de User Guide. Over het algemeen zijn Amazons interfaces behoorlijk uitgebreid, maar goed gedocumenteerd. Wie bekend is met de virtualisatie-managementinterface van bijvoorbeeld VMware of Red Hat, zal geen enkele moeite hebben met het doorgronden van Amazons Management Console. Alles is heel intuïtief in de bediening.

Over de prijzen van Amazon zijn we minder enthousiast. Gaat het om een tijdelijk project of heb je simpelweg het kapitaal niet om eigen systemen aan te schaffen, dan is EC2 een prima optie. Gaat het om permanente servers en kun je die ook betalen, dan is het beter om eigen systemen te kopen en die bij een goede colocation-provider onder te brengen.

Reacties (43)

[Packetloss]

Voor hen die op zoek zijn naar (recente) Debian en Ubuntu images, is deze een hele fijne: http://alestic.com/ . Ik werk er al geruime tijd mee, deze website komt telkens heel snel met de nieuwste images aan.
Het enige dat je hoeft te doen is de regio te kiezen en dan het AMI ID te gebruiken in Amazon EC2 om een server (instance) te starten.

Deze uitleg is erg duidelijk! Wat ik wel mis, is de mogelijkheid van EBS boot images. Ik ben begonnen met de S3 based images, maar de EBS images vind ik wel fijner. Veel gemakkelijker om een backup (AMI) van te maken. Alleen je instance ff stoppen (niet shutdown / terminate) en dan via de AWS Management Console kan je met de muis een AMI maken. Geen gedoe met Java en scriptjes.

[Yggdrasil]

Dat zijn inderdaad erg goede AMI's. Ik maak er al jaren dankbaar gebruik van.

Sinds een jaar of zo is Canonical, de commerciële sponsor van Ubuntu, actief bezig met cloud-computing. Zij maken dan ook inmiddels een deel van de images die op alestic.com gepubliceerd worden.

AMIs listed as “Canonical” are published by Canonical, the commercial sponsor of Ubuntu. AMIs listed as “Alestic” are published by Eric Hammond.

[merlijn85]

Het grote voordeel van deze clouds wordt niet belicht in dit artikel: Cloud Bursting.

Vaak is voor grotere omgevingen het niet voordelig om alles bij Amazon (of VMware die dit ook aanbiedt) onder te brengen, maar dan hang je een aantal servers of racks op met je eigen virtualisatie platform - waarvan de kosten vele malen lager liggen.

Wanneer er dan problemen zijn met bijvoorbeeld load of hardware, kan er besloten worden om complete VMs live te bursten naar de gigantische clouds. Dit kan zelfs voordelig zijn om te koppelen aan de uurtarieven van Amazon, waardoor je via technieken als Dynamic Power Management een deel van je eigen racks van de stroom kan halen omdat het goedkoper is in andere landen.

Dit kan naar Amazon o.a. met het Eucalyptus platform waarop de Ubuntu cloud services zijn gebouwd (VMware ESXi kan dit ook, maar alleen naar de eigen clouds). Helaas laat Eucalyptus nog wat zaken te wensen over en is het qua flexibiliteit nogal onhandig - het is bijvoorbeeld niet mogelijk om met namen te verwijzen naar de verschillende instances/kernels/templates.

Persoonlijk ben ik een fan van het OpenQRM platform, wat geheel GPL is en ook direct kan bursten naar EC2. Ook is het management veel makkelijker en zorgt het voor directe integratie met veel nuttige tools zoals: PXE boot voor je datacenter, Puppet, Nagios, Collectd en nog vele anderen.

[Sander]

Waar velen (inclusief schrijver van het artikel) aan voorbij gaan is dat de kosten die gemoeid zijn met hardware vele malen hoger zijn dan hier geschetst. Het houdt namelijk niet op bij het bestellen van een stukje ijzer voor 1000e. Denk eens aan:
- Support op hardware
- Uren voor uitzoeken, installeren, ophangen in datacenter
- Reiskilometers/Uren bij storingen
etc etc.

Om met gekochte hardware dezelfde beschikbaarheid te kunnen bieden als die Amazon biedt, dan zul je eigenlijk al dingen redundant moeten maken etc. De kosten lopen dan nog harder op.

Uren zijn voor een hobbyist misschien verwaarloosbaar, maar op moment dat je zakelijk aan de slag gaat zijn de personeelskosten een veel groter deel. Op het moment dat je dan een kleine omgeving draait kan het al snel uit om dat onder te brengen in dit soort clouds.

Nog afgezien van de mogelijkheid om zeer snel te kunnen schalen zonder directe investeringen.

[Reactie gewijzigd door Sander op 22 juli 2024 15:59]

[Anoniem: 36033]

Als ik het goed begrijp heb je een soort van VMware omgeving op afstand, met allerlei "elastic" uitbreidingen.
Wel mooi dat vendor onafhankelijk bent, maar hierdoor ben je wel zelf verantwoordelijk voor je OS patches.
Ook is die SLA nog niet echt volwassen; 10% cashback op het uurbedrag, dat staat in geen verhouding met de mogelijk geleden schade op een willekeurig kritiek systeem, toch?

[chronoz]

Je moet je beseffen dat klanten veel te snel zeuren dat ze zoveel schade lijden door downtime op een server, terwijl ze vaak €30 per jaar betalen.

Indien je echt belangrijke sites hebt, dan dien je ook een echte redundant omgeving te draaien in een topdatacentrum en dat kost tienduizenden euro's.

99,95% is een PRACHTIGE uptime-garantie en 10% is dan ook uitstekend. Indien je echt meer dan 99,95% nodig hebt... en daarmee echt een grote hoeveelheid schade lijdt, dan moet je daar ook in investeren.

[Cergorach]

0,05% is iets meer dan 4 uur op jaar basis, dat kan ook nog eens in het weekend of midden in de nacht vallen.

Ik weet ook niet wat men hier als 'kritiek' rekent, maar je gaat hier niet je bank/stroom/water servers op draaien. 0,05% beïnvloed dan ook maar 0,05% van je omzet, dat kan oplopen tot 0,19% als die downtime tijdens kantoor uren valt en het systeem alleen tijdens kantoor uren draait (9:00-18:00).

[tweakerbee]

Probleem is niet de uptime garantie, maar de consequentie als ze het niet halen. Je krijgt dan 10% van je geld terug. Oftewel 250 dollar op jaarbasis per instance van 30ct. En dat is vrijwel niets.

[Reactie gewijzigd door tweakerbee op 22 juli 2024 15:59]

[Cergorach]

Als ze het niet halen bij hoeveel niet gehaald? Als ze er een half jaar uitleggen dan is 10% van het jaar bedrag erg weinig, als ze er een uurtje extra uitleggen op jaar basis dan is 10% niet verkeerd. Omdat ze niet de uptime niet halen betekent niet direct dat je er schade door krijgt. Komt natuurlijk weer bij dat als je grotere boete clausules wil (en die dan ook rendabel zijn) dan zal je daarvoor moeten betalen, maar dat zal dan niet zo een probleem zijn aangezien je dan al een enorme omzet moet draaien.

Ik heb bij een bank gewerkt en daar koste een uurtje downtime een heleboel geld (denk een jaar salaris) en daar haalden we voor de meeste systemen niet eens 99% uptime en dat was alleen gerekend gedurende kantoor tijden. Die systemen met personeel koste een hele hoop meer dan bij S3.

Hou er ook rekening mee dat het over het algemeen per instance geld, dus als je meerdere instances draaid (wat wel zo handig is) dan is er alle kans dat niet alle instances niet werken of niet bereikbaar zijn. Dus zou het je niets/weinig hoeven te kosten qua winst/omzet.

[OverSoft]

99,95% prachtig? Ik denk dat je niet echt bekend bent met datacentra...
Die rekenen op z'n minst met 3x9 of hoger, wat wil zeggen 3 negens achter de komma (99,999% dus)
Als ik een servertje ergens wil hangen, draai ik HEEL snel om bij een 99,95% uptime garantie! 4 uur per jaar down-time is echt schrikbarend hoog!

[eborn]

Het verschilt wel of je en SLA van een datacentrum pakt of van een applicatie hoster. Het 'up' houden van 'alleen' de stroom en de verbinding is alweer een stap minder dan daadwerkelijk een machine beschikbaar houden. Om nog niet eens te spreken van een applicatie die weer op die machine draait.

WIl je op alle drie die onderdelen een SLA met een aantal 9's achter de komma, dan komt er in prijs waarschijnlijk een aantal 9's voor de komma bij

[Gwaihir]

En is het de echte uptime het jaar rond, of de uptime voor zoverre geen gepland onderhoud is afgekondigd? Vaak is die 99,9x die tweede en dat maakt ook een wereld van verschil.

[Dreamvoid]

Het is mooi vendor onafhankelijk, maar lost het daardoor niet maar de helft van het probleem op? De grootste reden waarom ik services (file server, web server, etc) in de cloud zou willen hangen is omdat iemand anders dat beter/veiliger/goedkoper/efficienter/etc kan dan ik zelf. Als ik zelf vervolgens weer mijn eigen server moet beheren heb ik uiteindelijk alleen de hardware-kant aan iemand uitbesteed, en de software/beheer kant is toch waar de meeste tijd in gaat zitten (en waar de meeste problemen vandaan komen).

[Reactie gewijzigd door Dreamvoid op 22 juli 2024 15:59]

[eborn]

Maar ook weer het onderdeel waar een externe partij vaak weer minder ervaring mee heeft of waar je meer als een nummer wordt gezien. Het bijhouden van updates is vaak geen problem, maar het controleren of die updates ook goed samenwerken met je applicaties, is een hele andere vraag.

Er zijn maar heel weinig partijen die zulke diensten in bulk willen aanbieden, zonder daarbij te zeggen: als er iets kapot gaat, ligt het niet aan ons. En partijen die dat wel leveren zijn duur. Wat logisch is.

[swtimmer]

Daarnaast zou je in zo'n geval kunnen zorgen dat je op ieder Amazon netwerk een backup hebt draaien. De kans dat alle 4/5 lokaties tegelijk plat gaan is namelijk nog een stuk lager!

[maniak]

Ik geloof wel dat de prijzen zullen dalen als het meer gebruikt gaat worden. Hopelijk komt er ooit een tijd dat mensen voor prive gebruik een server kunnen hosten dat niet al te veel kost

[Pogostokje]

TIP: Voor prive gebruik is het voordeliger om een VPS te nemen. Veel goedkoper en dezelfde features als een dedicated server. Als je bij een goeie provider zit merk je totaal niks van de virtualisatie bij normaal gebruik. Je hebt geen verdere onderhoudskosten.
Voor gewoon een paar familie websites hosten met wat e-mail heb je geen super grote server nodig en kun je voor 13 euro per maand ofzo al klaar zijn.

[Reactie gewijzigd door Pogostokje op 22 juli 2024 15:59]

[OxiMoron]

True. Hoewel Amazon nu Micro instances heeft.

Een reserved instance hiervan kost voor een jaar $54, met dan $0.01 per uur.
Wat ongeveer neerkomt op $11.78 per maand + bandwidth.

Maar qua performance is het absoluut niet geweldig.

[CMG]

Nou, als je een beetje oplet met LeaseWeb aanbiedingen, kan je voor minder dan 50 euro per maand incl. btw al een dedicated servertje daar hebben draaien... Dat zijn toch niet echt prijzen waarvoor je het hoeft te laten?

[chronoz]

Inderdaad, ze bieden het al voor €39,95 aan. Stuur ze een e-mail of ze de set-up fee kunnen waiven en vaak doen ze dat dan ook.

Installeer eventueel VMWare ESXi of andere virtualizatie zonder de VM's automatisch op te laten starten en je hebt genoeg aan de APC remote reboot die je erbij krijgt. Het is bij Leaseweb namelijk erg duur om hun personeel in te schakelen. Je bent al snel een paar honderd euro kwijt bij simpele werkzaamheden.

[wootah]

Dit ziet er erg interessant uit.
Als een consument heb ik er eigenlijk nooit naar gekeken omdat het er vrij vreemd uitzag voor mij.
Maar nu ik hier zo de uitleg van tweakers heb gelezen lijkt zoiets me wel een vet idee!

Als je verstand hebt van linux servers, zou het dan rendabel zijn om een kleine website te hosten bij amazon?
Je heb natuurlijk op die manier net even wat meer vrijheid dan een normale web-host

[SPee]

Als 'hobby-ist' zou ik eerst thuis mijn servertje draaien. Pas wanneer dat niet voldoende is, zou ik overstappen naar een hosted machine.
Of dat op de Amazon-cloud of (kleine) hostingbedrijf is, hangt af van de wensen aan de server.

-Het hosten van een simpele php website kan bij elke cheapo hoster; amazon is dan te duur.
-Het hosten van een beginnende site ala tweakers; amazon is een optie.
-Het hosten van tweakers.net bij amazon; ...
mijn antwoord/gok: eigen servers laten hosten zijn goedkoper.

[Yggdrasil]

Je analyse klopt wel aardig. Op kosten is Amazon meestal de verliezer. De nieuwe Micro instances zijn vrij goedkoop en voldoende voor een persoonlijke LAMP-server, maar ze kosten $0.02/hr, dus ongeveer $14,40/mnd. Een vergelijkbare VPS heb je echter voor ongeveer €10/mnd, dus is al goedkoper. Simpele shared PHP-hosting kan nog veel goedkoper, maar dan lever je die vrijheid in.

De voordelen zitten hem dan ook niet in prijs, maar flexibiliteit. Die VPS betaal je meestal per maand, soms zelfs met een minimale duur van een jaar. Amazon EC2 wordt per uur betaald en is dus handig als je veel experimenteert. De flexibele manier waarop je met IP adressen en storage kunt omgaan kan waardevol zijn. Daarnaast is het feit dat je alles via de API's kunt automatiseren handig. Amazon kan dus alsnog interessant zijn voor privégebruik door ervaren IT-ers, ondanks de iets hogere kosten. De minder veeleisende hobbyist kan elders goedkoper terecht.

[Cergorach]

Als hobby-ist zou ik beginnen met een goedkoop hosted server, regelen ze alle linux zooi waar je geen verstand van heb en kan je direct aan de slag met de website te hosten. Een hoop hosters bieden hun normale hosting pakketten ook aan als deel van een grote cluster (dus een soort van mini cloud).

Ik zie Amazon pas goedkoop zijn als een hosting pakket niet meer voldoende is (geen redundancy vs. niet voldoende rekenkracht/geheugen), de startup kosten niet op te brengen zijn of je een hele flexible website nodig heb (bepaalde tijden veel reken kracht nodig, maar verre van altijd).

[OxiMoron]

We gebruiken amazon nu al meer dan een jaar voor al onze hosting. Ideaal.

Klant komt in het nieuws en website verwacht veel traffic, in no time heb je extra servers achter de Elastic Load Balancer hangen.

[driaker]

Je kunt zelfs automatisch servers bijschakelen als de CPU load boven bijvoorbeeld 70% komt en weer automatisch verwijderen als de load onder bijvoorbeeld 30% komt. http://aws.amazon.com/autoscaling/

[CMG]

Omdat zij er tussen zitten voor hun klanten lijkt me dat, tenzei je dat in detail kan terugvinden niet wenselijk is omdat ze anders moeite hebben om dit soort dingen door te belasten aan hun klanten.

[OxiMoron]

Nee hoor, het is alleen dat om autoscaling te kunnen gebruiken je ook auto deployment etc nodig hebt. En aangezien je van 1 server naar meerdere gaat en wel graag wilt dat ze dezelfde database en file storage blijven gebruiken doen we dit met de hand

Daarnaast is het wel zo dat je bij amazon de kosten op 1 grote hoop krijgt en het dan dus lastig te zien zou zijn welke klant voor welk deel van de auto scaling moet betalen ;-)

[Reactie gewijzigd door OxiMoron op 22 juli 2024 15:59]

[swtimmer]

Binnen het 1000 Genomes Project is ook gekeken of Amazon gebruikt zou kunnen worden om zodoende onderzoeks labs rekentijd met de laatste data te geven. Het voordeel zou zijn dat men niet eerst je mirror hoeft leeg te trekken voordat ze aan het rekenen kunnen gaan.

Helaas bleek uit proeven dat het uploaden van alle 1kg data meer dan een maand zou duren (waarmee de data direct alweer oud zou zijn). Helaas is het dus nog geen oplossing voor echt grote data projecten. Maar wie weet in de toekomst!

[Mennootje]

Amazon heeft daar al een oplossing voor: http://aws.amazon.com/importexport/

Je stuurt simpelweg je fysieke medium op en de data wordt op locatie naar S3 overgezet.

[swtimmer]

Dit hebben ze gedaan voor de pilot data set die dus al wel via AWS beschikbaar is (iets van 7TB). Het grote probleem is dat er regelmatig aanpassingen worden gedaan aan de data (het is allemaal nog work-in-progress). Het liefst zouden ze dus hetzelfde doen als wat met de US wordt gedaan, gewoon over internet syncen.

De publieke datasets staan trouwens hier:
http://aws.amazon.com/publicdatasets/

[Bl@ckbird]

WAN optimalisatie specialist Riverbed heeft een appliance in de cloud van Amazon draaien. (voorlopig in Beta) Ik verwacht dat dit binnenkort commercieel verkrijgbaar wordt.

[lvmeijer]

Ik gebruik ook Amazon EC2, maar sinds gisteren heb ik ook een virtual machine draaien bij rackspacecloud.com. Moet zeggen dat het me beter bevalt. Veel betere IO performance, dedicated RAM, ook Win2008 R2 en ook 64-bits images voor een betaalbare prijs.

[Pogostokje]

Dit kan ik bevestigen.
Ik ben met bijna al mijn servers afgestapt van Amazon naar rackspacecloud. Dat laatste is echt sneller, iets goedkoper en als geheel wat meer ingericht op "permanente" servers.
Ik kan niet wachten tot ze binnenkort hun datacentrum in UK openen. De latency naar hun huidige datacentra in de US ligt tussen de 80ms en 130ms. Voor mij geen probleem, maar misschien voor anderen wel.

Wat ze niet hebben zijn software firewalls en loadbalancers. Wel kun je on demand je servers scalen (op en neer) en ze hebben net als Amazon ook een cloud file storage die je kunt gebruiken indien nodig. Je kunt daar ook je server images in stoppen om die wanneer je wilt tot een werkende server om te toveren, of juist een server tijdelijk offline te halen en op te slaan. Hun interface is erg gelikt en werkt uitstekend.

Ander belangrijk punt voor mij was dat ze, in tegenstelling tot Amazon, een support afdeling hebben die je kunt mailen, bellen of chatten 24x7.

[lvmeijer]

Ik wacht momenteel ook op de opening van het UK DC. Dan verplaats ik alles van colo en EC2 naar rackspace.

Ander groot voordeel van rackspace is dat je twee NIC's krijgt. Eén private en één public zonder NAT. Bij EC2 zijn je netwerkadapters ge-NAT en had ik moeite met het werken krijgen van VPN software zoals Kerio Control VPN of Hamachi.

[DrClaw]

de interface is wel gelikt hoor. en het fijne is, dat amazon al zoveel verschillende soorten cloud diensten aanbiedt .. storage, failover, backup, enzovoort.

ikzelf heb ook machientjes in 'the cloud' draaien, maar dan bij linode.com, een bedrijf dat de afgelopen jaren flink gegroeid is. van origine een amerikaans bedrijf (4 datacenters verspreid over dat land) is er recentelijk eentje bijgekomen in engeland. en de prijzen van linode zijn een stuk goedkoper.

de nederlandse variant van linode.com is trouwens xlshosting; die bieden ook een prima service, en hun kennis is zeer goed te noemen. maar je betaalt wel nederlandse prijzen. je kunt dan wel weer in het nederlands met hen praten =)

ok, genoeg reclame hahaha.

[Chilly_Willy]

Ik gebruik ook al jaar linode.com voor een aantal vps, echt super. Sinds ze in Londen zitten is latency ook geen probleem meer (16-20ms). En het mooie is dat je gewoon on Dollars blijft betalen wat nog steeds aardig scheelt.