翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 優先順位付けされたアプリケーション評価
前のステージの主な成果の 1 つは、[ポートフォリオ検出と初期計画](portfolio-discovery-initial-planning.md)であり、詳細な評価のために[アプリケーションのサブセットを優先](prioritization-and-migration-strategy.md#prioritizing-applications)することでした。このセクションでは、アプリケーションの詳細な評価について説明します。
いくつかのアプリケーションの詳細を早い段階で見ると、加速が促進されます。評価と今後のアーキテクチャ設計のプロセスは、潜在的なブロック要因を明らかにし、より大きな範囲の移行に取って代わる重要なタスクを明確にします。これらのタスクには、 のランディングゾーンなどの AWS 基盤を確立したり AWS、既存のランディングゾーンを拡張して検証したりするための要件の収集が含まれます。この評価は、移行のステップと戦略を検討するときでもあります。
このステージの主な成果は次のとおりです。
+ 優先順位付けされたアプリケーションの検証済みリスト
+ 文書化された現在の状態アーキテクチャ
+ 移行候補の文書化された初期ターゲットアーキテクチャと移行戦略
+ 特定された移行パターンとツール
+ 文書化されたプラットフォーム要件 (セキュリティ、 AWS インフラストラクチャ、オペレーション)
+ 移行計画に関する文書化されたカットオーバーの考慮事項
+ 推定 AWS 実行レート
# 詳細な評価データ要件について
次の表は、移行内のアプリケーションとその関連インフラストラクチャの完全なポートフォリオビューを取得するために必要な情報を示しています。
テーブルでは、次の略語を使用します。
+ R、必須
+ O、オプション
+ 該当なし、該当なし
**アプリケーション**
| **属性名** | **説明** | **検出、設計、移行戦略** | **推定実行レート** | **推奨される忠実度レベル (最小)** |
| --- |--- |--- |--- |--- |
| 一意の識別子 | たとえば、アプリケーション ID などです。通常、既存の CMDBs またはその他の内部インベントリと管理システムで使用できます。一意の IDs組織で定義されていない場合は必ず作成することを検討してください。 | R | O | 高 |
| アプリケーション名 | このアプリケーションが組織で認識される名前。必要に応じて、市販の (COTS) off-the-shelf ベンダーと製品名を含めます。 | R | R | 高 |
| COTS ですか? | はいまたはいいえ。商用アプリケーションか内部開発か | R | R | 高 |
| COTS 製品とバージョン | 商用ソフトウェア製品名とバージョン | R | R | 高 |
| 説明 | プライマリアプリケーション関数とコンテキスト | R | O | 高 |
| 緊急性 | 例えば、戦略的アプリケーションや収益を生み出すアプリケーション、重要な機能のサポートなど | R | O | 高 |
| タイプ | データベース、顧客関係管理 (CRM)、ウェブアプリケーション、マルチメディア、IT 共有サービスなど | R | O | 高 |
| 環境 | 例: 本番稼働前、本番稼働前、開発、テスト、サンドボックス | R | R | 高 |
| コンプライアンスと規制 | ワークロードに適用されるフレームワーク (HIPAA、Sox、PCI-DSS、ISO、SOC、FedRAMP など) と規制要件 | R | O | 高 |
| 依存関係 | 内部および外部のアプリケーションまたはサービスへのアップストリームとダウンストリームの依存関係 | R | 該当なし | 高 |
| インフラストラクチャマッピング | アプリケーションを構成する物理アセットや仮想アセットへのマッピング | R | R | 高 |
| ライセンス | 商品ソフトウェアライセンスタイプ (Microsoft SQL Server Enterprise など) | R | R | 高 |
| Cost | ソフトウェアライセンス、ソフトウェアオペレーション、メンテナンスのコスト | 該当なし | R | やや高い |
| ビジネスユニット | マーケティング、財務、営業など | R | O | 高 |
| 所有者の詳細 | アプリケーション所有者の連絡先情報 | R | O | 高 |
| アーキテクチャタイプ | ウェブアプリケーション、2 層、3 層、マイクロサービス、サービス指向アーキテクチャ (SOA) など | R | R | 高 |
| 目標復旧時点 (RPO)、目標復旧時間 (RTO)、/サービスレベルアグリーメント (SLA) | 現在のサービス - 管理属性 | R | R | 高 |
| 収益を生み出すアプリケーションかビジネス戦略アプリケーションか。 | はい。アプリケーションが会社の収益に直接または間接的に影響を与えるか、ビジネスによって戦略的と見なされる場合。 | R | O | やや高い |
| ユーザー数 (同時) | 例えば、内部ユーザー、外部ユーザー、または内部ユーザーや外部ユーザー/顧客など | R | R | やや高い |
| ユーザーの場所 | ユーザーセッションのオリジン | R | R | やや高い |
| リスクと問題 | 既知のリスクと問題 | R | O | やや高い |
| 移行に関する考慮事項 | 移行に関連する可能性のある追加情報 | R | R | やや高い |
| 移行戦略 | 例えば、移行用の AWS 6 R の 1 つ | R | R | やや高い |
| データベースの詳細 | 例えば、パーティショニング、暗号化、レプリケーション、拡張機能、Secure Sockets Layer (SSL) サポートなど | R | R | 高 |
| サポートチーム | 例えば、アプリケーションオペレーションチーム名 | R | O | やや高い |
| モニタリングソリューション | このアプリケーションをモニタリングするために使用される製品 | R | O | やや高い |
| バックアップ要件 | で必要なバックアップスケジュール AWS | R | R | やや高い |
| DR 情報 | 例えば、このアプリケーションのディザスタリカバリコンポーネント | R | R | やや高い |
| ターゲット AWS 要件 | コンポーネント、アカウントプレイスメント、ネットワーク、セキュリティなど | R | R | 高 |
**インフラストラクチャ**
| | | | | |
| --- |--- |--- |--- |--- |
| **属性名** | **説明** | **検出、設計、移行戦略** | **推定実行レート** | **推奨される忠実度レベル (最小)** |
| 一意の識別子 | たとえば、サーバー ID などです。通常、既存の CMDBs またはその他の内部インベントリと管理システムで使用できます。一意の IDs組織で定義されていない場合は必ず作成することを検討してください。 | R | O | 高 |
| ネットワーク名 | ネットワーク内のアセット名 (ホスト名など) | R | O | 高 |
| DNS 名 (完全修飾ドメイン名、または FQDN) | [DNS 名] | O | O | やや高い |
| IP アドレスとネットマスク | 内部 IP アドレスおよび/またはパブリック IP アドレス | R | R | 高 |
| アセットタイプ | 物理サーバーまたは仮想サーバー、ハイパーバイザー、コンテナ、デバイス、データベースインスタンスなど | R | R | 高 |
| 製品名 | 商用ベンダーと製品名 (VMware ESXi、IBM Power Systems、Exadata など) | R | R | 高 |
| オペレーティングシステム | 例: REHL 8、Windows Server 2019、AIX 6.1 | R | R | 高 |
| 設定 | 割り当てられた CPU、コア数、コアあたりのスレッド数、合計メモリ、ストレージ、ネットワークカード | R | R | 高 |
| 使用率 | CPU、メモリ、ストレージのピークと平均。データベースインスタンスのスループット。 | R | R | 高 |
| ライセンス | 商品ライセンスタイプ (RHEL Standard など) | R | R | 高 |
| は共有インフラストラクチャですか? | はいまたはいいえ。認証プロバイダー、モニタリングシステム、バックアップサービス、および同様のサービスなどの共有サービスを提供するインフラストラクチャサービスを示します。 | R | O | 高 |
| アプリケーションマッピング | このインフラストラクチャで実行されるアプリケーションまたはアプリケーションコンポーネント | R | O | 高 |
| 通信データ | 例えば、プロセスレベルでのサーバー間 | R | 該当なし | やや高い |
| ターゲット AWS 要件 | インスタンスタイプ、アカウント、サブネット、セキュリティグループ、ルーティングなど | R | R | 高 |
| 移行戦略、パターン、ツール | 例えば、移行用の 6 R の 1 つ、特定の技術パターン、移行ツール | R | O | 高 |
| リスクと問題 | 既知のリスクと問題 | R | O | やや高い |
# 詳細なアプリケーション評価
詳細なアプリケーション評価の目的は、ターゲットアプリケーションとその関連インフラストラクチャ (コンピューティング、ストレージ、ネットワーク) を完全に理解することです。落とし穴を回避するには、忠実度の高いデータが必要です。たとえば、組織がアプリケーションを完全に理解していることを前提とするのが一般的です。これは自然であり、多くの場合当てはまります。ただし、ビジネスへのリスクを最小限に抑えるには、プログラムによるデータを可能な限り取得して、組織の知識と静的ドキュメントを検証することが重要です。これにより、検出プロセスの負担が軽減されます。ビジネス固有の情報、戦略的ロードマップなど、代替ソースから得られるデータ要素に集中できます。
重要なのは、移行中および移行後の直前の変更を避けることです。例えば、移行するときは、継続的な移行ウェーブにサーバーを含める必要がある可能性のある未確認の依存関係に基づく変更を避けることが重要です。移行後すぐに、関連するプラットフォーム要件に基づく変更を回避して、トラフィックを許可したり、追加のサービスをデプロイしたりすることが重要です。このような予期しない変更により、セキュリティや運用上の問題のリスクが高まります。詳細なアプリケーション評価を実行するときは、プログラムによる検出ツールを使用してトラフィックパターンと依存関係を検証することを強くお勧めします。
評価の最初に、アプリケーションのステークホルダーを特定する必要があります。これらは通常、次のようになります。
+ ビジネスユニットリード
+ アプリ所有者
+ アーキテクト
+ オペレーションとサポート
+ クラウド対応チーム
+ コンピューティング、ストレージ、ネットワークなどの特定のプラットフォームチーム
詳細な検出には 2 つのアプローチがあります。トップダウン検出は、アプリケーションまたはユーザーから開始し、インフラストラクチャまで行きます。これは、アプリケーションの識別が明確である場合に推奨されるアプローチです。逆に、ボトムアップ検出はインフラストラクチャから始まり、アプリケーションまたはサービスとそのユーザーにまで至ります。このアプローチは、移行プログラムがインフラストラクチャチームによって推進されている場合や、application-to-infrastructure間のマッピングが不明な場合に役立ちます。一般的に、両方の組み合わせを使用する可能性があります。
アプリケーションを深く掘り下げるには、既存のアーキテクチャ図から始めることをお勧めします。これらが利用できない場合は、現在の知識に基づいて作成します。単純なリホストまたは再配置移行戦略であっても、このタスクの重要性を過小評価しないでください。アーキテクチャ図をプロットすると、クラウド上の小さな変更で迅速に対処できる非効率性を特定できます。
トップダウンアプローチとボトムアップアプローチのどちらを実行するかに応じて、最初の図にアプリケーションコンポーネントとサービス、またはサーバーやロードバランサーなどのインフラストラクチャコンポーネントがプロットされます。主要なコンポーネントとインターフェイスを特定したら、検出ツールとアプリケーションパフォーマンスモニタリングツールのプログラムデータを使用して検証します。このツールは、依存関係分析をサポートし、コンポーネント間の通信情報を提供する必要があります。このアプリケーションを構成する各コンポーネントを特定する必要があります。次に、内部と外部の両方の他のアプリケーションとサービスへの依存関係を文書化します。
依存関係とマッピングを検証するためのツールがない場合は、手動アプローチが必要です。たとえば、インフラストラクチャコンポーネントにログインし、スクリプトを実行して、オープンポートや確立された接続などの通信情報を収集できます。同様に、実行中のプロセスとインストールされているソフトウェアを特定できます。手動検出に必要な労力を過小評価しないでください。プログラムツールを使用すると、ほとんどの依存関係を数日でキャプチャしてレポートできます。ただし、より長い間隔 (通常は少数の割合) で発生する依存関係は除きます。手動検出では、すべてのデータポイントの収集とマージに数週間かかる場合がありますが、それでもエラーや欠落データが発生しやすくなります。
次に、優先順位付けされた各アプリケーションとマッピングされたインフラストラクチャ[のデータ要件](understanding-detailed-assessment-data-requirements.md)セクションで指定された情報を取得します。次に、次のアンケートを使用して、詳細な評価プロセスについて説明します。特定されたステークホルダーとミーティングを行い、これらの質問に対する回答について話し合います。
## General
+ このアプリケーションの重要度レベルはどのくらいですか? 収益は生成されていますか? ビジネス戦略アプリケーションか、サポートビジネスアプリケーションか。他のシステムによって共有されるコアインフラストラクチャサービスですか?
+ このアプリケーションに進行中の変換プロジェクトはありますか?
+ これは内部向けか外部向けか。
## アーキテクチャ
+ 現在のアーキテクチャタイプ (SOA、マイクロサービス、モノリスなど) は何ですか? アーキテクチャにはいくつの階層がありますか? しっかりと結合されているか、緩く結合されているか。
+ コンポーネント (コンピューティング、データベース、リモートストレージ、ロードバランサー、キャッシュサービスなど) は何ですか?
+ APIs API 名、オペレーション、URLs、ポート、プロトコルなど、これらについて説明します。
+ コンポーネント間、およびこのアプリケーションやサービスと他のアプリケーションやサービスとの間で許容される最大レイテンシーはどのくらいですか?
## オペレーション
+ このアプリケーションはどの場所で動作しますか?
+ アプリケーションとインフラストラクチャを運用しているユーザー これらは内部チームまたは AWS パートナーチームによって運営されていますか?
+ このアプリケーションがダウンするとどうなりますか? 影響を受けるのは誰ですか? その影響は何ですか？
+ ユーザーまたは顧客はどこにいますか? アプリケーションへのアクセス方法 同時ユーザー数はいくつですか?
+ テクノロジーを最後に更新したのはいつですか? 更新は今後予定されていますか? その場合、いつですか?
+ このアプリケーションの既知のリスクと問題は何ですか? 停止、中程度および重要度の高いインシデントの履歴は何ですか?
+ 使用サイクル (営業時間) を教えてください。運用タイムゾーンは何ですか?
+ 変更凍結期間とは何ですか?
+ このアプリケーションをモニタリングするには、どのようなソリューションを使用しますか?
## パフォーマンス
+ 収集されたパフォーマンス情報には何が表示されますか? 使用量は急増しているか、一定で予測可能か。使用可能なパフォーマンスデータの時間枠、間隔、日付を教えてください。
+ このアプリケーションの一部である、またはこのアプリケーションとやり取りするスケジュールされたバッチジョブはありますか?
## ソフトウェアのライフサイクル
+ 現在の変化率はどのくらいですか (毎週、毎月、四半期ごと、または毎年)?
+ 開発ライフサイクル (テスト、開発、QA、UAT、本番前、本番など) は何ですか?
+ アプリケーションとインフラストラクチャのデプロイ方法は何ですか?
+ デプロイツールとは
+ このアプリケーションまたはインフラストラクチャは、継続的インテグレーション (CI)/継続的デリバリー (CD) を使用していますか? 自動化のレベルはどのくらいですか? 手動タスクとは
+ アプリケーションとインフラストラクチャのライセンス要件は何ですか?
+ サービスレベルアグリーメント (SLA) とは
+ 現在のテストメカニズムは何ですか? テストステージとは
## 移行
+ 移行に関する考慮事項は何ですか?
この時点で、このアプリケーションを移行する際の考慮事項に注意してください。より完全で正確な評価を行うには、さまざまな利害関係者からこの質問に対する回答を取得します。次に、知識と意見を対比します。
## 回復性
+ 現在のバックアップ方法は何ですか? バックアップに使用される製品 バックアップスケジュールとは何ですか? バックアップ保持ポリシーとは
+ 現在の目標復旧時点 (RPO) と目標復旧時間 (RTO) は何ですか?
+ このアプリケーションにはディザスタリカバリ (DR) プランがありますか? その場合、DR ソリューションとは何ですか?
+ 最後の DR テストはいつ行われましたか?
## セキュリティとコンプライアンス
+ このアプリケーションに適用されるコンプライアンスと規制のフレームワークは何ですか? 最終監査日と次回の監査日はいつですか?
+ このアプリケーションは機密データをホストしていますか? データ分類とは?
+ データは転送中、保管中、またはその両方で暗号化されていますか? 暗号化メカニズムとは
+ このアプリケーションは SSL 証明書を使用していますか? 発行機関とは
+ ユーザー、コンポーネント、その他のアプリケーションやサービスの認証方法は何ですか?
## データベース
+ このアプリケーションはどのデータベースを使用しますか?
+ データベースへの同時接続の一般的な数を教えてください。接続の最小数と最大数を教えてください。
+ 接続方法 (JDBC、ODBC など) は何ですか?
+ 接続文字列は文書化されていますか? その場合、どこにありますか?
+ データベーススキーマとは
+ データベースはカスタムデータ型を使用していますか?
## 依存関係
+ コンポーネント間の依存関係は何ですか? 解決できず、コンポーネントを一緒に移行する必要がある依存関係に注意してください。
+ コンポーネントは複数の場所に分かれていますか? これらの場所 (WAN、VPN など) 間の接続は何ですか?
+ このアプリケーションの他のアプリケーションやサービスへの依存関係は何ですか?
+ 運用上の依存関係は何ですか? 例えば、パッチ適用ウィンドウなどのメンテナンスとリリースのサイクルなどです。
# AWS アプリケーション設計と移行戦略
アプリケーションの将来の状態を設計および文書化することは、移行の重要な成功要因です。シンプルでも複雑でも、あらゆる種類の移行戦略の設計を作成することをお勧めします。設計を作成すると、アーキテクチャの変更が予想されない場合でも、潜在的なブロック要因、依存関係、アプリケーションを最適化する機会が明らかになります。
また、移行戦略レンズ AWS を使用して、 のアプリケーションの将来の状態に近づくことをお勧めします。この段階では、この移行 AWS の結果としてアプリケーションがどのようになるかを必ず定義してください。結果として得られる設計は、移行後のさらなる進化の基盤となります。
次のリストには、設計プロセスに役立つリソースが含まれています。
+ [AWS アーキテクチャセンター](https://aws.amazon.com/architecture/)は、 AWS Well-Architected フレームワークなどのツールとガイダンスを組み合わせています。また、アプリケーションに使用できるリファレンスアーキテクチャも提供します。
+ [Amazon Builders' Library ](https://aws.amazon.com/builders-library/)には、Amazon がソフトウェアを構築および運用する方法に関するいくつかのリソースが含まれています。
+ [AWS ソリューションライブラリ](https://aws.amazon.com/solutions/)は、数十の技術的およびビジネス上の問題について AWS、 によって検証されたクラウドベースのソリューションのコレクションを提供します。これには、リファレンスアーキテクチャの大規模なコレクションが含まれています。
+ [AWS 規範ガイダンス](https://aws.amazon.com/prescriptive-guidance/)は、設計プロセスと移行のベストプラクティスに役立つ戦略、ガイド、パターンを提供します。
+ [AWS Documentation](https://docs.aws.amazon.com/) には、ユーザーガイドや API リファレンスなどの AWS サービスに関する情報が含まれています。
+ [入門リソースセンター](https://aws.amazon.com/getting-started/)には、基礎を学習するための実践的なチュートリアルと詳細な演習がいくつか用意されています AWS。
クラウドジャーニーのどの段階にあるかに応じて、 AWS 基盤が既に存在している可能性があります。これらの AWS 基盤には以下が含まれます。
+ AWS リージョン が特定されました。
+ アカウントが作成されているか、オンデマンドで取得できます。
+ 一般的なネットワークが実装されました。
+ 基本 AWS サービスは アカウント内にデプロイされています。
逆に、プロセスの早い段階で AWS 基盤がまだ確立されていない可能性があります。基盤が確立されていないと、アプリケーション設計の範囲が制限されたり、定義のためのさらなる作業が必要になる可能性があります。この場合、ランディングゾーンの基本的な設計をアプリケーション設計作業と並行して定義して実装することをお勧めします。アプリケーション設計は、 AWS アカウント 構造、ネットワーキング、仮想プライベートクラウド (VPCs)、クラスレスドメイン間ルーティング (CIDR) 範囲、共有サービス、セキュリティ、クラウドオペレーションなどの要件を特定するのに役立ちます。
[AWS Control Tower](https://aws.amazon.com/controltower/) は、ランディングゾーンと呼ばれる安全なマルチアカウント AWS 環境をセットアップして管理するための最も簡単な方法を提供します。 は を使用してランディングゾーン AWS Control Tower を作成します。これにより AWS Organizations、何千人ものお客様とクラウドに移行する際に、 AWS ベストプラクティスベースのエクスペリエンスを継続的に管理、ガバナンス、実装できます。
## アプリケーションの将来の状態
まず、このアプリケーションの初期移行戦略を確立します。この時点で、戦略は将来の状態設計の一部として変更され、潜在的な制限が明らかになる可能性があるため、初期と見なされます。初期の前提条件を検証するには、[6 Rs 決定ツリー](prioritization-and-migration-strategy.md#migration-r-type)を参照してください。また、潜在的な移行フェーズを文書化します。たとえば、このアプリケーションは 1 つのイベントに移行されますか (すべてのコンポーネントは同時に移行されますか）。または、これは段階的な移行ですか (一部のコンポーネントは後で移行されます)?
特定のアプリケーションの移行戦略は一意ではない場合があることに注意してください。これは、複数の R タイプを使用してアプリケーションコンポーネントを移行できるためです。例えば、最初のアプローチは、変更なしでアプリケーションをリフトアンドシフトすることです。ただし、アプリケーションのコンポーネントは、さまざまな処理を必要とするさまざまなインフラストラクチャアセットに存在する場合があります。たとえば、アプリケーションは 3 つのコンポーネントで構成され、それぞれが別のサーバーで実行され、いずれかのサーバーはクラウドでサポートされていないレガシーオペレーティングシステムを実行します。このコンポーネントにはリプラットフォームアプローチが必要ですが、サポートされているサーバーバージョンで実行されている他の 2 つのコンポーネントはリホストできます。移行する各アプリケーションコンポーネントおよび関連するインフラストラクチャに移行戦略を割り当てることが重要です。
次に、コンテキストと問題を文書化し、現在の状態を定義する既存のアーティファクトをリンクします。
+ このアプリケーションが移行される理由
+ 提案された変更は何ですか?
+ 利点は何ですか?
+ 重大なリスクやブロック要因はありますか?
+ 現在の欠点は何ですか?
+ スコープ内とスコープ外のものは何ですか?
## 再現性
設計作業全体を通して、このアプリケーションのこのソリューションとアーキテクチャを他のアプリケーションに再利用する方法を検討してください。このソリューションは一般化できますか?
## 要件
セキュリティを含め、このアプリケーションの機能要件と非機能要件を文書化します。これには、選択した移行戦略に応じて、現在と将来の状態の要件が含まれます。詳細なアプリケーション評価中に収集された情報を使用して、このプロセスをガイドします。
## To-Be アーキテクチャ
このアプリケーションの将来のアーキテクチャについて説明します。ソース環境 (オンプレミス) とターゲット AWS 環境 (ターゲット、アカウント AWS リージョン、VPCs、アベイラビリティーゾーンなど) の構成要素を含む再利用可能な図テンプレートを作成することを検討してください。
移行されるコンポーネントと新しいコンポーネントのテーブルを作成します。このアプリケーションとやり取りする他のアプリケーションとサービス (オンプレミスまたはクラウド) を含めます。
次の表に、コンポーネントの例を示します。リファレンスアーキテクチャや精査された設定を表すものではありません。
| **名前** | **説明** | **詳細** |
| --- |--- |--- |
| アプリケーション | 外部サービス (インバウンド接続) | サービスは、公開された API からのデータを消費します。 |
| DNS | 名前解決 (内部) | ベースラインアカウント設定の一部としてデプロイされた Amazon Route 53 |
| Application Load Balancer | バックエンドサービス間でトラフィックを分散します | オンプレミスロードバランサーを置き換えます。プール A を移行します。 |
| アプリケーションのセキュリティ | DdoS 保護 | を使用して実装 AWS Shield |
| セキュリティグループ | 仮想ファイアウォール | ポート 443 (インバウンド) のアプリケーションインスタンスへのアクセスを制限します。 |
| サーバー A | フロントエンド | Amazon Elastic Compute Cloud (Amazon EC2) を使用してリホストします。 |
| サーバー B | フロントエンド | Amazon EC2 を使用してリホストします。 |
| サーバー C | アプリケーションロジック | Amazon EC2 を使用してリホストします。 |
| サーバー D | アプリケーションロジック | Amazon EC2 を使用してリホストします。 |
| Amazon Relational Database Service (Amazon RDS) – Amazon Aurora | データベース | サーバー E と F を置き換えます |
| モニタリングとアラート | 変更管理 | Amazon CloudWatch |
| 監査ログ | 変更管理 | AWS CloudTrail |
| パッチ適用とリモートアクセス | メンテナンス | AWS Systems Manager |
| リソースアクセス | 安全なアクセスコントロール | AWS Identity and Access Management (IAM) |
| 認証 | ユーザーアクセス | Amazon Cognito |
| 証明書 | SSL/TLS | AWS Certificate Manager |
| API 1 | 外部 API | Amazon API Gateway |
| オブジェクトストレージ | イメージホスティング | Amazon Simple Storage Service (Amazon S3) |
| 認証情報 | 認証情報の管理とホスティング | AWS Secrets Manager |
| AWS Lambda 関数 | データベース認証情報と API キーの取得 | AWS Lambda |
| インターネットゲートウェイ | アウトバウンドインターネットアクセス | VPC へのインターネットゲートウェイ |
| プライベートサブネット 1 | バックエンドと DB | アベイラビリティーゾーン 1 – VPC 1 |
| プライベートサブネット 2 | バックエンドと DB | アベイラビリティーゾーン 2 – VPC 1 |
| パブリックサブネット 1 | フロントエンド | アベイラビリティーゾーン 1 – VPC 1 |
| パブリックサブネット 2 | フロントエンド | アベイラビリティーゾーン 2 – VPC 1 |
| バックアップサービス | データベースと EC2 インスタンスのバックアップ | AWS Backup |
| DR | Amazon EC2 の耐障害性 | AWS Elastic Disaster Recovery |
コンポーネントを特定したら、任意のツールを使用してそれらを図にプロットします。初期設計を、アプリケーション所有者、エンタープライズアーキテクト、プラットフォームチーム、移行チームなど、主要なアプリケーションステークホルダーと共有します。次の質問をすることを検討してください。
+ チームは通常、設計に同意していますか?
+ 運用チームはサポートできますか?
+ 設計を進化させることはできますか?
+ 他にオプションはありますか?
+ 設計はアーキテクチャ標準とセキュリティポリシーに準拠していますか?
+ 不足しているコンポーネント (コードリポジトリ、CI/CD ツール、VPC エンドポイントなど) はありますか?
## アーキテクチャ上の決定事項
設計プロセスの一環として、アーキテクチャ全体またはその特定の部分に対してより多くのオプションが見つかる可能性があります。これらのオプションを、優先または選択したオプションの理論的根拠とともに文書化します。これらの決定は、アーキテクチャ上の決定として文書化できます。
メインオプションがリストされ、新しいリーダーが別のオプションを使用する決定の背後にあるオプションと理由を理解するのに十分な詳細で説明されていることを確認します。
## ソフトウェアライフサイクル環境
現在の環境への変更を文書化します。たとえば、テスト環境と開発環境は で再作成され AWS 、移行されません。
## Tagging
各インフラストラクチャコンポーネントの必須および推奨されるタグ付けと、この設計のタグ付け値について説明します。
## 移行戦略
設計のこの時点で、移行戦略に関する最初の前提を検証する必要があります。選択した R 戦略にコンセンサスがあることを確認します。全体的なアプリケーション移行戦略と個々のアプリケーションコンポーネントの戦略を文書化します。前述のように、異なるアプリケーションコンポーネントでは、移行に異なる R タイプが必要になる場合があります。
さらに、移行戦略を主要なビジネス推進要因と成果に合わせます。また、さまざまな移行イベントでのコンポーネントの移動など、移行に対する段階的なアプローチについても説明します。
6 R の決定の詳細については、[AWS Migration Hub 「戦略の推奨事項](https://aws.amazon.com/blogs/aws/new-strategy-recommendations-service-helps-streamline-aws-cloud-migration-and-modernization/)」を参照してください。
## 移行パターンとツール
アプリケーションおよびインフラストラクチャコンポーネントの移行戦略を定義することで、特定の技術パターンを探索できるようになりました。たとえば、リホスト戦略は、 などの移行ツールで実装できます[AWS Application Migration Service](https://aws.amazon.com/application-migration-service/)。状態やデータをレプリケートする必要がない場合は、Amazon マシンイメージ (AMI) とアプリケーションデプロイパイプラインを使用してアプリケーションを再デプロイすることで、同じ結果を実現できます。
同様に、アプリケーションをリプラットフォームまたはリファクタリング (リアーキテクト) するには、[AWS App2Container](https://aws.amazon.com/app2container/)、 [AWS Database Migration Service (AWS DMS)](https://aws.amazon.com/dms/)、 [AWS Schema Conversion Tool](https://aws.amazon.com/dms/schema-conversion-tool/) (AWS SCT)、 などのツールを使用できます[AWS DataSync](https://aws.amazon.com/datasync/)。コンテナ化には、[Amazon Elastic Container Service (Amazon ECS)](https://aws.amazon.com/ecs/)、[Amazon Elastic Kubernetes Service (Amazon EKS)](https://aws.amazon.com/eks/)、または を使用できます[AWS Fargate](https://aws.amazon.com/fargate/)。再購入するときは、特定の製品または の Software as a Service (SaaS) ソリューションに AMI を使用できます[AWS Marketplace](https://aws.amazon.com/marketplace/)。
目標を達成するために利用できるさまざまなパターンとオプションを評価します。長所と短所、および移行の運用準備を検討してください。分析に役立てるには、次の質問を使用します。
+ 移行チームはこれらのパターンをサポートできますか?
+ コストと利点のバランスはどれくらいですか?
+ このアプリケーション、サービス、またはコンポーネントをマネージドサービスに移動できますか?
+ このパターンを実装する労力は何ですか?
+ 特定のパターンの使用を妨げる規制やコンプライアンスポリシーはありますか?
+ このパターンは再利用できますか? 再利用可能なパターンが推奨されます。ただし、パターンが 1 回だけ使用される場合があります。代替の再利用可能なパターンよりも、シングルユースパターンの労力のバランスを検討してください。
[AWS 規範ガイダンス](https://aws.amazon.com/prescriptive-guidance/)には、さまざまな移行パターンと手法が含まれています。
## サービス管理とオペレーション
への移行のためのアプリケーション設計を作成するときは AWS、運用準備を検討してください。アプリケーションチームとインフラストラクチャチームで準備状況要件を評価するときは、次の質問を考慮してください。
+ 運用する準備はできていますか?
+ インシデント対応手順は定義されていますか?
+ 予想されるサービスレベルアグリーメント (SLA) とは何ですか?
+ 職務の分離は必要ですか?
+ さまざまなチームがサポートアクションを調整する準備はできていますか?
+ 誰が何を担当しますか?
## カットオーバーに関する考慮事項
移行戦略とパターンを考慮すると、アプリケーションが移行された時点で知っておくべき重要なことは何ですか? カットオーバー計画は、設計後のアクティビティです。ただし、予想されるアクティビティと要件に関する考慮事項があれば文書化します。例えば、該当する場合は概念実証を実行する要件を文書化し、テスト、監査、または検証の要件を概説します。
## リスク、前提、問題、依存関係
未解決の未解決のリスク、前提、潜在的な問題を文書化します。これらの項目に明確な所有権を割り当て、全体的な設計と戦略の実装を承認できるように進捗状況を追跡します。さらに、この設計を実装するための主要な依存関係を文書化します。
## 実行コストの見積もり
ターゲット AWS アーキテクチャのコストを見積もるには、 [AWS 料金計算ツール](https://calculator.aws/)を使用します。設計で定義されているインフラストラクチャコンポーネントを追加し、推定実行コストを取得します。アプリケーションコンポーネントに必要なソフトウェアライセンスと、使用する AWS サービスにまだ含まれていないソフトウェアライセンスを考慮します。