Lesson 115 · AWS Learning Path

AWS 115: S3 Object Lock and Glacier archives

Anil Jalela · Published Oct 18, 2025 · 15 min read

The real problem

A team recognizes the name S3 Object Lock and Glacier archives but has not connected the feature to a real requirement, identity boundary, network or data path, failure mode, price dimension, and cleanup owner. A plausible configuration could still fail the workload.

Final outcome

The learner will produce a requirement-led artifact for S3 Object Lock and Glacier archives, inspect the matching AWS control plane in the Management Console, run a matching CloudShell or AWS CLI query, interpret the output, diagnose one failure, defend one architecture choice, and prove cleanup or approved retained state.

The practical outcome is not a command transcript. It must show what was expected, what happened, what the result proves, what it does not prove, and which evidence would change the decision.

Learning objectives

By the end of this lesson, the learner can:

• explain object lock;
• explain governance mode;
• explain compliance mode;
• explain legal hold;
• explain archive access;
• connect control-plane state to the real data, network, identity, or application behavior;
• identify cost and cleanup ownership before any optional mutation;
• troubleshoot from evidence without opening broad access or adding broad permissions.

Relationship model

Requirement
   |
   v
Identity and policy -> AWS configuration -> network or data path -> workload behavior
        |                    |                      |                    |
        +--------------------+----------------------+--------------------+
                                      |
                                      v
                         monitoring, cost, recovery, cleanup

Use this model to separate an AWS object that exists from a result that actually works. Every arrow is a verification boundary.

Prerequisites, permissions, Region, and safety

• Learning baseline: This sequence assumes practical Linux knowledge but no prior cloud-computing or AWS knowledge. Cloud, networking, security, data, automation, and architecture concepts must come from completed earlier lessons. If a prerequisite checkpoint is incomplete, return to its linked lesson before continuing.
• Confirm a non-root caller with aws sts get-caller-identity and keep the account number private.
• Use ap-south-1 unless this lesson explicitly names a second Region.
• Confirm the intended profile and Region with aws configure list before interpreting an empty result.
• Use read-only List, Get, and Describe permissions for the named services. Design exercises run locally and require no resource-creation permission.
• This is a no-create lesson. Console and CLI work is read-only, and every design artifact is created locally.
• Never publish account IDs, public addresses, ARNs containing private account data, session IDs, presigned URLs, object data, credentials, or KMS material.
• Do not use root, world-open SSH or RDP, disabled TLS verification, unowned resources, or irreversible retention controls in a training exercise.

Core model

How it works

Immutability is a governance decision with legal, security, retention, key, cost, and account-closure implications. Never experiment with compliance retention in a personal training bucket that must be deleted immediately.

Read the result in layers:

1. Scope: account, Region, VPC, bucket, AZ, endpoint, principal, object version, or resource ARN.
2. Control plane: the requested configuration exists and reached an expected state.
3. Behavior: the request, connection, health check, replication, restore, or application result meets the requirement.
4. Operations: monitoring, failure owner, cost, retention, rollback, and cleanup are known.

Control-plane success is necessary but not sufficient. A resource can be available while policy, routing, DNS, health, data, or application behavior remains wrong.

Architecture decision table

Professional questions normally contain several valid services. State the requirement that selects one option, why the nearest alternative fails it, and what changed requirement would reverse the choice.

Object Lock protects versions, not key names

Object Lock uses a write-once-read-many model on individual object versions in a versioning-enabled general purpose bucket. A protected version cannot be overwritten in place, but a caller can create a new version with the same key and can add a delete marker. A normal GET may therefore return newer content or appear deleted while the protected historical version remains intact. Auditors and recovery procedures must identify exact version IDs.

key: records/customer-42.json

v3  delete marker (current: ordinary GET appears deleted)
v2  new corrected value, not automatically locked unless policy/header applies
v1  original value, COMPLIANCE retained until date + legal hold if set

Object Lock requires versioning and has bucket-level enablement/configuration plus object-version retention state. A default retention configuration applies to new versions according to its rule; it does not retroactively protect every historical version. To retain existing versions, use a reviewed operation such as S3 Batch Operations with exact scope and evidence.

Retention period versus legal hold

Retention and legal hold are independent. If either still protects a version, deletion remains blocked. Extending retention is different from shortening it. A bucket default can use days or years; an object can have an explicit retain-until date. Record UTC time, time-zone conversion, authority, approval case, and evidence.

Governance bypass requires s3:BypassGovernanceRetention and an explicit bypass request/header. Merely possessing permission should not silently bypass through automation; however, current console behavior can include the bypass header when the user has permission. Keep bypass out of routine workload roles, require a separate break-glass role and approval, alert on its use, and test in a disposable governance scenario.

In compliance mode, a protected version cannot be deleted and its retention cannot be shortened until expiry - even by account root. This is an intentional irreversible boundary. Wrong duration, wrong object scope, or a forgotten KMS dependency can create unavoidable storage cost or inaccessible retained data. Production compliance retention requires legal/compliance, security, data-owner, cost-owner, and recovery approval.

Immutability does not replace encryption, backup, or availability

• Object Lock does not encrypt data. Choose SSE-S3/SSE-KMS/DSSE-KMS/client-side protection separately.
• A retained SSE-KMS object still depends on an enabled, authorized KMS key. Protect the key policy and deletion lifecycle for at least the retention/recovery period.
• Object Lock does not create another Region/account copy. Replicate or back up according to failure and administrative isolation requirements.
• Replication of locked objects requires compatible destination configuration and permissions. Verify retention/legal-hold behavior on exact replica versions.
• Retention does not ensure the application can find or interpret data. Preserve catalogs, schemas, software, checksums, and restoration runbooks.
• Durability does not prove legal admissibility. Chain of custody, identity, timestamps, audit logs, change control, and evidence handling remain governance responsibilities.

Glacier storage classes versus the older Glacier vault service

“Glacier” can refer to S3 storage classes - Glacier Instant Retrieval, Glacier Flexible Retrieval, and Glacier Deep Archive - or to the older Amazon S3 Glacier vault/archive APIs. Modern S3 object architectures normally use S3 buckets, S3 storage classes, lifecycle, object policies, versioning, and Object Lock. Do not mix S3 Object Lock with S3 Glacier Vault Lock terminology or assume vault APIs manage S3 bucket objects.

Vault Lock applies an immutable access policy to a Glacier vault after a lock process. S3 Object Lock applies retention/legal hold to S3 object versions. Certification scenarios may test this distinction; production teams should use current AWS service guidance and avoid starting new designs with legacy vault assumptions.

Archive retrieval in detail

Glacier Instant Retrieval supports direct millisecond reads and does not use the temporary restore workflow. Flexible Retrieval and Deep Archive objects require RestoreObject before normal access.

Restoration steps:

1. Identify bucket, key, and exact version ID; inspect storage class, encryption, retention, and any current restore header/state.
2. Select a supported retrieval tier and temporary availability duration from current docs. Faster retrieval can cost more and is not available in every class/circumstance.
3. Submit one bounded restore request. Repeated requests can alter/upgrade behavior and cost; do not loop uncontrolled.
4. Poll HeadObject or event/operations evidence with a timeout. “Restore initiated” does not satisfy RTO.
5. After completion, retrieve with the approved role, validate checksum/content/application readability, and record elapsed time.
6. The temporary restored copy expires; the original object remains archived. Copy it to another storage class/key if a permanent active copy is required.
7. Clean up any permanent recovery copy according to authorization, while retained archive versions remain governed by their controls.

Retrieval time is only one part of RTO. Add incident detection, approval, manifest/version selection, bulk job setup, queue time, download/transfer, KMS access, validation, and application rehydration. At large scale, use S3 Batch Operations restore with manifest/completion reports rather than an unsafe shell loop.

Worked decisions

Example 1: seven-year financial records

Use compliance retention only after the authoritative retention schedule is approved. Apply default retention to new final versions, separately remediate existing versions, restrict writes and retention administration, protect KMS for the full period, replicate to the approved account/Region if required, and continuously inventory retention status. A legal hold can add unknown-duration protection for selected versions without changing the seven-year baseline.

Example 2: ransomware-resistant backups with emergency recovery

Governance mode in a security-owned account may fit when a tightly controlled break-glass team must retain an override. Production roles cannot delete versions or bypass; monitoring alerts on policy/retention/bypass activity; KMS and organization controls are separated; periodic clean-room restore proves usability. Governance is not “weaker compliance” - it serves a different recoverability/authority requirement.

Example 3: litigation hold after normal retention would expire

Place a legal hold on exact relevant versions using a reviewed manifest and Batch Operations, validate a completion report, and maintain a case-to-version inventory. The hold has no automatic end date. Release requires an authorized case closure and a second inventory; normal lifecycle can act only after all applicable protection ends.

Example 4: annual Deep Archive recovery test

Select a representative manifest, initiate the approved bulk restore tier, measure time to available, retrieve through the real recovery role/network, validate checksums and application interpretation, record cost, and allow temporary copies to expire. One small object restore does not prove a petabyte-scale RTO.

Failure and safety matrix

Required tests and evidence

The normal learner lab must not create compliance retention. Use governance mode in a dedicated disposable bucket with a short, reviewed duration or supplied evidence when cleanup timing is uncertain.

1. Put one version under governance retention; prove normal permanent deletion is denied.
2. Through a separate approved break-glass role, demonstrate explicit governance bypass, capture the audit event, and remove that role after the exercise - or use instructor-supplied evidence if policy forbids live bypass.
3. Add and remove a legal hold on a separate version, proving that retention and hold are independent.
4. Diagnose a supplied compliance-mode scenario and state why no administrator change can shorten it.
5. Restore an instructor-approved archived object/version, measure actual elapsed time, validate bytes/checksum, and explain temporary-copy expiry.
6. Produce a retained-state register containing bucket/key/version, owner, mode, retain-until UTC, hold status/case, KMS key, replica/backup, evidence location, cost owner, review date, and lawful deletion authority.

AWS Management Console guided practice

Before opening a service page, write the expected account, Region, starting state, and evidence. Do not choose Create, Save, Purchase, Lock, or Delete unless the lesson explicitly authorizes the live track.

1. Open an instructor-supplied Object Lock bucket and inspect default retention, version-level retain-until date, mode, and legal-hold state without changing them.
2. Open a supplied archive object and compare Storage class, Restore status, restore tier, temporary-copy expiry, and current retrieval pricing.
3. Complete the retention-risk review and explicitly reject creating compliance-mode retention in the AWS 120 cleanup lab.

For each step, capture the field name and value in text. A screenshot may support the record but does not replace the explanation. Console labels can evolve, so use the service search and current documentation if a navigation label differs.

CloudShell and AWS CLI practice

CloudShell is the default browser-based command environment taught in AWS 028. AWS 029 and AWS 030 cover local CLI installation and authentication. This lesson therefore does not assume that an unconfigured local shell is ready.

Start every session with:

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure list

Redact the account portion of the ARN before sharing. Then perform the topic query:

Inspect Object Lock configuration and archive restore metadata only on supplied or explicitly owned evidence.

NW_BUCKET="replace-with-owned-bucket-name"
NW_ARCHIVE_KEY="replace-with-owned-archive-key"
aws s3api get-object-lock-configuration --bucket "$NW_BUCKET"
aws s3api head-object --bucket "$NW_BUCKET" --key "$NW_ARCHIVE_KEY"

Expected interpretation:

ObjectLockEnabled and default retention describe configured protection. HeadObject restore metadata can show ongoing or temporary restore state. Do not issue a retention change or restore without approval and price review.

Replace every replace-with-... sample value before running its command, and use only an explicitly owned resource. Explain each option first. These queries are read-only; a successful response does not authorize a later create or delete operation.

Practical work

Create p06-immutability-archive-plan.md for a seven-year regulated dataset. Separate governance and compliance candidates, legal hold, retention owner, KMS key, lifecycle to archive, minimum-duration cost, restore tier, temporary-copy duration, permanent recovered copy, deletion after expiry, and quarterly restore test. Use supplied evidence only; create no locked or archived object.

The evidence package must contain:

• the problem and final requirement in the learner's own words;
• caller type and Region with private identifiers redacted;
• exact planned values, ownership, and cost class;
• one Console observation and matching CLI or API evidence;
• one behavior result or supplied data-plane record;
• one denied, failed, or counterexample result and evidence-led diagnosis;
• one architecture choice plus the rejected alternative;
• cleanup proof or explicit retained-state owner, expiry, and next lesson.

Verification standard

Use expected state before observed state. Record timestamps in UTC and preserve the original failure before changing anything. A passing submission answers all four questions:

1. What exact requirement was tested?
2. Which evidence proves the AWS configuration?
3. Which evidence proves the workload behavior?
4. What remains unproven or requires later monitoring?

If AWS returns no rows, verify account, Region, permission, filters, pagination, resource type, and deletion state before concluding that nothing exists.

Common failures and troubleshooting

Do not troubleshoot by attaching administrator access, opening administration ports to the internet, disabling encryption, retrying uncontrolled creation, deleting unknown resources, or weakening retention.

Cost, cleanup, and retained state

No AWS resource is created. Close CloudShell and remove or redact downloaded evidence.

Cleanup evidence requires terminal state and an after-inventory. Search related ENIs, public IPv4 addresses, EBS volumes and snapshots, load balancers, target groups, Auto Scaling instances, endpoints, logs, S3 versions and delete markers, backup recovery points, and global IAM roles when they apply. Billing data can lag, so schedule a later review.

Architecture and certification decisions

• Certification coverage: SAA-C03; SOA-C03; SAP-C02; DOP-C02.
• Exam mapping: SAA D1-D4.
• Explain service scope, failure boundary, consistency, recovery, security, operations, and price rather than matching a keyword.
• Treat availability and durability, encryption and authorization, routing and filtering, health and lifecycle, backup and replication, and discount and capacity as separate concepts.
• Do not reproduce protected certification questions.

Knowledge check

1. Can root delete a compliance-locked version before expiry?

Expected direction: No.

1. Does Object Lock prevent creation of a new version?

Expected direction: No. It protects specified versions.

1. Does Glacier Instant Retrieval require a restore job?

Expected direction: No. It supports real-time access.

1. Is a Flexible Retrieval restore permanent?

Expected direction: No. It creates a temporary accessible copy unless you copy it to another class.

Completion gate and assessment

Pass at 80 out of 100 with no critical safety failure. A missing practical artifact, unexplained output, unsafe access, destructive action outside the owned scope, unplanned billed resource, or false cleanup claim requires remediation and a changed retest.

Official sources

• S3 Object Lock
• Object Lock configuration and governance bypass
• Applying Object Lock with S3 Batch Operations
• Archived objects
• Restore archived objects
• S3 Glacier storage classes
• Amazon S3 Glacier Vault Lock