EC2-lagring: Instance Store jämfört med EBS

Amazon EBS-volymer är nätverksansluten lagring som finns kvar oberoende av EC2-instansens livscykel. En EBS-volym finns i en specifik Availability Zone och kan vara ansluten till en EC2-instans åt gången (med undantag för io1/io2 multi-attach). När Ni stoppar och startar om en instans behåller EBS-volymen all data. Ni kan koppla från den från en instans och ansluta den till en annan i samma AZ, eller skapa en snapshot för att kopiera den till en annan AZ eller region.

AWS erbjuder fyra EBS-volymtyper. gp3 (General Purpose SSD): basnivå på 3 000 IOPS och 125 MB/s, som kan konfigureras oberoende upp till 16 000 IOPS och 1 000 MB/s – standardvalet och det mest kostnadseffektiva alternativet för de flesta arbetsbelastningar. gp2: äldre General Purpose SSD där IOPS ökar med storleken (3 IOPS/GB, högst 16 000) – fasas ut till förmån för gp3. io2 Block Express: Provisioned IOPS SSD med upp till 256 000 IOPS och 4 000 MB/s – för I/O-intensiva databaser som SAP HANA eller Oracle. io1: äldre Provisioned IOPS SSD.

De två HDD-baserade EBS-typerna är optimerade för genomströmning, inte IOPS. st1 (Throughput Optimised HDD): basnivå på 40 MB/s/TB, med burst upp till 250 MB/s/TB – idealisk för stordata, loggbearbetning och datalager med stora sekventiella läsningar. sc1 (Cold HDD): basnivå på 12 MB/s/TB, med burst upp till 80 MB/s/TB – det billigaste EBS-alternativet för sekventiella data som sällan används. HDD-volymer kan inte användas som startvolymer (root-enheter). Välj st1 eller sc1 endast när genomströmning är viktigare än IOPS och åtkomstmönstret består av stora sekventiella läsningar och skrivningar.

EBS-ögonblicksbilder är säkerhetskopior av en volym från en viss tidpunkt, som lagras med hög beständighet i Amazon S3 (även om du kommer åt dem via EC2 API och inte direkt via S3). Ögonblicksbilder är inkrementella: den första ögonblicksbilden innehåller hela volymen och efterföljande ögonblicksbilder innehåller endast de block som har ändrats sedan den senaste ögonblicksbilden, vilket minskar lagringskostnaden. Du kan skapa en ny EBS-volym från valfri ögonblicksbild i valfri AZ inom samma Region eller kopiera ögonblicksbilden till en annan Region för katastrofåterställning mellan regioner.

EBS-volymer och ögonblicksbilder kan krypteras med AWS KMS keys. Krypteringen är transparent för instansen – data krypteras under överföringen mellan instansen och volymen samt när den lagras. Du kan aktivera account-level default encryption så att varje ny EBS-volym som skapas i kontot krypteras automatiskt utan konfiguration per volym. För att kryptera en okrypterad volym måste du skapa en ögonblicksbild, skapa en krypterad kopia av ögonblicksbilden och därefter skapa en ny volym från den krypterade ögonblicksbilden.

EBS Multi-Attach gör det möjligt att samtidigt ansluta en io1- eller io2-volym till upp till 16 EC2-instanser i samma Availability Zone. Alla anslutna instanser har fullständig läs- och skrivåtkomst. Detta används för klustrade Linux-applikationer (som Oracle RAC eller Teradata) som hanterar samtidighet på applikationsnivå med hjälp av ett klustermedvetet filsystem. Multi-Attach ersätter inte EFS för delade filsystem – det är specifikt avsett för klustrad blockåtkomst med samordning som hanteras av applikationen.

Viktiga beslutsfaktorer: Behövs beständighet? → Använd EBS. Kan data återskapas eller replikeras? → Instance Store är ett godtagbart alternativ och ger högre prestanda. Databas med kritiska data? → Använd alltid EBS (med ögonblicksbilder och kryptering). Tillfälligt arbetsutrymme för ML-träning eller sorteringsåtgärder? → Instance Store ger maximal genomströmning utan extra kostnad. På provet förekommer ofta scenarier där du måste avgöra om temporär eller beständig lagring är lämplig för en viss arbetsbelastning.

EBS-optimerade instanser tillhandahåller dedikerad nätverksbandbredd mellan EC2-instansen och EBS, separat från instansens allmänna nätverksbandbredd. Detta förhindrar nätverkskonkurrens mellan applikationstrafik och lagrings-I/O. De flesta instanstyper från nuvarande generationer är EBS-optimerade som standard utan extra kostnad. Äldre instanstyper kan kräva att EBS-optimering aktiveras manuellt (mot en extra timavgift). För databaser med hög I/O bör du alltid bekräfta att instanstypen är EBS-optimerad för att uppnå volymens fullständigt provisionerade IOPS.

Amazon Data Lifecycle Manager (DLM) automatiserar skapandet, bevarandet och borttagningen av EBS-ögonblicksbilder och AMI:er. Du definierar livscykelprinciper som anger vilka volymer som ska säkerhetskopieras (efter tagg), hur ofta ögonblicksbilder ska skapas (var 1, 2, 3, 4, 6, 8 eller 12:e timme eller dagligen) och hur många ögonblicksbilder som ska bevaras. DLM eliminerar behovet av anpassade säkerhetskopieringsskript och integreras med CloudWatch för övervakning av principernas status. För ögonblicksbilder mellan regioner konfigurerar du en kopieringsprincip i samma DLM-definition.

I den här lektionen lärde du dig att: Instance Store erbjuder den högsta lokala I/O-prestandan men är temporär – data går förlorade när instansen stoppas eller avslutas, EBS tillhandahåller beständig nätverksansluten blocklagring med fyra volymtyper som är optimerade för IOPS (gp3, io2) eller genomströmning (st1, sc1), och EBS-ögonblicksbilder möjliggör säkerhetskopiering från en viss tidpunkt, lagrad i S3, som kan användas för återställning mellan AZ:er eller regioner. Härnäst utforskar vi grunderna i S3-objektlagring.