Amazon SAP-C02: 移行とモダナイゼーション — 学習ガイド

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

移行戦略と計画

効果的な移行は、体系的な検出、依存関係のマッピング、リスクベースの優先順位付けから始まります。AWS Application Discovery ServiceとAWS Migration Hubを使用して、サーバーのインベントリを作成し、パフォーマンスメトリクスを収集し、アプリケーションの依存関係を可視化します。これをエージェントレスのネットワークフロー分析や構成管理データで補完し、隠れたステートフルなリンクを見つけ出します。検出結果をランディングゾーンの決定に反映させます。AWS Control TowerとOrganizationsでアカウント戦略を選択し、Transit Gatewayでネットワークトポロジーを定義し、Compute Optimizerとサイジングのベストプラクティスを用いて移行先のコンピューティングリソースのサイズを決定します。カットオーバー戦略はアプリケーションごとに選択する必要があります。小規模で低リスクのシステムにはビッグバン方式、ビジネスクリティカルなスイートには段階的またはウェーブベースの方式、ユーザー影響を最小限に抑えるための顧客向けサービスにはブルー/グリーンまたはカナリア方式を選択します。カットオーバーを計画する際には、データ同期のウィンドウ、DNSのTTL、帯域幅の制約、規制上の制約を考慮してください。よくある落とし穴には、データ転送時間とコストの過小評価、リフト＆シフトを最終状態と見なすこと、ライセンスのポータビリティを無視すること、ロールバックの計画を怠ることなどがあります。決定基準は、多くの場合、コストと、運用工数および回復力とのトレードオフになります。マネージドサービス（RDS/Aurora, DocumentDB）は、OPEXの予測可能性と回復力を高めますが、スキーマの変更が必要になる場合があります。マネージドサービスへのリプラットフォームは、移行が複雑になる代わりに、運用負荷を軽減します。

リフト＆シフトとデータ移行ツール

迅速なリホストのために、AWS Application Migration Service (MGN)は、VMware、Hyper-V、物理サーバーからEC2へのブロックレベルのレプリケーションを自動化し、カットオーバー時間を最小限に抑え、OSレベルの構成を維持します。大容量またはオフラインのデータ移行には、ファイルおよびPOSIX/NFSワークロード向けにAWS Snow FamilyまたはDataSyncが必要になる場合があり、一方、Amazon S3 Transfer AccelerationとDirect Connectはオブジェクトおよびバルク転送を高速化します。データベース移行には、同種または異種の移行のためにAWS Database Migration Service (DMS)を利用し、構造的な変更が必要な場合はSchema Conversion Tool (SCT)と組み合わせて使用します。DMSの制限に注意してください：MongoDBのソース/ターゲットの動作にはバージョンと機能の制約があり、大きなLOBの処理、CDC中のレプリケーションラグの可能性があります。データの整合性を確保するように設計します：チェックサムで検証し、ダウンタイムを最小限に抑えるためにフルロードとCDCを実行し、トラフィックの少ない時間帯にカットオーバーを実施します。設計上のトレードオフは、速度と忠実度を中心に展開します。MGNまたはリホストは、アプリケーションの変更を最小限に抑えますが、レガシーな運用モデルを引き継いでしまいます。リプラットフォームは長期的な運用負荷を削減しますが、リファクタリングとテストが必要です。よくある落とし穴には、エンドポイントセキュリティの軽視、カットオーバー前の不十分な検証、クラウドストレージで同等のIOPS/スループットを想定してしまうことなどがあります。

モダナイゼーション：コンテナ、サーバーレス、リファクタリングのパターン

モダナイゼーションの選択肢は、コンテナオーケストレーションへのリプラットフォームから、サーバーレスへの完全なリファクタリングまで多岐にわたります。インフラ管理を最小限に抑えた迅速なコンテナ化デプロイにはAmazon ECS on Fargateを、ポータビリティと複雑なオーケストレーションを必要とするKubernetesネイティブなワークロードにはAmazon EKSを選択します。イベント駆動型マイクロサービスには、AWS LambdaをAPI Gateway、EventBridge、Step Functionsと組み合わせて、運用オーバーヘッドを削減し、リクエストごとにスケールさせます。データサービスはマネージドバックエンドに移行すべきです。リレーショナルデータベースにはAmazon RDS/Aurora、NoSQL/ドキュメントストアにはAmazon DynamoDBまたはAmazon DocumentDB、低レイテンシーキャッシングにはElastiCacheを使用します。トレードオフは、運用の複雑さと、コストおよびパフォーマンスの予測可能性との間のトレードオフになります。EKSは、より高い運用コストで制御とポータビリティを提供します。Fargateは運用を簡素化しますが、大規模になるとより高価になる可能性があります。サーバーレスは、スパイクのあるワークロードに対してコスト効率を提供しますが、コールドスタート、同時実行数の制限、可観測性の課題をもたらします。アーキテクトが陥りがちな罠には、ステートフルなコンポーネントを分解せずにモノリスをコンテナにリフトすること、デプロイを管理するためのCI/CDとIaC（CloudFormation, CDK, Terraform）が不十分であること、タスクロールとLambda実行ロールに対するIAMの最小権限を無視することなどがあります。

カットオーバー、ハイブリッドネットワーキング、移行後の運用

成功するカットオーバーは、ハイブリッドネットワーキングとID統合、そして堅牢な可観測性とロールバック計画にかかっています。VPCとオンプレミスのActive Directory間のハイブリッドDNS解決には、Amazon Route 53 Resolverのインバウンドおよびアウトバウンドエンドポイントをデプロイするか、EC2 Windowsインスタンスのドメイン参加にAD ConnectorやManaged Microsoft ADを使用します。ネットワーク接続の選択肢には、スケーラブルなマルチアカウントトポロジー向けのAWS Direct ConnectやTransit Gatewayが含まれます。予測可能な帯域幅と低い下り（egress）コストが重要な場合はDirect Connectを選択し、多数のVPCとオンプレミス間の多対多接続を簡素化するにはTransit Gatewayを選択します。移行後の運用では、モニタリング（CloudWatch, X-Ray）、集中ログ記録と分析（CloudWatch Logs, Kinesis Firehoseによる一元管理アカウントへの転送）、バックアップとクロスリージョンスナップショット戦略（AWS Backup, クロスリージョンスナップショットコピー）、そしてAWS ConfigとIAM境界ポリシーによって強制されるセキュリティベースラインをカバーする必要があります。よくある落とし穴は、カットオーバー前にDNSのTTLを下げ忘れること、大規模なAD統合をテストしないこと、Transit Gatewayの帯域幅を過小にプロビジョニングしたり、ルート伝播の設定を忘れたりすることです。ここでの決定基準は、回復力とコストのトレードオフです。アクティブ-アクティブのマルチリージョン設計は可用性を高めますが、レプリケーションのコストと複雑性が増大します。一方、アクティブ-パッシブはコストを簡素化しますが、RTOが長くなります。

実践的な問題: ユースケースシナリオ

シナリオ: グローバルな研究企業であるAcme Energyは、AWS Organizations傘下に複数のアカウントを持つ既存のAWS環境と、プライベートなDirect Connectリンクで接続されたオンプレミスのデータセンターを保有しています。彼らは、一連のLinuxシミュレーションサーバー、MongoDBレプリカセット、および夜間のイメージファイル共有を、中断を最小限に抑えてAWSに移行する必要があります。

課題: シミュレーションのカットオーバーダウンタイムを2時間以内に抑え、MongoDBレプリカセットと夜間イメージ取り込みのデータ損失をゼロにしながら、運用負荷を軽減し、弾力的なスケーリングを可能にすること。

推奨アプローチ:

AWS Application Migration Service (MGN) エージェントをデプロイして、シミュレーションサーバーを専用の移行アカウントにレプリケートします。低いRPOで継続的なブロックレベルのレプリケーションを設定し、重要でないノードから段階的なカットオーバーウェーブをスケジュールします。
AWS DMSを使用して、MongoDBをソース、Amazon DocumentDB（MongoDB互換）をターゲットとして、フルロードとCDCを実行し、チェックサムと検証用の並列リードレプリカを使用してドキュメントレベルの整合性を検証します。
AWS DataSyncを使用して、夜間イメージをS3 Lifecycleルールで管理されるAmazon S3バケットに移行します。NFSセマンティクスを必要とするPOSIXベースのワークロードにはAmazon FSx for LustreまたはAmazon EFSをプロビジョニングし、ピーク負荷時の読み取り/書き込みパフォーマンスをテストします。
Route 53のTTLを下げ、ブルー/グリーン方式のトラフィックシフトのためにRoute 53の加重ルーティングを使用してカットオーバーを調整し、スモークテストが成功した後にDNSの切り替えを完了させます。IAMロールを適用し、CloudWatch X-Ray、集中管理されたCloudWatch Logs、およびスナップショット用のAWS Backupを有効にします。

根拠: このアプローチは、段階的なレプリケーションとCDCによってダウンタイムを最小限に抑え、マネージドサービス（DocumentDB, S3, DataSync）を採用することで運用オーバーヘッドを削減し、最終的なカットオーバー前に正確性を検証するための安全なロールバックポイントと可観測性を提供します。これは、移行とモダナイゼーションに関するプロフェッショナルなアーキテクチャのベストプラクティスに沿ったものです。

← データベースとアナリティクス · すべてのドメイン · レジリエンス、ディザスタリカバリ、高可用性 →

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