クラウド移行を成功させるためのヒント

世界中で進行中のコロナウイルスの流行は、さまざまな業界の組織に新たな課題をもたらしています。これは、組織のビジネス開発と運用モデルに大きな影響を与えます。多くの組織は、「パンデミック中にビジネスの回復力を高めるにはどうすればよいか」、「より迅速に革新し、顧客に新しいビジネス サービスを提供するにはどうすればよいか」、「総所有コストを削減するにはどうすればよいか」、「より優れた接続性とコラボレーションを実現するにはどうすればよいか」などの問題について考えています。これらの問題と課題はパンデミック以前から存在していましたが、現在ではますます重要かつ重要になっています。

[[378418]]

すでにクラウド コンピューティングの導入を開始している組織は、パンデミックに対して優れた回復力と対応力を発揮しています。近い将来、さまざまなクラウド サービス モデル (SaaS、PaaS、IaaS) とハイブリッド クラウドおよびマルチクラウド トポロジの組み合わせにより、さまざまな業界の組織におけるクラウド コンピューティングの導入が大幅に増加すると予想されます。クラウド ホスティングは、企業にとって欠かせない新たな IT サービスになります。

組織が採用するクラウド コンピューティング変革アプローチにより、ビジネス目標の達成、コストの削減、戦略的優位性の実現が期待されます。以下は、アプリケーションのクラウド移行とデジタル変革に対する一般的なアプローチの要素の簡単な概要です。この記事では、付加価値のないポートフォリオへの支出を削減することで潜在的なコスト削減を特定する方法と、クラウド コンピューティング テクノロジーのメリットを享受するためのクラウド移行アプローチを組み合わせます。クラウド コンピューティング変革を成功させるための体系的なアプローチについても説明します。

一般的なクラウド コンピューティング プロジェクトは 4 つのフェーズに分かれています。組織の変革の現在の段階に応じて、どの段階にあるかを判断することが重要です。これには以下が含まれます。

• 戦略とポートフォリオの評価
• 設計と計画
• 移住と変革
• 管理業務と最適化

以下では、最初の 2 つの段階、つまり「戦略とポートフォリオの評価」と「設計と計画」に焦点を当てます。

1. 戦略とポートフォリオの評価

このフェーズの目標は、組織のクラウド コンピューティングの準備状況を評価し、クラウド コンピューティング戦略を定義し、アプリケーション ポートフォリオの評価を実施し、ターゲットの展開を定義することです。

1. クラウドコンピューティング戦略

組織がクラウド コンピューティング戦略を策定する前に、現在のビジネス目標と優先事項、現在の IT 環境、進行中の変革イニシアチブ、およびテクノロジ戦略を理解することが重要です。組織は次の点を考慮する必要があります。

（1）組織のビジョン、ビジネス、IT戦略に沿ったクラウドコンピューティングの目標を定義します。クラウド コンピューティングによって組織がビジネス目標や新しい機能をどのように達成できるかを定義します。

（２）クラウドコンピューティングを導入する主な目的を定義する。たとえば、デジタル変革、データセンターの廃止、近代化、レガシー テクノロジの置き換え、新しいビジネス サービスの開始、柔軟性の向上、容量の急増、コストの削減、回復力、応答性、柔軟性、運用効率の向上などです。組織は、有形と無形の両方のメリットを持つこれらの目標に対して主要業績評価指標 (KPI) を定義します。

（３）クラウドへの移行と変革のプロセスアプローチを定義する。たとえば、多くの組織は、実装前にさまざまなワークロード シナリオを理解するためのパイロットを実施するよりも、短期間で移行することを好みます。

（4）クラウド導入の根拠、影響、およびクラウド導入の決定の定義。決定事項の一部を以下に示します。

• クラウド コンピューティング サービス プロバイダー (AWS、Azure、または Google Cloud Platform) を選択する決定。 「プライベート クラウド」、「ハイブリッド クラウド」、「マルチクラウド」などのクラウド コンピューティング トポロジを定義します。マルチクラウド戦略の場合は、異なるクラウド プラットフォームを選択する理由と、異なるクラウド プラットフォームに配置できるワークロードの種類 (たとえば、分析業務は AWS 上に、既存サーバーは Azure 上) を定義する必要があります。
• コンテナ プラットフォームとコンテナ化戦略に関する決定。
• アプリケーションに適したクラウド コンピューティング サービス モデルを選択します。たとえば、SaaS、PaaS、CaaS (Container as a Service)、IaaS の順になります。
• どのクラウド コンピューティング サービス プロバイダーからどのクラウド コンピューティング サービス (IaaS/PaaS) を採用するかを定義します。たとえば、サーバーレス コンピューティング機能 (Lambda/Azure Functions など) は、さまざまなセキュリティ上の理由により、組織のポリシーとして承認されない場合があります。新しいクラウド コンピューティング サービスの使用承認を取得します。
• パッケージ化されたソフトウェアまたはアプリケーションを SaaS またはコモディティ製品やテクノロジー (COTS) プラットフォームに置き換えるために行われた、または検討されているすべての決定として定義されます。
• DevOps の原則、セルフサービスとクラウド ブローカーの原則の適用、移行のための標準テクノロジー スタックの実装など、クラウド導入の原則を定義します。ベンダーロックインを回避するために、移植性の原則が採用されています。たとえば、クラウド プラットフォーム間の移植性をサポートするために Kubernetes ベースの PaaS コンテナ プラットフォームを実装します。 「コードとしてのインフラストラクチャ」の原則により、あらゆるクラウド プラットフォームへの展開が可能になります。ネイティブ データベースではなく、クラウドに依存しないデータベースを選択します。クラウド プラットフォーム間の移植性オプション (AWS から Azure、Azure から AWS など)。

（５）データウェアハウスやビッグデータ・分析プラットフォームなどのデータ移行には、クラウドネイティブや新時代のCOTSデータプラットフォームを使用した詳細なデータ移行戦略を策定する必要がある。

（6）マルチクラウド統合のためのプラットフォームを定義する（例：iPaaSおよびAPIゲートウェイプラットフォームの使用）。

（7）クラウド移行と変革のタイムラインの概要。

（８）新しい役割、新しいスキル、導入プロセスの変更、必要となる可能性のある追加のテスト（セキュリティ/侵入テストなど）、新しいクラウドコンピューティングスキルのトレーニング要件などの高度な変更管理プロセス

（9）データセキュリティや規制上の制限、進行中の戦略的取り組みによる影響など、組織におけるクラウドコンピューティングアプリケーションの制限、リスク、緩和策を定義します。 IT サービス プロバイダーの終了基準は、クラウド サブスクリプション/アカウント所有権の譲渡プロセスに似ており、クラウド コンピューティング サービス プロバイダーの終了基準もあります。

（10）クラウドガバナンスの原則とガードレール、すなわち規制とコンプライアンスのプロセス、クラウド移行プロジェクトの承認プロセス、運用ガイドライン、およびコスト管理を満たすためのルールを定義します。

（11）データセンターの撤退戦略については、高度なデータセンター（DC）廃止プロセスを定義する。

（12）クラウドコンピューティング戦略は進化し続ける文書です。多くの場合、クラウド コンピューティング戦略の実装を開始するときに曖昧さが生じます。設計および計画のプロセス中に、この戦略はより正確になります。

2. アプリケーションポートフォリオの評価

組織全体のアプリケーション ポートフォリオ評価を実施します。これは、組織全体の変革戦略を定義するために必要なステップです。評価が行われた場合は、さらに分析を実行できます。組織全体がクラウドの準備ができていない場合は、クラウド変革の準備ができているビジネス ユニット内のアプリケーションを評価する計画を立てます。組織は、再ホスト、再プラットフォーム、リファクタリング、再設計、置き換え、保持、廃止という 7R 移行戦略を採用します。評価フェーズの結果は、アプリケーション マッピングの 7R 戦略の 1 つになります。

アプリケーションは、トップダウンとボトムアップの両方のアプローチを通じて評価する必要があります。このフェーズでは、ワークショップを実施し、一連のアンケートへの回答を収集することで、必要な申請の詳細を取得します。アプリケーションおよびインフラストラクチャの属性は、構成管理データベース (CMDB) または既存のエンタープライズ アーキテクチャ (EA) リポジトリから収集することもできます。 IT フットプリントが大きい企業の場合、自動化されたアプリケーションおよびインフラストラクチャ検出ツールを活用して、必要な属性とアプリケーションの詳細を取得することをお勧めします。

アプリケーションのライフ サイクル状態を識別します。近い将来に「廃止が計画されている」、またはそれ以上の評価から「廃止」されたアプリケーションとインフラストラクチャの評価リストをフィルタリングします。

（１）データ収集

アプリケーションごとに、次のカテゴリのプロパティが収集されます。

• アプリケーション属性: 機能、アプリケーションのライフサイクル状態、ビジネス機能、サポートされているビジネス ユニット、ホスティング場所/地理的位置、アプリケーションの種類 (Web/バッチ/ミドルウェア/トランザクション/分析など)、近い将来に予定されているアップグレードや変更など、基本的なアプリケーション属性のインベントリを作成します。
• ビジネス価値属性: 収益の創出、分析レポートの提供、運用のサポートなど、アプリケーションがビジネスにとってどの程度重要であるか。ビジネス戦略との整合性、現在の収益、ビジネス上の重要性、他のアプリケーションに存在するこのアプリケーションの冗長/重複機能、ユーザー数、新機能のリリースにかかる時間 (俊敏性)、組織の差別化要因、ユーザー満足度、このアプリケーションの自動化レベルなどの要素を把握します。
• 総所有コスト: アプリケーションの保守コスト、インフラストラクチャ コスト、ライセンス コストなど。
• 技術的価値属性: アプリケーションと技術戦略の整合、アプリケーションの技術的負債とパフォーマンス、サポートの容易さ、統合の容易さ、最新の技術標準への準拠、モジュール性、拡張性、移植性、アクセシビリティ、保守性、応答時間、回復性、可用性、パフォーマンス、開発および展開方法などの非機能要件 (NFR) の満たし状況、および生成されるデータの品質と正確性。
• リスクとコンプライアンスの属性: データ機密性レベル、データ暗号化要件、アプリケーション セキュリティ要件、組織的制約、ローカル/地域の規制要件 (HIPPA、GDPR、PCI-DSS など) などのデータ プライバシー、セキュリティ、規制要件。
• クラウド適合性: アプリケーションをクラウド プラットフォームに移行する技術的な実現可能性を確認します。また、さまざまな状況を理解します。たとえば、アプリケーションにはクラウドでサポートされていないハードウェア依存関係 (デバイス) やオペレーティング システム (OS) がありますか?パッケージ化された COTS アプリケーションの場合は、クラウド プラットフォームのサポート可能性を確認する必要があります。アプリケーションは COBOL、C、C++ などの従来のテクノロジーを使用していますか?それとも現代の技術を使っているのでしょうか?オンプレミスのデータセンターでホストされているか、サードパーティのデータセンターでホストされているかなど、クラウド プラットフォームでのデータベースのサポート可能性を確認します。
• 複雑さ: クラウド移行に影響を及ぼす可能性のある複雑さ。アプリケーションの配布、構成、ホストの数、データベースのサイズ、インターフェース テクノロジ、インターフェースの数 (インバウンドとアウトバウンド)、トポロジ/クラスタリング要件、負荷分散要件、コードの複雑さ、ビルド/テスト/展開の容易さ、使用されるレガシー テクノロジなどの要因。

多くの IT 企業やクラウド サービス プロバイダー (AWS/Azure/Google) は、無料の自動アプリケーション検出および評価ツールを提供しています。ただし、組織は適切な廃棄戦略を決定するために、特定の属性を把握するために手動による介入とインタビューを必要とします。

（２）分析

展開に影響を与える組織のクラウド コンピューティング戦略を理解することが重要です。組織が近い将来にデータ センターの統合またはデータ センターの廃止戦略を立てている場合、既存のアプリケーションに対しては「再ホスト」および「再プラットフォーム」の処分チェックが最初の選択肢となる可能性があります。

これは、ワークロードの一部をより迅速に移行し、後の段階でアプリケーションを更新する必要がある組織にも当てはまります。重要なビジネス アプリケーションを実行している基盤となるオペレーティング システムまたはソフトウェアのサポートが終了している可能性があります。このようなアプリケーションは、ベンダーのサポートが利用できるクラウド プラットフォーム上の新しいソフトウェア バージョンまたはオペレーティング システム バージョンへの移行の候補となる可能性があります。一部の組織では、クラウド変革を既存の IT を合理化および最新化する機会として活用しています。また、サポートされているコンテナ テクノロジ スタック (Docker など) にリファクタリングすることで、採用したアプリケーションをコンテナ化に対応させたいと考える企業もあります。また、コストを節約するために、商用アプリケーション/データベースをより安価なオープンソースに変換する機会を利用する人もいます。一部の組織では、クラウド コンピューティングを追加の容量ニーズの延長と見なす場合があります。一方、クラウド コンピューティング プラットフォームを、データ レイク、分析、機械学習などの新しい機能を構築するためのツールと見なす人もいます。

たとえば、製薬メーカーは、新型コロナウイルス感染症のパンデミックに対抗するための効果的なワクチンをより早く見つけるために、大量のデータを分析したいと考えるかもしれません。クラウド コンピューティングは、実験 (パイロット/概念実証など) にも使用できます。

「再ホスト/再プラットフォーム」戦略では、リスクは低く、移行作業も少なくなりますが、メリットは少なくなります。アプリケーションの修復または最新化には移行作業が増えますが、長期的なメリットが大きくなります。各アプリケーションの移行のリスクと報酬の比率を評価することが重要です。一部のレガシー アプリケーションは、技術的な制限により再ホストまたは再プラットフォーム化できず、新しいプラットフォーム上で変更 (再構築) する必要があります。高価なリファクタリング作業を行うよりも、価値の低いアプリケーションを低コストのハードウェアでホストする方が有益です。

前述のように、アンケートやその他の属性から収集されたデータを使用して、7R処理の適用を分析しました。各カテゴリの属性の重みとスコアを提供します。重み付けは組織のビジネス戦略に基づいて決定できます。たとえば、優れたユーザー エクスペリエンスの提供よりも市場投入までの時間の方がビジネスにとって重要であったり、高可用性よりも技術的負債の方が重要であったりする場合があります。

ビジネス機能ヒープ マップは、各アプリケーションとビジネス機能間のマッピングを定義します。 COTS ライセンスの削減、統合または置き換えが可能な冗長アプリケーション、実行コストが高すぎるアプリケーション/データ ストアなどの合理化の機会を特定します。

ビジネス価値、技術的価値、クラウド コンピューティングの適合性のスコアに基づいて、組織は「時間」モデル、「移行の利点と容易さ」、「技術的価値とビジネス価値」のグラフなど、さまざまな分析モデルを作成できます。これにより、潜在的な「迅速な成功」、つまり、リスクが低く、より迅速に移行でき、コスト上の利点と短期的なビジネス価値も提供できるアプリケーションを特定できます。

3. 廃棄と推奨事項

ターゲットのクラウド プラットフォーム構成に到達するための意思決定ツリーを作成します。たとえば、ビジネス価値は低いがクラウド準備スコアが高いアプリケーションは、「再設計」に多大な労力をかけずに、単に「再ホスト」することができます。ビジネス価値がなく、技術的価値も低いアプリケーションは、廃止するか、低コストのインフラストラクチャで再ホストすることを検討できます。ビジネス上のメリットは非常に高いが、技術的な価値が低い (つまり、技術的負債が高い) アプリケーションについては、置き換え、リファクタリング、または再構築を検討してください。長期的なメリットがある再アーキテクチャ/再ホストのシナリオでは、ビジネス価値と技術価値の高いアプリケーションの採用を検討してください。一部の IT サービス プロバイダーは、分析プロセスを修正するために標準化されたスコアリング値とルール セットを維持する分析ツールを開発しています。

この段階では、アプリケーションに関する高レベルの推奨事項を提供することが役立つ場合があります。各アプリケーションに対して短期的および長期的な推奨事項を定義できます。たとえば、短期的な戦略として「再ホスト」、長期的な戦略としてサーバーレス コンピューティングのサンプル デプロイメントを使用して再構築することが考えられます。

4. ビジネスケース

高レベルの評価を完了したら、アプリケーションの高レベルの費用対効果分析を実行します。オンプレミス インフラストラクチャの運用コスト、減価償却、インフラストラクチャの運用コストに基づいて、アプリケーションを実行するための現在の総コストを決定します。組織は今後 3 ～ 4 年間の予想支出を把握できます。アプリケーションとデータベースの構成に基づいて、適切なインスタンス サイズ、インスタンス タイプ、ストレージ、ネットワーク コンポーネント、PaaS サービスを使用してターゲット インフラストラクチャ インベントリを作成します。

組織は、今後 3 ～ 4 年間の対象となるクラウド コンピューティング アプリケーションの実行コストを決定し、クラウド移行のおおよそのコストを決定する必要があります。クラウド プラットフォームに移行する場合は、現在の運用インフラストラクチャをシャットダウンすることでどれだけのコストが節約できるかを判断する必要があります。さまざまなクラウド コンピューティング プロバイダーの割引、長期料金プラン、特典を利用することでもコストを削減できます。

組織のクラウド コンピューティングへの投資は、通常 2 ～ 3 年以内に実現されます。さまざまなクラウド プラットフォームでのホスティングのコストを比較します。クラウド プロバイダーのオンライン TCO 計算ツール/月額費用計算ツールを使用してコストを計算できます。俊敏性、回復力、柔軟性、拡張性などの追加の無形のメリットをビジネスケースの一部として含めます。

このビジネス ケースは、ビジネス オーナーと組織の幹部に、クラウド コンピューティング プロジェクトを開始するための意思決定ポイントを提供します。アプリケーションとデータがクラウド プラットフォームに移行された後には、クラウドの最適化演習を含めることも重要です。

5. クラウドコンピューティング事業部

クラウドの導入と価値の実現を成功させるには、組織内での効果的な戦略的監視とガバナンスが重要です。組織は、組織の幹部、主要なビジネス関係者、アプリケーション所有者、インフラストラクチャ リーダー、セキュリティ リーダー、エンジニアリング リーダー、運用リーダー、調達チーム、リスクとコンプライアンス、およびクラウド変革を推進および実現する能力を含むクラウド ビジネス オフィス (CBO) を確立する必要があります。クラウド ビジネス オフィス (CBO) の目標は、変革の目標と目的を定義し、組織全体でクラウド戦略を推進し、予算編成、アーキテクチャ標準、変更管理を提供し、クラウド移行プロジェクトを開始および管理し、指標と利点を通じて価値実現を追跡することです。

各役割には、クラウド ビジネス オフィス (CBO) の目標とクラウド導入の決定をサポートする長期的または短期的な責任があります。この機能または部門は、クラウド戦略オフィス (CSO) またはクラウド センター オブ エクセレンス (COE) と呼ばれることもあります。

2. 設計と計画

このフェーズでは、アプリケーションの詳細な評価が実行され、クラウド移行戦略を実装するための最小限の実行可能なアーキテクチャが定義されます。このフェーズでは、クラウド コンピューティング戦略も改良できます。

（１）詳細評価：コードスキャナを使用して、リファクタリングする予定のアプリケーションコード/ソフトウェアを分析します。リファクタリングのためにコードをスキャンするための市販ツールは数多くあります。 Azure クラウド プラットフォームと AWS クラウド プラットフォームでは、.NET Migration Analyzer/Migration Assistant for .NET などのコード スキャン ツールも提供されています。また、アプリケーションをコンテナ化し、コンテナ プラットフォームにデプロイできる AWS App2Container などのツールもあります。組織は、アプリケーションの再ホスティング、再プラットフォーム化、再構成のための機能とコードを分析し、リスクと障害を特定する必要があります。

（２）変革ロードマップ：これまでの取り組みと評価に基づいてクラウド移行計画を定義します。共通の依存関係とデータベースを持つアプリケーションをグループ化します。このようなグループごとに移行を定義します。グループ化は、組織機能/ドメインまたは技術機能 (Web アプリケーション、ミドルウェア、コア トランザクション システム、ビッグ データなど) 別に行うこともできます。複雑さに応じてアプリケーションに優先順位を付けます。リスクが低く、複雑さが少ないアプリケーションの移行を計画します。

たとえば、シンプルな Web アプリケーションやレポート作成アプリケーションは、先行導入アプリケーションと見なすことができます。組織は、アジャイル プロセス アプローチとチーム構造を決定し、移行ユーザー ストーリーとスプリントの数を特定し、移行チームの構造を定義し、チームを部族と分隊に分割して適切なチーム サイズを決定できます。一部の組織では、これを POD 構造と呼ぶ場合があります。

組織は、アプリケーションの移行、テスト、および切り替え計画のライフサイクル フェーズも定義します。移行が成功すると、残りのアプリケーションを移動するためのテンプレートが作成されます。アプリケーションの最新化 (再設計またはリファクタリング) には、移行に DevOps および Agile 方法論 (Scrum、SAFe など) を適用し、より多くの時間と長期的な戦略が必要になる場合があります。

（３）ターゲットアーキテクチャ：アプリケーション、データ、ネットワークコンポーネントのターゲット展開アーキテクチャを定義します。クラウド移行はアジャイルに計画されるため、移行を実現するにはシンプルでありながら十分なアーキテクチャ (最小限の実行可能なアーキテクチャ) を定義することが重要です。移行中に既存のアプリケーションとデータベースが変換されるターゲット テクノロジ、ソフトウェア/OS バージョン、およびデータベース バージョンを定義します。

組織は、アプリケーションのデータベース依存関係、インターフェース、外部統合、およびデータ移行の要件を考慮する必要があります。データと関連アプリケーションがオンプレミスに存在する場合は、ハイブリッド クラウド アーキテクチャを検討する必要があります。このアーキテクチャは、クラウド移行中に進化し続けます。

組織はアーキテクチャ上の決定を行い、利害関係者からのサポートを得ます。高可用性、負荷分散、パフォーマンスを実現するアーキテクチャを設計し、「目的に適合」という原則に従います。結局のところ、クラウド コンピューティングはスケーラビリティと可用性を考慮して構築されているため、過剰なエンジニアリングは避けてください。

（4）DevOps：DevOpsは現在、さまざまな業界の組織が変革および近代化プロジェクトを実施するための事実上の標準となっています。各移行 POD チームは DevOps プロセスに従う必要があります。一部のアプリケーション (COTS など) では、DevOps は関連性がなく、適用できない場合があります。このようなアプリケーションは、アーキテクチャ上の決定の際に必要になります。このようなアプリケーションは、ターゲット クラウド プラットフォームの既存のビルドおよびデプロイメント方法論に従うことができます。

組織は、ターゲットのクラウド プラットフォーム上でアプリケーションを構築、テスト、展開、監視するために使用するツールを決定する必要があり、クラウド ネイティブのオプションは多数あります。 DevOps パイプラインを設計します (例: Jenkins/AWS CodePipeline/Azure DevOps などを使用)。展開前にコードの脆弱性スキャンとセキュリティ テストを検討してください。可能であれば、これらの手順 (テストなど) を自動化することを計画します。ソース コードの管理方法とバージョン管理方法を定義します (たとえば、Github リポジトリとブランチの使用)。ユーザー ストーリーをキャプチャおよび追跡する方法を定義します (たとえば、Jira などのツールを使用する)。既存のアプリケーションを本番環境に移行する前に、それらをデプロイしてテストするさまざまな環境を定義します。

移行プロセスは、必要なテスト KPI が満たされるまで、アプリケーションごとに継続的 (継続的インテグレーション/継続的デリバリー) かつ反復的なプロセスである必要があります。アプリケーションのサポート手順とポストプロダクションでの問題を監視する方法を定義します。コードの変更、展開から運用まで、DevOps チームがアプリケーションを所有する必要があります。

（５）概念実証（POC）：クラウドプラットフォームで概念実証を実施します。アプリケーションの移行であれ、データ ウェアハウスの移行であれ、クラウド コンピューティング環境での移行を試みることは、組織に自信を与えます。概念実証 (POC) は、組織が現在の組織プロセス、接続性、環境依存性に基づいて問題やギャップを特定するのに役立ちます。移行時に DevOps プロセスとツールを適用し、ほとんどの移行ユースケースに対応できる、中程度に複雑な再ホストおよびリファクタリング アプリケーション (POC など) を選択します。概念実証 (POC) は、組織がターゲット アプリケーションとインフラストラクチャを改良するのに役立ちます。

（6）クラウドコンピューティングインフラストラクチャとセキュリティ設計：これは設計フェーズの非常に重要な部分です。ターゲット アーキテクチャの技術的なランディング ゾーンを定義することです。 AWS ランディングゾーンの例には、VPC の数、データセンターの接続性、VPC 間通信、サブネット、API ゲートウェイなどのネットワークコンポーネントが含まれます。

組織は、コンピューティングとストレージ (EC2、EKS、ECS、RDS、SQS、S3 など)、セキュリティ コンポーネント (IAM グループ、ユーザー グループ、IAM ポリシー、既存のエンタープライズ ユーザー向けの AD SSO など)、ネットワーク レベルのセキュリティ グループ、ポート制御にも注意を払う必要があります。コンポーネントのマーキング (ラベル付け) ルールを定義します。環境のアクセス制御メカニズムと、インフラストラクチャを定義するためのコーディング原則としてインフラストラクチャを使用します。組織は、クラウドネイティブ インフラストラクチャ作成サービスや、Terraform などのクラウドに依存しないオープン ソース コードなどの新しいツールを活用する必要もあります。 DevOps ツールとの統合を設計して、インフラストラクチャを簡単に作成します。設計では次の点を考慮する必要があります。

• クラウド コンピューティング インフラストラクチャ コンポーネントとサービス。
• 統合レイヤー;
• ビッグデータおよび分析コンポーネント（該当する場合）
• インターネット接続;
• ハイブリッド クラウド ネットワーク接続トポロジ (データ センターおよび外部クラウドへの場所/リージョン接続の定義)。
• 高可用性設計。
• および災害復旧方法。

（7）セキュリティアーキテクチャが対処すべき問題：アクセスとアイデンティティ管理（AD統合、AWSアカウント、組織など）。アクセス環境/アプリケーションおよびデータベースのセキュリティ制御とプロセス。セキュリティ監査および監視（SIEM 統合など）データのセキュリティと暗号化。脆弱性/パッチ管理プロセスの評価。

（8）クラウドコンピューティング運用モデル：クラウドコンピューティング運用モデルは、組織がクラウドコンピューティング変革をどのように実装するかに関するものです。それは人、プロセス、ツールで構成されます。クラウド コンピューティング プロジェクトを成功に導く鍵は人材です。

組織は、クラウド ビジネス オフィス、ビジネス/ドメイン、運用、セキュリティ、DevOps と一致する利害関係者、チーム構造、役割を特定する必要があります。アプリケーションおよびデータガバナンスのプロセスとポリシーを決定する。コンプライアンス要件と回避策を特定します。

集中型、分散型、または共有型の運用モデルを作成する戦略もあるかもしれません。分散型運用は、より高い柔軟性とコスト管理を提供するため、推奨されるモデルです。ただし、このモデルにはいくつかの制限がある可能性があります。

（9）変更管理：クラウドコンピューティングの変革には、プロセス技術とツールの変更への適応が必要です。ガバナンスとインフラストラクチャの制御が変更されます。既存のチームが担う必要があるさまざまな役割に対処するために必要な新しい変更に対処します。従業員のスキル開発とクラウド コンピューティングのトレーニング プランを作成します。組織は新しいスキルのギャップを埋めるための計画を策定します。

クラウドへの移行は、主にテクノロジーの変更です。多くの組織には、このような変革的な変更を検討および承認する責任を負う変更諮問委員会 (CAB) が存在します。従来の CAB 承認では、事前に関係者と十分なコミュニケーションが取れていないと、クラウドへの移行が妨げられる可能性があります。組織は、クラウド移行プロセス全体を管理および制御するために、エンタープライズ変更管理ツール (ServiceNow、BMC、Jira Service Desk、Freshservice など) の使用を検討する必要があります。

環境アクセス制御、リソースのプロビジョニング、課金/コスト管理、セキュリティ監視、インシデント管理、バージョン管理、変更管理および承認プロセスに使用できるツールがあります。または、クラウドネイティブサービス (AWS Config、CloudTrail、Service Catalog、AWS コンソール、AWS Organizations、信頼できるアドバイザーなど) とこれらのタスクを実装するエンタープライズツールを使用します。

3. 次のステップ

次のステップは「移行と変革」です。組織は POD チームを展開し、設計どおりにアプリケーションとデータを移行し、前の段階で計画を立てる必要があります。 「管理と最適化」フェーズでは、クラウド プラットフォーム上のインフラストラクチャ、アプリケーション、およびデータ移行を管理します。