翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 推奨事項
シングルクラウド、ハイブリッドクラウド、マルチクラウドの基本を理解したところで、このセクションではモデルを選択するための詳細な推奨事項を示します。
+ [プライマリの戦略的クラウドプロバイダーを選択する](primary-provider.md)
+ [CCoE を設立する](establish-ccoe.md)
+ [SaaS アプリケーションと基盤クラウドサービスを区別する](saas-apps.md)
+ [各クラウドサービスプロバイダーのセキュリティとガバナンスの要件を確立する](security-governance.md)
+ [可能な限り、かつ実用的であれば、クラウドネイティブのマネージドサービスを採用する](managed-services.md)
+ [既存のオンプレミス投資が継続利用を促す場合は、ハイブリッドアーキテクチャを実装する](hybrid-architecture.md)
+ [シングルクラウドのプロバイダーで技術要件またはビジネス要件を満たせないワークロードにのみ、マルチクラウドを適用する](multicloud.md)
# プライマリの戦略的クラウドプロバイダーを選択する
クラウドの導入は、IT のモダナイズ、コスト効率、イノベーションに不可欠な多くの利点をもたらします。ただし、限定的な SaaS アプリケーションを超えてクラウドテクノロジーを採用すると、教育機関が不要なコストや複雑さを避けるために慎重に計画しなければならない課題が生じる可能性があります。クラウドでのワークロードの実装に伴う技術的およびビジネス上の変更には、ネットワーク、セキュリティ、ガバナンス、運用など、コアインフラストラクチャに対するスタッフのスキル習得支援と調整が必要です。
これらの課題に効果的に対処するための最善のアプローチは、特に組織がクラウドジャーニーの初期段階にある場合、ワークロードの大部分をサポートするプライマリの戦略的クラウドプロバイダーを選択することです。クラウドの利点の実現を簡素化して加速できるように、そのプロバイダーに焦点を当てた導入から始めます。プライマリクラウドプロバイダーの選択は、排他的で不可逆的な決定ではありません。これにより、組織はクラウド導入を反復的に進化させることができます。まずは少数のサービスに焦点を当て、必要に応じて他のクラウドサービスに拡張できます。これにより、遅滞なくクラウドの全体的な利点を実現できます。このアプローチは、プロバイダーの機能を活用し、従業員のスキルとサードパーティーパートナーとの関係を集中的に強化し、ベンダー管理を簡素化するという組織の能力を最大化します。
複数のクラウドプロバイダーを同時に採用しようとしてクラウドジャーニーを開始したものの、その決定と、それによって生じた複雑さを後悔するお客様を見てきました。Gartner はこのインサイトを記事[「6 Steps for Planning a Cloud Strategy](https://www.gartner.com/smarterwithgartner/6-steps-for-planning-a-cloud-strategy)」で共有しており、ステップ 2 として、「マルチクラウドアーキテクチャではプライマリプロバイダーを優先する」と述べています。
各クラウドプロバイダーは、さまざまな運用およびサポートモデル、ID およびアクセス管理、ネットワーク、運用、コンプライアンス機能などを導入しています。**クラウドプロバイダーの運用モデルは、一度に 1 つに絞って習得する方が効果的です。**その後、合理的と判断される場合に、追加のクラウドサービスを反復的かつ段階的に組み込むことができます。プライマリクラウドプロバイダーを採用するかどうかの決定には多くの要因が影響しますが、選択の指針として以下の重要な質問を参考にしてください。
+ **プロバイダーが提供するサービスの幅と深さはどの程度ですか?**
クラウドプロバイダーごとに提供するサービスは異なります。少なくとも、プライマリプロバイダーに、すべての機能要件に加えて、セキュリティ、ガバナンス、自動化などの横断的かつ運用上のニーズをサポートできる機能があることを確認してください。これらの機能を、イノベーションと運用上の優秀性において実績のある形で提供しているプロバイダーを選択します。アプリケーションだけでなく、データも考慮してください。将来的なデータ統合や転送パターンを考慮し、プロバイダー間で大量のデータを移動する際のコスト、レイテンシー、複雑さを最小限に抑えます。現在のアプリケーションとデータのニーズを満たすだけでなく、時間と共に変化する機関のニーズに対応する新たなユースケースを可能にするような、可能な限り広範かつ多様なサービスを提供できるプロバイダーを選択します。
+ **プロバイダーは、すべてのセキュリティとコンプライアンスのニーズをサポートできますか?**
教育分野では、セキュリティとコンプライアンスは、あらゆるテクノロジーのデプロイにとって不可欠です。すべてのセキュリティとコンプライアンスのニーズを満たすことができるクラウドプロバイダーを選択します。[AWS Artifact](https://aws.amazon.com/artifact/) などのツールは、セキュリティおよびコンプライアンスレポートへのオンデマンドアクセスのための一元的なリソースを提供することで、プロバイダーを評価するのに役立ちます。クラウドプロバイダー独自のインフラストラクチャやサービスのセキュリティとコンプライアンスだけでなく、それらのサービスを使用して安全で準拠したソリューションを簡単に設計できるかどうかも検討します。構築済みソリューション、クイックスタート、規範的なガイダンスなどを組み合わせて提供し、安全なクラウド導入を加速できるプロバイダーを優先します。
+ **プロバイダーには堅牢なパートナーネットワークがありますか?**
クラウドトランスフォーメーションは、どの組織も単独では実施しません。導入を加速するには、クラウドプロバイダーとそのパートナーネットワークのサービスと専門知識を活用する必要があります。このネットワークには、クラウドテクノロジー上で動作するソフトウェアを提供したり、統合や支援を行ったりするテクノロジーパートナーに加え、クラウド上での独自アプリケーションの設計、構築、運用、管理を支援するコンサルティングパートナーが含まれます。既に協力関係のある多くの教育関連のテクノロジープロバイダー、独立系ソフトウェアベンダー (ISV)、コンサルタント、リセラーが、クラウドプロバイダーのパートナーネットワークの一員であることがわかるでしょう。厳選されたコンピテンシーを備えたパートナーによる、最も堅牢なネットワークを持つクラウドプロバイダーを優先します。業界および技術に関する実証済みの専門知識を持つパートナーの存在は重要です。
+ **プロバイダーはどのようなサポートとスキル習得支援を提供していますか?**
新しいテクノロジーを正常に導入するには、ベストプラクティスの推奨事項、設定ガイダンス、問題解決など、トレーニングや支援を要請するための仕組みが必要です。強力なサポートとトレーニングオプションを提供するクラウドプロバイダーを選択することで、成功への準備が整います。プロバイダーの公式なサポートモデルおよびリソース、さらに、ブログ、フォーラム、動画、ハウツーガイドなど、利用可能なサードパーティーやコミュニティベースのリソースも確認します。プロバイダーのテクニカルサポートプログラムだけでなく、ビジネスと文化のトランスフォーメーションに焦点を当てたプログラムも考慮します。例えば、[AWS クラウド導入フレームワーク (AWS CAF) ](https://aws.amazon.com/cloud-adoption-framework/)は、テクノロジーだけでなく、ビジネスプロセスや人材を含む視点に焦点を当てることで、組織のデジタルトランスフォーメーションを支援します。広範なトレーニングオプションと、実証済みの信頼性の高いサポートモデルおよびコミュニティを提供するクラウドプロバイダーを優先します。
# CCoE を設立する
トランスフォーメーションオフィスまたは [Cloud Center of Excellence (CCoE)](https://docs.aws.amazon.com/whitepapers/latest/public-sector-cloud-transformation/building-a-cloud-center-of-excellence-ccoe-to-transform-the-entire-enterprise.html) を通じてクラウドリーダーシップ機能を進化させることを検討してください。CCoE は、組織全体でクラウドテクノロジーを大規模に実装するためのアプローチを開発し、推進します。クラウド導入を成功させるには、関係するチームや部門を代表して意見を述べる担当者を含めるように CCoE を設計します。CCoE は、小規模に開始し、トランスフォーメーションジャーニーを進めながら、ニーズに合わせて段階的に進化させます。 AWS アカウントマネージャーやソリューションアーキテクトなどのプライマリクラウドプロバイダーの担当者は、CCoE の作成を支援するリソースを提供できます。CCoE は、対象分野の専門知識を確立し、組織全体の賛同と信頼を獲得し、ミッション要件を満たすための効果的なガイドラインを策定するための取り組みを加速します。すべての機関で機能する唯一の組織構造はありませんが、以下の質問は独自の CCoE を設計する際に役立ちます。
+ **CCoE には誰を含めるべきですか?**
初期段階の CCoE には、少数のアーリーアダプターとクラウドチャンピオンしか含まれていない可能性があります。CCoE は小規模のままでもかまいませんが、クラウド導入によって影響を受けるビジネス機能と技術機能の両方を代表して発言できるチャンピオンを含めるよう進化させる必要があります。ビジネス機能には、変更管理、ステークホルダーの要件、ガバナンス、トレーニング、調達、コミュニケーションが含まれます。これらの機能は通常、機関の管理チームと教育チームのメンバーが担当します。技術機能には、インフラストラクチャ、自動化、運用ツール、セキュリティ、パフォーマンス、可用性が含まれます。これらの機能は通常、機関の IT チームのメンバーが担当します。また、CCoE は、必要に応じてベンダーやパートナーを関与させ、対象分野の専門知識を提供してもらえるようにする必要があります。CCoE は「生きている組織」です。そのメンバーシップ、形態、機能は時間の経過と共に変化し、将来的には、成熟度が高まったタイミングで解散する可能性もあります。
+ **CCoE はステークホルダーとどのように関係を築くべきですか?**
CCoE は他のチームを支援する立場にあり、クラウド導入の成功に向けた情報提供と、その実現のみを目的としています。CCoE の一部をさまざまな部門、学校、機能に埋め込むことを検討します。これにより、幅広いリソースへのアクセスが可能になり、内部フィードバックが高速化されます。機関内の信頼を確立し、組織内のサイロを解消するために、ステークホルダー間でのパートナーシップとオープンなコミュニケーションを早期に構築することに重点を置きます。CCoE には、ステークホルダーとのコミュニケーション、フィードバックの収集、ユーザーのトレーニングを行うための明確なメカニズムが必要です。CCoE の成功メトリクスには、このようなコラボレーションとコミュニケーションが反映されている必要があります。チームがテクノロジーの構築のみを指標として評価されると、テクノロジーはさらに構築されますが、その活用や成果は軽視されることになります。代わりに、メトリクスでは、CCoE の取り組みによって自立できるようになったチームの数、イニシアチブにおいて CCoE がクリティカルパス上に置かれた回数、開催されたトレーニングイベントの数、CCoE の成果物の採用範囲などを測定する必要があります。適切に構築された信頼できる CCoE は、信頼を基盤としたより大きな組織トランスフォーメーションへの足がかりとなる可能性があります。
+ **CCoE をどのように設立するべきですか?**
ほとんどの組織は、特定の目的に特化したパイロットプロジェクトからクラウド導入を開始します。これらのプロジェクトの一環として、CCoE を設立します。ジャーニー全体の成功を定義するには、最初の一歩がきわめて重要です。
+ **ビジネス上の問題から始めます。**テクノロジーのためのテクノロジーは、適切な戦略ではありません。クラウドテクノロジーを試している場合は、どんなに小さく見えても説得力のあるビジネスユースケースを特定します。次に、そのユースケースを起点として、テクノロジーがどのように役立つかを明確に定義した目標を設定します。ソリューションをサイロに実装しないでください。プロジェクトの実装前および実装中には、常にビジネス部門のステークホルダーからフィードバックを受け取ります。成功しているクラウドプロジェクトはすべて、そのテクノロジーを利用する組織との緊密な連携に支えられています。
+ **小規模に始めます。**やり直しが可能な、低リスクで双方向ドア型のプロジェクトを選びます。つまり、可逆性があり、ミスがあってもすぐに修正できるプロジェクトということです。パイロットプロジェクトは実験が目的です。大規模かつ高リスクなプロジェクトを避けることで、実装と結果をより適切に制御できます。これにより、広範な目標ではなく、特定の定義可能な問題に的を絞ることができます。例えば、自動化が最終目標である場合は、ジョブ全体ではなく特定のタスクの自動化を目指します。
+ **結果を定義して測定します。**各プロジェクトの進捗状況とパフォーマンスを評価するために、明確なメトリクスを設定します。ステークホルダー間の期待のズレを避けるため、望ましい最終状態をあらかじめ十分に定義しておきます。ビジネスステークホルダーや組織内の他のリーダーと緊密に連携し、期待と測定可能な利益を定義します。また、結果を非技術的な言葉で表現することも重要です。例えば、プロジェクトによって保持率が向上した、解約率が下がった、コストが削減された、納品速度が向上したなど、組織の目標に即した観点で結果を説明します。
+ **慣れた領域から始めます。**機関がよく知っているドメイン内のプロジェクトを選択します。これにより、意味があり、理解しやすく、実際に効果のある目標をプロジェクトに設定できます。このようなプロジェクトは、信頼を構築し、組織にとってより長期的な成果をもたらします。例えば、データ分析に関する専門知識が既にある場合は、分析プロジェクトから始めて、既存のスキルセットを活用しながらクラウドジャーニーを開始できます。各機関にはさまざまな専門知識があるため、成功するデジタルトランスフォーメーション戦略を立てるには、それぞれの独自のコンポーネントを見つける必要があります。
# SaaS アプリケーションと基盤クラウドサービスを区別する
ほとんどの教育機関は、Software as a Service (SaaS) アプリケーションを既に採用しています。SaaS は、サービスプロバイダーが実行および管理する完全なソリューションを機関に提供します。一般的な SaaS アプリケーションには、ワードプロセッシングや E メールなどの生産性向上アプリケーションがありますが、エンタープライズリソースプランニング (ERP)、学生情報システム (SIS)、学習管理システム (LMS) などのミッションクリティカルなワークロードにも SaaS オプションがあります。機関が SaaS サービスを導入すると、IT チームはサービスの維持方法やインフラストラクチャの管理方法について考える必要がなくなり、ユーザーは単にサービスを利用するだけで済みます。この提供モデルにより、IT スタッフの管理負担が軽減されます。多くの機関では、特に、同じアプリケーションをセルフホストするだけの時間、リソース、スキルセットが IT チームにない場合、IT 戦略に「SaaS ファースト」アプローチを採用しています。セルフホストするだけのリソースがあったとしても、SaaS ソリューションを採用し、他のプロジェクトに投資する方が、費用対効果が高い場合もあります。
SaaS アプリケーションを使用する場合、IT チームは基盤となるインフラストラクチャを管理する必要がないため、ベンダーがアプリケーションをホストする場所 (オンプレミスデータセンター、プライマリクラウドプロバイダー、または代替クラウドプロバイダー) はそれほど重要ではありません。プライマリの戦略的クラウドプロバイダーを選択した後でも、別のクラウドプロバイダーや、ベンダーのデータセンターのオンプレミスでホストされている SaaS サービスを利用するという選択肢もあります。逆に、SaaS アプリケーションが 1 つのクラウドプロバイダーでホストされている場合でも、非 SaaS ワークロードに対する強みを考慮して、別のクラウドプロバイダーをプライマリの戦略的プロバイダーとして選ぶこともできます。ホスティング環境の区別は、SaaS アプリケーションよりもセルフホスト型アプリケーションにおいてより重要です。ただし、SaaS が IT 戦略の一環としてクラウドとどのように適合するかを評価する際には、引き続き以下の重要な質問を考慮する必要があります。
+ **SaaS アプリケーションの可用性とスケーラビリティは高いですか?**
多くのベンダーは、自社の SaaS サービスにクラウドを採用することを既に決定しています。これにより、ベンダーは可用性とスケーラビリティの向上というクラウド上の利点を実現できます。さらに、ベンダーは、物理インフラストラクチャを管理および維持する代わりに、クラウドの責任共有モデルを採用できるため、新機能の提供により多くの時間とリソースを費やすことができます。このような利点があるため、クラウドファーストでクラウドホスト型のソリューションを提供するプロバイダーを優先する必要があります。
+ **SaaS アプリケーションはセキュリティ要件を満たすことができますか?**
SaaS を評価するときは、アプリケーションが保存するデータ、そのデータの使用方法、そのデータを保護するために実装されているセキュリティコントロールについて知っておくことが重要です。独自のセルフホスト環境のようにデータストレージを直接制御できない場合でも、ベンダーがデータを適切に処理するためのメカニズムとコントロールを備えていることを確認する必要があります。SaaS ソリューションに組み込まれているセキュリティ機能と、追加設定が必要な機能を把握しておいてください。クラウドにより、SaaS プロバイダーはより可用性が高くスケーラブルなソリューションを構築できます。また、[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)により、より安全なソリューションを構築することもできます。クラウドセキュリティツールとサービスをソリューションの一部として活用しているプロバイダーを優先する必要があります。
+ **SaaS アプリケーションデータは誰が所有しており、どのようにアクセスできますか?**
SaaS を利用する場合、機関のデータを適切に処理することをプロバイダーに委ねることになります。SaaS アプリケーションのサービス条件とサービスレベル契約を確認して、データの所有権、可用性、耐久性などの寄与要因を理解してください。データをバックアップまたはエクスポートするメカニズムを評価します。これは、プロバイダーを変更する場合や、プロバイダーがサービスを停止する場合に特に重要です。
+ **環境に関係なく、他のサービスやセルフホストアプリケーションは SaaS アプリケーションと統合できますか?**
SaaS ソリューションを採用する際には、同じホスティング環境を共有するサービスとアプリケーション (つまり、同じクラウドプロバイダーまたは同じベンダーのデータセンターを使用するアプリケーション) は、よりシームレスに統合できると考えがちです。しかし、現在のほとんどの SaaS ソリューションは API とサードパーティーの統合を幅広くサポートしているため、同じ環境にホストされているソリューションに限定する必要はありません。必要な統合が存在する場合、ソリューション同士が同じ基盤環境を共有している必要はありません。例えば、クラウドベースの学生ファイルストレージとして、Google Drive や Microsoft OneDrive などの SaaS ソリューションを使用しているとします。仮想デスクトップとアプリケーションのストリーミングを学生に提供するために、[Amazon WorkSpaces アプリケーション](https://aws.amazon.com/appstream2/)が要件に最適であると判断する場合があります。これらのサービスは異なる環境で実行されますが、WorkSpaces アプリケーションには Google Drive および Microsoft OneDrive とのネイティブ統合があるため、学生は既存のストレージを引き続き使用できます。
+ **SaaS アプリケーションは一元化された ID 管理をサポートしていますか?**
IT チームが異なる ID ストアを管理したり、ユーザーが複数の認証情報セットを覚えたりする必要がないように、SaaS ソリューションが既存の ID 管理またはシングルサインオンソリューションとの統合をサポートしていることを確認してください。分散した ID 管理は生産性を低下させ、特権の過剰付与や脆弱なパスワードなど、不適切なセキュリティプラクティスにつながる可能性があります。希望する SaaS ソリューションがシングルサインオンまたは既存の ID ストアをサポートしていない場合は、そのソリューションを採用するビジネス価値が、ユーザーやスタッフへの負担の増加を上回るかどうかを評価してください。
+ **SaaS アプリケーションとのネットワーク通信を保護するにはどうすればよいですか?**
場合によっては、SaaS アプリケーションと通信するためにセルフホスト型アプリケーションが必要になることがあります。通常、この通信は、適切な認証および認可メカニズムで保護された API を介して行われます。ただし、2 つのアプリケーションのホスティング環境によっては、その通信を簡素化または保護するために、代替または追加のメカニズムが必要になる場合があります。例えば、アプリケーションをクラウドプロバイダーでセルフホストし、同じクラウドプロバイダーでホストされている SaaS アプリケーションと統合する必要がある場合、ベンダーはいくつかの接続オプションを提供することがあります。クラウド固有のピアリング接続、プライベート API、[AWS PrivateLink](https://aws.amazon.com/privatelink/) などのプライベートインターフェイスを使用して、その通信がパブリックインターネットを通過しないようにできます。同様に、オンプレミスアプリケーションが [AWS Direct Connect](https://aws.amazon.com/directconnect/) などのサービスを介してクラウドプロバイダーへの専用ネットワーク接続を持っている場合は、その同じ接続を使用して、同じクラウドプロバイダーでホストされている SaaS アプリケーションと通信できます。
# 各クラウドサービスプロバイダーのセキュリティとガバナンスの要件を確立する
教育機関には、コンプライアンス、ガバナンス、サイバーセキュリティに関する達成すべきさまざまな目標があります。これらの目標を達成できなかった場合のリスクには、機関の評判の低下、罰金、身代金、機密データの侵害、知的財産の盗難、ミッションクリティカルな機能の低下または完全な喪失などがあります。[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)により、クラウドサービスを導入する機関は、インフラストラクチャのセキュリティに関する一部の責任をクラウドサービスプロバイダーに移管することで、管理上の負担を軽減できます。さらに、オンプレミスデプロイでは利用できない、管理が難しい、またはコストがかかることの多い機能を提供する、専用のクラウドネイティブセキュリティサービスの恩恵を受けることができます。例としては、ウェブアプリケーション保護用の [AWS WAF](https://aws.amazon.com/waf/)、分散型サービス拒否 (DDoS) 対策用の [AWS Shield](https://aws.amazon.com/shield/)、脅威検出用の [Amazon GuardDuty](https://aws.amazon.com/guardduty/) などのサービスがあります。クラウドセキュリティとガバナンスの戦略が成功すれば、IT チームやセキュリティチームは設計による安全なシステム構築に集中でき、機関は進化するミッション要件に迅速に適応でき、教員や研究者には革新的な学習やイノベーションのための安全な環境が提供されます。セキュリティとガバナンスの要件を評価するには、以下の重要な質問を検討してください。
+ **ワークロードはどのコンプライアンスフレームワークに準拠する必要がありますか?**
教育機関は、サポートするステークホルダーやワークロードが多数存在するため、多くのコンプライアンスフレームワークに準拠する必要があります。これらのコンプライアンスフレームワークには、家族教育の権利とプライバシー法 (FERPA)、医療保険の相互運用性と説明責任に関する法律 (HIPAA)、連邦リスク認可管理プログラム (FedRAMP)、サイバーセキュリティ成熟モデル認定 (CMMC)、国際武器取引規則 (ITAR)、犯罪司法情報サービス (CJIS)、および Payment Card Industry Data Security Standard (PCI DSS) が含まれます。CMMC のように、関連するワークロードが準拠していると認定されるまで、研究助成金が交付されない場合もあります。各フレームワークは一意であり、ワークロードのサブセットにのみ適用される可能性があります。どのワークロードがどの要件に準拠する必要があるかを理解し、各ワークロードの環境でそれらの要件を満たすことができることを確認してください。クラウド環境では、自身の責任範囲とクラウドプロバイダーの責任範囲の違いを理解しておくようにしてください。コンプライアンスを達成して維持するには、必要な知識、リソース、スキルセットを備えておく必要があります。
+ **複数のクラウドプロバイダー間でコンプライアンスを徹底しながら、イノベーションを妨げないようにするために、どのようなメカニズムを導入していますか?**
教育機関がクラウドを初めて導入する場合は、プライマリの戦略的クラウドサービスプロバイダーを 1 社選択し、設計上安全なクラウド環境を設計、エンジニアリング、運用する方法を理解することに集中することをお勧めします。理想的には、セルフサービスシステムに自動的に埋め込まれたセキュリティコントロールにより、ユーザーは IT チームによる介入を最小限に抑えつつ、安全なクラウド環境を迅速にデプロイできるようになります。単一のプロバイダーに絞ることで、セキュリティとコンプライアンスの確保に必要なリソースと時間の投資を抑えることができます。多くの成功している機関では、コンプライアンス要件の大半を満たし、堅牢なパートナーネットワークを持ち、構築済みのコンプライアンスソリューションを提供し、安全なセルフサービス自動化を可能にするクラウドサービスプロバイダーを選択しています。複数のクラウドプロバイダーでセキュリティとコンプライアンスを確保する必要がある場合は、各環境のコンプライアンスを管理するためのスキルセットとリソースを構築するために、追加の投資が必要になります。各クラウドプロバイダーが異なる基盤環境、すなわちランディングゾーンを使用している場合、各ランディングゾーンがサポートできるコンプライアンス標準と要件を理解する必要があります。これにより、特定のワークロードをそのプロバイダーでホストできるかどうかが決まる可能性があります。プロバイダーごとにコンプライアンスを個別に管理したり、複数のプロバイダー間で管理を一元化できるカスタム構築されたソリューションやパートナーソリューションを使用したりできます。[AWS Marketplace](https://aws.amazon.com/marketplace) では、コンプライアンス要件を満たすターンキーソリューションも提供しています。
+ **複数のクラウドプロバイダーのコストと使用状況を評価して制御するにはどうすればよいですか?**
教育機関がクラウドを初めて導入する場合は、どのクラウドサービスが使用されているか、リソースの所有者が誰か、それらのクラウドリソースの目的は何か、消費を最適化することでどのようなコスト削減が可能か、といった情報を把握するために、コストの可視化と制御のメカニズムを確立することをお勧めします。機関は、クラウドサービスプロバイダーと提携して、ミッションクリティカルなシステムの移行とモダナイズを実施することで、エンタープライズレベル契約の交渉、ボリュームディスカウントの適用、プロバイダーの専門知識の活用が可能となり、大きな投資収益率を実現できます。複数のプロバイダーでコストと使用状況を管理する必要がある場合は、社内のプロセスやツール、またはパートナーソリューションを活用して、各プロバイダーのコストと使用状況を集計して分析する方法を検討してください。多くの組織では、クラウド財務運用 (FinOps) を重要な機能と位置づけ、クラウドコストの管理と最適化のための機能の普及と導入にリソースを投入し始めています。
+ **時間の経過と共にユーザーアクセス許可を簡単に管理するためのメカニズムはありますか?**
学術機関がクラウドを導入する際には、主要なステークホルダーのニーズを把握することをお勧めします。機関システムのユーザーには、学生、教員、研究者、IT スタッフ、管理、セキュリティ、一般市民、サードパーティーの共同研究者が含まれます。これらのユーザーの主要なニーズを特定し、クラウドサービスへのアクセスを許可するための適切なメカニズムが整っていることを確認する必要があります。ユーザーの種類によって、必要とされるクラウドサービスへのアクセスの種類も異なります。例えば、学生、教員、一般市民はアプリケーションにアクセスする必要があります。IT スタッフ、管理者、セキュリティはクラウドインフラストラクチャにアクセスする必要があります。研究者やそのサードパーティーの共同研究者は安全な研究環境にアクセスする必要があります。教員は安全な教育環境にアクセスする必要があり、クラウドテクノロジーへの実践的なアクセスを学生に提供したい場合もあります。自動的に[これらの ID を一元管理する](identity-sso.md)ためのツールを用意し、ロールや責任の変化に応じてアクセス許可を特定、付与、取り消すために、確立されたプロセスを使用する必要があります。
+ **新しいシステムを ID 管理ソリューションと適切に統合するメカニズムはありますか?**
学術機関では、新しいシステムを ID 管理システムと簡単に統合できるようにすることをお勧めします。これにより、ステークホルダーが ID 管理システムと簡単に統合できるシステムを調達して構築できるようになり、さまざまなミッションクリティカルな機能を柔軟にサポートできます。統合プロセスを簡素化することで、ステークホルダーがシングルサインオン、パスキー、多要素認証 (MFA) といったセキュリティのベストプラクティスを実装していない独自のアクセスコントロール手段を使用する可能性が低くなります。ID 管理システムが、ネイティブ統合または業界標準プロトコルを通じて必要なシステムと相互運用できることを確認します。
+ **インシデントの効果的な検出と対応を可能にするメカニズムはありますか?**
教育機関は、サイバー攻撃やランサムウェアのターゲットになることがよくあります。このようなインシデントを効果的に検出して対応できるように、2 つの視点から成るアプローチをお勧めします。
+ クラウド環境に自動的に埋め込まれるセキュリティコントロールという形で、予防策に重点を置きます。
+ サイバーインシデント対応者がセキュリティ違反をタイムリーに検出、封じ込め、軽減するのに役立つ検出機能を実装します。
コンプライアンスと同様に、各環境のイベントを検出、防止、対応するためのリソース、スキルセット、ツールを確保しておく必要があります。単一のプライマリクラウドプロバイダーに集中することで、必要なリソースを抑えることができます。成熟したセキュリティ運用チームを持たない教育機関は、これらの分野において、独立系ソフトウェアベンダー、マネージド型検出および対応プロバイダー、サイバーセキュリティコンサルタントから支援を受ける必要があります。
# 可能な限り、かつ実用的であれば、クラウドネイティブのマネージドサービスを採用する
クラウドサービスを活用する方法を初めて検討するときは、チームが使い慣れているインフラストラクチャサービスや開発ツールを使用することが最善の方法のように思えるかもしれません。しかし、クラウドネイティブのマネージドサービス、特にサーバーレスオプションを選択することで、コスト、労力、複雑さを大幅に削減できます。
クラウドネイティブのマネージドサービスを利用することで、スタッフの時間と労力を要する、差別化されていない IT タスクの多くが排除されます。これらの時間と労力は、ミッションに重点を置いたアクティビティに費やす方が有効です。さらに、プロバイダーがサービスの機能を改善するにつれて、ソリューションは効率、セキュリティ、レジリエンス、パフォーマンスなどの特性における段階的な改善を自然に継承します。例えば、フルマネージドデータベースサービスは高機能なリレーショナルデータベース管理システムですが、データベースが実行される基盤となるサーバーやオペレーティングシステムをプロビジョニングおよび管理する必要はありません。これにより、自前のデータセンターや、クラウドでプロビジョニングするセルフマネージドの仮想サーバーでリレーショナルデータベースを維持する際に、通常必要となる管理タスクがなくなります。次の図は、この違いを示したものです。
![\[セルフマネージド型データベースサービスとフルマネージド型データベースサービスの責任の比較\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/strategy-education-hybrid-multicloud/images/db-services.png)
インフラストラクチャ管理を排除することの利点は、クラウドネイティブのマネージドサービスを、同等のセルフマネージドのアプローチと比較すると明らかです。そのため、購入またはカスタム開発したアプリケーションが実行されるコンポーネントをデプロイする必要がある場合は、時間と労力を削減するために、クラウドネイティブのマネージドサービスを使用する必要があります。
チームがクラウドでソリューションの構築、デプロイ、管理を担当する場合は、クラウドプロバイダーの差別化された機能とイノベーションを最大限に活用するために、クラウドネイティブのマネージドサービスを使用します。この戦略により、クラウドサービスを選択、統合、デプロイする際に、これらのプロジェクトに必要な時間と労力を削減しながら、レジリエンスとセキュリティを向上させることができます。クラウド戦略を成功させるには、カスタムソリューションをクラウドに移行したり、クラウドで新しいソリューションを開発したり、ライセンスソフトウェアをクラウドにデプロイしたりするときに、これらのクラウドネイティブの*構成要素*を採用することを検討してください。クラウドネイティブのマネージドサービスのオプションを評価するときは、以下の重要な質問を考慮してください。
+ **教育ミッションの中核となる機能に、スタッフの時間と労力をより集中させる必要がありますか?**
仮想サーバーであっても、サーバーを管理するには、システムソフトウェアのアップグレードやパッチを適用して最新の状態を維持するための時間と注意が必要です。これらのタスクを処理するマネージドサービスを使用することで、IT スタッフの時間を、組織のミッションにより密接に関係するアクティビティに振り向けることができます。例えば、コンテナをデプロイする必要がある場合は、サーバーの設定や維持が不要な [AWS Fargate](https://aws.amazon.com/fargate/) のようなサーバーレスのマネージドサービスを検討してください。基盤となるインフラストラクチャを調達、プロビジョニング、管理する必要がなくなるため、新機能の提供、パフォーマンスの最適化、ユーザーエクスペリエンスの向上に集中できます。マネージドサービスをセルフマネージドオプションと比較して評価するときは、この利点を考慮してください。
+ **チームがクラウドネイティブのマネージドサービスを採用するには、どのような労力がかかりますか?**
クラウドネイティブのマネージドサービスを使用してソリューションを設計および実装するには、学習曲線が伴う場合がありますが、こうした労力は、ソリューションのライフタイムを通じてコスト、時間、複雑さを削減することで回収されます。クラウドコンピューティングはオンデマンドで従量制料金のため、クラウドネイティブサービスを使用すると、先行投資を抑えつつ、よりアジャイルな方法で迅速に反復や実験ができます。これにより、イノベーションが促進され、プロジェクトのタイムラインが短縮されます。ただし、これらの利点を効果的に実現するには、最適な使用パターンに関するスタッフトレーニングや、サービス固有の API に対応するコードのリファクタリングなど、サービスを採用して使用するために必要となる可能性がある事項を考慮してください。サービスが業界標準またはオープンソースの API を使用している場合でも、機能差やバージョンの不一致に対応するため、アプリケーションをリファクタリングまたは設定する必要がある場合があります。
+ **現在、インフラストラクチャをどのようにデプロイおよび管理していますか? そのレベルのコントロールを維持する必要がありますか?**
クラウドでインフラストラクチャをホストおよび管理するには、ベアメタルホスト、仮想マシン、マネージドコンテナサービス、サーバーレスサービスなど、さまざまな方法があります。現在、オンプレミス環境で仮想マシンやコンテナなどの同様のインフラストラクチャを使用している場合でも、特定のワークロードに別のアプローチが適しているかどうかを検討してください。例えば、すべてのアプリケーションを仮想マシンで実行する代わりに、アプリケーションのコンテナ化を検討し、[Amazon Elastic Container Service (Amazon ECS) ](https://aws.amazon.com/ecs/)などのマネージドコンテナサービスを活用してください。これにはリファクタリングが必要になる場合がありますが、[AWS App2Container](https://aws.amazon.com/app2container/) などのツールを使用してコンテナ化を簡素化および支援できます。さらに一歩進めて、すべてのコンポーネントにサーバーまたはコンテナをデプロイするのではなく、完全なサーバーレスオプションを検討してください。サーバーレステクノロジーは、自動スケーリング、組み込みの高可用性、従量課金制の請求モデルを備えており、俊敏性の向上とコスト最適化を実現します。同時に、サーバーの管理やキャパシティ計画が不要になります。[AWS Lambda](https://aws.amazon.com/lambda/) などのサーバーレスコンピューティングサービスは、サーバーレスアーキテクチャの中核を成します。Lambda は一般的なプログラミング言語をサポートしており、開発者はインフラストラクチャを管理する代わりにアプリケーションコードに集中できます。ワークロードごとにこれらのオプションを検討し、学習曲線、管理オーバーヘッド、コスト、ライセンスなどの要因を考慮してください。
+ **ライセンスされたソフトウェアのインフラストラクチャをデプロイおよび管理する必要がありますか?**
独立系ソフトウェアベンダー (ISV) からライセンスされたソフトウェアをデプロイおよび管理する場合、クラウドインフラストラクチャを使用してオンプレミスのデプロイを模倣することが論理的に思える場合があります。例えば、オンプレミスの仮想マシンをクラウドホスト型の仮想マシンに置き換えることを検討する場合があります。これは実行可能なオプションですが、アーキテクチャのコンポーネントのいずれかをクラウドネイティブのマネージドサービスに置き換えることができるかどうかを検討してください。例えば、セルフマネージド型データベースサーバーを、同じデータベースエンジンを実行しながら管理上の負担を軽減するフルマネージド型データベースサービスに置き換えられる場合があります。多くの ISV は、マネージドサービスを利用するクラウドアーキテクチャを既に使用しており、デプロイを簡素化するために構築済みのテンプレートを提供する場合もあります。可能な場合は、クラウドデプロイの規範的なガイダンスとサポートを提供する ISV をお勧めします。ライセンスされたソフトウェアをクラウドにデプロイする前に、クラウド環境のライセンスとオンプレミスのライセンスとの違いを理解するために、必ず ISV に相談してください。
+ **マネージドサービスを使用すると、ベンダーロックインが発生する可能性があることを懸念していますか?**
多くのクラウドネイティブのマネージドサービスは、一般的な業界標準と API をサポートするように構築されています。例えば、[AWS Glue](https://aws.amazon.com/glue/) や [Amazon EMR](https://aws.amazon.com/emr/) などの分析サービスは、Apache Spark や Apache Parquet などの業界標準の処理およびストレージフレームワーク上に構築されています。[AWS Lambda](https://aws.amazon.com/lambda/) は、Java、Go、Microsoft PowerShell、Node.js、C\$1、Python、Ruby のコードをネイティブにサポートしています。[Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/) は、SQL Server、Oracle、PostgreSQL、MySQL など、一般的なデータベースエンジンの複数のバージョンをサポートしています。サービスに独自の API がある場合、クラウドに依存しない一般的なプロトコルを使用して、ネイティブソリューションまたはパートナーソリューションが API とやり取りできる場合があります。例えば、[Amazon Simple Storage Service (Amazon S3) ](https://aws.amazon.com/s3/)には直接統合するためのサービス固有の API がありますが、[AWS Storage Gateway](https://aws.amazon.com/storagegateway/) を使用する場合、ネットワークファイルシステム (NFS)、サーバーメッセージブロック (SMB)、Internet Small Computer System Interface (iSCSI) などの標準ストレージプロトコルを使用して操作することもできます。運用上のオーバーヘッドを最大限削減しながら、ニーズに最適なクラウドネイティブのマネージドサービスを選択することにそれでも集中する必要がありますが、一般的な業界標準やプロトコルを使用する、または利用できるサービスが望ましい場合もあります。
# 既存のオンプレミス投資が継続利用を促す場合は、ハイブリッドアーキテクチャを実装する
ほとんどの教育機関は、エンタープライズアプリケーション、データストレージソリューション、エンドユーザーコンピューティング (EUC) 環境、共有コンピューティングリソースをホストするために、さまざまな規模のオンプレミスデータセンターに投資しています。これらのデータセンターのすべてのリソースは、さまざまな更新サイクルの対象となります。この更新サイクルでは、将来の成長を考慮し、ピークスケールに対応するために十分な容量をプロビジョニングする必要があります。これは、年に数回のみ必要になる場合があります。その結果、リソースは多くの場合、次の更新サイクルまでアイドル状態になります。新しいハードウェアの計画、予算編成、調達、デプロイには、数週間、場合によっては数か月以上かかる場合があります。この長いプロセスはイノベーションを妨げ、学習と研究を遅らせる可能性があります。
クラウドコンピューティングは、これらの課題の多くを解決します。クラウドはオンデマンドで従量制料金の IT リソースを提供するため、大規模な事前計画や投資を行わずに、現在の容量と実際の需要をより密接に一致させることができます。ただし、オンプレミスのハードウェアとリソースに既に多額の投資をしている場合は、それらのリソースを効率的に活用し、必要に応じてクラウド技術を用いてハイブリッドモデルで強化することを検討する必要があります。
成功するハイブリッドクラウド戦略は、既存の投資を活用しながら、それらの投資単独では得られない俊敏性、スケーラビリティ、信頼性を実現します。次の考慮事項が、開始の際に役立ちます。
+ **新しいワークロードをホストする必要がある場合、まずクラウドについて考えますか?**
パブリッククラウドインフラストラクチャとプライベートクラウドインフラストラクチャをどのように組み合わせて使用するかによって、ハイブリッドクラウド戦略が定義されます。クラウドファーストアプローチは、クラウドがすべてのワークロードに適した選択肢であることを意味するわけではありません。ただし、新しいワークロードを計画する場合、特に、新しいテクノロジーを必要とするワークロードや、オンプレミスで利用可能なストレージとコンピューティング容量を超えるワークロードの場合は、クラウドを最初のオプションとして評価してください。一時的で一貫性のない使用パターンを持つワークロード、迅速な結果を必要とするワークロード、簡単に移植できるワークロード、最新のハードウェアを必要とするワークロードは、クラウドのスケーラビリティと伸縮性を活かすのに最適な候補です。また、利用可能な容量がある場合でも、オンプレミスで利用できないクラウドネイティブのマネージドサービスからワークロードが恩恵を受けるかどうかを検討してください。
+ **オンプレミス環境の TCO を理解し、新しい投資を行う際に CFO と提携していますか?**
独自のオンプレミスデータセンターを維持する真の総保有コスト (TCO) を理解しておくことをお勧めします。オンプレミスでのインフラストラクチャの所有と運用には、ハードウェア、ソフトウェア、サポートだけでなく、施設、ユーティリティ、保険、スタッフの稼働時間など、多くの隠れたコストが伴います。これらのコストは、スタッフの生産性、運用レジリエンス、ビジネスの俊敏性に悪影響を及ぼす可能性があります。現在のライセンス構造とその更新およびメンテナンス期間も評価します。最高財務責任者 (CFO) と連携することで、新しい投資を計画する際に、隠れているすべてのコストを特定できます。ライセンスによっては、クラウドでの Bring Your Own License (BYOL) オプションが提供されている場合があり、または、クラウドサービスとの適合性に違いがある場合があります。現在のインフラストラクチャの真の TCO を理解することで、組織全体の TCO に最も大きな影響を与えるワークロードのクラウド導入を優先できます。 AWS アカウントチームには、オンプレミス TCO をよりよく理解するためのツールがすぐに用意されています。
+ **ハイブリッドデプロイをサポートするには、どのようなインフラストラクチャが必要ですか?**
ハイブリッドモデルを正常に採用するには、基盤となるネットワーク、セキュリティ、インフラストラクチャツールが必要です。クラウドプロバイダーとの適切なネットワーク接続を維持できることを確認します。これは、既存のインターネット接続、仮想プライベートネットワーク (VPNs)、 などの専用接続 Direct Connect、サードパーティーの接続プロバイダー、[Internet2](https://internet2.edu/)、リージョンの研究および教育ネットワークの組み合わせによる場合があります。オンプレミス環境とクラウド環境全体で ID とアクセスの管理が統一されていることを確認します。一貫したセキュリティ、コスト、使用ガードレールを適用するためのツールとプロセスを確立します。
+ **IT スタッフがハイブリッドデプロイを運用する準備はできていますか?**
クラウドサービスには、チームが持っていない特定のスキルセットが必要になる場合があります。効果的なクラウド導入のために IT スタッフのスキルアップに必要なトレーニングとスキル習得支援を制限するには、クラウドプロバイダーがオンプレミスとクラウドの両方にわたる既存のスキルセットを再利用し、それを基盤として構築されたサービスを提供しているかどうかを検討してください。例えば、Kubernetes を使用していて、それに精通している場合は、[Amazon Elastic Kubernetes Service (Amazon EKS)](https://aws.amazon.com/eks/) または [Amazon EKS Anywhere](https://aws.amazon.com/eks/eks-anywhere/) の使用を検討してください。NetApp を使用していて、それに精通している場合は、[Amazon FSx for NetApp ONTAP](https://aws.amazon.com/fsx/netapp-ontap/) の使用を検討してください。同様に、使用している既存のパートナーソリューションに、クラウド環境のネイティブ統合またはサポートがあるかどうかも検討してください。
+ **長期ストレージまたは使用量の少ないコンピューティングをオンプレミスからクラウドにオフロードできますか?**
クラウドストレージには、長期データストレージ用のコスト効率の高いオプションがいくつか用意されています。例えば、[Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/) は、さまざまなユースケース向けに最適化されたさまざまなストレージ層を提供します。機関が特定のデータを長期間保持する必要がある場合は、[Amazon Glacier](https://aws.amazon.com/s3/storage-classes/glacier/) などのコールドストレージソリューションを検討してください。このデータをクラウドストレージにオフロードすると、価値のある高性能なオンプレミスストレージを解放できます。[AWS Storage Gateway](https://aws.amazon.com/storagegateway/) などのサービスを使用すると、オンプレミスアプリケーションは SMB、NFS、iSCSI などの標準プロトコルを使用してクラウドストレージ層に簡単にアクセスできます。同様に、使用頻度が低い、または使用量が少ないコンピューティングタスクをオフロードすることを検討してください。このようなタスク専用のオンプレミスサーバーがある場合は、代わりにスケーラブルなクラウドコンピューティングサービスを使用できます。この場合、リソースはオンデマンドでプロビジョニングされ、使用した分だけ料金が発生します。こうした低コストの長期ストレージと使用量の少ないコンピューティングのオプションにより、クラウドはバックアップやディザスタリカバリの用途にも最適です。クラウドの安全で耐久性があり、スケーラブルなストレージとコンピューティングを使用すると、必要なストレージとコンピューティングインフラストラクチャを自分で維持することなく、データを保護し、災害発生時にも迅速に復旧できます。
+ **実験とイノベーションのための十分な容量がオンプレミスにありますか?**
固定サイズのオンプレミス環境では伸縮性と俊敏性がないため、ユーザーが利用できるサービスとテクノロジーが制限される可能性があります。厳密な更新サイクルがある場合、新しいワークロードは次のサイクルまで実装を待つ必要がある場合があります。この運用モデルは、実験を制限し、イノベーションを遅らせる可能性があります。新規または新しいワークロードをテストする必要がある場合は、スケーラブルで伸縮自在なクラウドサービスの使用を検討してください。クラウドリソースはオンデマンドでプロビジョニングおよびプロビジョニング解除でき、使用した分に対してのみ料金が発生するため、組織のリスクを最小限に抑えながら、実験と*フェイルファスト*を行うことができます。
+ **データをオンプレミスに保持することを強制する固有のコンプライアンス要件またはパフォーマンス要件はありますか?**
データレジデンシー要件またはレイテンシー要件が厳しいワークロードでは、データをオンプレミスに保持するか、可能な限りユーザーの近くに保持する必要があります。これらのユースケースでは、既存のオンプレミスリソースの使用を優先できます。ただし、クラウドプロバイダーがオンプレミスでクラウドベースのテクノロジーを使用するエッジサービスまたはメカニズムを提供しているかどうかを検討してください。エッジサービスは、データ処理、分析、ストレージを自身のエンドポイントの近くで行えるようにし、標準的なクラウドプロバイダーのデータセンターの外部にツールをデプロイできるようにします。例えば、AWS は [AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) や [AWS Wavelength](https://aws.amazon.com/wavelength/) などのサービスを提供し、エンドユーザーに近い特定の場所にアプリケーションをデプロイします。また、[AWS Outposts](https://aws.amazon.com/outposts/)、[AWS Storage Gateway](https://aws.amazon.com/storagegateway/)、[Amazon ECS Anywhere](https://aws.amazon.com/ecs/anywhere/)、[Amazon EKS Anywhere](https://aws.amazon.com/eks/eks-anywhere/) などのサービスを使用して、既存のデータセンターにクラウドサービスと機能を導入することもできます。
# シングルクラウドのプロバイダーで技術要件またはビジネス要件を満たせないワークロードにのみ、マルチクラウドを適用する
*マルチクラウド*とは、複数 (2 つ以上) のクラウドサービスプロバイダーからクラウドサービスを利用することを指します。マルチクラウド戦略を持つことは、複数のクラウドプロバイダーの差別化された機能を活用できるオプションや、単一のクラウドプロバイダーが対応できないデータ主権要件を満たす機能など、特定の利点をもたらす可能性があります。ただし、使用するプロバイダーごとに、そのプロバイダーを効果的に使用するための適切な人材、スキル、トレーニング、ツールセットがあることを確認してください。さらに、特定のワークロードにマルチクラウド戦略を使用する場合は、各クラウドプロバイダーの必要なサービスを統合および相互運用するための追加リソースが必要になります。**マルチクラウドは、利点が投資の増加を上回る場合にのみ検討することをお勧めします。**マルチクラウド戦略を選択すべきかどうかを判断するには、以下の重要な質問を検討してください。
+ **さまざまなクラウドプロバイダーが提供するサービスをナビゲートするためのリソースとスキルセットはありますか?**
複数のクラウドプロバイダーがさまざまな製品やサービスを提供する場合、スタッフには、各プロバイダーの機能をナビゲートするための基本的なスキルが必要です。1 つのクラウドプロバイダーのサービスのみを使用する場合でも、使用しているサービスや機能によっては、スタッフにスキルアップやトレーニングが必要になることがあります。マルチクラウド戦略を検討している場合は、既存のリソースを評価して、複数のクラウドプロバイダーのサービスを効果的に使用するために必要な追加のスキルセットを決定します。単一のクラウドプロバイダーを使用する場合よりも、スタッフを補強したり、スキルアップとトレーニングに追加の時間と費用を投資したりする必要があるかもしれません。異なるクラウドプロバイダーを使用している個別のチームまたはユーザーが既に存在する場合は、状況に応じて、それらをプライマリクラウドプロバイダーに統合することで得られる組織的な利点を考慮してください。
+ **特定のマルチクラウドアーキテクチャでは、どのような追加のオーバーヘッドが発生しますか?**
マルチクラウドの一般的な推進要因は、他のクラウドプロバイダーのサービスと差別化できる機能を持つプロバイダーから特定のマネージドサービスを使用したいというものです。例えば、インフラストラクチャのニーズにはあるクラウドプロバイダーを使用し、ドメインおよびディレクトリサービスには別のプロバイダーのマネージドサービスを使用する場合があります。ただし、その単一のマネージドサービスによって管理上の負担が軽減され、そのアーキテクチャコンポーネントの管理が簡素化された場合でも、コードのリファクタリング、プライベート接続のニーズ、手動による統合作業など、他のワークロードに対して追加のオーバーヘッドが発生する可能性があります。この追加のオーバーヘッドを事前に特定し、そのオーバーヘッドが、チームが差別化されたサービスから得られる利点を相殺したり上回ったりしないようにします。
+ **クラウドプロバイダー間でモニタリングと管理を一元化するには、どのようにしますか?**
さまざまなクラウドプロバイダーのリソースを使用してアプリケーションと機能のデプロイを開始するときは、そのようなリソースをどのようにタグ付けし、モニタリングし、管理するかを検討してください。各プロバイダーには独自のツールがあり、他の環境に拡張できる場合があります。例えば、[Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) を使用して、主要なメトリクスとログのモニタリング、アラームの作成、単一環境、ハイブリッド環境、マルチクラウド環境にわたるアプリケーションとインフラストラクチャの視覚化を行うことができます。[AWS Systems Manager](https://aws.amazon.com/systems-manager/) を使用して、リソースの可視性と制御を向上させ、運用上の問題を迅速に診断して修正し、環境間で仮想マシンの更新やパッチ適用などのプロセスを自動化することもできます。プロバイダーのツールでは対応できない要件がある場合は、パートナーソリューションを検討できますが、追加コストや統合作業が発生する可能性があります。
+ **さまざまなクラウドプロバイダーを使用する場合、自動化を使用して Infrastructure as Code を管理するにはどうすればよいですか?**
クラウドでリソースを実行すると、リソースの自動プロビジョニングと管理により、さまざまな環境を効率的に管理できます。API やネイティブ自動化ツールは、クラウドプロバイダーによって異なります。可能であれば、さまざまなクラウドプロバイダーのリソースに対応できる共通のオーケストレーションおよびデプロイツールセットを使用することを検討してください。これにより、柔軟性が向上し、複数のクラウドクラウドにまたがる運用が簡素化されます。ただし、各プロバイダーのネイティブ自動化ツールを個別に使用し、適切な使用を確保するための組織プロセスを確立する方が簡単な場合があります。
+ **各クラウドプロバイダーが満たす必要があるコンプライアンス要件と規制要件はありますか?**
データの保存と処理方法を決定する規制上の考慮事項がある場合があります。クラウドプロバイダー全体の各クラウド環境に自動的に適用できるポリシー (ネットワークトラフィック、ストレージ、セキュリティなど) の標準化に焦点を当てます。アプリケーションがデータと通信する方法を検討し、同じプロバイダーでホストします。アプリケーションとそのデータがプロバイダー間で断片化されている場合、コンプライアンス要件と規制要件を確実に満たすことは困難です。多くの場合、セキュリティとアクセスコントロールを簡素化しながら、ネットワークレイテンシーを最小限に抑え、データスループットを最大化し、データ送信を制限するには、アプリケーションをできるだけデータの近くに配置することをお勧めします。
+ **クラウドプロバイダー全体にアプリケーションをデプロイすると、TCO を最小限に抑え、料金割引を最大化できますか?**
マルチクラウドを検討するときは、総保有コスト (TCO) を考慮することが重要です。複数のクラウドプロバイダーでアプリケーションを実行すると、各環境でリソースを維持および管理するための運用コストと管理オーバーヘッドが増加する可能性があります。さらに、使用量を複数のプロバイダーに分散させると、特定のプロバイダーのボリュームディスカウントやエンタープライズ契約を利用するのが難しくなります。マルチクラウドの利点が TCO の増加に見合うかどうかを判断するときは、これらの要因を考慮してください。