4. 存储服务（S3/EFS/Glacier/Storage Gateway）：高频问题（成本与性能）、回答框架（需求优先级）、公司侧重点（数据合规要求）

--- ## 面试问答卡片 ### 卡片 1：S3 与 EFS 选型对比 **面试问题：** 你的项目需要存储大量日志文件（每天 500 GB），且需要低频访问，你会选择 S3 还是 EFS？为什么？ **面试官考察点：** - 是否理解对象存储与文件存储的本质差异 - 成本意识（S3 按量付费 vs EFS 按预置吞吐付费） - 对访问模式的敏感度 **回答框架：** 1. 确认业务特征：大量·冷数据·无需共享文件系统 2. 成本优先：S3 标准‑IA 或 Glacier 比 EFS 便宜 80%+ 3. 性能匹配：EFS 吞吐受预置容量限制，冷数据无需低延迟 4. 最终选择 S3 + 生命周期策略 **简短示例回答：** “我会选 S3。日志是冷数据、无需 POSIX 语义。S3 标准‑IA 存储成本仅约 0.0125 $/GB，而 EFS 最低 0.08 $/GB。配合生命周期规则，90 天后自动转入 Glacier，总成本降低 90% 以上。” **可能追问：** - 如果日志需要实时流式写入并多次读取？ - Glacier 取回时间是否满足合规要求？ - 如何设计生命周期策略避免取回费用？ **避坑提醒：** ❌ 不要直接说“S3 便宜”，需要量化对比。 ❌ 忽略生命周期配置，会被认为缺乏运维经验。 ✅ 主动提及“S3 对象锁定”用于合规保留。 --- ### 卡片 2：Glacier 深度归档与数据合规 **面试问题：** 金融行业客户要求数据保留 7 年，且每年最多审计 2 次。你会怎么设计存储方案？ **面试官考察点：** - Glacier 产品层级熟悉度（Deep Archive vs Flexible Retrieval） - 合规功能（Vault Lock、Object Lock） - 成本优化的精细度 **回答框架：** 1. 合规核心：WORM 策略（一次写入不可删除） 2. 成本最优：S3 标准 → 30 天后转入 Glacier Deep Archive（0.00099 $/GB/月） 3. 审计配合：通过 S3 批量操作或 Glacier 批量取回（12‑48 小时内完成） 4. 数据保护：启用 S3 Object Lock 并配置默认保留期限 **简短示例回答：** “采用 S3 + 生命周期规则，30 天后转入 Glacier Deep Archive。启用 Object Lock 设置 7 年保留期，满足金融合规。审计时通过批量取回，每 PB 数据约 200 $ 取回费，年审计 2 次可接受。” **可能追问：** - 如果审计要求立即取回（分钟级）？ - Deep Archive 的最低存储期限？如何处理短于 180 天的情况？ - 如何监控 Object Lock 是否生效？ **避坑提醒：** ❌ 不可只提 Glacier 而不区分检索模式。 ❌ 假设所有 Glacier 都支持秒级取回。 ✅ 补充“Vault Lock 实现监管合规锁定”为加分项。 --- ### 卡片 3：Storage Gateway 混合云场景 **面试问题：** 某企业有 50 TB 本地 NAS，希望将冷数据迁移上云，同时保持热数据本地访问。你会使用哪种 Storage Gateway？ **面试官考察点：** - Gateway 三种模式（File/Volume/Tape）理解程度 - 混合云架构设计能力 - 迁移与缓存策略 **回答框架：** 1. 业务诉求：本地热访问 + 云端冷备份 2. 推荐 File Gateway：提供 NFS/SMB 挂载，本地缓存热数据 3. 数据上传至 S3 后，结合生命周期转入 Glacier 4. 部署优化：多网关高可用，缓存盘采用本地 SSD **简短示例回答：** “选用 File Gateway。本地挂载 NFS，日常读写命中缓存（40% 容量），冷数据异步上传至 S3。配合生命周期规则，30 天后移至 Glacier。50 TB 数据迁移约 3‑5 天，网络带宽 1 Gbps，成本可控。” **可能追问：** - 如何保障网关本地缓存不丢数据？ - 网络中断时能否继续服务？ - 网关故障后的恢复流程？ **避坑提醒：** ❌ 不要推荐 Volume Gateway（块存储）给 NAS 迁移需求。 ❌ 忽略缓存比例设计，会导致频繁从 S3 拉取。 ✅ 强调“Gateway 支持 S3 事件通知，可触发 Lambda 做后处理”体现架构能力。 --- ## 项目案例章节 ### 项目名称：金融日志合规归档平台 **业务背景：** 某上市银行需满足 GDPR & 银保监会要求，所有交易日志保留 10 年，前 3 个月频繁查询，之后仅审计使用。原有自建 HDFS 成本高、运维难，迁移至 AWS。 **规模指标：** - 数据量：120 TB/年，总量 1.2 PB - 写入 IOPS：2000 （峰值 4000） - 审计查询：每季度 2‑3 次，每次检索量约 2 TB - 合规要求：不可修改、不可删除，存储地域限定法兰克福 **技术栈：** S3 + Glacier Deep Archive | Object Lock ( Governance mode ) | S3 Lifecycle Policy | CloudTrail + AWS Config | Lambda ( tag 校验) | Kafka ( 流式写入 S3 前缓冲) **核心难点：** 1. 数据写入高峰窗口：Kafka 消费端批量写入 S3，每秒 3000 个 object，需要配置多分区且调整 S3 请求速率限制。 2. 合规锁定与自动化：需要确保每个对象自动打上“retention‑10years” tag，并在生命周期转入 Glacier 前完成锁定。 3. 审计取回性能：Deep Archive 取回需 12 小时，配合 Glacier 批量操作并行请求，将 2 TB 检索缩短至 6 小时。 4. 成本预算控制：前 3 个月 S3 标准存储费用 + 后续 Deep Archive，年化成本从 150 万降至 35 万人民币。 **面试高频追问：** - 如何保证 Object Lock 在生命周期转换时不失效？ - 使用 Tag 还是 Bucket 级别的默认保留？ - 审计取回时如何避免重复取回产生额外费用？ - 如果法律要求立即删除部分数据（权利删除请求），怎么处理？ - S3 与 Glacier 之间的请求费用如何优化（PUT/GET 请求数量）？ **可迁移回答话术：** > “我做金融日志归档时，核心逻辑是成本‑合规‑性能三级过滤——先用 S3 标准跑满 3 个月热窗口，再通过生命周期转入 Deep Archive。合规方面，开启 Object Lock Governance 模式并设定 10 年保留，同时使用 CloudTrail 监控所有置锁操作。审计取回通过批量任务 + 并行分区，将 12 小时缩短到 6 小时。类似的冷数据场景，比如监控录像归档、医疗影像存档，都适用这套模式。” ---