1. 基本的なOracle Cloud Infrastructure Governance Modelの確立
  2. ベースライン・ガバナンス・ライフサイクル

ベースライン・ガバナンス・ライフサイクル

テクノロジ・チームがクラウド上で最初に定義し強化するベースライン・セキュリティ・ポリシーと原則のセットです。

リソースの編成

単一のアプリケーションをプロビジョニングする場合でも、テナンシの制御を維持するために必要な拡張性、柔軟性および説明責任のためにリソースを編成するようにしてください。

次に基づいてリソースを編成します。

  • コンパートメント:組織の特定のレシピを持つコンパートメント
  • リソースの場所:ターゲット・オーディエンスが存在する場所に基づくリージョン
  • リソースの分離: Virtual Cloud Network (VCN)やサブネットなどの適切なネットワーク制御

コンパートメント設計

次の図は、特定の結果を達成するためにコンパートメント内のリソースを編成する方法の例を示しています。

oci-governance-compartment-design.pngの説明が続きます
図oci-governance-compartment-design.pngの説明

各組織は、必要な結果に固有のコンパートメント構造レシピを使用できます。使用可能な事前定義テンプレートを基礎として使用して、組織構造を作成できます。OCI CISランディング・ゾーンには、ネットワーク、セキュリティ、アプリケーションおよびデータベース・リソースを網羅する広範なコンパートメント構造テンプレートが用意されています。コンパートメント構造を拡張して、様々なアプリケーションまたはライフサイクル環境(開発、テスト、本番)ごとに個別の子コンパートメントを追加できます。CISランディング・ゾーン・テンプレートのイメージをここで入手してください。

階層コンパートメント・モデル

ルート・レベルから始まるコンパートメント階層の様々なレベルで定義する必要があるポリシーを定義します。

ルート・レベル

IAMポリシーの定義

レベル1

ネットワーク、共有セキュリティ、app-devおよびデータベース・ポリシーの定義

レベル2

本番以外のプロトタイプ・ポリシーを定義します。

  • ネットワーク:ネットワーク・ファミリ
    • 本番および非:本番VCNおよび本番サブネット
  • 共有セキュリティ: KMS、ロギング、通知、ボールト
  • App-Dev: OSバケット、ブートおよびブロック・ボリューム、FSS
    • Prod: Prod OAC、OIC、FAW
    • プロトタイプ:すべてのプロトタイプサービス
  • データベース: Prod AWD、非本番ADW

ガバナンス・モデルの構築には、効果的なコンパートメント設計の開発が不可欠です。コンパートメント設計は、組織でビジネスやプロセスの変更が発生したときに調整するためにいつでも変更できます。また、OCIにプロビジョニングされたリソースをコンパートメント間で移動できます。

リソース地理的位置

地理的リージョンにリソースを作成し、ターゲット・オーディエンスの場所に基づいてリージョンを選択する必要があります。ヨーロッパの顧客向けのアプリケーションは、欧州のデータ・センターに存在する必要があります。リージョン内では、最高の可用性を実現するために、アプリケーション・リソースを可用性ドメインおよびフォルト・ドメインに分散する必要があります。すべてのリソースまたはワークロードについて、複数の基準に基づいて適切なリージョンを選択する必要があります。

リソース・ネットワークの分離

コンパートメントを使用してリソースを分離することはできません。ネットワーキング・コントロールを使用してリソースを分離できます。リソースを分離するには、異なるVCNおよびサブネットでリソースを編成する必要があります。同じVCN内の同じアプリケーションに属するリソースと、異なるVCN内の異なるアプリケーションのリソースを含めます。2つのアプリケーションが相互に通信する必要がある場合は、VCNを共有するか、2つのVCNをペアにできます。

リソース・アイデンティティの管理

効果的なリソース・ガバナンスには、従業員のアイデンティティの確立が不可欠です。

oci-identity-governance.pngの説明が続きます
図oci-identity-governance.pngの説明

Identity Governanceのシナリオ

新規採用者が組織に加入すると、人事管理システムによってユーザーIDが作成され、一元管理されたポリシーベースのIDとその資格がプロビジョニングされます。新しいユーザーは、出生権の資格のプロビジョニングと呼ばれる特定のリソースおよびアプリケーションへのデフォルト・アクセスを取得します。その後、ユーザーの組織、グループおよびロールに応じて、追加のアプリケーションおよび資格へのアクセス権がユーザーに付与されます。

ユーザーは、承認プロセスを通過する追加の資格をリクエストして、それらの資格/権利に自分自身を割り当てることができます。ユーザーが組織を退職または退社すると、アイデンティティはプロビジョニング解除されます。組織内で同じユーザーが再雇用される場合、ユーザーは通常、同じIDを要求できますが、採用されたグループまたはロールに応じて異なる資格を持つことができます。

クラウド内のアイデンティティ

oci-identity-cloud.pngの説明が続きます
図oci-identity-cloud.pngの説明

Oracleは、Oracle Cloud Infrastructure Identity and Access Management (IAM)を使用して、IaaS、PaaSおよびSaaS全体で統一されたアイデンティティを提供します。すべてのOCI IaaSおよびPaaSサービスを接続するための統合アイデンティティは、OCI IAMとネイティブ統合されています。OCI IAMは、ユーザー・ストアとログイン・サービスの両方として使用されます。ただし、OCI上のSaaSサービス(Fusion SaaSサービスを含む)は、SCIM 2.0とSAML標準を使用して、OCI IAMと統合できます。お客様は、IAM OAuthを使用してPaaSサービスをSaaSと統合することもできます。SCIM 2.0、SAML、OIDCなどのオープン・スタンダードを使用して、Oracle Cloudをオンプレミスまたはサードパーティ・クラウドと統合できます。

統合アイデンティティ・サービスは、ユーザーのオンボーディングおよびオフボーディング・プロセスを合理化します。ユーザー・アカウントがHRシステムに対して作成または削除されると、OCI IAMはすべてのOracleサービスに対してユーザー・アカウントを作成または削除します。OCI IAMサービスでは、サードパーティ・クラウド・サービスからのユーザー・アカウントの作成と削除を容易にすることもできます。

OCI IAMは、Oracle Cloudのアイデンティティの単一のデータ・ソースを提供します。お客様はIAM監査ログを利用して、クラウド・システムまたはリソースへのアクセス権を持つユーザーを確認できます。また、セキュリティ脅威モデリングを実行して、不正アクセスを検出し、是正措置を取ることもできます。

リソース・アクセスの管理

OCIにはデフォルトで拒否セキュリティ対策があります。テナンシがプロビジョニングされている場合、テナンシ管理者ユーザー以外のユーザーはOCIのリソースにアクセスできません。

テナンシ管理者は、コンパートメントまたはテナンシ内のリソースのグループに権限を付与するポリシーを作成できます。次に、「コンパートメント」セクションで提案されたコンパートメント構造の開始点として使用できるIAMポリシーの例を示します。

  1. コンパートメント管理者が各コンパートメント内のすべてのリソースを管理できるようにするポリシーを作成します。 
    • Allow group security_admin to manage all resources in compartment Shared_Security:Prod
Allow group security_admin to manage all resources in compartment Shared_Security:NonProd
Allow group network_admin to manage network-family-resources in compartment Network
Allow group database_admin to manage database-family-resources in compartment Database
Allow group appdev_admin to manage instance-family-resources in compartment App-Dev
  2. コンパートメント管理者のポリシーを作成して、他のコンパートメントの共有リソースを使用します。 
    • Allow group appdev_admin to use network-family-resources in compartment Network
Allow group appdev_admin to use database-family-resources in compartment Database
Allow group database_admin to use network-family-resources in compartment Network
Allow group database_admin to use vaults in compartment Shared_Security
  3. 監査者およびその他の読取り専用ユーザー・グループのポリシーを作成して、テナンシ内のすべてのリソースを読み取ります。 
    • Allow group auditors to read all resources in tenancy
Allow helpdesk-users to inspect all resources in tenancy
Allow group announcement_readers_group to read announcements in tenancy

タグを使用してIAMポリシーを定義することもできます。条件およびタグ変数のセットを使用して、リソースに適用されているタグに基づいてアクセスの範囲を指定するポリシーを記述できます。リクエストしているリソース(グループ、動的グループまたはコンパートメント)またはリクエストのターゲット(リソースまたはコンパートメント)に存在するタグに基づいてアクセスを制御できます。最初の3つのサンプル・アクセス・ポリシーではリソース・タグのリクエストを使用し、最後の2つのサンプル・アクセス・ポリシーではターゲット・リソース・タグを使用します。

Allow any-user to manage instances in compartment HR where request.principal.group.tag.Operations.Project= 'Prod'
Allow dynamic-group InstancesA to manage instances in compartment HR where request.principal.group.tag.Operations.Project= 'Prod'
Allow dynamic-group InstancesA to manage instances in tenancy where request.principal.compartment.tag.Operations.Project= 'Prod'
Allow group GroupA to manage all-resources in compartment HR where target.resource.tag.Operations.Project= 'Prod'
Allow group GroupA to manage all-resources in tenancy where target.resource.compartment.tag.Operations.Project= 'Prod'

最初は、オンボードするすべてのワークロードの上位レベル・ロールが3つあります。

  1. サービス管理者
  2. サービス開発者
  3. サービス・ビューア

サービス・インスタンスに対する権限を管理、使用、読取りおよび検査するロールごとに、ベースライン・ポリシーを作成します。共有リソースに対する権限をサービス管理者に付与するポリシーを作成できます。たとえば、アナリティクス・サービスの場合、次のポリシーを作成できます。

  1. サービス管理者ロール 
    • Allow group Analytics-admin to manage analytics-instances in compartment App-Dev
Allow group Analytics-admin to manage analytics-instance-work-requests in compartment App-Dev
Allow group Analytics-admin to use network-family-resources in compartment Network
Allow group Analytics-admin to use autonomous-databases in compartment Database
  2. サービス開発者ロール 
    • Allow group Analytics-developer to use analytics-instances in compartment App-Dev
Allow group Analytics-developer to use analytics-instance-work-requests in compartment App-Dev
  3. サービス・ビューア・ロール 
    • Allow group Analytics-viewer to read analytics-instances in compartment App-Dev
Allow group Analytics-viewer to read analytics-instance-work-requests in compartment App-Dev

これらのポリシーまたは類似したポリシーを使用してプロセスを開始し、オンボードするすべての新しいサービスでポリシー・モデルを拡張できます。

リソース・コストの管理

プロジェクトの実装時に多くのコストが固定されるCapExモデルから、システムの使用量に応じてコストがスケール・アップおよびスケール・ダウンするOpExモデルに移行する場合、組織内でこれらのクラウド・コストを理解、制御および通信するためにコスト管理ツールが必要になることがよくあります。

Oracleには、組織の支出を管理し、支出を最適化するためのツールが用意されています。

  • 予測:クラウド予算の設定と管理
  • 制御:支出超過の防止
  • 可視性:部門やプロジェクト間の正確なコスト追跡を保証し、どの部門、サービス、プロジェクトがクラウドの使用量に長期にわたって貢献しているかを分析します
  • 最適化:請求書照合の使用状況を詳細に把握し、コストを最適化する領域を識別します
  • 拡張:必要に応じて使用状況を拡張する領域を特定します。

Cost Management

これらの2つの方法のいずれかを使用して、コストを管理できます。

  • リソースのチーム/グループごとに財務予算を作成し、それらの予算に対して使用量を処理し、使用量が予算を超えたり、予算を超えようとしている場合にチーム管理者に警告します。
  • すべてのサービス・インスタンスの制限または割当て制限を作成します。チームが割り当てられた割当て制限を超えるインスタンスを作成しようとすると、リクエストは失敗します。

2番目のアプローチは制限的であり、コストの超過を防ぎますが、使用が割り当てられた予算を超えた場合、最初のアプローチでは手動介入が必要です。コンパートメント・ツリーは予算および割当てを集計するため、子コンパートメントは親に設定されている合計集計予算または割当てを共有します。

たとえば、コンパートメント・データ・サイエンスの予算が$2000の場合、DEVとTSTの子コンパートメントはそのグローバル予算を共有し、いずれか一方がその制限を超えた場合は制限されます。

コスト・トラッキング

予算を使用して、コスト・トラッキング・タグまたはコンパートメント(ルート・コンパートメントを含む)を設定することで、OCI支出のソフト制限を設定できます。そのコスト・トラッキング・タグまたはそのコンパートメントとその子に対するすべての支出を追跡できます。予算にアラートを設定して、予算を超えたときに管理に通知することもできます。OCIコンソールでは、すべての予算および支出制限を表示できます。

ほとんどの地域では1時間ごとにすべての予算アラートが評価され、アッシュバーン(IAD)では4時間ごとに評価されます。予算が最後に評価された時間を確認するには、予算の詳細を確認します。予算が評価された期間を示す、現在の支出額、予測および支出期間フィールドが表示されます。予算アラートがトリガーされると、予算アラートに構成されている受信者は電子メールを受信します。

OCIコスト・ガバナンスおよびパフォーマンス・インサイト・ソリューション・アプリケーションは、「さらに探索」セクションでリンクされたOracle Cloud Marketplaceからインストールして使用できます。

原価管理

サービス制限およびコンパートメント割当てを使用して作成されたサービス・インスタンスの数を制限することで、OCIでコストを制御できます。

サービス制限は、テナンシ、リージョン、可用性ドメインおよびコンパートメントでプロビジョニングできるリソースの最大数を管理するのに役立ちます。これらのソフト制限により、定義された制限を超える可能性のあるプロビジョニング・リソースが制限されます。権限のあるユーザーのみが、これらのサービス制限の引上げまたは減少をリクエストできます。サービス制限により、リージョン、可用性ドメインおよびコンパートメント内の特定のサービスのサービス・インスタンスの最大数を制限できます。

コンパートメント割当ては、テナンシおよびコンパートメント管理者がOCIでのリソースの消費方法をより適切に制御できるようにすることで、管理者が高いレベルの柔軟性を備えたリソースを割り当てることができるポリシーです。コンパートメント割当てはサービス制限に似ていますが、サービス制限はOracleによって設定されます。コンパートメント割当て制限は、高レベルの柔軟性でリソースを割り当てることができるポリシーを使用する管理者によって設定されます。

リソースの監視と監視

ガバナンス・モデルが組織の目標を達成するために機能していることを確認するために、リソースを監視および監視する必要があります。

クラウド・セキュリティ対策管理

Cloud Guardは、Oracle Cloudで強力なセキュリティ状況をモニターおよび維持するのに役立つOCIサービスです。クラウド・ガードには3つの必須要素があります。

  • ターゲットは監視するリソースです
  • ディテクタ・レシピは、問題を検出するためのレシピです
  • 問題が検出されると、レスポンダ・レシピがその問題に応答します。レスポンスは、通知または修正処理です。

クラウド・ガードは、OCIリソースのセキュリティ構成の問題を検出します。問題の考えられる影響に基づいて、リスク・スコアが問題に割り当てられます。クラウド・ガード・ダッシュボードからテナンシの集計リスク・スコアをモニターできます。クラウド・ガードの使用に関する推奨事項を次に示します。

  • クラウド・ガードは無料のサービスで、ベスト・プラクティスは、すべてのコンパートメントに対してクラウド・ガードをアクティブ化することです。
  • Cloud Guardレシピをカスタマイズして、検出された問題に対するカスタム・リスク・スコアおよびレスポンス・アクションを定義します。
  • 一部のコンパートメントを除外して、特定の他のコンパートメントでリソースを使用できるようにします。たとえば、開発コンパートメントを除外すると、本番コンパートメントでは許可されていないリソースを柔軟に作成できるようになります。

Cloud Guardは、Cloud Guardポリシーに対する例外のリストである許可リストをサポートしています。たとえば、クラウド・ガード・ポリシーがパブリック・オブジェクト・ストア・バケットを拒否するように設定されている場合。正当なユースケースにパブリック・バケットを作成する必要がある場合は、パブリック・バケットのOCIDを許可リストに明示的に追加できます。

セキュリティ・ロギング

すべてのクラウド・リソースに対するすべてのアクションを一元的に記録し、それらをクラウド・エコシステムで監査できることで、クラウドの実装が成功します。さらに、ネットワーク・フロー・ログおよび一部のアプリケーション・ログを使用して異常な動作を検出できます。セキュリティおよびコンプライアンス・チームは、不要なインシデントの通知または是正措置を自動化できます。クイックアクションを許可すると、侵害や脅威を緩和できます。

監視、監査およびロギング・データに基づくダッシュボードおよびレポートは、チームを更新し、障害になる前に問題を解決することに集中できます。セキュリティ・ロギングを設定することで、次のことができます。

  • ログ・グループで、OCIでデフォルトでオンになっている監査ログを集計し、ロギング・アナリティクスを使用して監視します。
  • ネットワーク・フロー・ログを有効にして、疑わしいネットワーク・アクティビティを検出します。
  • サービス・ログをサポートするすべてのサービスのサービス・ログを有効にします。サービス・ログの有効化中に適切なログ・グループを選択してください。
  • ログ・アナリティクスの対話型ビジュアライゼーションを使用して、データを分析します。クラスタ機能を使用して、数百万ものログ・エントリを少数の興味深いログ署名セットまで減らすと、ログを簡単に確認できるようになります。
  • ロギング分析のリンク機能を使用して、トランザクション内のログを分析し、グループ化されたビューを使用して異常パターンを識別します。

サードパーティのSIEMソリューションを使用する場合は、OCIストリーミング・サービスおよびサービス・コネクタを使用してOCIと統合できます。

ベースライン・ガバナンスの実装

Oracleでは、セキュア・ランディング・ゾーンを使用して、リソース組織(コンパートメント構造)およびリソース・アクセス・ガバナンスを実装することをお薦めします。

テナンシ構造およびアクセス・ポリシーの作成に加えて、ベースライン・ガバナンスでは、Cloud Guard、AuditおよびLoggingなどの他のセキュリティ機能も有効にする必要があります。

次の項で推奨するように、タグ付け構造とコスト・ガバナンス構造も作成する必要があります。

タグ付け

次の表のタグ・ネームスペースはCost-Managementです。

タグ・キー サンプル・キー値 摘要
名前 - -
CostCenterID ERP-U、ERP-Uk プロジェクト・コード名

次の表のタグ・ネームスペースはOperationsです。

タグ・キー サンプル・キー値 摘要
環境 本番以外 ライフサイクル環境
AppName 財務、HR ビジネス ユニット
AppCI - -
OProjectName 財務-EBS、財務-ERP -
ビジネス所有者 ABC.someone@example.com -
SystemCustodian ABC.someone@example.com -
SupportGrp ABC.someone@example.com -
OS 林、勝利 -
メンテナンス Group1、Group2、Group3 -
影響 低、中、高 組織全体の半径

次の表のタグ・ネームスペースはGovn-Securityです。

タグ・キー サンプル・キー値 摘要
InfoClass パブリック、内部、機密 -
NetTrustLevel 企業(3) /ベンダーDMZ(2) /インターネットDMZ(1) /ファイアウォール -
重要度 T1、T2、T3、T4
  • 階層1:最もクリティカル
  • 階層2:クリティカル
  • 階層3:クリティカルでないビジネス・ワークロード
  • Tier 4:非クリティカルなITワークロード

原価管理

OCIコンソールで、「ガバナンス」の下の「タグ・ネームスペース」UIを使用して、次の手順を実行します。

  1. CostManagement.CostCenterIDという名前のタグ・キーを定義し、それをコスト・トラッキングに使用できるようにします。
  2. 財務コスト・センターCostManagement.CostCenterID = "Finance"の財務のキー・タグ値を特定のリソースに割り当てます。
  3. ITコスト・センター"IT" (CostManagement.CostCenterID = "IT")のITのキー・タグ値を他のリソースに割り当てます。

テナンシでの予算作成UIを使用した予算の作成

  1. CostManagement.CostCenterID = Financeというタグが付けられたリソースの予算を作成します。
  2. CostManagement.CostCenterID = ITにタグ付けされたリソースの別の予算を作成します。
  3. コストが事前定義済の予算を超えた場合、または予測が設定されたしきい値を超えた場合に、Eメールを使用して受信者に通知するようにアラートを構成します。

タグ値に固有のコンパートメントの予算を作成できます。たとえば、月次予算$500は、Cost-Management/Financeタグ・ネームスペースおよびCostCenterIDタグ・キーでタグ・キー値がITのプロジェクト内のすべてのリソースに割り当てられます。また、ビジネス要件に合わせて予算を特定の日に開始するように構成することもできます。その後、実際の支出額が500ドルの予算の80%に達したときにABC.someone@company.comにアラートを送信するように構成できます。

すべてのOCIサービスには、デフォルトのサービス制限が適用されます。ワークロードに基づいて、制限、割当ておよび使用状況のUIを使用して、デフォルトのサービス制限を更新できます。これらの制限は、それらのグループに必要なニーズに応じて、承認済の境界または予算と整合するように設定できます。

コントロール・コスト

OCI内のすべてのコンパートメントに対するコンパートメント割当てを作成します。次の例は、コンパートメント割当てを作成する方法を示しています。

  1. 次の例では、米国西部(フェニックス)リージョンのコンパートメントApp-Devの各ADで、VM.Standard2 and BM.Standard2コンピュート・シリーズの割当てを240 OCPU (コア)に設定します。
    set compute-core quota standard2-core-count to 240 in compartment App-Dev where request.region = us-phoenix-1
  2. 次の例は、許可リストを作成し、ファミリ内のすべての割当てをゼロに設定し、リソースを明示的に割り当てる方法を示しています。
    zero compute-core quotas in tenancy set compute-core quota standard2-core-count to 240 in tenancy
  3. この例では、Dense I/Oコンピュート・リソースの作成を1つのリージョンのみに制限する方法を示します:
    zero compute-core quotas /*dense-io*/ in tenancy set compute-core quota /*dense-io*/ to 48 in tenancy where request.region = us-phoenix-1
  4. リソースの割当てを削除するunset文を使用して割当てをクリアできます。このリソースに対する制限は、設定されているサービス制限を使用して強制されるようになります:
    zero compute-core quotas in tenancy unset compute-core quota standard2-core-count in tenancy

コスト分析およびレポート

コスト分析とレポート作成は、コストのモニターと、コスト管理メジャーが機能していることを検証するための2つのサービスです。

コスト分析ツールを使用すると、Oracle Cloudのクレジットがどのように費やされているか、および消費量がコミットメント金額と比較してどのようにかを分析できます。ダッシュボードを使用して、コンパートメントまたはコスト・トラッキング・タグおよびトレンド線を使用して、サービスまたは部門別の支出を表示できます。これにより、支出パターンがどのように変化しているかを理解し、コスト削減に集中できます。予算に類似した特定のタグ・キーのコスト分析を実行できます。

特定の期間および係数に対して実行する特定のレポート・タイプを選択できます。また、これらのレポートをコンパートメント、タグ付けまたはその他のグループ値に基づいてグループ化すると、チャージバックまたは分析のきめ細かいレポートが可能になります。

使用状況およびコスト・レポート

使用状況レポートを使用すると、請求に関するインサイトを取得したり、カスタム請求アプリケーションを作成できます。レポートには、リソースごとに1つのレコードが含まれます。たとえば、メタデータおよびタグを含む1時間当たりのインスタンス、DBシステムまたはオブジェクト・ストレージ・バケットです。

コスト・レポートは、使用状況レポートに似たカンマ区切り値(CSV)ファイルで、コスト列が含まれます。レポートを使用して、リソース・レベルの粒度で請求書明細項目の内訳を取得できます。その結果、OCI支出を最適化し、より情報に基づいたクラウド支出の意思決定を行うことができます。

使用レポートには、消費量が示されます。コスト・レポートは、リソース消費のコストを示します。レート・カードと組み合せると、使用状況レポートによって次のようなシナリオが実現します。

  • 請求書突合せ
  • カスタム・レポート作成
  • クロス請求
  • 原価最適化
  • リソース在庫

新しい請求シナリオの有効化に加えて、使用状況レポートでは、請求システムの仕組みを透過的に把握できます。使用状況レポートは、使用レポート内で端数処理がどのように行われるか、また1時間未満のリソースの請求方法を示すことができます。

デプロイ

このソリューションのTerraformコードは、GitHubで入手できます。1回のクリックでコードをOracle Cloud Infrastructure Resource Managerにプルし、スタックを作成してデプロイできます。または、GitHubからコンピュータにコードをダウンロードし、コードをカスタマイズして、Terraform CLIを使用してアーキテクチャをデプロイします。

  • Oracle Cloud Infrastructure Resource Managerを使用してデプロイします:
    1. Oracle Cloudへのデプロイをクリックします

      まだサインインしていない場合は、テナンシおよびユーザー資格証明を入力します。

    2. 条件をレビューして受け入れます。
    3. スタックをデプロイするリージョンを選択します。
    4. 画面上のプロンプトと手順に従ってスタックを作成します。
    5. スタックの作成後、「Terraformアクション」をクリックし、「プラン」を選択します。
    6. ジョブが完了するまで待機し、プランをレビューします。

      変更するには、「スタックの詳細」ページに戻り、「スタックの編集」をクリックして必要な変更を行います。次に、「プラン」アクションを再度実行します。

    7. これ以上の変更が必要ない場合は、「スタックの詳細」ページに戻り、「Terraformアクション」をクリックして「適用」を選択します。
  • Terraform CLIを使用してデプロイします。
    1. GitHubにアクセスします。
    2. ローカル・コンピュータにコードをダウンロードまたはクローニングします。
    3. READMEの指示に従います。