Amazon SAA-C03: ストレージとデータライフサイクル — 学習ガイド

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

こちらの一部です： AWS SAA-C03 — 完全学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

S3ストレージクラスとコスト/レイテンシースペクトラム

S3ストレージクラスは、GBあたりのストレージコストに対して、取得レイテンシー、最低ストレージ期間、GBあたりの取得料金をトレードオフの関係で位置づけられています。適切なクラスを選択することは、オブジェクトストレージのコストを最適化するための最も大きな手段です。

S3 Standardはデフォルトです。3つ以上のアベイラビリティーゾーン（AZ）にまたがるイレブンナインの耐久性、ミリ秒単位のレイテンシー、取得料金なし、GBあたりの価格が最も高い、という特徴があります。Standard-IAとOne Zone-IAは、ストレージコストを約40〜50%削減しますが、GBあたりの取得料金、30日間の最低課金期間、128 KBの最小オブジェクトサイズが追加されます（小さいオブジェクトは128 KBとして課金され、節約効果が薄れます）。One Zone-IAは単一のAZに保存することでさらにコストを削減します。これは、単一AZの損失が許容できる、再現可能なセカンダリコピーにのみ適しています。

S3 Intelligent-Tieringは、アクセスパターンが不明、予測不能、または大規模なコーパス全体で変化する場合に正しい選択です。観測されたアクセスに基づいて、オブジェクトを頻繁アクセス、低頻度アクセス、アーカイブ即時、アーカイブ、ディープアーカイブの各階層間で自動的に移行し、オブジェクトごとに小さなモニタリング料金を請求します。頻繁アクセス階層と低頻度アクセス階層の間には取得料金がなく、最低期間もないため、128 KB以上のオブジェクトを持つデータレイクや混合ワークロードにとって最も安全なデフォルトです。オブジェクトが恒久的にホットである（追加のモニタリングコストがかかる）か、10年間恒久的にコールドである（Deep Archiveの方がはるかに安い）ことがすでにわかっている場合には、誤った選択です。

Glacier Instant Retrievalは、四半期に一度以下しかアクセスされないデータ（医療画像、要求されたときに即座に提出する必要があるコンプライアンスPDFなど）に対して、アーカイブ価格でミリ秒単位のアクセスを提供します。Glacier Flexible Retrievalは、分から時間単位の取得を提供します。Glacier Deep Archiveは、AWSで最も安価な階層で、月額約$1/TB、標準で12時間（またはバルクで48時間）の取得時間、180日間の最低期間を持ちます。7〜10年の規制上の保持要件やテープの置き換えに最適な選択肢です。

主なコストの罠は、2つの正反対の間違いです。長期間ほとんど読み取られないデータにStandardを選択すると、Standardにはコールドストレージの価格割引がないため、お金を無駄にします。数年間Standardに保持された5 TBのデータセットは、同じデータをDeep Archiveに保存した場合の数倍のコストがかかります。逆に、新しいオブジェクトをすぐにStandard-IAやGlacierに移行するのは罠です。オブジェクトがまだホットな場合、30/90/180日間の最低料金と取得料金が、節約額を上回ってしまうためです。Glacier FlexibleやDeep Archiveは、同期的な読み取りを期待するワークロードとは完全に互換性がありません。HTTP GETを待っているユーザーは、分から12時間の取得SLAを許容できません。Glacier Instant Retrievalは、即時アクセスと互換性のある唯一のGlacier階層です。

ライフサイクルポリシーとバージョニングの処理

ライフサイクル設定は、バケットに添付される宣言的なJSON/YAMLで、オブジェクトの経過日数、タグ、またはプレフィックスに基づいてオブジェクトを移行または失効させます。移行は1日1回評価され、指定された経過日数に達した後にのみ実行されます。Days: 30の移行は、最初の30日間はStandardの料金が適用されることを意味します。移行は、よりコールドな階層へと段階的に行われなければならず、128 KB未満のオブジェクトは、オブジェクトごとのオーバーヘッドが節約額を上回るため、StandardからIAには移行されません。まずtar/zipやS3 Batch Operationsで小さなオブジェクトを統合してください。

30日間ホットで、その後はコールドになり、期間を通して即時アクセスが必要で、4年間保持され、適切な衛生管理が行われるワークロードの標準的なポリシーは次のとおりです。

Rules:
  - ID: archive-and-clean
    Status: Enabled
    Transitions:
      - Days: 30
        StorageClass: STANDARD_IA
      - Days: 180
        StorageClass: DEEP_ARCHIVE
    NoncurrentVersionTransitions:
      - NoncurrentDays: 30
        StorageClass: GLACIER
    NoncurrentVersionExpiration:
      NoncurrentDays: 365
    Expiration:
      Days: 1460
    AbortIncompleteMultipartUpload:
      DaysAfterInitiation: 7

バージョニング処理でよくある罠は、バージョニングが有効なバケットで、現行バージョンを失効させるライフサイクルルールは削除マーカーを挿入するだけで、以前のバージョンは静かに蓄積され、課金され続けることです。非現行バージョンには、独自の明示的なNoncurrentVersionTransitionsとNoncurrentVersionExpirationが必要です。同様に、常にAbortIncompleteMultipartUploadを含めるべきです。孤立したマルチパートアップロードのパーツはコンソールのリストには表示されず、無期限にストレージ料金が発生します。

混合パターンの場合、例えば、最初の1ヶ月はMLトレーニングでホットになり、その後1年間は四半期ごとにクエリされ、その後はアーカイブされるIoTテレメトリのようなケースでは、最初の1年間はIntelligent-Tieringを使用し（トレーニングのバーストとアイドル日の間でクラスが自動最適化されるようにする）、その後365日目にDeep Archiveへのスケジュールされた移行を行うのが正解です。

バージョニング、MFA削除、オブジェクトロック

バージョニングは一度有効にすると、停止のみ可能で、無効化はできません。すべてのPUTは新しいバージョンIDを作成し、DELETEはデータを削除するのではなく、削除マーカーを挿入します。バージョニングは偶発的な上書きから保護しますが、不変性ではありません。s3:DeleteObjectVersionを持つプリンシパルは、特定のバージョンを恒久的に削除できます。MFA削除は、ルートアカウントがバージョンを恒久的に削除したり、バージョニングの状態を変更したりする際にMFAトークンを提示することを要件として追加します。これにより、価値の高いバケットにおける偶発的な削除のギャップを埋めますが、権限を持つアクターによるデータ破壊を防ぐことはできません。

真の不変性を実現するにはS3オブジェクトロックが必要です。これにはバージョニングが必要で、通常、バケット作成時に有効にする必要があります。これにはよく混同される2つのモードがあります。

リテンションはオブジェクトごとに (Retain-Until-Date)、または有効期限のないリーガルホールドを介して適用できます。会計記録で、1年間はホット、9年間はアーカイブ、そして10年間は削除不可という要件がある場合、正しいパターンは、コンプライアンスモードのオブジェクトロックで10年間のリテンション期間を設定し、365日目にDeep Archiveへのライフサイクル移行を組み合わせることです。ガバナンスは法的要件の代替として許容されません。規制当局は、「権限を持つ誰かがこれを削除できた可能性がある」という状態を不変性とは認めません。

既存のPDF群に単一のジョブでリテンションを適用するには、S3インベントリのマニフェストを利用してS3バッチオペレーションを使用します。バッチオペレーションは、リテンション、タグ付け、PUTコピーによる再暗号化、Lambdaの呼び出しなど、数十億のキーにわたる大規模な変更操作に対するマネージドな解決策です。手書きの反復処理スクリプトは適切なパターンではありません。

暗号化: SSE-S3、SSE-KMS、バケットキー

すべてのバケットにはデフォルト暗号化が設定されています。SSE-S3 (AES-256、S3マネージドキー) は無料で、キー管理は不要です。SSE-KMSはKMSのカスタマーマスターキーを使用し、キーごとのCloudTrail監査証跡、IAMベースのキーアクセスポリシー、キーローテーションの制御を可能にします。その代償として、KMS APIの料金、そしてより重要な点として、高スループットの読み取りワークロードのボトルネックになりうるKMSリクエストのスロットリングが発生します。これらの制御（規制準拠の証明、職務分掌、クロスアカウントでのキー共有）が実際に必要な場合にSSE-KMSを選択してください。SSE-S3で要件を満たせるにもかかわらず、「安全のために」とデフォルトでSSE-KMSを使用すると、不要なコストと複雑さが増します。

S3バケットキーは、SSE-KMSのリクエストコストの問題に対処します。S3はCMKから短命のバケットレベルのキーを生成し、オブジェクトごとのデータキーをローカルで派生させます。これにより、オブジェクトごとのKMS GenerateDataKey/Decrypt呼び出しを回避し、KMSリクエストコストを最大99%削減します。

"ServerSideEncryptionConfiguration": {
  "Rules": [{
    "ApplyServerSideEncryptionByDefault": {
      "SSEAlgorithm": "aws:kms",
      "KMSMasterKeyID": "arn:aws:kms:..."
    },
    "BucketKeyEnabled": true
  }]
}

要件でKMSが必須とされている場合に、「KMSコストを避けるため」にSSE-S3に切り替えるのは間違った回避策です。バケットキーは、KMSを放棄することなく、コンプライアンスとコストの両方の目的を満たします。

バケットのデフォルト暗号化を有効にすると、将来のすべてのアップロードが暗号化されるようになります（暗号化されていないPUTは透過的に暗号化されます）。暗号化されていないPUTを完全に拒否するには、ヘッダーが欠落している書き込みを拒否します。

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringNotEquals": {
      "s3:x-amz-server-side-encryption": "AES256"
    }
  }
}

デフォルト暗号化は、既存の暗号化されていないオブジェクトには何もしません。S3インベントリとバッチオペレーションを介して、各キーをその場で上書きするCopyジョブを実行して再暗号化します。これが標準的な一括再暗号化パターンです。

アドホックなクライアントサイド暗号化は、デフォルト暗号化とKMSの組み合わせに劣ります。キー管理がアプリケーションチーム間に分散し、CloudTrailのKMSイベントを通じて一元的に監査できず、バケットキーも使用できません。

クロスリージョンレプリケーションとマルチリージョンKMSキー

クロスリージョンレプリケーション (CRR) は、コンプライアンス、DR、またはレイテンシーのために、オブジェクトを異なるリージョンのバケットに非同期でコピーします。同一リージョンレプリケーション (SRR) は、コンプライアンス上の分離、ログ集約、クロスアカウントコピーの目的で使用されます。どちらも送信元と送信先の両方でバージョニングを有効にし、送信元バケットが引き受けるIAMロールを必要とします。バケットを別のリージョンにミラーリングする必要がある場合、CRRは手間のかからない解決策です。aws s3 syncのスクリプト化、ObjectCreatedでのLambdaの連携、またはスケジュールされたバッチコピーの実行は、運用上のオーバーヘッド、競合状態、そしてサイレント障害を引き起こします。CRRもSRRも、デフォルトでは既存のオブジェクトをレプリケートしません。バックフィルにはS3バッチレプリケーションを使用します。

暗号化の相互作用は、設計が失敗しがちな箇所です。

• SSE-S3オブジェクトは透過的にレプリケートされます。
• SSE-KMSオブジェクトはデフォルトではレプリケートされません。明示的にオプトインし、送信先リージョンの送信先KMSキーを指定し、レプリケーションロールに送信元キーに対するkms:Decryptと送信先キーに対するkms:Encryptを付与する必要があります。シングルリージョンキーは、他のリージョンのオブジェクトを暗号化できません。
• クライアントサイドで暗号化されたオブジェクトは、不透明な暗号文としてレプリケートされます。クライアントのキーマテリアルが送信先リージョンで利用可能でない限り、送信先リージョンは何の利益も得ません。

2つの独立したCMKを管理するという歴史的な手間は、AWS KMSマルチリージョンキーによって解決されます。これは、複数のリージョンで同じキーマテリアルとキーID（リージョンプレフィックス付き）を提供します。これにより、レプリケートされたオブジェクトは、クロスリージョンのKMS呼び出しやデータキーの再ラップなしに、送信先リージョンで復号できます。これは、リージョンのフェイルオーバー時にも使用可能でなければならない、暗号化され、レプリケートされたバケットの標準的なパターンです。

カスタマーマネージドKMSキーを使用したクロスアカウントのスナップショットとオブジェクト共有では、ターゲットアカウントのプリンシパルが、キーポリシーを介してソースキーに対するkms:Decrypt、kms:CreateGrant、kms:DescribeKey、およびkms:ReEncrypt*の権限を持ち、さらに対応するIAM権限も持っている必要があります。AWSマネージドキー（例: aws/ebs、aws/s3）はアカウント間で共有できないため、クロスアカウントのワークフローではカスタマーマネージドキーが必須です。

ブロックパブリックアクセスとCloudFrontへのアクセス制限

S3ブロックパブリックアクセス (BPA) には4つの設定があります — 新しいパブリックACLのブロック、既存のパブリックACLの無視、新しいパブリックバケットポリシーのブロック、パブリックバケットポリシーの制限 — これらはバケットごと、そしてより重要なことに、アカウントレベルで設定可能です。アカウントレベルのBPAは、パブリックアクセスを許可するいかなるバケットポリシーよりも優先され、「このアカウント内のどのオブジェクトもパブリックにしてはならない」という要件に対する正しい制御です。バケットレベルのポリシーだけでは脆弱です。新しいバケットがポリシーなしで起動される可能性がありますが、アカウントレベルのBPAはデフォルトで非公開になる (フェイルクローズ) ため安全です。

メンバーアカウントの管理者がBPAを無効にすることを防ぐには、OrganizationsのOUまたはルートでサービスコントロールポリシーを適用します。

{
  "Effect": "Deny",
  "Action": "s3:PutAccountPublicAccessBlock",
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:PrincipalIsAWSService": "false" }
  }
}

S3コンテンツをCloudFront経由でのみ提供するには、オリジンアクセスコントロール (OAC) — レガシーなOAIの現代的な代替 — をディストリビューションにアタッチし、ディストリビューションのARNに基づいてバケットポリシーでアクセスを制限します。

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E123"
    }
  }
}

BPAはバケットで有効のままにしておきます。特定のユーザーにプライベートオブジェクトへの時間制限付きアクセス（アップロード/ダウンロードの有効期限）を許可するには、署名したプリンシパルの権限を継承する署名が埋め込まれた署名付きURLを生成します。

プライベートネットワークパス: ゲートウェイエンドポイント

VPC内のEC2からS3へのトラフィックは、自動的にAWSのプライベートバックボーンを使用するわけではありません。設定がない場合、S3 APIコールはパブリックエンドポイントに解決され、インターネットゲートウェイやNATゲートウェイを経由します。これにより、NATのデータ処理料金が発生し、トラフィックがインターネットに公開されます。S3（およびDynamoDB）のゲートウェイVPCエンドポイントは無料で、指定されたルートテーブルにプレフィックスリストのルートとして追加され、トラフィックをAWSネットワーク内に保持します。S3用のインターフェイスエンドポイント (PrivateLink) も存在し、こちらは有料ですが、Direct Connect経由でオンプレミスからアクセスする場合に便利です。エンドポイントとバケットポリシーのaws:SourceVpce条件キーを組み合わせることで、バケットが承認されたVPCエンドポイントからのみ到達可能であることを強制します。これは、規制対象のワークロードにおける標準的なパターンです。

Object Lambdaによるオンザフライ変換

S3 Object Lambdaは、GET/HEAD/LISTのパスにLambda関数を挿入することで、呼び出し元に返されるオブジェクトを読み取り時に変換します。これにより、バリアント（墨塗り、リサイズ、再フォーマットなど）ごとにデータを複製することを回避し、基盤となるバケットに単一の信頼できる情報源 (single source of truth) を維持します。典型的な用途には、アナリスト向けのPII（個人を特定できる情報）の墨塗りと監査員向けの完全なデータの提供、ユーザーごとの画像へのウォーターマーク付与、レガシークライアント向けのXMLからJSONへの変換などがあります。IAMポリシーとバケットポリシーは引き続き基盤となるオブジェクトへのアクセスを制御し、Lambdaはその実行ロールが許可する範囲のデータのみを扱います。

イベント通知

S3はイベント（s3:ObjectCreated:*、s3:ObjectRemoved:*、レプリケーションおよびライフサイクルイベント）をLambda、SQS、SNS、またはEventBridgeに発行します。複数のターゲット、オブジェクトメタデータによるフィルタリング、またはアカウント間のルーティングが必要な場合は、EventBridgeが推奨されます。アップロード時のサムネイル生成のような単一ターゲットのパイプラインには、直接通知の方がシンプルで安価です。通知は「少なくとも1回 (at-least-once)」配信されるため、コンシューマーはべき等である必要があります。

スループットの最適化: マルチパートアップロードとTransfer Acceleration

100MBを超えるオブジェクトにはマルチパートアップロードがベストプラクティスであり、5GBを超えると必須です。パートは並列にアップロードされ、失敗したパートは独立して再試行され、スループットは同時実行数に応じてスケールします。バイト範囲GETは、ダウンロード時に同等の並列性を提供します。前述の通り、孤立したパートに対する課金を避けるため、常にAbortIncompleteMultipartUploadライフサイクルルールをアタッチしてください。

S3 Transfer Accelerationは、アップロードを最寄りのCloudFrontエッジ経由でAWSのバックボーンを通してルーティングします。これは、グローバルに分散したクライアントが単一のバケットにアップロードする場合に使用します。ダウンロードの場合は、S3の前面にCloudFrontを配置してエッジでキャッシュします。Transfer Accelerationはアップロード指向であり、CloudFrontはダウンロード指向です。これらは関連しているが異なる問題を解決します。

EBS: ボリュームタイプ、暗号化、スナップショット

EBSボリュームは、単一のEC2インスタンスにアタッチされるAZスコープのブロックデバイスです。gp3はデフォルトの汎用SSDです。gp2に対するその決定的な利点は、IOPS（最大16,000）とスループット（最大1,000 MiB/s）が容量とは独立してプロビジョニングされる点にあります。これにより、パフォーマンス目標を達成するためだけにストレージを過剰にプロビジョニングするというgp2のアンチパターンが解消されます。io2 Block Expressは、レイテンシーに敏感なデータベース向けに、サブミリ秒のレイテンシーで最大256,000 IOPSを提供します。st1とsc1は、スループット指向のシーケンシャルワークロードやコールドワークロード向けのHDDベースのボリュームです。io1/io2のMulti-Attachは存在しますが、同一AZ内でクラスター対応ファイルシステムを実行する16インスタンスに限定されます。これは一般的な「共有EBS」パターンではなく、限定的な例外です。EBSを（例えばロードバランサーの背後にあるような）複数のインスタンスにまたがってアタッチしようと試みるのはカテゴリーエラーです。各ボリュームはプライベートなブロックデバイスであるため、「リフレッシュすると一部のドキュメントは見え、他は見えない」という典型的な症状を引き起こします。

EBSボリュームは、KMSでラップされたデータキーを使用してAES-256で保管時に暗号化されます。暗号化は透過的で、パフォーマンスへのペナルティやアプリケーションの変更は不要です。一度ボリュームが暗号化されると、そこから派生するスナップショットやボリュームも暗号化されます。インプレースで暗号化を解除することはできません。リージョンごとにEBS暗号化をデフォルトで有効化することで、開発者の記憶に頼ることなく、すべての新しいボリュームとスナップショットが暗号化されるようになります。

aws ec2 enable-ebs-encryption-by-default --region us-east-1
aws ec2 modify-ebs-default-kms-key-id \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

既存の暗号化されていないボリュームが遡って暗号化されることはありません。修正するには、スナップショットの取得、暗号化を有効にしたコピー、そして暗号化されたスナップショットからのボリューム作成が必要です。

スナップショットは、S3が管理するインフラストラクチャに保存される増分ブロックレベルバックアップです。しかし、無料ではなく（保持される変更ブロックに対して課金されます）、ソースボリュームが削除されても消えず、それを参照するAMIが登録解除されても削除されません。aws ec2 modify-snapshot-tier、Amazon Data Lifecycle Manager (DLM)、またはAWS Backupを使用して、EBS Snapshots Archive階層（75%安価、リストアに24～72時間）に移行させます。**Fast Snapshot Restore (FSR)**は、特定AZのスナップショットを事前にウォームアップすることで、そこから起動されたインスタンスが即座に完全なパフォーマンスを発揮できるようにします。迅速なスケールアウトに対応する必要があるオートスケーリンググループの背後にあるAMIに対して有効化します。

**ごみ箱 (Recycle Bin)**は、削除されたEBSスナップショットとAMIを復元ウィンドウ（1日～1年）内に保持します。これがない場合、スナップショットの削除は即時かつ永続的です。

aws rbin create-rule \
  --retention-period RetentionPeriodValue=30,RetentionPeriodUnit=DAYS \
  --resource-type EBS_SNAPSHOT \
  --description "30-day snapshot recovery"

長期的なコンプライアンス保持のために日次のEBSスナップショットのみに依存するのは、よくあるアーキテクチャ上の誤りです。スナップショットはウォームストレージに近い価格設定であり、明示的なアーカイブへの移行が必要です。

Amazon EFS: Linuxフリート向けの共有POSIX

EFSは、完全マネージドで伸縮自在な、POSIX準拠のNFSv4.1ファイルシステムです。リージョン内の複数のAZにまたがる何千ものEC2、ECS、EKS、Lambdaクライアントから、またDirect ConnectやVPN経由でオンプレミスのホストから同時にマウントできます。その決定的な特性は、同一のファイルハンドルとバイトレベルのセマンティクスを持つ同じファイルシステムが、すべてのクライアントから同時に見えることです。したがってEFSは、ロードバランサーの背後にあるLinuxフリートが、ユーザーのアップロードファイル、設定ファイル、共有ホームディレクトリといった共通のファイル群を共有する必要がある場合に常に正しい答えとなります。

マウントターゲットは、設定した各AZのサブネットに配置されます。amazon-efs-utilsヘルパーを使用すると、転送中のTLS暗号化とIAMによるマウント認証が可能になります。

sudo mount -t efs -o tls,iam fs-0123456789abcdef0:/ /mnt/shared

EFSのストレージクラスは2つの側面を持ちます。ライフサイクル管理は、7～90日間アクセスされなかったファイルをStandardからInfrequent Accessへ、さらにオプションでArchiveへと階層化し、ストレージコストを最大92%削減します。Intelligent-Tieringはアクセス時にファイルを元に戻します。1ゾーンクラスは単一AZに保存することで約47%安価になります。開発/テストや再現可能なデータには適していますが、AZ障害時のデータ損失が許容できないデータには決して使用すべきではありません。すでにEFS Standard-IA上にあるワークロードのコストを最適化する一つの方法は、アプリケーションの変更なしにEFS One Zone-IAに切り替えることです。

パフォーマンスには独立した2つの調整項目があります。パフォーマンスモード（作成時に設定）：*汎用（General Purpose）*は最も低レイテンシーで、メタデータが多いウェブサービングに適しています。*最大I/O（Max I/O）*はレガシーなオプションで、Elasticによって置き換えられました。スループットモード：*バースト（Bursting）*はサイズに応じてスケールし（ベースラインはGBあたり50 KB/s、ベースラインを下回るとバーストクレジットが蓄積）、*プロビジョンド（Provisioned）*はサイズに依存しない固定のMB/sに対して料金を支払い、Elastic（現在のデフォルト）はキャパシティプランニングなしで10+ GB/sまで自動的にスケールします。持続的な負荷がかかる小さなファイルシステムは、バーストクレジットを使い果たし、低いベースラインにスロットリングされる可能性があります。そのため、フットプリントが小さい高I/Oワークロードでは、Elasticまたはプロビジョンドを使用する必要があります。

EFSは高IOPSのブロックストレージの代替にはなりません。すべてのEFS I/Oはネットワーク越しのNFS RPCであるため、単一ライター、サブミリ秒、トランザクションログ形式のワークロードはEBS io2 Block Expressが適しています。単一ボリュームでサブミリ秒のレイテンシーで256,000 IOPSを提供でき、これはEFSがオペレーション単位では達成できない性能です。また、EFSはコールドデータ用としてはDeep Archiveに比べて著しく高価です。「簡単だから」という理由でコンプライアンスデータをEFSに保持することは正当化できません。

FSx: Windows, Lustre, ONTAP, OpenZFS

FSxは、プロトコルとワークロードに応じて選択されるマネージドファイルシステムのファミリーです。

FSx for Windows File Serverは、ネイティブなSMB 2.0/3.1.1を、NTFS ACL、DFS名前空間、シャドウコピー、Active Directory経由のKerberosと共に提供します。Multi-AZでは、1つのAZにアクティブなファイルサーバーを、別のAZに同期レプリケーションされるスタンバイをデプロイし、単一のフェイルオーバー用DNS名を提供します。AD統合はオプションではありません。FSxはAWS Managed Microsoft ADまたは到達可能なセルフマネージドADに参加する必要があり、クライアントはドメインユーザーとしてドメインSIDに対して認証します。「共有は見えているのにアクセスが拒否される」という典型的な症状は、ADをスキップしたり、フォレスト間の信頼関係がない信頼されていないフォレスト内のファイルシステムにクライアントを接続したりした場合に発生します。FSx for Windowsは、Windowsファイル共有をリフトアンドシフトする際の、そのまま使える移行先となります。

FSx for Lustreは、HPC、MLトレーニング、EDA、ゲノミクス向けの並列POSIXファイルシステムです。数千のクライアント、数百GB/sのスループット、ミリ秒未満のメタデータアクセスを実現します。その重要なAWS機能は、S3とのデータリポジトリの関連付けです。オブジェクトキーはLustreの名前空間にファイルとして表示され、初回アクセス時に遅延ロードされます（またはhsm_restoreで事前ロードも可能）。新規/変更されたファイルは、スケジュールまたはオンデマンドでS3にエクスポートされます。典型的なHPCのパターンは以下の通りです。

1. オンプレミスのデータセットをS3にコピーします（DataSyncまたはStorage Gateway経由）。
2. そのバケットにリンクされたLustreを作成します。
3. すべてのスポットワーカーにマウントし、ラインレートで入力の読み取りと出力の書き込みを行います。
4. 結果をS3にエクスポートします。S3は永続的な長期リポジトリとして機能します。
5. ジョブが終了したらLustreファイルシステムを削除します。

LustreのScratchデプロイメントにはレプリケーションがなく、ハードウェア障害でデータが失われます。最も安価で高速であり、一時的なジョブデータに適しています。Persistentデプロイメントは、AZ内でレプリケートしてより高い耐久性を実現します。スループットはTiBあたりMB/s（50/125/250/500/1000）でプロビジョニングされ、容量とパフォーマンスを分離できます。

FSx for NetApp ONTAPは、NFS、SMB、iSCSIを同一データ上で同時に利用できるマルチプロトコルの答えであり、スナップショット、SnapMirrorレプリケーション、FlexClone、重複排除機能も備えています。Multi-AZの冗長性を備えたクロスプロトコルアクセスが必要なLinuxのNFS共有とWindowsのSMB共有を統合する場合や、オンプレミスのNetAppから移行する場合にONTAPを選択します。FSx for OpenZFSは、NFS経由でZFSの機能（スナップショット、クローン）を必要とするLinuxワークロードというニッチなニーズに応えます。ONTAPのマルチプロトコルという強みを、他のバリアントと混同しないようにしてください。

選択を誤ると、明確に失敗します。共有ワークロードにEBS、WindowsのSMB共有にEFS、AD統合されたWindows共有にLustreを使うのは、すべて不適合です。まずはプロトコルとアクセスパターンを一致させましょう。

Storage Gateway: ハイブリッドアクセス

Storage Gatewayは、クラウドストレージをあたかもローカルにあるかのように提示します。これはデータを移動させるDataSyncとは異なります。

メディアライブラリをS3に移行したものの、オンプレミスでの低レイテンシーな読み取りが依然として必要なレンダリングアプリケーションには、S3 File Gatewayが適しています。NFS/SMBアクセス、ローカルキャッシュを提供し、コールドオブジェクトはオンデマンドでS3からフェッチします。FSx File Gatewayは支社向けのソリューションです。中央のクラウド上にあるFSx共有のLANスピードのSMBキャッシュであり、EC2インスタンス間の共有アクセス（この場合はFSxを直接マウントすべき）のためのソリューションではありません。Volume Gatewayは、ワークロードがファイルセマンティクスではなくブロックiSCSIを使用する場合に適用されます。Tape Gatewayは、既存のバックアップソフトウェアの下で物理テープライブラリを置き換えます。

データ転送と移行

AWS DataSyncは、NFS、SMB、HDFS、オブジェクトストアからS3、EFS、FSxへのエージェントベースのオンライン移行サービスです。オープンソースのツールより最大10倍高速で、暗号化、整合性検証、スケジューリング、POSIXメタデータとNTFS ACLの保持機能を備えています。数百万の小さなファイルと深い階層を持つ大規模なSMB移行において、最もオーバーヘッドの少ない答えは、DataSyncを使ってFSx for Windowsに移行することです。SMBは保持され、ACL/タイムスタンプは維持され、小さなファイルのスループットは並列転送で処理され、アプリケーションの変更は不要です。このようなデータセットを直接S3に移行するのは罠です。オブジェクトストレージは深いプレフィックスを持つ小さなファイルのリスト表示が苦手で、SMBクライアントはバケットをマウントできません。

AWS Snow Familyは、オフライン転送用の物理アプライアンスを提供します。Snowcone（最大8TB、エッジ向け高耐久性）、Snowball Edge（最大約80TB使用可能、コンピューティングオプション付き）、Snowmobile（エクサバイト規模）があります。経験則として、ネットワーク転送に1週間以上かかる場合は、Snowballの方が安価で高速です。

AWS Transfer Familyは、S3またはEFSをバックエンドとしてSFTP、FTPS、FTP、AS2を公開します。外部パートナーが標準的なファイル転送プロトコルを使い続ける必要がある場合に最適なソリューションです。

AWS Backup、クロスリージョンコピー、Vault Lock

AWS Backupは、EBS、EFS、FSx、RDS、DynamoDB、S3などのポリシーを一元管理します。バックアッププランでは、スケジュール、ウォームリテンション（保持期間）、コールドストレージへの移行、およびクロスリージョン/クロスアカウントのコピーアクションを定義します。

BackupPlan:
  Rules:
    - RuleName: DailyWithDRCopy
      TargetBackupVault: prod-vault
      ScheduleExpression: "cron(0 5 * * ? *)"
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 2555        # 7 years
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:eu-west-1:...:backup-vault:dr-vault
          Lifecycle:
            MoveToColdStorageAfterDays: 30
            DeleteAfterDays: 2555

コールドストレージへの移行には、最低90日間のウォームリテンションと、さらに最低90日間のコールドストレージでの保持が必要です。不適切に設定されたライフサイクルは拒否されます。複数年にわたる真の規制コンプライアンス保持のためには、AWS Backup Vault Lock（WORM）と組み合わせます。これにより、管理者であっても保持期間を短縮することができなくなり、SEC 17a-4や同様の指令を満たすことができます。クロスリージョンコピーはリージョンDRに対応し、クロスアカウントコピーは本番アカウントの爆発半径からバックアップを隔離することで、ランサムウェアや内部脅威のシナリオに対応します。

選択チートシート

← サーバーレスとイベント駆動型アーキテクチャ · すべてのドメイン · データ転送と移行 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Amazonを閲覧 →