Versioning, MFA Delete en replicatie

Om een oudere versie van een object met versioning te herstellen, heb je twee opties. Optie 1: kopieer de oudere versie-ID terug naar dezelfde sleutel — hierdoor wordt een nieuwe versie gemaakt die een kopie is van de oudere inhoud en wordt die versie de huidige. Optie 2: verwijder de huidige versie of verwijdermarkering om de vorige versie als huidige zichtbaar te maken. Wanneer je in de console een object in een versiebeheerste bucket 'verwijdert' zonder een versie-ID op te geven, voegt S3 een verwijdermarkering toe — voor verzoeken zonder versioning lijkt het object verwijderd, maar alle versies bestaan nog.

MFA Delete voegt een tweede beschermingslaag toe voor buckets met versioning. Wanneer dit is ingeschakeld, moet je geldige MFA-referenties opgeven in het API-verzoek om een specifieke versie permanent te verwijderen of de versioning-status te wijzigen (ingeschakeld → opgeschort). Dit beschermt tegen: een aanvaller die je AWS-referenties heeft buitgemaakt en kritieke versies permanent verwijdert; het per ongeluk of geautomatiseerd verwijderen van vastgezette objectversies; en interne dreigingen die audittrails proberen te vernietigen. MFA Delete kan alleen door de rootgebruiker via de CLI worden in- en uitgeschakeld.

S3 Object Lock dwingt een WORM-model (write once, read many) af voor naleving van regelgeving. Objecten die met Object Lock zijn vergrendeld, kunnen gedurende een opgegeven bewaartermijn niet worden verwijderd of overschreven — zelfs niet door de rootgebruiker van het account. Er zijn twee modi: Governance mode (gebruikers met speciale machtigingen kunnen de vergrendeling omzeilen of verwijderen) en Compliance mode (niemand, zelfs AWS niet, kan het object tijdens de bewaartermijn verwijderen — de sterkste bescherming). Object Lock moet worden ingeschakeld wanneer de bucket wordt gemaakt en vereist versioning.

Cross-Region Replication (CRR) repliceert automatisch nieuwe objecten en updates van een bronbucket in één regio naar een bestemmingsbucket in een andere regio. Gebruiksscenario's zijn: naleving (een kopie van gegevens in een specifiek land bewaren), herstel na calamiteiten (de RPO voor kritieke gegevens verlagen door een kopie in een tweede regio te bewaren) en latentieverlaging (objecten aanbieden vanuit de regio die het dichtst bij gebruikers ligt). Voor CRR moet versioning op zowel de bron- als de bestemmingsbucket zijn ingeschakeld en is een IAM-rol met de vereiste replicatiemachtigingen nodig.

Same-Region Replication (SRR) repliceert objecten binnen dezelfde regio. Gebruiksscenario's zijn: logaggregatie (logs uit meerdere bronbuckets naar één centrale bucket repliceren), synchronisatie van testomgevingen (een kopie van productiegegevens bewaren in een ontwikkelbucket binnen dezelfde regio) en naleving van gegevenssoevereiniteit binnen één land met meerdere AWS-AZ's. Net als CRR vereist SRR versioning op beide buckets en een IAM-rol. Alleen nieuwe objecten die na het inschakelen van replicatie worden gemaakt, worden automatisch gerepliceerd — gebruik S3 Batch Replication om bestaande objecten te repliceren.

S3-replicatie repliceert wel: nieuwe objecten, metagegevens, tags, ACL's en de versleutelingsstatus. Standaard repliceert replicatie niet: objecten die al bestonden voordat replicatie werd ingeschakeld (gebruik daarvoor S3 Batch Replication), verwijdermarkeringen (tenzij je Delete Marker Replication inschakelt), objecten in Glacier (niet repliceerbaar — herstel ze eerst) en gerepliceerde objecten (geen trapsgewijze replicatie tussen drie buckets). Inzicht in deze grenzen is belangrijk bij het ontwerpen van volledige strategieën voor herstel na calamiteiten, waarbij ook historische gegevens en verwijdergebeurtenissen moeten worden gerepliceerd.

Replication Time Control (RTC) is een optionele uitbreiding voor CRR die een Service Level Agreement biedt: 99,99% van de objecten wordt binnen 15 minuten gerepliceerd, met replicatiestatistieken en meldingen in CloudWatch. Zonder RTC biedt replicatie geen tijdsgarantie — de meeste objecten worden snel gerepliceerd, maar uitzonderingen kunnen uren duren. RTC is essentieel wanneer je vereisten voor herstel na calamiteiten of naleving een maximale Recovery Point Objective (RPO) voor gegevens in S3 voorschrijven. Naast de standaardkosten voor gegevensoverdracht bij replicatie brengt RTC kosten per GB voor replicatie met zich mee.

Als je versiebeheer inschakelt, stijgen de opslagkosten omdat S3 elke versie van elk object bewaart totdat je deze expliciet verwijdert. Een bestand van 100 MB dat 10 keer wordt overschreven, gebruikt daardoor 1.000 MB opslagruimte. Beperk dit met levenscyclusregels die niet-actuele versies na een ingesteld aantal dagen automatisch laten verlopen (bijvoorbeeld: niet-actuele versies die ouder zijn dan 30 dagen verwijderen), of verplaats niet-actuele versies naar goedkopere opslagklassen zoals Glacier. Combineer versiebeheer in productie altijd met levenscyclusregels om de opslagkosten te beheersen.

S3-versiebeheer in combinatie met Object Lock (Compliance-modus) biedt sterke bescherming tegen ransomware. Als een aanvaller je objecten versleutelt of verwijdert, zorgt versiebeheer ervoor dat eerdere versies behouden blijven (tenzij de aanvaller ze permanent verwijdert — daarom voorkomt Object Lock permanente verwijdering tijdens de bewaartermijn). Schakel voor maximale bescherming versiebeheer en MFA Delete in, pas Object Lock in Compliance-modus toe op kritieke gegevens en repliceer naar een tweede Region met afzonderlijke IAM-inloggegevens. Zo voorkom je dat één gecompromitteerd account alle kopieën kan vernietigen.

In deze les heb je geleerd dat versiebeheer alle versies van elk object bewaart en beschermt tegen onbedoelde verwijdering, dat MFA Delete en Object Lock extra onveranderlijkheid bieden voor compliance en bescherming tegen ransomware en dat CRR en SRR objecten naar andere buckets repliceren om aan vereisten voor noodherstel en compliance te voldoen. Hierna verkennen we S3-opslagklassen en levenscyclusbeleid voor kostenoptimalisatie.