CLF-3.6AWS のストレージサービスを特定する。

ヒントボタン

200 TB ものデータを 12 か月以上参照せずに保持しコストを抑えたい場合、保存単価が Amazon S3 Standard の 10 分の 1 以下となる Amazon S3 Glacier Deep Archive が最有力です。S3 Lifecycle でアップロード後すぐに移行すればバケットを分ける必要はなく、11 ナインの耐久性を確保しながら保管コストを極小化できます。Bulk では 48 時間ですが Standard 取得なら 12 時間以内に完了でき、分析要求の SLA を満たします。

取得時間 12 時間という条件は Amazon S3 Standard-IA や Amazon S3 Glacier フレキシブルリトリーブではオーバースペックまたはコスト増になりがちです。Amazon S3 Glacier Deep Archive には Standard と Bulk の 2 種類のリトリーブモードがあり、Standard を選択すれば追加料金は最小限で 12 時間以内の復元が保証されます。ウォームアップや頻繁なアクセスを想定しないワークロードに最適です。

Amazon EBS sc1 や Amazon EFS Standard はランダム I/O やサブ秒アクセスに秀でていますが、GB 単価は S3 より一桁高く 200 TB 規模では費用負担が大きくなります。コスト、復元時間、データ耐久性、運用容易性を横断的に比較すると、S3 Lifecycle で最下位階層に自動移行し必要時に Standard リトリーブを行う構成が、全要件を満たす総合的な最適解となります。

ヒントボタン

複数の Linux コンテナが同一ファイルシステムを共有しつつ、リージョン障害に備えて３つのアベイラビリティーゾーンへ自動レプリケーションされ、クライアントは NFSv4 で透過的に接続できる構成を考えると、Amazon EFS はマネージドで各 AZ にマウントターゲットを配置し、SLA 99.99% と自動フェイルオーバーによる低運用負荷を実現しています。
ストレージ容量と IOPS をアプリケーションの増減に合わせてプロビジョンレスで伸縮させたい場合、Amazon EFS は数百ペタバイトまでファイルシステムが自動拡張し、バーストモードでは 100,000 IOPS 超のパフォーマンスを発揮できるため、EBS の RAID 構成やスループットの手動チューニングに追われる心配がなく、Elastic スループットモードによって容量に比例した性能向上も自動で得られます。
選択肢を比較すると、io2 を RAID0 で束ねて NFS 共有すると AZ をまたげず冗長化設計とバックアップ運用が増え、S3 はオブジェクトストレージで POSIX 操作や低レイテンシランダム I/O には適さず、FSx for Windows File Server は SMB と NTFS 前提で Linux コンテナからの互換性が課題となるため、性能・可用性・運用コストを総合的に見渡すとマネージドな Amazon EFS が条件を最もシンプルに満たします。

ヒントボタン

三つのアベイラビリティーゾーンに散在する約500台のコンテナへ同一データ20 TBを同時供給し、60秒以内の復旧点を保つには、NFS互換でマルチAZ冗長を備える Amazon EFS が第一に検討されます。標準ストレージをプロビジョンドスループットで構成すれば最大1 GB/秒の帯域を確保でき、容量は自動拡張、課金は使用分だけとなるため設計と運用の手間を大幅に削減できます。

Amazon FSx for Lustre は高速ですがシングルAZ利用では障害時の回復点が途切れやすく、Amazon S3 と EC2 上の自前 NFS サーバーや Amazon EBS を個別に割り当てる案はレプリケーション、スナップショット、パッチ適用など日常運用が重くなりがちです。対して Amazon EFS はマルチAZ複製、自動バックアップ、ライフサイクル管理をサービス内で完結でき、要求される RPO を平常運転のまま維持しやすい特徴があります。

要件を整理すると「20 TB 規模を自在に拡張」「500 コンテナが同時マウント」「1 GB/秒スループット」「3 AZ 冗長で RPO60秒」「最小運用負荷」の五つを同時達成する必要があります。Amazon EFS Standard にプロビジョンドスループットを適用する構成は、これら複数要件を単一サービスでバランス良く満たせるため、総合判断として最も合理的な選択となります。

ヒントボタン

世界中の視聴者へ大容量の静的動画を途切れず届けるには、オブジェクトストレージの Amazon S3 Standard を配信オリジンに据え、Amazon CloudFront でエッジキャッシュさせる構成が最もシンプルです。S3 Standard は 99.999999999% の耐久性と高スループットを誇り、複数 AZ へ自動レプリケーションされるため、大規模トラフィックを受けても遅延が起きにくい利点があります。さらに予期せぬリージョン障害にも自動的に耐えるので、初期 90 日間の頻繁なアクセス期に最適と考えられます。必要に応じ S3 Transfer Acceleration でアップロード速度も補えます。

ピークを過ぎてアクセス頻度が大きく下がるタイミングでは、Amazon S3 のライフサイクルポリシーを使い、オブジェクトを 90 日後に S3 Glacier Flexible Retrieval へ自動階層化すると運用が簡単です。このクラスはストレージコストが Standard 比で約 1/5 になりながら、一時的に再生要求が来た際には 1〜5 分程度で取り出せるため、アーカイブと配信用途の両立に向いています。自動移行はリージョンをまたぐ設定やプレフィックス単位など柔軟に制御できるため管理者作業を極小化できます。

同じく低レイテンシを提供できるファイルシステム型サービスとして Amazon EFS や Amazon FSx for Windows File Server がありますが、POSIX や SMB など共有書き込みが必要なアプリ向けで、CDN と組み合わせたグローバル動画配信ではオブジェクトストレージよりコスト効率が下がります。また Amazon S3 One Zone-IA は単一 AZ にしかデータを置かないため、大容量メディアを世界に公開する用途では耐久性と可用性の面で慎重さが求められます。これらを踏まえ、低レイテンシ配信・高耐久・自動階層化という複数要件を俯瞰すると、マルチ AZ かつライフサイクル機能を備える S3 ベースの構成が総合的に理想的と判断できます。

ヒントボタン

100 TBの監査証跡を10年間動かさず保管するならアクセス頻度が極端に低く保存コストが支配的になるため、Amazon S3ストレージクラスの中で最も単価が低いAmazon S3 Glacier Deep Archiveを起点に考えるのが定石であり、Standard-IAやEBSなど比較的高価なクラスをライフサイクルやバックアップで運用するよりも月額が何倍も安く抑えられ、特に保持期間が長いほどこの差は雪だるま式に膨らむことを忘れないでください。
取得要件が年1回かつ12時間以内なら、Amazon S3 Glacier Deep ArchiveのStandardリストアが最大12時間で完了し追加料金も最小で済む一方、Glacier Flexible RetrievalのExpeditedは数分で復元できるもののリクエストとデータ取り出し料金が高く毎年発生するため長期的な総コストは有利にならず、Standard-IAの常時即時アクセス性も今回のSLAには不要です。
金融サービスではログの改ざん防止と法定保持が求められるため、Amazon S3 Object LockをComplianceまたはGovernanceモードで10年間設定すればGlacier Deep Archiveに保管したオブジェクトをWORM化でき、EBSスナップショットやAWS Backupのボリューム単位保護よりファイル粒度で規制対応しやすく、単価・保持・復元SLAを総合的に満たせます。

ヒントボタン

100台のAmazon EC2が同じゲノムファイルを低遅延で同時に読み書きするには、POSIXに準拠した共有ファイルシステムが必要です。Amazon EFSやAmazon FSx for LustreはNFSプロトコルで複数インスタンスからマウントでき、負荷に応じスループットを自動拡張します。一方、Amazon S3はオブジェクトストレージであり直接マウントはできず、単一のio2 EBSに自前でNFSを立てると性能と可用性がホストに依存する点が課題になります。

災害対策としてRPOゼロを求める場合、ストレージがリージョン内の複数AZに同期複製されているかが決定的です。Amazon EFS Standardはデフォルトでメタデータを3AZ、データを最低2AZへ同時書き込みし、AZ障害でも直ちにアクセスを継続できます。対照的にAmazon FSx for LustreのSingle-AZ構成や自前NFSはAZ障害でボリュームごと失われる可能性があり、RPO0の要件達成には追加設計が必要です。

運用負荷を抑えたいなら容量プロビジョニングやパッチ適用を意識せず使えるフルマネージドサービスが有利です。Amazon EFSは利用量に応じ自動スケールし耐久性確保もAWSが担いますが、io2 EBS＋自前NFSはサーバ運用や復旧手順が研究所側に残り、S3もアプリ改修が必要です。共有性能・マルチAZ冗長性・運用自動化の三要件を俯瞰すると最適な選択肢が自然に浮かび上がります。

ヒントボタン

Amazon EFS は NFSv4.1 互換で Linux コンテナから並列マウントでき、マルチ AZ オプションを選ぶだけで自動的に冗長配置が構成され 99.99% 可用性 SLA が付与されます。容量増加に応じたバーストに加えプロビジョンドスループットで 1 GB/s 超を予約でき、フェイルオーバーやパッチ適用を利用者が管理する必要がない点が運用負荷削減に直結します。

Amazon FSx for Windows File Server は SMB 前提で NFS が不要になる Windows ワークロード向け機能が中心となり、s3fs で Amazon S3 を FUSE マウントすると POSIX 互換やレイテンシが限定的です。また単一 EC2 に gp3 を付けて NFS 共有にする案は AZ 障害時の単一障害点や Auto Scaling 時の状態同期が課題になり、50 台のコンテナが 1 GB/s を安定維持するには追加設計が欠かせません。

三つの AZ へネイティブにレプリケートされるファイルシステム、NFS プロトコル対応、スループットの独立スケール、マネージド運用での省力化、そして 99.99% 可用性という複数条件を俯瞰すると、マルチ AZ で利用できプロビジョンドスループットを備える Amazon EFS が総合的に要件を満たすことが読み取れます。

ヒントボタン

RPOが1時間ということは最新の変更を60分以内に他リージョンへ転送する必要があります。S3のクロスリージョンレプリケーション(CRR)はバージョニングを有効化したバケット間でオブジェクトを自動複製でき、追加スクリプトやジョブ運用なしでほぼリアルタイムにコピーされるため、低運用で要件を満たしやすいです。

復旧時間4時間以内を考えるとコピー先ストレージクラスの取り出し速度が重要です。S3 Glacier Flexible Retrievalは標準モードで1〜5時間、緊急モードなら数分で取得でき、Glacier Deep Archiveの平均12時間より短くRTOに収まります。CRR完了後にバケット全体をこのクラスへ移行設定すれば大容量100TBでも保管コストを抑えられます。

EBSスナップショットやStorage Gateway＋FSxといった構成はボリューム管理やリストア手順の運用負荷が増え、クロスリージョン転送の自動化も追加設定が必要です。各案のRPO・RTO・コスト・運用面を俯瞰すると、マネージドでスケールするS3を中心にバージョニングとCRRで即時保護し、複製先をGlacier Flexible Retrievalに置く構成が総合的にバランスに優れています。

ヒントボタン

毎日 500GB を高スループットで書き込む段階では 99.999999999% の耐久性とマルチ AZ 冗長を備えた S3 Standard が最適です。大量 PUT でも追加料金がなく、Athena などから即時に検索できる低レイテンシを維持できるため、生成から 30 日間は運用を簡素化しつつ調査や分析の要求に応えられます。Server-Side Encryption やバージョニングも同一ストレージクラスで完結するため、セキュリティとガバナンス設定を一貫して適用できる点も利点です。

31 日目以降はアクセス頻度が大きく落ち込むものの削除は不可欠なので、11ナイン耐久と 99.5% 可用性を保ちながら料金を抑えられる S3 One Zone-IA が有力です。Standard-IA より安価で、ライフサイクルルールを使えば自動転送され API やアプリの変更は不要です。監査用データはリージョン障害よりもコスト効率が優先されるケースが多く、単一 AZ 構成でもガードレールとして MFA Delete やバージョン管理を併用すれば実運用上のリスクを許容範囲に収められます。

7 年間の長期保管では取得が年に数回、しかも 12 時間以内で問題ないため、容量単価の最安層で Bulk 取出し最大 12 時間の S3 Glacier Deep Archive が要件に合致します。ライフサイクルを 90 日目トリガーで設定すれば Standard から One Zone-IA、さらに Deep Archive へ自動遷移し、人的作業なく保存コストを最小化できます。取り込み・低頻度・アーカイブの各フェーズを S3 Standard、S3 One Zone-IA、S3 Glacier Deep Archive で段階的に構成するアプローチが性能、価格、運用自動化を総合的に満たします。

ヒントボタン

5,000 台の Linux コンテナが 3 つの AZ から同時に 100 TB の共有データへ 5 万 IOPS でアクセスするには、NFS プロトコルを共有しながらスケールアウトし、バックエンドを自動複製してくれる仕組みが求められます。Amazon EFS Standard はマルチ AZ でメタデータを分散し、性能・容量をフルマネージドで弾力的に伸張できるため、大量 IOPS と帯域を必要とするコンテナ用途に最適です。

RPO 1 時間を満たすには、増分バックアップを 60 分ごとに継続的かつ API ベースで実施できると運用が簡単です。EFS は AWS Backup とネイティブに統合され、ファイルシステム全体をスナップショット方式で保護しつつ、ライフサイクルや保持期間もポリシーで一元管理できるため、個別のボリュームやスクリプトの管理負荷が大幅に減ります。

一方で S3 One Zone-IA は AZ が単一で可用性要件を満たさず、FSx for Windows File Server は SMB 専用で Linux からのアクセスに向きません。また gp3 EBS をタスクごとに付ける方法はボリューム数が膨大になりスナップショットも分散します。可用性、性能、運用負荷を総合すると、マルチ AZ で伸縮自在なファイルシステムとバックアップ統合を提供する案が最も合理的と言えます。

ヒントボタン

毎日2TBという大容量を受け付けながらアップロード直後から整合性をチェックしたい場合は、まず Amazon S3 Standard に着地させるのが定石であり、バケットポリシーやバージョニング、MFA Delete などの S3 機能で削除・上書きを防ぎつつ可用性99.9%以上と RPO24時間を確保しておけば、後段でより安価なアーカイブクラスへ移行する際の運用がスムーズになります。
復旧制限時間4時間以内という RTO を満たしつつ保管コストを下げるには、標準取り出しで平均3〜5時間の Amazon S3 Glacier Flexible Retrieval が最適で、S3 Standard-IA は保存単価が高く、S3 Glacier Deep Archive や Amazon Glacier 単体は Bulk ジョブで12時間以上かかったり API が別だったりして時間要件や運用負荷の面でフィットしない点を意識してください。
したがって S3 Lifecycle で30日後に S3 Glacier Flexible Retrieval へ自動遷移させる設計を採ると、取り込み時の Amazon S3 Standard が持つ高可用性と取り出し容易性、長期保存時の低ストレージ単価という利点を組み合わせ、RPO24時間・RTO4時間・可用性99.9%をすべて満たしつつコスト最小化を図るという総合判断が導けます。

ヒントボタン

1行目
1日に3TBという大量のログが発生し、30日間は「いつでも読みたいかもしれない」状態が続きます。RTOは1時間以内なので取り出し速度も犠牲にできません。Amazon S3 Standard やライフサイクルポリシーを手動設定する運用では、アクセスが読めない場合に早過ぎる移行や戻し作業が発生しがちです。アクセス頻度を自動で見極めるサービスに視点を向けてみましょう。

2行目
Amazon S3 Intelligent-Tiering はオブジェクト単位でアクセス状況を機械的に監視し、頻繁アクセス層・標準低頻度層・Archive 関連層へ自動で振り分けます。設定はバケットポリシーで一度有効化するだけで、以後の運用は不要です。標準フェッチはミリ秒オーダー、Archive でも分単位の取り出しが可能なため、1時間以内のRTO要件を十分にクリアできます。

3行目
S3 Standard-IA へ日数で移行する方式はアクセスが集中した際の追加課金と運用負荷、EFS Standard/IA は容量単価の高さ、Glacier Deep Archive は数時間の取り出し遅延という制約があります。突発的な読み込み、コスト最適化、自動階層化、そして短い復旧時間という複数要件を俯瞰すると、アクセスパターンに応じて柔軟に層を変えるソリューションが最も合理的と判断できます。

ヒントボタン

1 日に 50TB という大容量を連日受け止め、Athena や EMR からほぼリアルタイムでアクセスされる 30 日間は高いスループットとレイテンシの低さが不可欠です。キャパシティの事前確保も不要で自動的にスケールする Amazon S3 Standard なら、その期間の解析ジョブが集中してもボトルネックになりにくく、運用担当が容量監視やシャーディングを気に掛けずに済みます。

31 日目以降に参照頻度が下がることが分かっているなら、Amazon S3 のライフサイクルポリシーで Standard-IA や Glacier などの下位ストレージクラスへ段階的に移行する設計がシンプルです。バケットに一度ルールを設定するだけで完全自動化され、CLI でのコピーや Lambda スクリプトによる移送と比べて人的作業がゼロになり、移行漏れやタイミングずれのリスクも排除できます。

ブロックストレージ gp3 や Amazon EFS は高 IOPS や POSIX 準拠が求められるケースに適しており、1 日 50TB のログ保管ではコストが急増します。Storage Gateway とオンプレ NAS を組み合わせる案は設備維持と運用負荷が増えるため、本番環境の可用性、スケーラビリティ、自動階層化、コスト最適化という複数要件を俯瞰するとオブジェクトストレージ主体のアプローチが総合判断として妥当です。

ヒントボタン

1．1日2TBのログを高速に取り込み、直近30日だけ秒単位で分析するのであれば Amazon S3 Standard が最適です。31日目以降は即時性が不要ですから、S3 ライフサイクルポリシーで Amazon S3 Glacier Flexible Retrieval に自動移行させると、数時間〜半日でのリストアが可能なまま保管コストを大幅に抑えられます。Athena や S3 Select での分析時もリストア後そのまま利用でき、ペタバイト級まで制限なくスケールするため7年保持の要件にも余裕で対応できます。

2．Amazon EFS Standard や Amazon EBS gp3 はレイテンシの小さいファイル／ブロックストレージですが、ペタバイト単位で長期間保持するとストレージ料金とスナップショット料金が急増します。また ILM やスナップショットは同リージョン内のホットストレージが前提で、読み出し SLA が24時間以内に緩和されている本ユースケースでは過剰性能です。ログ生成後はほぼ参照しないため、オブジェクトストレージ階層化の方が経済的かつ運用自動化しやすいです。

3．取り込み時の高スループット、30日以内のミリ秒アクセス、24時間以内のリストア、7年間の高耐久、そして最小コストという複数条件を同時に満たすには、Amazon S3 Standard で受けてライフサイクルで Amazon S3 Glacier Flexible Retrieval に段階移行する構成が、スケール性・価格・運用容易性のバランスを最も良く実現します。リージョンクロスレプリケーションは可用性を高めますが転送コストが倍増するため、今回の必須条件ではありません。

ヒントボタン

生成から30日間は監査部門が頻繁に映像を再生するため取り出し課金が発生しにくい Amazon S3 Standard が向いています。Standard-IA にすると GET ごとに課金が増えやすく総額が上がる可能性がありますし、S3 Standard なら 99.99％可用性と複数 AZ 冗長で製造現場の業務継続性も確保できます。

30日を過ぎても監査要請が来れば数分以内に映像を提示しなければならないので、ミリ秒で取得できる S3 Glacier Instant Retrieval が最適です。Glacier Flexible Retrieval はエクスペディテッドなら 1～5 分ですが追加料金が都度発生し、S3 Glacier Deep Archive は最短でも数時間要するため SLA を満たせません。

5 TB/日の取り込みを 7 年続けると約 12.7 PB に達しますが、Amazon S3 Lifecycle で 30 日後に Glacier Instant Retrieval へ自動遷移させれば保存コストを大きく削減しながら即時取得も維持できます。EFS Standard＋EFS IA はファイル共有向けで単価が高く、Standard-IA＋Glacier Flexible も取り出し課金や速度で不利です。アクセス頻度・取得時間・長期保管コストの三要件を俯瞰するとこの構成が最もバランスに優れています。

ヒントボタン

ヒント1: 法的証拠ファイルはアップロード直後に確認作業が集中し、その後は急激に参照が減る性質があります。このようなデータはまずAmazon S3 Standardで多AZの耐久性と高速取込を確保し、ライフサイクルポリシーで60日後にS3 Glacier Deep Archiveへ自動移行させると、12時間以内の標準リストアで復元要件を満たしつつ手動運用が不要になり、長期保管コストも大幅に削減できます。

ヒント2: アクセス頻度が極端に低い非構造化データでは、スループット課金やメタデータI/Oが生じるAmazon EFSより、階層化を自動化できるAmazon S3が費用面で有利です。特にS3 Glacier Deep ArchiveはS3 One Zone-IAの約4分の1のGB単価で、7年間という長期保管では差が拡大します。S3の3AZ冗長設計により証拠喪失リスクも低減でき、月間10TBの増分でも運用はライフサイクル設定でほぼ完結します。

ヒント3: 改ざん防止が必須ならS3 Glacier Vault LockのWORM機能も検討できますが、リクエスト料金やExpeditedリストア費用が高く、取り出し要求が稀な大容量長期保管では総コストが増えやすい点に留意してください。S3 One Zone-IAは単一AZのため災害耐性が落ちます。複数要件を総合すると、取り込み時はStandardで柔軟性を確保し、60日後にDeep Archiveへ段階的に移行するライフサイクル運用が復元時間・コスト・可用性の最も良いバランスとなります。

ヒントボタン

既存のセンサーファイルはAmazon S3に格納され、分析用途のEC2からはPOSIX互換でミリ秒未満の応答と高スループットが求められています。この条件に合うのがHPC向け並列ファイルシステムであるAmazon FSx for Lustreです。S3バケットをリンクすればメタデータだけを取り込み、要求されたオブジェクトを透過的にプリフェッチしつつ非同期で書き戻すため、大量ファイルを扱うジョブでもI/O待ちが最小化され、データサイエンティストはストレージを意識せずに高速処理に集中できます。

Amazon FSx for Lustreはペタバイト級まで自動拡張し、利用容量×利用時間で課金されるため将来的なデータ増にもプロビジョニング作業は不要です。一時成果物が多いワークロードではキャッシュを削除するだけでコストが戻り、保持すべき本番データは耐久性の高いAmazon S3に残る構成となります。これにより追加ノードの手配やレイテンシ評価を都度行う必要がなく、運用負荷とコストの双方を継続的に抑えられます。

共有アクセスを実現できるAmazon EFSは大容量スループット確保のためにプロビジョンドスループット設定が欠かせずコストが増大し、EBS RAID0やEC2 Auto Scalingはノード管理とデータ再同期の手間が発生し、AWS Storage Gatewayはオンプレミス連携前提のため要件に対して過剰です。性能・自動拡張・コスト効率・運用簡素化という複数要件を俯瞰すると、S3ネイティブ連携を持つAmazon FSx for Lustreが最もバランスよく対応できる選択肢だと判断できます。

ヒントボタン

毎月50TBずつ無期限に積み上がるアーカイブで、実際に取り出されるのは月間合計の5%に過ぎず6時間以内に読めればよい、というアクセス特性のワークロードでは、Amazon S3 Standard の即時アクセス性能やリクエスト課金は必要以上に高価になりますので、復元が数時間で完了し保存単価が大幅に低い Amazon S3 Glacier Flexible Retrieval のようなアーカイブ階層へダイレクトに書き込む設計が費用対効果を大きく改善します。
同じコールドストレージでも Amazon S3 Glacier Deep Archive は標準復元で12時間以上が前提となるため6時間以内という取得要求を満たせず、かといって頻繁アクセス向けの Amazon S3 Standard-IA は保存コストが割高になるため、中間に位置しストレージ単価が Standard の約10分の1でありながら標準復元3〜5時間、エクスペダイト数分のオプションまで備える Amazon S3 Glacier Flexible Retrieval が低頻度アクセスと復元時間の両方を両立させる最適ポイントとなります。
gp3 Amazon EBS ボリュームやそのスナップショット保管は IOPS やスループット性能を優先する OLTP 系に向いた高価なブロックストレージで、長期保管用に50TBずつ雪だるま式に増える動画を置くとストレージ料金とスナップショット料金が急増しますから、取得頻度が月5%かつ6時間以内という複数要件を俯瞰した総合判断では、保存単価が最も低く標準復元が要件を満たす Amazon S3 Glacier Flexible Retrieval を即時保存先とする案が最も費用最適となります。

ヒントボタン

4K映像を毎日数 TB 規模で高速に編集する局面では、EC2 から超低レイテンシで直接ブロック I/O を発行できる Amazon EBS io2 Block Express が適しています。Nitro 世代との組み合わせで単一ボリューム最大 256,000 IOPS と 4,000 MB/s 超を引き出せ、ファイルシステムのオーバーヘッドなくアプリがランダム読み書きを処理できるため、動画編集フローをボトルネックなく実現できます。

素材が公開後 90 日を過ぎればアクセス頻度が激減しコスト最小化を優先したい状況では、Amazon S3 Standard に置いたままライフサイクルポリシーで Glacier Deep Archive へ自動遷移させる設計が王道です。取り出し待ち時間が許容できる前提で約 0.1 円/GB/月まで保管費を抑えられ、オブジェクトコピーや削除をスクリプトで管理する運用負荷も不要になるメリットがあります。

Amazon FSx for Lustre や Amazon EFS One Zone-IA も検討余地がありますが、前者は短期バースト後に手動で別ストレージへ移行する運用が発生し、後者はスループットが限定され高解像度編集のレイテンシ要件を満たしにくいです。EBS で編集性能を確保し、S3 のライフサイクルで低コスト長期保管を自動化する構成が、性能・コスト・運用の複数要件を俯瞰した総合的判断として最も整合性が高いでしょう。