EC2-opslag: Instance Store versus EBS

Amazon EBS-volumes zijn via het netwerk gekoppelde opslag die onafhankelijk van de levenscyclus van de EC2-instance blijft bestaan. Een EBS-volume bevindt zich in een specifieke Availability Zone en kan aan één EC2-instance tegelijk worden gekoppeld (behalve bij io1/io2 multi-attach). Wanneer je een instance stopt en opnieuw start, behoudt het EBS-volume alle gegevens. Je kunt het volume loskoppelen van de ene instance en in dezelfde AZ aan een andere koppelen, of een snapshot maken om het naar een andere AZ of regio te kopiëren.

AWS biedt vier EBS-volumetypen. gp3 (General Purpose SSD): een basislijn van 3.000 IOPS en 125 MB/s, onafhankelijk configureerbaar tot 16.000 IOPS en 1.000 MB/s—de standaardkeuze en voor de meeste werklasten de voordeligste optie. gp2: oudere General Purpose SSD waarbij de IOPS toenemen met de grootte (3 IOPS/GB, maximaal 16.000)—wordt uitgefaseerd ten gunste van gp3. io2 Block Express: SSD met ingerichte IOPS, tot 256.000 IOPS en 4.000 MB/s—voor databases met intensieve I/O, zoals SAP HANA of Oracle. io1: verouderde SSD met ingerichte IOPS.

De twee op HDD gebaseerde EBS-typen zijn geoptimaliseerd voor doorvoer, niet voor IOPS. st1 (Throughput Optimised HDD): een basislijn van 40 MB/s/TB, met pieken tot 250 MB/s/TB—ideaal voor big data, logverwerking en datawarehouses met grote sequentiële leesbewerkingen. sc1 (Cold HDD): een basislijn van 12 MB/s/TB, met pieken tot 80 MB/s/TB—de voordeligste EBS-optie voor sequentiële gegevens die weinig worden geraadpleegd. HDD-volumes kunnen niet als opstartvolumes (hoofdapparaat) worden gebruikt. Kies st1 of sc1 alleen wanneer doorvoer belangrijker is dan IOPS en het patroon voor gegevenstoegang bestaat uit grote sequentiële lees- en schrijfbewerkingen.

EBS-snapshots zijn back-ups van een volume op een bepaald tijdstip die duurzaam worden opgeslagen in Amazon S3 (hoewel je ze benadert via de EC2 API en niet rechtstreeks via S3). Snapshots zijn incrementeel: de eerste snapshot bevat het volledige volume en volgende snapshots registreren alleen de blokken die sinds de vorige snapshot zijn gewijzigd, waardoor de opslagkosten dalen. Je kunt in elke AZ binnen dezelfde Region een nieuw EBS-volume maken vanuit elke snapshot, of de snapshot naar een andere Region kopiëren voor herstel na calamiteiten tussen Regions.

EBS-volumes en -snapshots kunnen worden versleuteld met AWS KMS-sleutels. De versleuteling is transparant voor de instantie: gegevens worden versleuteld tijdens de overdracht tussen de instantie en het volume en wanneer ze in de opslag staan. Je kunt standaardversleuteling op accountniveau inschakelen, zodat elk nieuw EBS-volume in het account automatisch wordt versleuteld zonder configuratie per volume. Als je een niet-versleuteld volume wilt versleutelen, moet je een snapshot maken, een versleutelde kopie van de snapshot maken en vervolgens een nieuw volume maken vanuit de versleutelde snapshot.

Met EBS Multi-Attach kun je een io1- of io2-volume tegelijkertijd koppelen aan maximaal 16 EC2-instanties in dezelfde Availability Zone. Alle gekoppelde instanties hebben volledige lees- en schrijftoegang. Dit wordt gebruikt voor geclusterde Linux-toepassingen, zoals Oracle RAC of Teradata, die gelijktijdige toegang op applicatieniveau beheren met een clusterbewust bestandssysteem. Multi-Attach is geen vervanging voor EFS voor gedeelde bestandssystemen: het is specifiek bedoeld voor geclusterde toegang op blokniveau met coördinatie die door de applicatie wordt beheerd.

Belangrijke criteria voor je keuze: Is persistentie nodig? → Gebruik EBS. Kunnen de gegevens opnieuw worden gemaakt of zijn ze gerepliceerd? → Instance Store is dan geschikt en biedt hogere prestaties. Database met kritieke gegevens? → Gebruik altijd EBS (met snapshots en versleuteling). Tijdelijke werkruimte voor ML-training of sorteerbewerkingen? → Gebruik Instance Store voor maximale doorvoer zonder extra kosten. In het examen krijg je vaak scenario's waarin je moet bepalen of vluchtige of persistente opslag geschikt is voor een bepaalde werklast.

EBS-geoptimaliseerde instanties bieden speciale netwerkbandbreedte tussen de EC2-instantie en EBS, los van de algemene netwerkbandbreedte van de instantie. Hierdoor ontstaat er geen netwerkconcurrentie tussen applicatieverkeer en opslag-I/O. De meeste instancetypen van de huidige generatie zijn standaard EBS-geoptimaliseerd, zonder extra kosten. Voor oudere instancetypen moet je EBS-optimalisatie mogelijk handmatig inschakelen, tegen een extra uurtarief. Controleer bij databases met intensieve I/O altijd of je instancetype EBS-geoptimaliseerd is, zodat je de volledige ingerichte IOPS van je volume kunt benutten.

Amazon Data Lifecycle Manager (DLM) automatiseert het maken, bewaren en verwijderen van EBS-snapshots en AMI's. Je definieert levenscyclusbeleid waarin je opgeeft van welke volumes een back-up moet worden gemaakt (op basis van tags), hoe vaak snapshots moeten worden gemaakt (elke 1, 2, 3, 4, 6, 8 of 12 uur, of dagelijks) en hoeveel snapshots moeten worden bewaard. DLM maakt aangepaste back-upscripts overbodig en kan met CloudWatch worden geïntegreerd om de status van beleid te bewaken. Configureer voor snapshots tussen Regions een kopieerbeleid in dezelfde DLM-definitie.

In deze les heb je geleerd dat Instance Store de hoogste lokale I/O-prestaties biedt, maar vluchtig is: gegevens gaan verloren wanneer je de instantie stopt of beëindigt, dat EBS persistente netwerkgekoppelde blokopslag biedt met vier volumetypen die zijn geoptimaliseerd voor IOPS (gp3, io2) of doorvoer (st1, sc1) en dat EBS-snapshots back-ups op een bepaald tijdstip mogelijk maken die in S3 worden opgeslagen en kunnen worden gebruikt voor herstel tussen AZ's of Regions. Hierna behandelen we de basisprincipes van S3-objectopslag.