生命周期 · XB 现场笔记

S3 存储类用成本换访问方式

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

存储类改变的不只是每月保存字节的价格，还包括取回方式、故障韧性和计费结构。首先应确定业务允许多久恢复数据，以及丢失后是否有其他可重建副本。Standard-IA 可以立即读取，但取回另行收费；Glacier Flexible Retrieval 和 Deep Archive 则需要先恢复，再执行普通读取。One Zone-IA 还有不同故障边界：它不能抵御所在可用区被物理摧毁。相同的宣传持久性数字，不能替代对实际故障域的判断。

先拆清费用，再比较总额

使用桶所在区域的当前价目表，明确存储类、取回档次与请求种类。存储取决于计费容量和持续时间；取回可能同时按字节及请求计费。逐对象迁移请求和归档元数据则随对象数量增长。不能把所有费用都说成只由对象数量决定，也不能从某一条存储单价直接推出整个工作负载的节省比例。同样大小的数据拆成大量小对象，成本模型可能完全不同。

不要把 Flexible Retrieval 和 Deep Archive 的标准取回统一当成免费。AWS 明确提供 Flexible Retrieval 批量取回及其请求免费，Intelligent-Tiering 则有另外的标准和批量取回免费规则。这些例外不能推导出其他存储类和档次也免费。归档恢复后，原归档对象仍在；临时可读副本还会按选定保留时间收取 Standard 存储费。只计算原归档的低价，会漏掉这个并存阶段。

即使对象提前消失，最短存储期限仍然影响费用：Standard-IA 和 One Zone-IA 为三十天，Glacier 即时与灵活取回为九十天，Deep Archive 为一百八十天。提前删除、覆盖或迁出可能产生剩余期限费用。Standard-IA、One Zone-IA 和 Glacier Instant Retrieval 有 128 KB 的最小计费对象大小；灵活取回与深度归档则每对象增加四十 KB 元数据，分别按 Standard 与归档费率计费。

生命周期规则必须对应工作负载

对象年龄不是距离上次访问的时间。三十天后迁移的规则，也会命中一份已经保存一年、却仍然每周读取的报告。需要同时评估对象尺寸、取回字节数、请求频率、保留时间及可接受的恢复延迟。前缀和标签可以分开不同工作负载，但只有分类长期准确时才有效，不能把存储时间长直接解释为访问已经变少。

二零二四年九月开始的新默认行为，阻止小于 128 KB 对象的生命周期迁移。没有修改的旧配置可能保留此前行为，显式大小过滤器也可以覆盖默认限制。因此，一个小对象仍在 Standard，不能独自证明规则已经坏了。应检查配置实际生效的过滤条件和变更历史，再判断它为何保留原存储类，而不是看到某次查询结果就猜测迁移失败。

坏掉的样子

存储小计下降，可能掩盖取回和请求费用上升。反过来，已经恢复的临时副本在有效期内被多次读取，也不一定每次都重新发起归档恢复。应按真正的“恢复后读取”流程建模，把临时副本存储算进去，不能机械地将归档恢复费用乘上每一次 GET。访问频率与恢复请求频率有关，却不是同一个数。

恢复耗时同样是运维依赖。灵活取回的标准请求通常需要三至五小时；深度归档的标准请求通常在十二小时内完成，批量通常在四十八小时内完成。这是文档描述的典型预期，不是无条件的截止保证。承诺恢复时间目标之前，应实际演练恢复并确认完成；请求已接受、恢复正在进行和内容已经可读，是不同阶段。

快速验证

用 Python 3 运行下面独立脚本；本轮以 Python 3.12.14 执行。价格是刻意虚构的教学输入，不是当前 AWS 报价，也不是完整账单。模型比较一个 GiB 保存十二个模型月份，假定每次读取都取回整个对象。把参数说清楚之后，才可以讨论为什么访问量变化会让选择反转。

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")

零次读取时，较冷模型的 0.121 低于 0.24；五十二次完整读取后，0.641 反而高于 0.24。在这组输入下，十一次仍便宜，十二次就不再便宜。尺寸计算展示小对象起计门槛为何需要独立处理。这些结果都不是通用的存储类切换阈值，也没有验证云服务上的实际迁移或计费。

下面保留原有 AWS CLI 诊断命令。需要已授权桶的读取权限，并替换 B 与 K；本轮没有执行这些命令：

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'

清单成功且非空时，第一条按存储类统计当前对象个数，不统计字节或非当前版本。空清单和 CLI 错误需要另外处理；管道退出成功，本身不证明 AWS 调用成功。第二条只显示每条规则的第一个迁移，遗漏过滤条件、后续迁移与非当前版本迁移，决策前必须检查完整响应。HeadObject 对 Standard 不返回 StorageClass，所以投影为 null 本身不是故障。这些查询都不能测量访问频率，也不证明尚待处理的迁移或恢复已经完成。应结合完整策略、清单、访问证据与账单之后再改变生命周期行为。

来源

AWS S3 pricing，计费维度、恢复副本与免费取回例外，已核验 2026-10-15。
AWS storage class guide，访问、韧性、最短期限与最小计费尺寸，已核验 2026-10-15。
AWS lifecycle transitions，小对象默认行为及旧配置差异，已核验 2026-10-15。
AWS archive retrieval options，典型恢复时长，已核验 2026-10-15。
AWS CLI HeadObject，Standard 不返回 StorageClass，已核验 2026-10-15。
AWS CLI ListObjectsV2，清单范围与对象字段，已核验 2026-10-15。
AWS CLI lifecycle configuration，过滤器及迁移数组，已核验 2026-10-15。

凭据到期必须由验证方执行

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

只有负责决定是否允许访问的系统检查了适用截止时间，凭据才真的会到期。在资产清单里写一个日期，不会自动改变数据库或接口接受什么。较短有效期可以压缩被盗凭据继续建立新访问的时间窗口，但具体效果取决于认证机制，以及此前已经建立的会话、签发的其他凭据如何处理。秘密不是因为自身附带一行日期，就能独立让所有访问失效。

坏掉的样子

到期不会撤销已经发生的行为。复制出去的数据仍在外面，截止时间之前建立的会话也可能继续工作。攻击者还可能在原本有效的权限下建立另一条访问路径。因此，有效期只是限制后续使用的一种手段，还要结合权限范围、撤销机制、会话管理和对实际影响的调查。它并不能为一次泄漏造成的全部损失设定通用上限，也不能把过去的访问自动变成没有发生过。

PostgreSQL 的 VALID UNTIL 控制角色密码的有效时间，不控制角色是否存在，也不覆盖所有认证方式。使用非密码方式建立连接，就不会获得同样的截止检查。如果通过本地信任规则来测试密码到期，便可能误以为到期功能失效。判断结果之前，应先确认客户端实际命中了哪条认证路径，不能只看两次连接用了同一个用户名。

轮换与续期是两个不同变化。在 PostgreSQL 中，仅修改 PASSWORD 会保留 VALID UNTIL，仅修改 VALID UNTIL 也会保留原密码。更新流程如果只修改其中一项，可能导致应用依然无法重新连接，也可能让原值继续有效。一个连接池里的旧连接查询成功，不足以证明新凭据能够完成新的认证，因为它可能根本没有重新交出密码接受检查。

快速验证

准备隔离的 Linux 实验环境，让 PostgreSQL 18 程序位于 PATH 中，以非 root 用户运行，并确认回环端口 55477 未被使用。将下列内容保存为脚本，用 sh 执行。它初始化一次性数据库集群，只使用明确虚构的密码，TCP 仅监听回环地址，退出时删除临时目录。本地信任认证只为展示另一条认证路径而启用，不应照搬到真实服务：

#!/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"

此前 PostgreSQL 18.6 记录中的输出确认截止时间已经过去；本轮没有重跑认证实验。脚本把期限设为数据库当前时间的一秒之后，然后等待数据库时钟越过它，所以这里实际经历了到期，而不是只拿一个编造日期做字符串比较。随后，通过 SCRAM 密码认证建立的新连接被拒绝，验证了真正决定认证结果的服务端规则。

到期之前打开的连接仍然可用。输入管道让同一个客户端和数据库会话跨过截止时间与密码替换过程，最后的输出确认它在两件事发生后都还能以该角色执行查询。如果需求是终止既有会话，就必须建立超出这个密码属性的明确策略；只观察新登录失败，并不能宣称此前的连接也已全部失去访问。

新的本地信任登录依然成功，这符合不同认证方式适用不同规则的文档契约。单独替换密码后，新的密码登录还是失败，因为原截止时间没有被重置。脚本再提供一个未来期限，替换后的密码才可以连接，而原密码被拒绝。这样分别验证了凭据值、有效日期和会话存续，不会把三件事合并成一个模糊的“轮换成功”。

实验最终明确了三项独立观察：期限影响新的密码认证；认证方式决定这条规则是否适用；已经建立的会话不会自动终止。示例没有实现生产凭据代理，也没有证明所有访问路径都能被统一撤销。实验完成后，专用集群与两条虚构密码一起被丢弃，不把这套仅为观察行为而设计的认证配置留在运行环境中。

在消费者需要重新连接之前完成更新

选择有效期时，应为获取替换值、分发、刷新消费进程，以及从有限中断中恢复预留时间。监控验证方剩余有效时间，也要观察每个消费者实际载入值的版本或年龄。管理清单显示已经产生新版本，并不证明运行中的应用已经使用新值，更不能代替一次真正的新连接测试。

平台的切换模型允许重叠时，应先用替换凭据完成新的认证，再退休旧版本。之后确认原凭据无法建立新访问，并单独决定是否排空或终止既有会话。发生泄漏时，紧急撤销可能优先于无中断切换；不能因为期限将来会到，就推迟当下应实施的撤销动作。流程目标是控制实际接受行为，而不是维持一个看起来整齐的轮换日历。

保持时钟同步，避免续期失败就悄悄延长有效期。记录被测主体、版本、验证方和期限，不记录秘密值。有效证据应包含预期边界前能接受、边界后在目标路径上被拒绝，以及对既有会话影响的清楚认识。管理界面显示了一个日期，只说明配置里存在这个字段，还没有证明系统执行了相应的访问限制。

来源

PostgreSQL 18 CREATE ROLE，密码专属有效期与非密码认证，已核验 2026-10-15。
PostgreSQL 18 ALTER ROLE，密码与有效期的独立修改，已核验 2026-10-15。
PostgreSQL 18 主机认证，认证规则匹配，以及信任认证和 SCRAM 的区别，已核验 2026-10-15。
OWASP 秘密管理，到期、轮换、撤销和生命周期控制，已核验 2026-10-15。

生命周期 · XB 现场笔记

S3 存储类用成本换访问方式

先拆清费用，再比较总额

生命周期规则必须对应工作负载

坏掉的样子

快速验证

来源

凭据到期必须由验证方执行

坏掉的样子

快速验证

在消费者需要重新连接之前完成更新

延伸阅读

来源