Servisphere

モジュール 4 · SAA-C03

ストレージ: S3、EBS、EFS、FSx

S3 のストレージクラスとライフサイクル、暗号化と Object Lock、EBS ブロックボリューム、EFS / FSx のファイルストレージ、Storage Gateway によるハイブリッドストレージ、AWS Backup による一元的なバックアップ。

  • 分野弾力性のあるアーキテクチャ
  • 分野高性能なアーキテクチャ
  • 分野コスト最適化
  • 分野セキュアなアーキテクチャ
  • 図 17
  • 出題パターン 10
  • サービス 9

5 分で押さえる要点

  1. ストレージは 3 種類: オブジェクト (S3)、ブロック (EBS、1 台の EC2 にアタッチ)、ファイル (Linux / NFS 向けの EFS、Windows / SMB・Lustre・ONTAP・OpenZFS 向けの FSx)。試験ではアクセス特性が示され、種類を選ばせる問題がよく出ます: 複数台で同じファイルを読み書き → EFS / FSx、EC2 上のデータベース → EBS、画像・ログ・バックアップ → S3。
  2. S3 の耐久性はイレブンナイン。One Zone-IA と Express One Zone を除くすべてのクラスは ≥ 3 AZ に保存されます。One Zone-IA は再作成できるデータ (2 つ目のコピー、サムネイル) 専用です。
  3. アクセス頻度別の S3 クラス: Standard → Standard-IA (≥ 30 日) → Glacier Instant Retrieval (≥ 90 日、即時取得可) → Glacier Flexible Retrieval (≥ 90 日、数分〜数時間) → Deep Archive (≥ 180 日、最大 12〜48 時間)。最低保存期間より前に削除 / 移行しても、期間分の料金がかかります。IA クラスは 1 オブジェクトあたり最低 128 KB として課金されます。
  4. アクセス頻度がわからない → S3 Intelligent-Tiering (取得料金なし、オブジェクトごとのモニタリング料金あり)。128 KB 未満のオブジェクトはモニタリング対象外で、常に Frequent Access 階層に置かれます。
  5. ライフサイクルルールは、オブジェクトの経過日数に応じてクラスを移行または削除します (旧バージョンや未完了のマルチパートアップロードも対象)。「ログは 30 日間は頻繁に使い、1 年間アーカイブし、7 年後に削除」→ lifecycle transition + expiration。
  6. S3 はすべての Region で PUT / DELETE に対して read-after-write の強い整合性を提供します。「S3 の結果整合性」に触れている選択肢は古い知識です。
  7. 1 回の PUT は最大 5 GB。マルチパートアップロードで最大 50 TB のオブジェクトに対応し、約 100 MB から使うのが推奨です。大きなアップロードがネットワークエラーで失敗する → マルチパート (パートごとに再送)。遠方のクライアント → S3 Transfer Acceleration。
  8. S3 のパフォーマンス: プレフィックスごとに毎秒 3,500 以上の PUT/COPY/POST/DELETE と 5,500 以上の GET/HEAD。プレフィックスを増やせば比例して増えます。503 Slow Down が出る → キーを複数のプレフィックスに分散し、並列で読み込む (byte-range fetch)。
  9. レプリケーション (CRR は別 Region、SRR は同一 Region) には両側でバージョニングの有効化が必要。既存オブジェクトはコピーされないため S3 Batch Replication を使います。S3 RTC は新規オブジェクトの 99.99% を 15 分以内に複製することを保証します。DR や地理的距離に関するコンプライアンス → CRR。複数アカウントのログ集約 → SRR。
  10. 削除からの保護: バージョニング + MFA Delete、Object Lock (WORM、governance / compliance モード)、AWS Backup Vault Lock。「root を含め誰も 7 年間削除できない」という規制 → Object Lock compliance モード。
  11. EBS は 1 つの AZ に紐づきます。別の AZ / Region へ移すにはスナップショットを取って再作成します。gp3 は IOPS / スループットを容量と切り離して設定でき、io2 Block Express は非常に高い IOPS と Multi-Attach に対応します。80,000 を超える安定した IOPS が必要なデータベース → io2。大きなシーケンシャル処理を安く → st1。アクセスが少なく最安 → sc1。
  12. インスタンスストアは物理ホストに備わったディスクです。非常に高速ですが、stop / terminate でデータが消えます。キャッシュ、バッファ、他に複製のある一時データ専用です。
  13. EFS: 複数 AZ の数千台で共有できる NFS ファイルシステムで、自動で拡張。Standard / Infrequent Access / Archive クラスがあり、ライフサイクルで自動移行します。複数の EC2 / Lambda / Linux コンテナが同じディレクトリを必要とする → EFS。Windows + Active Directory → FSx for Windows。
  14. オンプレミスとのハイブリッド: Storage Gateway (File: NFS、SMB 経由で S3 / FSx、Volume: iSCSI、Tape: 磁気テープの置き換え)、DataSync (1 回 / 定期的なデータコピー)、Snowball (回線が足りないときのオフライン転送)。「オンプレミスのアプリはそのままで S3 に保存したい」→ File Gateway。「500 TB を 100 Mbps の回線で移行」→ Snowball。

構成図

ライフサイクル: オブジェクトの経過日数で S3 クラスを移行

ライフサイクル: オブジェクトの経過日数で S3 クラスを移行Bucket: logs/ · lifecycle rule30日190日21年27年3Standard0日目Standard-IA≥ 30日Glacier IR≥ 90日Deep Archive≥ 180日削除expiration 7年
ライフサイクルルールは、経過日数に応じてオブジェクトをより安いクラスへ順に移し、最後に削除します。各クラスには最低保存期間があり、早めに移行・削除しても期間分の料金がかかります。

ステップ

  1. 最初の 30 日は頻繁に読まれるので Standard。その後 Standard-IA へ移行します (即時取得可、取得料金あり)。
  2. 読まれなくなるほど安いアーカイブクラスへ移します。Deep Archive は読む前に復元 (12 時間以内) が必要です。
  3. 規定の保持期間が終わったら expiration で自動削除します。

DR のための S3 Cross-Region Replication

DR のための S3 Cross-Region Replicationap-southeast-1ap-northeast-1PUT1111回だけ複製2アプリ複製元versioning ON複製先versioning ONCRR + RTC15分Batch Replication既存分
両方のバケットでバージョニングを有効にします。新規オブジェクトは別 Region へ非同期で複製され (RTC: 99.99% を 15 分以内)、既存オブジェクトには Batch Replication を使います。

ステップ

  1. 新規オブジェクト: レプリケーションルールが別 Region のバケットへ非同期で複製し、メタデータとバージョン ID を保持します。
  2. ルール有効化前からあるオブジェクト: S3 Batch Replication を実行します。

S3 Event Notifications

S3 Event Notifications送信11122ユーザーS3ObjectCreatedLambdaサムネイルSQS後で処理EventBridge絞込・複数宛先Step Functions
オブジェクトが作成 / 削除されると、S3 は SNS、SQS、Lambda、EventBridge にイベントを送ります。EventBridge なら詳細なフィルタリングと複数の宛先が使えます。

ステップ

  1. プレフィックスとファイル拡張子に応じて、イベントを Lambda / SQS / SNS に直接送ります。
  2. EventBridge への送信を有効にすると、複数のフィールドで絞り込み、20 種類以上の宛先に届けられます。

presigned URL で S3 に直接アップロード

presigned URL で S3 に直接アップロードAppBackendS31. 送信許可を要求2. presigned URL 署名 (15分)3. 署名URL4. URLで画像をPUT5. 200 OK
サーバーは 1 オブジェクトだけを対象にした期限付き URL に署名するだけです。データはクライアントから S3 へ直接送られ、アクセスキーは漏れません。

大きなファイルのマルチパートアップロード

大きなファイルのマルチパートアップロードClientS31. CreateMultipartUpload2. UploadId3. UploadPart 1..N (並列)4. パート7失敗: パート7を再送5. CompleteMultipartUpload6. オブジェクト完成
ファイルを複数のパートに分けて並列にアップロードし、失敗したパートだけを再送します。5 GB を超えるオブジェクトには必須で、約 100 MB から使うのが推奨です。

EBS、EFS、FSx: どれが何に接続できるか

EBS、EFS、FSx: どれが何に接続できるかRegionAZ aAZ bblock1NFS2NFS2SMB3EC2 LinuxEBS gp3AZ aのみEC2 LinuxEC2 WindowsEFSNFS・複数AZFSx for WindowsSMB + AD
EBS は同じ AZ の EC2 1 台にアタッチします。EFS は各 AZ にマウントターゲットを持ち、複数の Linux マシンで共有します。FSx for Windows は Windows マシン向けに SMB を使います。

ステップ

  1. EBS: 1 台のマシン用のブロックボリュームで、同じ AZ 内。
  2. EFS: 複数 AZ の複数の Linux マシンが同じファイルシステムをマウント。
  3. FSx for Windows: SMB 共有、権限は Active Directory に基づく。

EBS スナップショット: ボリュームを別の AZ や Region へ

EBS スナップショット: ボリュームを別の AZ や Region へメインRegionDR RegionAZ aAZ b取得1再作成2定期1別Regionへコピー3VolumeSnapshotRegion単位新VolumeData Lifecycle ManagerSnapshot copy
スナップショットは Region レベルに保存される増分コピーです。スナップショットから別 AZ にボリュームを作成でき、DR のために別 Region へコピーすることもできます。Data Lifecycle Manager はスケジュールに従って自動で取得します。

ステップ

  1. スケジュールに従ってスナップショットを取得します (Data Lifecycle Manager または AWS Backup)。2 回目以降は変更分だけを保存します。
  2. スナップショットから別 AZ に新しいボリュームを作成します。これが EBS を別 AZ へ「移す」唯一の方法です。
  3. Region 全体の障害に備えて、スナップショットを別 Region にコピーします。

Storage Gateway でオンプレミスと S3 / Glacier を接続

Storage Gateway でオンプレミスと S3 / Glacier を接続データセンターAWS1object12snapshot23テープ3File serveriSCSI アプリBackup ソフトFile GatewayNFS / SMBVolume GatewayiSCSITape GatewayVTLS3EBS snapshotGlacier保管テープ
Gateway はオンプレミス (VM またはアプライアンス) で動作し、アプリは従来どおり NFS/SMB、iSCSI、テープを使いながら、データは AWS に置かれます。

ステップ

  1. File Gateway: NFS/SMB で書き込まれたファイルが S3 のオブジェクトになり、ローカルキャッシュも持ちます。
  2. Volume Gateway: iSCSI ボリュームで、データ / スナップショットは AWS に置かれます。
  3. Tape Gateway: バックアップソフトが仮想テープに書き込み、S3 Glacier にアーカイブされます。

AWS Backup: 複数サービスを 1 つのプランで

AWS Backup: 複数サービスを 1 つのプランでメインRegionDR Region111保存2複製3EC2 / EBSRDSEFSBackup plantag backup=dailyVault + Vault LockWORMDR Vault
Backup plan がタグでリソースを選び、スケジュールに従って vault に取得します。Vault Lock で削除を防ぎ、DR のために別 Region / 別アカウントへコピーします。

ステップ

  1. 1 つの backup plan を、タグの付いたすべてのリソースに複数のサービスをまたいで適用します。
  2. 復旧ポイントは vault に保存され、Vault Lock (WORM) により期限前には誰も削除できません。
  3. 別 Region (または別アカウント) へ自動コピーし、Region 障害やアカウントへの攻撃に備えます。

EBS ボリュームタイプの選択

EBS ボリュームタイプの選択YesNo1YesNoYesNo2大きなブロックの順次読み書き (ログ、ビッグデータ、DWH)?頻繁にアクセス?80,000 IOPS / 2,000 MiB/s超、遅延1 ms未満、Multi-Attachが必要?st1: スループット最適化 HDDsc1: 最安の HDD、低頻度アクセスio2 Block Express: 最大256,000 IOPSgp3: デフォルト、最大80,000 IOPS、ブート可
gp3 がデフォルトの選択肢です。gp3 を超える IOPS / スループット、安定した 1 ms 未満のレイテンシー、または Multi-Attach が必要なときだけ io2 Block Express にします。st1 / sc1 (HDD) はブートボリュームにできません。

ステップ

  1. データベース、ブートボリューム、トランザクション処理のアプリ: 小さくランダムな I/O → SSD 系。
  2. 大半のケース: gp3 で、IOPS とスループットを容量とは独立に調整します。

S3 のデータ暗号化方式: キーを持つのは誰か

S3 のデータ暗号化方式: キーを持つのは誰かHTTPSでPUT1122毎回キーを送信3暗号化済み4アプリClient側暗号化送信前に暗号化S3 bucket既定 SSE-S3SSE-S3キーはS3が管理SSE-KMSKMSキー、CloudTrailログDSSE-KMS二重暗号化SSE-C自前のキー
2023 年 1 月 5 日以降、すべての新規オブジェクトは追加料金なしで SSE-S3 により暗号化されます。key policy でキーを自分で管理し、キー使用のたびに CloudTrail ログを残したいときは SSE-KMS、2 層目の暗号化を加えるなら DSSE-KMS、キーを自分で保持するなら SSE-C、S3 に平文データを一切見せないならクライアント側暗号化を選びます。

ステップ

  1. デフォルト: 新規オブジェクトは S3 管理のキーで SSE-S3 により暗号化されます。
  2. SSE-KMS / DSSE-KMS: KMS キーを使い、key policy で制御し、キー使用のたびに CloudTrail に記録されます。
  3. SSE-C: リクエストごとにキーを送ります。S3 は使用後にキーを保存しません。
  4. クライアント側暗号化: データは手元のマシンを離れる前に暗号化済みです。

S3 のバージョニング: 現行バージョン、旧バージョン、削除マーカー

S3 のバージョニング: 現行バージョン、旧バージョン、削除マーカー上書きPUT1通常DELETE → delete marker2delete marker削除/再コピー3version id指定 DELETElifecycle / version id指定 DELETE4現行バージョンGET で返されるNoncurrentversion id で取得可完全に削除済み
バージョニングを有効にすると、上書きや削除でデータは失われません。旧バージョンは noncurrent になり、通常の削除は delete marker を追加するだけです。version id を指定した DELETE だけがバージョンを完全に削除します。コスト削減にはライフサイクルで noncurrent バージョンを削除します。

ステップ

  1. 上書き: 新しいバージョンが現行になり、古いバージョンは noncurrent になります。
  2. version id なしの DELETE: S3 は delete marker を追加し、GET は 404 を返しますが、データは残っています。
  3. 復元: delete marker を削除します (または旧バージョンをコピーして現行にします)。
  4. ライフサイクル (NoncurrentVersionExpiration) で N 日後に旧バージョンを完全削除し、コストを削減します。

S3 Object Lock: governance、compliance、legal hold

S3 Object Lock: governance、compliance、legal holdBucket: Versioning + Object Lockbypass ヘッダーで削除140314033403、root も2bypass権限保持者一般ユーザーRootGovernance保持期間 90日Legal hold解除までCompliance保持期間 7年
Object Lock (WORM) はバージョニングが有効なバケットでのみ動作し、バージョン単位でロックします。Governance: s3:BypassGovernanceRetention 権限を持つ人は削除できます。Compliance: 期限まで root を含め誰も削除・短縮できません。Legal hold: 期限がなく、解除されるまで保持されます。

ステップ

  1. Governance: ほとんどのユーザーをブロックしますが、bypass 権限を持つ人は削除 / 変更できます (事前のテストに向いています)。
  2. Compliance: root を含め誰もそのバージョンを期限前に削除できません。期限は延長のみ可能で、短縮はできません。
  3. Legal hold: 期限のないロックで、s3:PutObjectLegalHold を持つ人だけが解除できます。

S3 Access Points: チームごとに専用の入り口

S3 Access Points: チームごとに専用の入り口VPC1212分析チーム財務アプリ社内ジョブAP analyticsanalytics/ のみAP financefinance/読取専用VPC専用 APnetwork origin: VPCS3 データレイク
全チーム向けの長い bucket policy 1 つの代わりに、各 access point が独自のポリシーを持ち (例: 1 つのプレフィックスのみ)、1 つの VPC からのリクエストのみ受け付けるようにもできます。access point のポリシーは bucket policy と併せて適用されます。access point はオブジェクト操作にのみ使います。

ステップ

  1. 各チームは、自分のプレフィックスだけを開放するポリシーを持つ専用の access point を使います。
  2. network origin が VPC の access point: インターネットからのリクエストは拒否されます。

EFS: 複数 AZ で共有する 1 つのファイルシステム、アクセス頻度別のストレージクラス

EFS: 複数 AZ で共有する 1 つのファイルシステム、アクセス頻度別のストレージクラスRegionAZ aAZ bNFS1NFS1lifecycle2lifecycle2再アクセス3EC2EC2EFS file systemthroughput ElasticStandard~1 msInfrequent Access安価Archive最安、低頻度
EFS Regional はデータを複数の AZ にまたがって保存し、どの AZ のマシンも NFS で同じものをマウントします。ライフサイクルは、あまり使われないファイルを Standard (レイテンシー約 1 ms) から Infrequent Access、さらに Archive (レイテンシー数十 ms、より安価) へ移します。AWS は Elastic スループットと General Purpose モードを推奨しており、Max I/O は旧世代です。

ステップ

  1. 複数 AZ のマシンが NFS で 1 つのファイルシステムをマウントします。
  2. ライフサイクルが長く読まれていないファイルを IA、さらに Archive へ移し、コストを削減します。
  3. 再び読まれたファイルを Standard に戻すよう設定することもできます。

HPC / ML 向けに S3 と連携する FSx for Lustre

HPC / ML 向けに S3 と連携する FSx for LustreHPC/ML環境自動 import1結果を export3222S3元データFSx for Lustre/data ↔ s3://bucket/data/計算ノード計算ノード計算ノード
FSx for Lustre は計算クラスタ向けの非常に高性能なファイルシステムです。data repository association (最大 8 個) でディレクトリを S3 のバケット / プレフィックスに関連付けます。S3 からメタデータを読み込み、ファイルは必要時に読み込まれ、結果は S3 へ自動でエクスポートされます。

ステップ

  1. S3 内のデータのメタデータを読み込み、ファイルの中身は必要時に取得します。
  2. クラスタ全体が非常に高いスループットと低レイテンシーで並列に読み書きします。
  3. 作成 / 変更されたファイルは長期保存のため S3 へエクスポートされます。

ストレージサービスの選択

ストレージサービスの選択1台用のディスク共有ファイル1APIでobject2Linux, NFSWindows, SMB1HPC / MLYes/予測困難稀・長期保存2データの使い方は?EBSファイルシステムをマウントするのは?頻繁にアクセス?EFSFSx for WindowsFSx for LustreS3 Standard / Intelligent-TieringS3 Glacier
まず分類します: ブロック (1 台)、ファイル (複数台で共有)、オブジェクト (API 経由)。次に OS / プロトコルとアクセス頻度で選びます。

ステップ

  1. Windows マシン、Active Directory 向けのファイル共有: FSx for Windows File Server。
  2. 長年保存し、ほとんど読まない: S3 Glacier (Flexible Retrieval / Deep Archive)。

比較表

S3 のストレージクラス

クラス取得最低保存期間AZ用途
Standardミリ秒なし≥ 3頻繁なアクセス
Intelligent-Tieringミリ秒 (オプションのアーカイブ階層は復元が必要)なし≥ 3アクセス頻度が不明 / 変動する
Standard-IAミリ秒、取得料金あり30 日≥ 3アクセスが少ない (月 1 回程度)、再作成できない
One Zone-IAミリ秒、取得料金あり30 日1アクセスが少ない、再作成できる
Glacier Instant Retrievalミリ秒90 日≥ 3アーカイブ、四半期に 1 回程度、即時取得が必要
Glacier Flexible Retrieval1〜5 分 / 3〜5 時間 / 5〜12 時間90 日≥ 3アーカイブ、取得を待てる
Glacier Deep Archive12 時間以内 / 48 時間以内180 日≥ 3長年のアーカイブ、最安
Express One Zone1 桁ミリ秒なし1超低レイテンシーが必要な処理、コンピューティングの近くに配置

EBS、EFS、FSx、S3

EBSEFSFSx for WindowsS3
種類ブロックファイル (NFS)ファイル (SMB)オブジェクト (HTTP API)
接続先同じ AZ の EC2 1 台 (io1/io2: Multi-Attach)複数 AZ の数千クライアントWindows マシン、Active Directory 連携API 経由でどこからでも
範囲1 つの AZRegion (または One Zone)Single-AZ または Multi-AZRegion
向いている用途OS ボリューム、EC2 上のデータベースLinux 共有ディレクトリ、CMS、MLホームディレクトリ、Windows アプリ画像、ログ、バックアップ、データレイク

EBS ボリュームタイプ

タイプ種別最大 IOPS最大スループット備考
gp3汎用 SSD80,0002,000 MiB/sIOPS / スループットを容量と別に指定
gp2汎用 SSD16,000250 MiB/sIOPS は容量に比例
io2 Block Express高 IOPS SSD256,0004,000 MiB/s耐久性 99.999%、Multi-Attach
io1高 IOPS SSD64,0001,000 MiB/sMulti-Attach
st1スループット最適化 HDD500500 MiB/sビッグデータ、ログ。ブートボリューム不可
sc1コールド HDD250250 MiB/s最安。ブートボリューム不可

S3 の暗号化

方式キーの管理者備考
SSE-S3S3すべての新規オブジェクトのデフォルト
SSE-KMSKMS (AWS managed キーまたは自分のキー)CloudTrail ログあり、キー使用権限を制御可能。KMS 呼び出しごとに課金 (S3 Bucket Key で削減)
DSSE-KMSKMS、二層の暗号化二層の暗号化を求めるコンプライアンス要件向け
SSE-Cリクエストごとに利用者がキーを送信S3 はキーを保存しない
クライアント側暗号化利用者送信前にデータを暗号化済み

オンプレミスのデータを AWS に移す

方式使うとき
Storage Gateway – S3 File Gatewayオンプレミスのアプリが NFS / SMB で読み書きし、データは S3 に置き、ローカルにキャッシュ
Storage Gateway – Volume GatewayiSCSI ボリューム: cached (プライマリデータは AWS) または stored (プライマリデータはオンプレミス、スナップショットを AWS へ)
Storage Gateway – Tape Gatewayテープを使うバックアップソフトで、物理テープを S3 / Glacier に保存される仮想テープライブラリに置き換え
DataSyncNFS、SMB、HDFS、S3、EFS、FSx 間で大量データをネットワーク経由でコピー / 同期
Snowball Edge数十〜数百 TB でネットワークが遅すぎる場合、デバイスで輸送
Transfer Family取引先が SFTP / FTPS / FTP で S3 または EFS にファイルを送信

よく出る出題パターン

1ログは最初の 30 日間は頻繁にアクセスされ、その後はほぼ誰も読みませんが 7 年間保持する必要があります。監査時には 12 時間以内に取得する必要があります。

答えを見る

正解: ライフサイクル: Standard で 30 日 → Glacier Deep Archive、7 年後に expiration
Deep Archive が最安で、Standard 取得の 12 時間以内で監査要件を満たせます。

不正解: すべて S3 Standard に置いたままにする
何年も放置されるデータには最も高くつきます。

不正解: すぐに Deep Archive へ移行する
最初の 30 日間は頻繁なアクセスが必要です。

2ユーザーがアップロードしたデータのアクセス頻度が予測できません。ルールを書かずにコストを最適化したいです。

答えを見る

正解: S3 Intelligent-Tiering
実際のアクセスに応じて自動で階層を移行し、取得料金はかかりません。

不正解: ライフサイクルで 30 日後に Standard-IA へ移行
頻繁に読み直されるオブジェクトは取得料金がかさみます。

3サムネイルは元画像からいつでも再作成できます。アクセスはまれで、即時取得できる中で最安にしたいです。

答えを見る

正解: S3 One Zone-IA
Standard-IA より安価です。AZ を失っても元画像から再作成できます。

不正解: Glacier Flexible Retrieval
復元が必要で、即時取得できません。

4規制により、取引記録は root アカウントを含め誰も 5 年間変更・削除できないようにする必要があります。

答えを見る

正解: S3 Object Lock の compliance モード、保持期間 5 年
root を含め誰も期限前に短縮・削除できません。

不正解: バージョニングと MFA Delete を有効化
権限と MFA を持つ人は削除できてしまいます。

不正解: Object Lock の governance モード
特別な権限を持つ人は回避できてしまいます。

5DR のために、複製時間が保証された S3 データのコピーを別 Region に置く必要があります。バケットには既に数百万の既存オブジェクトがあります。

答えを見る

正解: 両側でバージョニングを有効化し、S3 Replication Time Control 付きの CRR を設定、既存オブジェクトには S3 Batch Replication を実行
RTC は新規オブジェクトの 99.99% を 15 分以内に複製することを保証し、Batch Replication が既存分をコピーします。

不正解: CRR を有効にするだけ
CRR は有効化後の新規オブジェクトしかコピーしません。

6モバイルアプリで、ユーザーが大きなファイルをアプリサーバーを経由せず S3 に直接アップロードできるようにしたいです。アクセスキーは漏らせません。

答えを見る

正解: バックエンドがアップロードごとに (期限付きの) presigned URL を生成し、クライアントが S3 に直接 PUT する (大きければマルチパート)
一時的な権限で、対象は 1 オブジェクトのみ。サーバーがデータを中継する必要もありません。

不正解: アクセスキーをアプリに埋め込む
認証情報が漏えいします。

不正解: バケットをパブリック書き込み可にする
誰でも書き込めてしまいます。

73 つの AZ にある多数の Linux EC2 が同じ共有ディレクトリを読み書きする必要があり、容量の増加は予測できません。

答えを見る

正解: Amazon EFS (各 AZ にマウントターゲット)
複数 AZ で共有できる NFS で、容量は自動で伸縮します。

不正解: EBS Multi-Attach
1 つの AZ 内のみ、io1/io2 のみで、同時書き込みはアプリ側で処理する必要があります。

不正解: S3 をディスクとしてマウント
S3 はオブジェクトストレージであり、POSIX ファイルシステムではありません。

8Windows アプリに、Active Directory と統合され、1 つの AZ の障害に耐えられる SMB ファイル共有が必要です。

答えを見る

正解: FSx for Windows File Server の Multi-AZ デプロイ
ネイティブ SMB、Active Directory による認証、別 AZ にスタンバイを持ちます。

不正解: EFS
EFS は Linux 向けの NFS です。

9オンプレミスの分析部門は、アプリの NFS での読み書きはそのままにしつつ、AWS で処理するためにデータを S3 に置きたいと考えています。

答えを見る

正解: S3 File Gateway
オンプレミスに NFS / SMB を公開し、S3 にオブジェクトとして書き込み、最近読んだデータをキャッシュします。

不正解: DataSync を 1 時間ごとに実行
定期コピーにすぎず、アプリは引き続きオンプレミスのサーバーに書き込みます。

10400 TB を 2 週間で S3 に移行する必要がありますが、回線は 200 Mbps しかありません。

答えを見る

正解: 複数台の Snowball Edge
デバイスでオフライン転送するため、回線に依存しません。

不正解: インターネット経由の DataSync
200 Mbps では 400 TB に約 6 か月かかります。

早見表

データをどこに保存するか?

やりたいこと使うもの
ファイル、画像、ログ、バックアップ、データレイクS3 (アクセス頻度でクラスを選択) · 図を見る
EC2 1 台用のボリューム、自己管理のデータベースEBS (gp3、高 IOPS なら io2) · 図を見る
複数の Linux マシンで共有するディレクトリEFS · 図を見る
Windows / Active Directory のファイル共有FSx for Windows File Server · 図を見る
HPC で S3 のデータを高速に読むFSx for Lustre · 図を見る
別 Region に S3 のコピーCRR (保証された時間が必要なら + RTC) · 図を見る
規制により削除 / 変更を禁止S3 Object Lock (compliance) または Backup Vault Lock · 図を見る
クライアントから S3 へ安全に直接アップロードPresigned URL · 図を見る
大きなファイル、不安定なネットワークマルチパートアップロード (遠方なら + Transfer Acceleration) · 図を見る
NFS/SMB/iSCSI/テープを使うオンプレミスのアプリ、保存先は AWSStorage Gateway · 図を見る
複数サービス・複数アカウントのバックアップを一元化AWS Backup · 図を見る

落とし穴

  • 唯一の、再作成できないデータに One Zone-IA を選ぶ。
  • 最低保存期間の料金を忘れる: Standard-IA のオブジェクトを 10 日後に削除しても 30 日分課金。Glacier は 90 日、Deep Archive は 180 日。
  • 非常に小さなオブジェクト (< 128 KB) を IA クラスに置く: 128 KB として課金される。
  • Glacier Flexible Retrieval / Deep Archive をすぐ読めると思い込む: 先に復元が必要。
  • バージョニングを忘れて CRR を有効にする、または CRR が既存オブジェクトもコピーすると思い込む。
  • EBS を別の AZ で使えると思い込む: スナップショットを取って新しいボリュームを作る必要がある。
  • 重要なデータをインスタンスストアに保存する。
  • Windows マシンに EFS を使う (EFS は NFS)、または NFS だけの Linux に FSx for Windows を使う。
  • Object Lock の governance (権限があれば解除できる) と compliance (誰も解除できない) を混同する。
  • st1 / sc1 をブートボリュームに使う。
  • 期限が迫る中、数百 TB を遅い回線で DataSync する: Snowball の方が速い。
  • S3 は結果整合性のみ、またはオブジェクトは最大 5 TB と思い込む: 現在は強い整合性で、マルチパートで最大 50 TB。

このモジュールのサービス

変わりやすい数値 (AWS ドキュメントで確認済み)

  • 最低保存期間: Standard-IA と One Zone-IA は 30 日、Glacier Instant Retrieval と Flexible Retrieval は 90 日、Deep Archive は 180 日。IA と Glacier IR は 1 オブジェクトあたり最低 128 KB として課金。 2026-10-16 確認 ↗
  • S3 の耐久性は 99.999999999%。One Zone-IA と Express One Zone を除くすべてのクラスは ≥ 3 AZ に保存。 2026-10-16 確認 ↗
  • Glacier Flexible Retrieval: Expedited 1〜5 分、Standard 3〜5 時間、Bulk 5〜12 時間。Deep Archive: Standard 12 時間以内、Bulk 48 時間以内。 2026-10-16 確認 ↗
  • 1 回の PUT は最大 5 GB。マルチパートアップロードで最大 50 TB のオブジェクト。コンソールからのアップロードは最大 160 GB。 2026-10-16 確認 ↗
  • S3 はプレフィックスごとに毎秒 3,500 以上の PUT/COPY/POST/DELETE と 5,500 以上の GET/HEAD を処理。 2026-10-16 確認 ↗
  • S3 RTC は新規オブジェクトの 99.99% を 15 分以内に複製。通常のレプリケーションは既存オブジェクトをコピーしない (Batch Replication を使用)。 2026-10-16 確認 ↗
  • S3 はすべての Region で PUT と DELETE に対して read-after-write の強い整合性を提供。 2026-10-16 確認 ↗
  • EBS gp3: 最大 80,000 IOPS、2,000 MiB/s、1 GiB〜64 TiB。io2 Block Express: 最大 256,000 IOPS、4,000 MiB/s。Multi-Attach は io1/io2 のみ。st1/sc1 はブートボリューム不可。 2026-10-16 確認 ↗
  • EFS には Standard (ミリ秒未満のレイテンシー)、Infrequent Access と Archive (数十ミリ秒) のクラスがある。One Zone の SLA は 99.9%、Regional は 99.99%。 2026-10-16 確認 ↗
  • FSx for Windows File Server は SMB を使用し、Active Directory で認証、Single-AZ と Multi-AZ のデプロイがある。 2026-10-16 確認 ↗
  • Storage Gateway には S3 File Gateway、FSx File Gateway、Volume Gateway (cached / stored、iSCSI)、Tape Gateway がある。 2026-10-16 確認 ↗
  • 2023 年 1 月 5 日以降、S3 のすべての新規オブジェクトはデフォルトで SSE-S3 により暗号化。その他の選択肢: SSE-KMS、DSSE-KMS、SSE-C、クライアント側暗号化。 2026-10-19 確認 ↗
  • Object Lock はバージョニングが有効なバケットでのみ動作。compliance は root を含め誰も削除できない。governance は s3:BypassGovernanceRetention を持つ人に許可。legal hold には期限がない。 2026-10-19 確認 ↗
  • EFS: AWS は Elastic スループットと General Purpose モードを推奨。Max I/O は旧世代。Standard の読み取りレイテンシーは約 1 ms、IA / Archive は数十 ms。 2026-10-19 確認 ↗
  • FSx for Lustre: S3 との data repository association は最大 8 個、自動インポート / エクスポートに対応。 2026-10-19 確認 ↗
  • 各 S3 access point は独自のポリシーを持ち、1 つの VPC からのリクエストのみ受け付けるようにできる。オブジェクト操作に使用。 2026-10-19 確認 ↗
このモジュールの問題を解く →