Amazon SAA-C03: データ転送と移行 — 学習ガイド

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

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

帯域幅と物理輸送の判断

すべての移行は計算から始まります。ツールを選択する前に、理論上の転送時間を計算してください。

Transfer days = (Dataset size in bits) / (Usable bandwidth in bps × 86,400)
Usable bandwidth = Link speed × Allowed utilization %

数字は容赦ありません。持続的に100 Mbpsの速度では1 TBに約24時間、1 Gbpsでは約2.5時間かかります。70%の上限がある15 Mbpsの回線では1日あたり約113 GBしか転送できず、20 TBを転送するには175日以上必要になります。150 TBを夜間（100 Mbpsの80%で10時間）に転送すると、一晩で約360 GB、月間で10.5 TBにしかならず、30日という期限には到底及びません。たとえ24時間365日、100 Mbpsの回線を完全に使い切ったとしても、1日あたり約1 TBしか移動できないため、150 TBには最低150日が必要です。ペタバイト規模になると状況はさらに悪化します。実効効率で500 Mbpsの回線では、理論上のスループットは1日あたり約5.4 TBとなり、10 PBを転送するには5年以上の連続転送が必要になります。これは、ほとんどのDirect Connect回線のプロビジョニングにかかる時間よりも長いのです。

合理的な経験則は次のとおりです。

移行シナリオで最もよくある誤った答えは、指定された期間内に数学的に完了不可能なWAN転送を選択することです。その結果として陥りがちな罠、つまり「毎晩WAN経由で実行すればいい」という考えは、単に遅いだけではありません。本番環境の帯域幅を消費し、再アップロードが必要となる部分的または破損した転送のリスクを伴い、帯域幅の料金とエンジニアリング時間を考慮すると、通常はより多くのコストがかかります。Snowballのユニット料金と送料は、固定的で予測可能な費用項目です。

オフラインでの一括転送のためのSnowファミリー

Snowball Edgeデバイスには2つのバリエーションがあります。

Snowconeは、小型（約8 TB SSD）で堅牢、宅配便で輸送可能なデバイスで、スペースに制約のある拠点に役立ち、エッジでの同期のためにDataSyncエージェントがプリロードされています。Snowmobileは、最大100 PBを輸送する45フィートのコンテナで、エクサバイト規模のデータセンター移転を対象としていましたが、ほとんどのリージョンで並行利用するSnowball Edgeフリートに取って代わられ、非推奨となっています。ペタバイト未満のデータ量でSnowmobileを選択するのは、誤答を誘う選択肢です。

Computeバリエーションは、単にドライブ容量が大きいだけではありません。EC2 AMI、Lambda関数、Greengrassワークロードをローカルで実行できるため、取り込み前にデータの変換、フィルタリング、PIIの墨消しが必要な場合、取り込み後にAWSですぐにワークロードを再開する必要がある場合、または拠点（船舶、遠隔地の鉱山、戦術的展開、遠隔地の研究）が非接続または断続的にしか接続できない場合に最適な選択肢となります。デバイス上での処理が必要な場合はCompute Optimizedを、ワークロードが純粋な一括コピーである場合はStorage Optimizedを選択してください。

すべてのSnowデバイスは、AWSから出ることのないKMSキーを使用して、保管中のデータを256ビットで暗号化します。筐体は、E Inkの配送ラベルとハードウェアのTrusted Platform Module（TPM）により、改ざん防止機能が備わっています。デバイス上のデータは、Snowballクライアント、S3互換エンドポイント、またはNFSマウントを使用して書き込まれます。取り込み時および配送マニフェストの交換時には、TLSが転送中のデータを保護します。返却後、コンテンツはS3に取り込まれ、デバイスはNIST 800-88に準拠して暗号学的に消去されます。

拠点あたりペタバイト規模の作業では、並列処理が基本パターンです。1〜2 Gbpsの回線容量を持つオフィスでも、1 PBをオンラインで移動するには数ヶ月間、回線を飽和させ続ける必要があります。一方、拠点あたり約13台のStorage Optimizedデバイス（各80 TB）のフリートを並行して輸送すれば、オフィスのインターネット回線を圧迫することなく、4週間という期限を達成できます。飽和状態の100 Mbps回線で600 TBを2週間で転送するジョブの場合、小規模な並列フリートが唯一の正解です。コストを無視しても、物理的にDataSyncや新規のDirect Connectでは不可能です。

オンラインでの検証済み増分転送のためのDataSync

DataSyncは、帯域幅は十分にあるものの、数百万の小さなファイル、深いディレクトリツリー、継続的な増分同期、ファイルシステム間の移行といったワークロードの特性により、単純なツールでは機能不全に陥る場合に適したツールです。aws s3 cpで2,000万個の4KBファイルをコピーするディレクトリは、スループットではなくラウンドトリップのレイテンシーによってボトルネックになります。各PutObjectはTLS/HTTPのラウンドトリップとAPIリクエスト料金を発生させます。アーカイブにバンドルする方法もありますが、ファイル単位でのアドレサビリティが失われます。DataSyncのエージェントは、多数のTCPストリームにわたって並列化し、メタデータをネイティブに処理し、SHA-256を使用してすべてのファイルをエンドツーエンドでチェックサム検証し、透過的に再試行し、CloudWatchにレポートします。これにより、予測可能なGB単位の料金体系で、エージェントあたり最大約10Gbpsを達成します。

ソースとデスティネーションは、NFS、SMB、HDFS、セルフマネージドオブジェクトストア、S3、EFS、FSx for Windows File Server、FSx for Lustre、FSx for OpenZFS、FSx for NetApp ONTAPに及びます。転送はTLS 1.2を使用し、VPCインターフェイスエンドポイントを経由してパブリックインターネットを回避できます。

重要な詳細として、DataSyncはオンプレミスのNFS/SMBソースに対してエージェントを必要とします。エージェントは、VMware、Hyper-V、KVM上のVMとして、EC2上、またはSnowcone上で実行されます。DataSyncがオンプレミスに対してエージェントレスであると考えるのはよくある落とし穴です。エージェントレスになるのは、両方のエンドポイントがAWSネイティブサービスである場合のみです。

最小限のデプロイメント：

# Activate the on-prem agent
aws datasync create-agent \
  --activation-key ABCDE-12345-FGHIJ-67890-KLMNO \
  --agent-name onprem-nfs-agent \
  --vpc-endpoint-id vpce-0a1b2c3d

# Define source (NFS) and destination (S3)
aws datasync create-location-nfs \
  --server-hostname 10.0.5.20 \
  --subdirectory /export/video \
  --on-prem-config AgentArns=arn:aws:datasync:...:agent/agent-0abc

aws datasync create-location-s3 \
  --s3-bucket-arn arn:aws:s3:::video-archive \
  --s3-config BucketAccessRoleArn=arn:aws:iam::111122223333:role/DataSyncS3Role

# Task with bandwidth cap, verification, and a nightly schedule
aws datasync create-task \
  --source-location-arn <nfs-arn> \
  --destination-location-arn <s3-arn> \
  --options VerifyMode=POINT_IN_TIME_CONSISTENT,BytesPerSecond=104857600,PreserveDeletedFiles=PRESERVE,PosixPermissions=PRESERVE \
  --schedule ScheduleExpression="cron(0 2 * * ? *)"

2つの運用機能が重要です。帯域幅制限 (BytesPerSecond) は、共有リンクを飽和させることを防ぎます。これは、「他の部門と共有している1Gbpsのリンク」といったパターンに直接対応します。フィルタリングとスケジューリングにより、業務時間外の同期や一時ファイルの除外が可能です。ユーザーが読み書きを続ける10GbpsのDirect Connect上で、繰り返しタスクをスケジューリングするのが典型的なパターンです。最初のスイープで大部分を転送し、その後の増分実行で差分をキャッチすることで、部分的な使用率であっても700TBを1週間未満で達成可能です。

より微妙な落とし穴は、メタデータの忠実性に関するものです。DataSyncは、NFSのUID/GID/モード/タイムスタンプやSMBの所有権とDACLなど、厳選されたPOSIXまたはSMB属性のセットを保持しますが、すべての独自NAS属性をキャプチャするわけではありません。ベンダー固有のACL、プロトコルが公開する範囲を超える拡張属性、スナップショット、重複排除メタデータなどは、その範囲外となります。コンプライアンス要件でベンダー機能を含む正確なNASレプリカが必要な場合、DataSyncだけでは不十分です。FSx for ONTAPとSnapMirrorのようなNetApp対応のパス、またはStorage Gatewayを介したリフトアンドシフトが必要になります。

DataSyncはSnowballを補完する役割も果たします。最初の150TBはSnowballで移動し、その後は500GBのワーキングセットの毎週の差分をDataSyncが処理します。

Storage Gateway: 移行ではなく、ハイブリッドなプレゼンテーション

Storage Gatewayは移行ツールではなく、ハイブリッドなプレゼンテーション層です。オンプレミスのアプリケーションはNFS、SMB、iSCSI、またはiSCSI-VTLを話し続けますが、データはS3、S3 Glacier、またはEBSスナップショットに格納されます。Storage GatewayとDataSyncを混同するのはよくある間違いです。File Gatewayは70TBを急いで移動するようには設計されておらず、DataSyncはオンプレミスクライアントに永続的な共有を提示しません。

File Gatewayが主力です。\\gateway\share\reports\2024\report.pdfに書き込むと、s3://bucket/reports/2024/report.pdfが生成され、Athena、Lambda、EMR、または任意のS3クライアントでネイティブに利用できます。このファイルとオブジェクトの1対1マッピングは、ブラックボックスなバックアップターゲットに対する大きな利点です。ローカルキャッシングにより、ホットファイルはLANの速度で返され、コールドファイルはS3からオンデマンドでストリーミングされます。

キャッシュこそが、このアプライアンスの要です。ホットデータへの読み取りはローカルで処理され、書き込みはまずローカルディスクに行われ、非同期でアップロードされます。よくある設計ミスは、S3バックエンドだからといってすべての読み取りがインターネットのラウンドトリップレイテンシーを伴うと仮定することです。ワーキングセットがキャッシュに収まる限り、そうはなりません。逆に、キャッシュのサイズが小さすぎると、絶えずキャッシュミスが発生し、ワークロードが「遅い」ように見えます。経験則として、キャッシュ = データセット全体の20%またはホットワーキングセットの100%の、いずれか大きい方です。

キャッシュ型と保管型の落とし穴には、特に注意が必要です。キャッシュ型モードは、プライマリコピーをS3に保持し、ホットブロックをローカルに置きます。安価で弾力的ですが、キャッシュミスはWANのラウンドトリップを意味します。保管型モードは、プライマリコピーをローカルディスクに保持し、S3にEBSスナップショットとして非同期スナップショットを作成します。すべての読み取りはローカルで低レイテンシーですが、データセット全体がオンプレミスに収まる必要があります。「AWSにバックアップされている間、すべてのデータにローカルアクセスできる」というバックアップ代替要件には、保管型が正解です。キャッシュ型ではこの要件を満たせません。データセット全体に低レイテンシーでアクセスする必要があるワークロードにキャッシュ型を選択すると設計の意図に反しますし、サイトが完全なデータセットをホストできない場合に保管型を選択することは定義上不可能です。

Tape Gatewayは、非常に具体的な要件に応えます。Veeam、NetBackup、Commvaultなどのワークフローを維持したまま物理テープライブラリを廃止するために、iSCSI経由でVTLを提示し、データをS3からGlacierやDeep Archiveにライフサイクル管理します。規制上の保持要件がテープメディアという観点で定義されており、既存のバックアップソフトウェアを変更できない場合に非常に価値があります。

AWS Transfer Family

Transfer Familyは、S3またはEFSをバックエンドとする、フルマネージドなSFTP、FTPS、FTP、およびAS2エンドポイントを提供します。その価値は、パートナー向けのプロトコル契約を維持できる点にあります。つまり、SFTP経由でのみファイルを送信するベンダーシステムは、そのままの運用を続けられる一方、受信側はライフサイクルポリシー、Lambdaトリガー、分析ツールとの統合が可能なネイティブなS3になるのです。

ここでの落とし穴は、レガシーなベンダーが「単にS3 APIに切り替えればよい」と想定してしまうことです。多くのベンダーシステムは、アプライアンス、病院のHL7フィード、銀行のバッチシステム、B2B EDIパイプラインなどであり、そのSFTPクライアントはファームウェアや署名付きバイナリに組み込まれています。それらに手を加えるための変更管理、セキュリティレビュー、再認定のコストは、AWSへの移行全体のコストを上回ることが少なくありません。Transfer Familyは、それを完全に回避します。さらに、AS2のサポートにより、B2BコンプライアンスのためのMDNレシートやメッセージの署名/暗号化を伴うEDIワークロードも可能になります。

認証は、サービスマネージドユーザー、AWS Directory Service（Managed Microsoft ADまたはオンプレミスAD用のAD Connector）、またはAPI Gateway/Lambda経由のカスタムIDプロバイダーをサポートしており、既存の企業認証情報を信頼できる唯一の情報源（source of truth）として維持できます。Lambdaオーソライザーは、ユーザーごとのIAMロール、ホームディレクトリのマッピング、セッションポリシーを返すことができ、ベンダーごとのインフラを構築することなく、ベンダーごとの分離を実現します。

Type: AWS::Transfer::Server
Properties:
  Protocols: [SFTP]
  IdentityProviderType: AWS_DIRECTORY_SERVICE
  IdentityProviderDetails:
    DirectoryId: d-9067f4a1c2
  Domain: S3
  EndpointType: VPC
  EndpointDetails:
    VpcId: vpc-0abc123
    SubnetIds: [subnet-0a, subnet-0b]
    SecurityGroupIds: [sg-0sftp]

Amazon AppFlow

AppFlowは、SaaSからAWSへのデータ移動のためのマネージドな統合レイヤーです。Salesforce、ServiceNow、Google Analytics、Slack、Marketo、SAP OData、Zendeskなど、数十のSaaSからS3、Redshift、またはSnowflakeにデータを流し込みます。ページネーション、増分抽出、フィールドマッピング、フィルタリング、マスキング、検証などを、手作りのETLジョブを必要とせずに処理します。

セキュリティ上重要な機能は、サポートされているコネクタ（特にSalesforce）に対するPrivateLink統合です。SaaSテナントに到達するためにパブリックインターネットに出てAWSに戻るのではなく、フローはプライベートなVPCエンドポイントを経由します。これにより、抽出ペイロードがパブリックインターネットに公開されるのを防ぎ、ヘルスケア、金融、PII（個人を特定できる情報）を扱うワークロードの監査対応を簡素化します。フローは、スケジュール実行、SaaSのレコード変更によるイベントトリガー、またはオンデマンドで実行でき、フロー実行あたり最大100GBまでサポートします。

AppFlowは、DataSyncやStorage Gatewayよりも高いレイヤーで動作します。ソースがファイルシステムやデータベースではなく、API駆動のSaaSである場合に適したツールです。

データベース移行: DMSとSCT

AWS Database Migration Serviceは、ソースデータベースを完全に稼働させたまま、ソースとターゲットのデータベース間でデータをレプリケートします。同種（MySQL → RDS MySQL、Oracle → RDS Oracle）および異種（Oracle → Aurora PostgreSQL、SQL Server → MySQL）の移行をサポートし、ターゲットはRDSだけでなく、Aurora、Redshift、S3、DynamoDB、Kinesisにも及びます。ソースには、Oracle、SQL Server、MySQL、PostgreSQL、MongoDB、Db2などがあります。

タスクは3つのモードのいずれかで動作します。

ダウンタイムを最小限に抑えた切り替えの原動力は、**変更データキャプチャ（Change Data Capture）**です。フルロード+CDCの実行中、DMSはソースのトランザクションログ（Oracleのredo、MySQLのbinlog、SQL ServerのMS-CDCまたはMS-Replication）をマイニングしながら、既存の行をバルクコピーします。フルロードが完了すると、CDCはキューに入れられた変更を適用し、アプリケーションが切り替わるまでターゲットを継続的に最新の状態に保ちます。アプリケーションが書き込み可能である必要がある場合にCDCを有効にしないことは、よくあるアーキテクチャ上の誤りです。フルロードのみでは、ロードが完了した瞬間からターゲットが古くなってしまいます。

{
  "MigrationType": "full-load-and-cdc",
  "ReplicationTaskSettings": {
    "TargetMetadata": { "ParallelLoadThreads": 8 },
    "ChangeProcessingTuning": { "BatchApplyEnabled": true }
  }
}

異種移行の場合、AWS Schema Conversion Tool（またはそのクラウド版であるDMS Schema Conversion）がDDL、ストアドプロシージャ、ビュー、関数を変換し、手動での書き換えが必要な項目にフラグを立てます。DMSはデータを移動し、SCTはスキーマを変換します。SCTの評価レポートをスキップすることが、切り替えの3日前に移行が失敗する原因です。

エンジン固有の前提条件や制限は、無視すると手痛いしっぺ返しを食らいます。64 KBを超えるOracle LOBは、固定された最大値を持つ限定LOBモードが必要です。LONG RAWには注意点があります。PostgreSQLではwal_level=logicalとレプリケーションロールが必要です。MySQLでは、ROW形式のバイナリロギングと、十分なbinlog_row_image、そして昇格されたCDC権限（REPLICATION CLIENT、REPLICATION SLAVE）が必要です。Oracle Spatial、RAC固有の動作、SQL Server CLRアセンブリは一般的にサポートされていません。レプリケーションインスタンスとエンドポイント間ではTLSが強制され、SSLモードはrequire、verify-ca、またはverify-fullが使用されます。

DMS Serverlessは、ワークロードのプロファイルが予測不可能または突発的である場合に正しい選択です。例えば、日中にスパイクがあり夜間は静かになるオンプレミスのOracleシステムなどです。DCU（DMS Capacity Unit）でMinCapacityUnitsとMaxCapacityUnitsを定義すると、DMSはCPUとメモリのプレッシャーに基づいてレプリケーションキャパシティをスケーリングします。

ReplicationConfigIdentifier: oracle-to-rds-cdc
ReplicationType: full-load-and-cdc
SourceEndpointArn: arn:aws:dms:...:endpoint:oracle-onprem
TargetEndpointArn:  arn:aws:dms:...:endpoint:rds-oracle
ComputeConfig:
  MinCapacityUnits: 4
  MaxCapacityUnits: 64
  MultiAZ: true

よくある落とし穴は、プロビジョニングされたDMSインスタンス（例: dms.c5.4xlarge）が自動的にスケールすると想定してしまうことです。それはスケールしません。プロビジョニングされたインスタンスは固定サイズのEC2ホストです。スループットがキャパシティを超えると、レプリケーションラグが増大し、手動でインスタンスクラスを変更してタスクを再起動する必要があります。プロビジョニングされたDMSはスループットが既知の定常的な移行に適しており、Serverlessは予測不可能な移行に適しています。

2週間の期間と短いダウンタイムが許容される20TBのMySQL移行では、DMSのフルロード+CDCを使用してAurora MySQLまたはRDS MySQLに移行するのが、コスト効率の良い方法です。ネイティブのmysqldump/mysqlpumpによるリストアは、許容できないダウンタイムを発生させます。Snowballは、輸送の遅延やオフラインのギャップを生じさせます。

DMS Fleet Advisorは、オンプレミスのデータベースインベントリを検出し、移行のウェーブ計画に役立ちます。

サーバー移行: AWS Application Migration Service (MGN)

AWS Application Migration Serviceは、主要なリフトアンドシフト（「リホスト」）サービスであり、ほとんどのユースケースでCloudEndure MigrationとServer Migration Serviceに取って代わりました。MGNは、各ソースサーバー（物理、VMware、Hyper-V、または他のクラウド）に軽量なAWS Replication Agentをインストールします。このエージェントは、ターゲットVPC内の低コストなステージングエリア（アタッチされたEBSボリュームを持つ小規模なT3インスタンス）に初回のブロックレベルのスナップショットを実行し、その後、ブロックレベルの変更を非同期で継続的にレプリケートします。レプリケーションはブロックレベルで継続的に行われるため、カットオーバーは数分で完了します。カットオーバー時に、MGNはステージングボリュームをターゲットインスタンスタイプのEC2本番インスタンスに変換します。

1. Install replication agent on each source (or use agentless for vCenter)
2. Configure launch template (instance type, subnet, IAM role, tags)
3. Run "Test" launches → validate → "Cutover" launch → decommission source

テスト起動は不可欠ですが、しばしば省略されがちです。MGNは、進行中のレプリケーションを中断することなく、現在のレプリケーション状態から隔離されたテストインスタンスを起動します。アプリケーションの動作を検証し、テストを破棄し、反復し、テストが成功した場合にのみカットオーバーを開始します。カットオーバーはレプリケーションを停止し、最終的なインスタンスを起動し、ウェーブを完了としてマークします。

間違ったアプローチは、VMを手動でOVFにエクスポートし、aws ec2 import-imageでアップロードし、新しくプロビジョニングしたEC2インスタンスにアプリケーションを再インストールすることです。これは時間がかかり、エラーが発生しやすく、エクスポート時間と同じだけのVMごとのダウンタイムを必要とし、差分レプリケーションを提供せず、非破壊的なテストも提供しません。MGNはこれらすべてを排除します。ソースは最終的なカットオーバーの瞬間まで稼働し続け、ソースとターゲット間の差異（ドリフト）は実質的にゼロです。

一般的なポートフォリオガイダンスは、まずリホストし、その後、イテレーションコストが低いリージョン内でリプラットフォームまたはリファクタリングを行うことです。リファクタリングと移行を同時に行うと、それに見合うメリットなくリスクが倍増します。

ハイブリッド接続: Direct ConnectとVPN

AWS Direct Connectは、オンプレミスルーターからDirect Connectロケーションへの専用のレイヤー2回線を提供し、一貫した帯域幅（専用接続で1、10、100 Gbps、パートナーのホスト型接続を介した1 Gbps未満）と予測可能なレイテンシーを提供します。Virtual Interface（VIF）が回線を分割します。

• プライベートVIF — Virtual Private Gatewayを介して単一のVPCにアクセスします。
• トランジットVIF — Transit GatewayにアタッチされたDirect Connect Gatewayを介して多数のVPCにアクセスします。これは、大規模なマルチVPC、マルチサイト環境における標準的なパターンです。
• パブリックVIF — インターネットを経由せずにAWSのパブリックサービスエンドポイント（S3、DynamoDBなど）にアクセスします。

DXは、それ自体では高可用性ではありません。単一のDXロケーションにある単一の回線は、単一のファイバーパスに依存します。2つの耐障害性パターンが重要です。

1. インターネット経由のDX + Site-to-Site VPNバックアップは、実用上最低限のHA構成です。BGPは、AS-path prepending、MED、またはlocal-prefを使用して、定常状態でDXを優先するように自動フェイルオーバーを処理します。
2. 別々のDXロケーションにあるデュアルDX回線は、ミッションクリティカルなワークロード向けの最大耐障害性パターンであり、DX SLAの要件でもあります。

いかなるバックアップパスもプロビジョニングしないことは、よく知られた落とし穴です。DXに障害が発生し、VPNがない場合、ハイブリッドアプリ、DataSyncジョブ、Storage Gatewayのアップロードはすべて、キャリアの修理期間中停止します。VPNのみの構成は、スループットが低いワークロードや、プロビジョニングに数週間かかることがあるDXが準備されるまでのつなぎとして許容されます。

On-prem Router ──── DX (primary, BGP MED=100) ────┐
                                                   ├── VGW/DXGW ── VPC
On-prem Router ──── VPN over Internet (backup) ────┘

# Multi-VPC access via DX Gateway
DirectConnectGateway:
  Associations:
    - TransitGateway: tgw-corp
    - VirtualPrivateGateway: vgw-prod-vpc
  AllowedPrefixes:
    - 10.0.0.0/8

物理層での暗号化が必須の場合は、MACsec対応のDX接続を選択します。帯域幅のためにDXを、オーケストレーションのためにDataSyncを、継続的なローカルアクセスのためにStorage Gatewayを組み合わせることは、ダウンタイムを許容できない大規模なライブデータセットに対する標準的なハイブリッドパターンです。

オンプレミスAWSインフラストラクチャのためのAWS Outposts

Outpostsは、フルマネージドのラック（または1U/2UのOutpostsサーバー）として、顧客の施設にAWSインフラストラクチャを拡張します。親リージョンと同じAPIを使用して、厳選されたサービス群（EC2、EBS、ECS、EKS、RDS、S3 on Outposts、EMR）をローカルで実行します。コントロールプレーンの操作は、冗長化された暗号化トンネルであるサービスリンクを介して親リージョンに送られます。WANの停止が発生すると、新しいインスタンスの起動は一時的にできなくなりますが、実行中のワークロードは停止しません。

責任共有の分界点は、運用担当者が陥りやすい罠です。AWSは、ハードウェア、ハイパーバイザー、およびマネージドサービスを提供・維持します。顧客は以下に対して責任を負います。

• Outpostsの仕様を満たす物理的なスペース、電源、冷却、およびネットワーク（冗長電源、アップストリームスイッチ、適切なPDU）。
• 施設の物理的なセキュリティ。
• ローカルネットワークの設定 — オンプレミストラフィック用の**Local Gateway (LGW)**とサービスリンクのアップリンク。
• リージョン内と全く同様に、ワークロードのOSとアプリケーションに関する懸念事項。
• 親リージョンへの適切なWAN接続。

Outpostsは運用をなくすのではなく、抽象化のレイヤーをシフトさせます。AWSがデータセンターの電源やアップストリームネットワークに責任があると想定するのは、根本的な誤解です。また、「オンプレミスであらゆるAWSサービスを実行できる」わけでもありません。サポートされるサービスのリストは限定されており、Route 53やIAMのようなサービスはリージョンベースのままです。

規制上の理由でデータをオンプレミスに保持する必要があるHadoop/Sparkのモダナイゼーションには、EMR on Outpostsが正しいパターンです。これは、リージョン内のツールを利用しつつ、ローカルでのデータレジデンシーを確保した、マネージドで伸縮自在なSparkクラスターです。Storage GatewayやDataSyncではレジデンシー要件を満たせず、リージョン内のEMRへのリフトアンドシフトではコンプライアンス違反となります。

エッジフリートへのコンテンツ配信

Outpostsサーバー、小売店、またはエッジデバイスが、例えば夜間のソフトウェアリリースのような同じ大きなペイロードを繰り返しプルする場合、単一リージョンのS3バケットから直接プルすると、アップリンクが飽和し、デプロイ時間が膨れ上がります。正しいパターンは、S3オリジンと署名付きURLを使用したCloudFrontです。

S3 bucket (ap-northeast-1)  ← Origin Access Control
        │
   CloudFront distribution (global edge PoPs)
        │
   Signed URLs (short expiry, per-server or per-release)
        │
   Edge devices download from nearest PoP

あるリージョン内の最初のデバイスがエッジキャッシュをウォームアップし、それ以降のすべてのデバイスはエッジのレイテンシーでプルします。署名付きURLは、デバイスごとのIAM認証情報なしで不正なダウンロードを防ぎ、管理すべきリージョンレプリカのフリートもありません。

拒否すべき2つのアンチパターンは、単一のEC2ウェブサーバーでリリースをホストすること（スケーリングとレイテンシーの惨事）、そしてダウンロードレイテンシーを削減するためだけに、クロスリージョンレプリケーションを介してS3バケットを全リージョンにレプリケートすること（CloudFrontのキャッシングが無料で解決する、不要なストレージコストと運用上の複雑さ）です。

決定の要約

← ストレージとデータライフサイクル · すべてのドメイン · ネットワーキングと接続性 →

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

Amazonを閲覧 →