Integrity and immutability
Lesson 3 of 4 in Protecting Data at Rest.
Confidentiality asks “who can read this?”. Integrity asks a harder question: “can anyone change or destroy this, and would we know?” The mechanisms that answer it form a ladder from recoverable to genuinely immutable.
Versioning is the floor. With it enabled, overwriting an object creates a new version and deletes place a delete marker rather than removing data, so accidental overwrites and deletions are recoverable. It is not immutability: a principal with s3:DeleteObjectVersion can permanently remove a specific version, so versioning protects against accidents, not against an adversary with sufficient permissions.
MFA delete raises the bar on that gap. When enabled, permanently deleting an object version or changing the bucket’s versioning state requires an MFA code. The constraints are the exam-relevant part: it can only be enabled by the bucket owner’s root user with MFA, it cannot be configured in the console, and those operations must then be performed with root credentials and an MFA code — which makes it genuinely strong and genuinely awkward, and explains why Object Lock is usually the better answer for a retention requirement.
S3 Object Lock is real write-once-read-many. It requires versioning (enabling Object Lock through the API enables versioning automatically), and it protects object versions — not keys — which is why versioning is structural rather than incidental. Two independent instruments: a retention period with a retain-until date, in one of two modes, and a legal hold with no expiry that stays until someone with permission explicitly removes it. An object version can carry a retention period, a legal hold, both, or neither.
The two modes are the distinction the exam tests most reliably. Governance mode protects against ordinary deletion but can be bypassed by a principal holding s3:BypassGovernanceRetention (with the x-amz-bypass-governance-retention: true header) — so it is the right choice for operational safety, and for testing a retention configuration before committing to it. Compliance mode cannot be bypassed by anyone, including the account’s root user: until the retain-until date passes, the version cannot be overwritten or deleted, the retention mode cannot be changed, and the retention period cannot be shortened — only extended. That is the answer whenever a requirement says records must survive an administrator.
| Control | Withstands an accident | Withstands a privileged insider | Withstands the root user | How it ends |
|---|---|---|---|---|
Versioning alone | Yes — overwrites and deletes are recoverable | No — | No | Never — versions accumulate until lifecycle rules expire them |
Yes | Mostly — version deletion needs root plus an MFA code | No — root with the MFA device can still delete | By disabling it, again as root with MFA | |
Object Lock — governance mode | Yes | No — | No | Retain-until date passes, or an authorized principal bypasses it |
Object Lock — compliance mode | Yes | Yes | Yes — not even the root user can delete or shorten it | Only when the retain-until date passes. It can be extended, never shortened |
Yes | Only against principals lacking | No | Never expires — removed explicitly by an authorized principal | |
Yes | Yes, once locked | Yes, once locked | The vault lock policy becomes immutable after you complete the lock; you have 24 hours to validate and complete or abort it |
Three practical notes on deploying Object Lock, all of which have been exam material.
Enabling it. Object Lock is a bucket-level flag that requires versioning. You can set it when creating the bucket, and you can also enable it on an existing bucket — through the API or console, which enables versioning as part of the operation (historically this was creation-time only, and older study material still says so). Turning the flag on locks nothing by itself: protection comes from a default retention configuration applied to new objects, or from per-object retention and legal-hold settings. The flag plus default retention is the combination that satisfies “all new records must be retained for seven years”.
Choosing a period you can live with. A compliance-mode retain-until date cannot be shortened by anyone. A finger slip entering 70 years instead of 7 is unfixable, and you will pay storage for the difference — so pilot retention configurations in governance mode first, which is one of the documented reasons governance mode exists. A bucket policy can also set minimum and maximum allowable retention periods, which is the guardrail that stops the finger slip.
Vault Lock for backups and vaults. S3 Glacier Vault Lock applies the same idea to Glacier vaults: you attach a vault lock policy, then have 24 hours to validate behaviour and either complete the lock — after which the policy is immutable — or abort. AWS Backup has its own equivalent, Backup Vault Lock, which the resilience module covers. The pattern to carry away is that all three give you a deliberate window between “configured” and “irreversible”, because irreversible controls need a rehearsal step.
Digital code signing: AWS Signer and Lambda code signing
Integrity is not only about stored records — it is also about what runs. AWS Signer manages signing profiles and signs artifacts; Lambda code signing uses a code-signing configuration to require that deployment packages carry a valid signature from a trusted profile, and to decide whether an expired or revoked signature warns or rejects the deployment. Container images get the equivalent through signing and verification in the registry. The exam phrase to recognise: “ensure only approved, unmodified code is deployed” → code signing, not a checksum and not a pipeline approval.
File validation: proving logs were not edited
CloudTrail log file validation produces hourly digest files, each signed and each referencing the previous one, so a deleted or modified log file breaks a verifiable chain — and aws cloudtrail validate-logs reports it. Enable it on every trail; it is the mechanism behind “prove the audit log has not been tampered with”. Store the digests in a separate account with Object Lock and the chain becomes very hard to argue with.
Checksums: integrity in transit and at rest
S3 supports additional checksum algorithms (CRC32, CRC32C, SHA-1, SHA-256, and CRC64NVME) computed on upload and stored with the object, so corruption in transit is detected at the moment of writing and the value can be re-verified later. For bulk transfers, AWS DataSync performs its own integrity verification. Checksums detect accidental corruption; they are not signatures and prove nothing about who wrote the data.
Where immutability actually has to live
An immutable copy in the same account as a compromised administrator is a weaker control than it looks: the account itself can be damaged in ways that make the data irrelevant. The strong pattern is a separate account whose only purpose is retention, with Object Lock or Vault Lock in compliance mode, cross-account replication writing into it, and no human principals holding delete permissions at all. That is the anti-ransomware design the resilience module develops.
Key terms: S3 Object Lock, Governance mode, Compliance mode, Legal hold, S3 versioning, MFA delete, S3 Glacier Vault Lock, AWS Signer and code signing
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.