Lifecycle · XB Field Notes

S3 storage classes trade cost for access

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

Choosing a storage class is a bet on when you will read the bytes again. S3 Standard costs $0.023 per GB-month in us-east-1; Glacier Deep Archive costs $0.00099. That is a 23-fold difference for identical durability, and the whole decision is which number your access pattern deserves.

The headline rate is the least informative number in the table. Retrieval charges, minimum storage durations, per-object metadata overhead and transition requests scale with object count rather than total bytes, so the cheap-looking class can be the expensive one for your workload.

What the real prices say

The published us-east-1 rates: Standard $0.023, Standard-IA $0.0125, One Zone-IA $0.010, Glacier Instant Retrieval $0.004, Glacier Flexible Retrieval $0.0036 and Deep Archive $0.00099 per GB-month. Retrieval is where the classes diverge more sharply: Standard-IA and One Zone-IA charge $0.010 per GB read, and Glacier Instant Retrieval charges $0.030.

The non-obvious part: in us-east-1 the current price list charges nothing per GB for standard-tier retrieval from Glacier Flexible Retrieval and Deep Archive. You pay per restore request instead — $0.00005 — and you wait hours. So “archive classes have retrieval fees” is only reliably true for the instant-retrieval classes. Assume otherwise and the arithmetic inverts: if Deep Archive charged the often-quoted $0.02 per GB, reading a 1 GB object 52 times a year would cost $1.05 instead of $0.015 — a 70-fold swing from one regional detail.

Minimum durations and minimum billable sizes

Minimum storage duration is 30 days for Standard-IA and One Zone-IA, 90 for Glacier Instant Retrieval, 90 for Glacier Flexible Retrieval, 180 for Deep Archive. Delete or transition out earlier and you are billed for the remainder — a 1 GB object deleted after 10 days from a 180-day class still costs $0.00586.

Minimum billable object size is the other trap. Standard-IA, One Zone-IA and Glacier Instant Retrieval bill a floor of 128 KB, so a 10 KB object stored in Glacier Instant Retrieval is charged as 128 KB — a 12.8-fold inflation. Glacier Flexible Retrieval and Deep Archive have no floor but add 40 KB of metadata per archived object, 32 KB at the class rate, 8 KB at the Standard rate. And the transition itself costs a request per object: $0.00001 into Standard-IA, $0.00002 into Glacier Instant Retrieval, $0.00003 into Glacier Flexible Retrieval, $0.00005 into Deep Archive. For a 10 KB object in Glacier Instant Retrieval that single request is 65% of the object’s whole annual cost. Since September 2024 the default lifecycle behaviour refuses to transition objects under 128 KB at all, for precisely that reason.

Break-even, not vibes

For a 1 GB object held a year, Standard-IA stops being cheaper than Standard after 13 reads, and Glacier Instant Retrieval after 8. Both land near one read a month, which is what the documented design points — “once a month”, “once a quarter” — describe. The break-even is computable, so compute it instead of assuming it.

The weekly reader is where this goes wrong. A 1 GB object read 52 times a year and transitioned to Glacier Instant Retrieval costs $1.61 against $0.276 on Standard, 5.8 times more, with $1.56 of retrieval fees accounting for the entire difference. A 30-day transition rule is right for a log archive and wrong for a weekly report, and the rule cannot tell them apart unless you scope it by prefix or tag.

When it breaks

The first failure is a lifecycle rule cooling objects that are read every week. It presents as a storage line that went down and a total bill that went up, with the difference sitting in retrieval charges elsewhere on the invoice. Pull per-class retrieval spend rather than looking at the storage line, and check whether any rule’s transition age is shorter than the interval between reads.

The second failure is objects stranded in an archive class with no tested restore path. Glacier Flexible Retrieval restores take minutes on the expedited tier and 5 to 12 hours in bulk; Deep Archive takes 12 to 48. A restore also produces a temporary copy with its own expiry, so a restore that worked last quarter may not work today. Worse, a 100 KB object in Standard-IA is already more expensive than Standard at zero reads, because the transition request exceeds the entire year’s storage saving — the object paid to become slower.

Check it quickly

See where the bytes actually are and what will happen to them:

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'

The first is the distribution across classes — a large GLACIER count on a bucket whose consumers read weekly is the whole problem. The second shows the transition ages; any age shorter than your read interval is a rule that will bill you for retrieval. The third confirms one object’s actual class, which is how you catch a lifecycle rule that silently skipped objects under 128 KB.

Sources

AWS S3 storage classes, what each class is designed for, checked 2026-09-16.
AWS S3 storage class guide, minimum storage durations and minimum billable object sizes, checked 2026-09-16.
AWS S3 lifecycle transition rules, transition constraints and the 128 KB default, checked 2026-09-16.
AWS S3 pricing, per-GB storage, retrieval and request charges, checked 2026-09-16.

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.

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. Replacing a password does not necessarily move its expiry date, and extending a deadline does not replace the value. 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 recorded PostgreSQL 18.6 run reports that the deadline has passed. 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-09-12.
PostgreSQL 18 ALTER ROLE, independent password and validity changes, checked 2026-09-12.
PostgreSQL 18 host authentication, matching authentication rules and trust versus SCRAM, checked 2026-09-12.
OWASP secrets management, expiry, rotation, revocation, and lifecycle control, checked 2026-09-12.