Lifecycle · XB Field Notes

S3 storage classes trade cost for access

Wed, 30 Sep 2026 00:00:00 +0000

A storage class changes retrieval behavior, resilience, and billing, not just the monthly price of bytes. Start with the time allowed to recover data and whether another copy can be recreated. Standard-IA offers immediate access with retrieval charges; Glacier Flexible Retrieval and Deep Archive require restoration before ordinary reads. One Zone-IA also has a different failure boundary: its data is not resilient to physical loss of its Availability Zone.

Separate the charges before comparing totals

Use the current price sheet for the bucket’s Region and the exact class, retrieval tier, and request type. Storage is charged by billable capacity and duration; retrieval can be charged by bytes, requests, or both. Per-object transitions and archive metadata scale with object count. It is incorrect to describe all these costs as driven only by object count, or to infer total savings from one storage rate.

Do not treat standard retrieval from Flexible Retrieval and Deep Archive as universally free. The price sheet checked on 2026-10-18 lists Flexible Retrieval bulk retrievals and requests as free; Intelligent-Tiering has separate free standard and bulk retrieval rules. Those exceptions do not establish the same price for another class or tier. A restored archive also retains the archived object while its temporary readable copy incurs Standard storage charges for the chosen lifetime.

Minimum durations matter even when an object disappears sooner: Standard-IA and One Zone-IA use thirty days, Glacier Instant and Flexible Retrieval ninety, and Deep Archive 180. Early deletion, replacement, or transition can incur the remaining minimum charge. Standard-IA, One Zone-IA, and Glacier Instant Retrieval have a 128 KB billable-size floor. Flexible Retrieval and Deep Archive add forty KB of metadata per object, split between Standard and archive rates.

Match lifecycle rules to the workload

An object’s age is not its time since last access. A thirty-day transition can affect a year-old report still read weekly. Evaluate object size, bytes retrieved, request frequency, retention, and acceptable restoration delay together. Prefixes and tags can distinguish workloads, but only if their classification stays accurate.

The September 2024 default prevents lifecycle transitions of objects smaller than 128 KB. Older unmodified configurations can retain the previous behavior, and explicit size filters can override defaults. Therefore, a small object remaining in Standard does not alone prove a broken rule. Inspect the configuration’s effective filters and history before attributing the outcome.

When it breaks

A lower storage subtotal can conceal higher retrieval and request charges. Conversely, a frequently read restored copy need not trigger a fresh archive restoration for every read while that copy remains available. Model the actual restore-and-read workflow, including temporary-copy storage, instead of multiplying archive restore charges by every GET.

A restore duration is also an operational dependency. Flexible Retrieval standard requests typically take three to five hours; Deep Archive standard requests typically finish within twelve hours, with bulk typically within forty-eight. These are documented expectations, not an unconditional deadline guarantee. Exercise restoration and verify completion before promising that a recovery-time objective is met.

S3 access before cost — mechanism diagram.

Check it quickly

Run this standalone Python 3 script with assertions enabled. The earlier article reports Python 3.12.14 execution; no matching raw run record was recovered here, and this review did not rerun it. Its deliberately invented prices demonstrate sensitivity, not a current AWS quote or a complete bill. It compares one GiB retained for twelve modeled months and assumes every read retrieves the entire object.

from decimal import Decimal as D

# Invented rates, not an AWS quote; one GiB held for twelve modeled months.
warm_storage = D("0.02")
cold_storage = D("0.01")
retrieval_per_gib = D("0.01")
transition_per_object = D("0.001")


def annual_cost(full_reads):
 warm = 12 * warm_storage
 cold = 12 * cold_storage + full_reads * retrieval_per_gib + transition_per_object
 return warm, cold


assert annual_cost(0) == (D("0.24"), D("0.121"))
assert annual_cost(52) == (D("0.24"), D("0.641"))
assert annual_cost(11)[1] < annual_cost(11)[0]
assert annual_cost(12)[1] > annual_cost(12)[0]
small_bytes, minimum_bytes = 10 * 1024, 128 * 1024
assert D(max(small_bytes, minimum_bytes)) / small_bytes == D("12.8")
assert max(10, 180) == 180 # Illustrative minimum-duration billing boundary.
for reads in (0, 11, 12, 52):
 print(reads, "full reads:", tuple(map(str, annual_cost(reads))))
print("10 KiB under a 128 KiB floor: 12.8x billable size")
print("Excluded: GET requests, transfer, restored copies, tax, and negotiated rates")

Zero reads favor the colder model at 0.121 versus 0.24; fifty-two full reads reverse the choice to 0.641 versus 0.24. With these inputs, eleven reads remain cheaper and twelve do not. The size calculation shows why small-object floors need explicit treatment. Neither result establishes a universal class-selection threshold.

For an authorized bucket, the following unchanged AWS CLI diagnostics require configured read access and replacement of B and K. They were not executed during this review:

aws s3api list-objects-v2 --bucket B --query 'Contents[].StorageClass' --output text | tr '\t' '\n' | sort | uniq -c
aws s3api get-bucket-lifecycle-configuration --bucket B --query 'Rules[].[ID,Status,Transitions[0].Days,Transitions[0].StorageClass]' --output table
aws s3api head-object --bucket B --key K --query 'StorageClass'

For a successful nonempty listing, the first command counts current objects by class, not bytes or noncurrent versions. Handle empty listings and CLI errors separately; pipeline success alone does not validate the AWS call. The second shows only each rule’s first transition, omitting filters and later or noncurrent transitions; inspect the full response before deciding. HeadObject omits StorageClass for Standard, so a null projection is not itself a failure. None of these observations measures access frequency or proves that a pending transition or restore completed. Combine inventory, complete policy, access evidence, and billing before changing lifecycle behavior.

Sources

AWS S3 pricing, billing dimensions, restore copies, and free-tier distinctions, checked 2026-10-15.
AWS storage class guide, access, resilience, minimum duration, and billable size, checked 2026-10-15.
AWS lifecycle transitions, small-object defaults and existing configurations, checked 2026-10-15.
AWS archive retrieval options, typical restore durations, checked 2026-10-15.
AWS CLI HeadObject, Standard omits StorageClass, checked 2026-10-15.
AWS CLI ListObjectsV2, listing scope and object fields, checked 2026-10-15.
AWS CLI lifecycle configuration, filters and transition arrays, checked 2026-10-15.

Credential expiry needs an enforcing verifier

Sun, 27 Sep 2026 00:00:00 +0000

A credential expires only when the system deciding access checks an applicable deadline. Writing an expiry date in an inventory does not change what a database or API accepts. A short lifetime can reduce the period during which a stolen credential starts new access, but its effect depends on the authentication mechanism and on what happens to sessions or other credentials already created with it.

Expiry changes acceptance only where the verifier enforces it. The historical PostgreSQL fixture separates fresh password login, held sessions and trust authentication. A separate generic overlap model applies only where supported; rotation, renewal and revocation require distinct evidence.

When it breaks

Expiry does not undo earlier actions. Data already copied remains copied, and a session established before the deadline may continue working. An attacker may also have created another access path while authorized. Treat lifetime as one limit on future use, alongside scope, revocation, session management, and investigation of actual effects. It does not put a universal ceiling on the damage from exposure.

PostgreSQL’s VALID UNTIL applies to a role’s password, not to the role’s existence or all authentication methods. A connection using a non-password method does not gain that deadline check. Testing expiry through a local trust rule can therefore misleadingly suggest that the deadline is broken. Verify the authentication path actually used by the client.

Rotation and renewal are separate changes. In PostgreSQL, changing only PASSWORD preserves VALID UNTIL, while changing only VALID UNTIL preserves the password. A refresh design that updates only one can leave applications unable to reconnect or leave the old value usable. Successful access through an existing pool connection does not prove that replacement credentials can establish fresh connections.

Check it quickly

Use an isolated Linux environment with PostgreSQL 18 programs on PATH, running as a non-root user, and an unused loopback port 55477. Save this as a shell script and run it with sh. It initializes a disposable cluster, uses explicitly invented passwords, binds TCP only to loopback, and removes its temporary directory on exit. Local trust is included solely to demonstrate a different authentication path:

#!/bin/sh
set -eu
lab_root=$(mktemp -d /tmp/credential-expiry.XXXXXX)
cleanup() {
 if test -f "$lab_root/data/postmaster.pid"; then
 pg_ctl -D "$lab_root/data" -m immediate -w stop >/dev/null
 fi
 rm -rf "$lab_root"
}
trap cleanup EXIT
initdb -D "$lab_root/data" --locale=C --auth-local=trust --auth-host=scram-sha-256 >/dev/null
pg_ctl -D "$lab_root/data" -l "$lab_root/server.log" \
 -o "-k $lab_root -p 55477 -c listen_addresses=127.0.0.1" -w start >/dev/null
admin() {
 psql -X -qAt -v ON_ERROR_STOP=1 -h "$lab_root" -p 55477 -d postgres "$@"
}
# Both passwords below are invented, disposable lab fixtures.
admin <<'SQL'
SET password_encryption='scram-sha-256';
CREATE ROLE article_expiry LOGIN PASSWORD 'LAB-ONLY-OLD-PASSWORD';
SQL
mkfifo "$lab_root/input"
PGPASSWORD=LAB-ONLY-OLD-PASSWORD psql -X -qAt -v ON_ERROR_STOP=1 \
 -h 127.0.0.1 -p 55477 -U article_expiry -d postgres \
 <"$lab_root/input" >"$lab_root/held.out" 2>"$lab_root/held.err" &
held_pid=$!
exec 3>"$lab_root/input"
printf "SELECT 'ready';\n" >&3
attempt=0
until grep -qx ready "$lab_root/held.out"; do
 attempt=$((attempt + 1))
 test "$attempt" -lt 100
 sleep 0.05
done
admin <<'SQL'
SELECT format('ALTER ROLE article_expiry VALID UNTIL %L',
 clock_timestamp()+interval '1 second') \gexec
SELECT pg_sleep(1.2);
SELECT 'deadline passed='||(rolvaliduntil<clock_timestamp())
FROM pg_authid WHERE rolname='article_expiry';
SQL
if PGPASSWORD=LAB-ONLY-OLD-PASSWORD psql -X -qAt -h 127.0.0.1 -p 55477 \
 -U article_expiry -d postgres -c 'SELECT 1' >"$lab_root/new.out" 2>"$lab_root/new.err"; then
 exit 1
fi
grep -q 'password authentication failed' "$lab_root/new.err"
printf '%s\n' 'fresh SCRAM login rejected after expiry'
printf "SELECT 'held after expiry='||current_user;\n" >&3
psql -X -qAt -v ON_ERROR_STOP=1 -h "$lab_root" -p 55477 \
 -U article_expiry -d postgres -c "SELECT 'local trust login='||current_user"
admin <<'SQL'
SET password_encryption='scram-sha-256';
ALTER ROLE article_expiry PASSWORD 'LAB-ONLY-NEW-PASSWORD';
SQL
if PGPASSWORD=LAB-ONLY-NEW-PASSWORD psql -X -qAt -h 127.0.0.1 -p 55477 \
 -U article_expiry -d postgres -c 'SELECT 1' >"$lab_root/rotated.out" 2>"$lab_root/rotated.err"; then
 exit 1
fi
grep -q 'password authentication failed' "$lab_root/rotated.err"
printf '%s\n' 'rotating password alone preserves expired deadline'
admin <<'SQL'
SELECT format('ALTER ROLE article_expiry VALID UNTIL %L',
 clock_timestamp()+interval '1 hour') \gexec
SQL
if PGPASSWORD=LAB-ONLY-OLD-PASSWORD psql -X -qAt -h 127.0.0.1 -p 55477 \
 -U article_expiry -d postgres -c 'SELECT 1' >"$lab_root/old.out" 2>"$lab_root/old.err"; then
 exit 1
fi
grep -q 'password authentication failed' "$lab_root/old.err"
printf '%s\n' 'old password rejected after rotation'
PGPASSWORD=LAB-ONLY-NEW-PASSWORD psql -X -qAt -v ON_ERROR_STOP=1 \
 -h 127.0.0.1 -p 55477 -U article_expiry -d postgres \
 -c "SELECT 'new password login='||current_user"
printf "SELECT 'held after rotation='||current_user;\n" >&3
printf '\\q\n' >&3
exec 3>&-
wait "$held_pid"
grep -qx 'held after expiry=article_expiry' "$lab_root/held.out"
grep -qx 'held after rotation=article_expiry' "$lab_root/held.out"
cat "$lab_root/held.out"

The historical PostgreSQL 18.6 run reports that the deadline has passed; this review did not rerun the authentication fixture. It waits on the database clock after setting a deadline one second ahead, so this is an actual expiry crossing rather than merely a string comparison against a fabricated date. A fresh SCRAM password login is then rejected.

The connection opened before expiry remains usable. Its input pipe keeps the same client and database session alive across the deadline and password replacement. The final output confirms queries under that role after both events. Closing or revoking existing sessions requires an explicit policy beyond this password attribute.

A new local trust login succeeds despite the expired password, as the documented authentication distinction predicts. Replacing the password alone still leaves a fresh password login rejected because the old deadline remains. Once the script supplies a new future deadline, the replacement password connects and the original password is rejected.

These checks isolate three independent observations: the deadline affects new password authentication, the chosen authentication method determines whether that rule applies, and existing sessions are not automatically terminated. The example does not implement a production credential broker or demonstrate revocation of every access path. The private cluster and both fixture passwords are discarded afterward.

Refresh before consumers need another connection

Choose lifetimes with enough allowance for obtaining a replacement, distributing it, refreshing consumers, and recovering from a bounded interruption. Monitor remaining validity at the verifier and the age of the value actually loaded by each consumer. An inventory showing a new version is insufficient if a running process still holds the old one.

Validate replacement credentials through fresh authentication before retiring an old version where the platform’s transition model permits overlap. Confirm that retirement denies new use of the old credential, and separately decide whether sessions must be drained or terminated. During a compromise, emergency revocation may take priority over an uninterrupted transition; expiry should not become a reason to wait for the clock.

Keep clocks synchronized and avoid silently extending lifetimes whenever renewal fails. Record which principal, version, verifier, and deadline were tested without recording secret values. The useful evidence is acceptance before the intended boundary, rejection afterward on the intended path, and an understood effect on existing sessions, not just a date displayed in a management interface.

Sources

PostgreSQL 18 CREATE ROLE, password-only validity and non-password authentication, checked 2026-10-15.
PostgreSQL 18 ALTER ROLE, independent password and validity changes, checked 2026-10-15.
PostgreSQL 18 host authentication, matching authentication rules and trust versus SCRAM, checked 2026-10-15.
OWASP secrets management, expiry, rotation, revocation, and lifecycle control, checked 2026-10-15.