採用トップ

AWS応用 カリキュラム

AWS応用(4)~高度なCloudFormationとIaCをマスターする~

今日のクラウド環境では、複雑なインフラを迅速かつ効率的に構築・管理する能力が求められています。

このカリキュラムでは、AWS CloudFormationを中心に、最新のIaC（Infrastructure as Code）のベストプラクティスを学びながら、コードによるインフラ管理を強化する方法を探求します。

また、AWS CDKやTerraformとの比較、クラウドの一貫性維持に役立つStack Drift Detectionのメンテナンスまで、スケーラビリティと自動化に不可欠な知識を深めていきます。

実用的な例を通じて、インフラ管理の効率を最大限に引き上げましょう。

1. CloudFormationテンプレートのモジュール化とベストプラクティス

はじめに: モジュール化の重要性

CloudFormationテンプレートを一つの巨大なファイルとして管理すると、メンテナンスが難しく、特に大規模なインフラになると変更やデバッグが困難です。

テンプレートを複数の小さなモジュールに分割することで、各モジュールを再利用可能にし、複数の環境やプロジェクトに適用できます。

また、モジュールごとに独立したテストが可能になり、エラーの発見や修正が簡単になります。

ベストプラクティス1: リソースごとの分割

一般的に、テンプレートを「ネットワークリソース」「IAMリソース」「アプリケーションリソース」などのカテゴリごとに分けると管理がしやすくなります。

例えば、VPCやサブネット、セキュリティグループなどは「network.yaml」などのファイルに、IAMユーザーやロール、ポリシーは「iam.yaml」にまとめることで、それぞれが独立して保守可能になります。

実装例

yaml

# network.yaml
Resources:
  VPC:
    Type: "AWS::EC2::VPC"
    Properties:
      CidrBlock: "10.0.0.0/16"
  Subnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      CidrBlock: "10.0.1.0/24"
      VpcId: !Ref VPC

# iam.yaml
Resources:
  AdminRole:
    Type: "AWS::IAM::Role"
    Properties:
      RoleName: "AdminRole"
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: "Allow"
            Principal:
              Service: "ec2.amazonaws.com"
            Action: "sts:AssumeRole"

これにより、IAMに関する設定を変更したいときはiam.yamlのみに変更を加えればよく、デプロイもIAM関連のみに限定できます。

ベストプラクティス2: クロススタック参照による依存関係の管理

リソース間の依存関係がある場合、各スタック間でリソースを参照するためにクロススタック参照を利用します。

たとえば、VPCスタックで作成されたリソースをアプリケーションスタックで参照したいときに、ExportとImportを活用することで、スタックを疎結合に保ちながら連携が可能です。

yaml

# network.yaml (VPCスタック)
Resources:
  VPC:
    Type: "AWS::EC2::VPC"
    Properties:
      CidrBlock: "10.0.0.0/16"
Outputs:
  VPCId:
    Value: !Ref VPC
    Export:
      Name: VPCId

# application.yaml (アプリケーションスタック)
Resources:
  EC2Instance:
    Type: "AWS::EC2::Instance"
    Properties:
      SubnetId: !ImportValue VPCId
      ImageId: "ami-0abcdef1234567890"

VPCスタックが先にデプロイされていれば、アプリケーションスタックからそのVPCのIDを簡単に参照できるため、依存関係を整然と管理できます。

ベストプラクティス3: SSMパラメータストアとの連携

環境ごとの変数（例: VPCのCIDRブロック、データベースのパスワードなど）をAWS Systems Manager（SSM）パラメーターストアに保存し、CloudFormationテンプレートでこれらの値を参照することで、テンプレート自体を修正することなく異なる環境で利用できます。

実装例

1. パラメータストアに値を保存

bash

aws ssm put-parameter --name "/dev/dbPassword" --value "your-password" --type "SecureString"

2. CloudFormationテンプレートでの使用

Resources:
  Database:
    Type: "AWS::RDS::DBInstance"
    Properties:
      MasterUsername: "admin"
      MasterUserPassword: !Sub "{{resolve:ssm-secure:/dev/dbPassword:1}}"

これにより、異なるパスワードや設定値を環境ごとに保持しながら、共通のテンプレートでのデプロイが可能となります。

ベストプラクティス4: AWS公式のベストプラクティスに基づいた構造の設計

AWSの公式ベストプラクティスでは、リソースの命名規則の統一、スタック構造のモジュール化、パラメータと出力の適切な使用が推奨されています。

これらのガイドラインに従うことで、保守性が向上し、複数のエンジニアによる共同作業も円滑になります。

  • 命名規則: リソースに共通の接頭辞を付ける、環境ごとにサフィックスを設けるなどして一貫性を持たせます。
  • タグ付け: 部門やプロジェクトごとのリソースの識別を容易にするため、標準タグ（例: Project、Environment）を導入します。

2. パラメーターストアとテンプレートの動的設定

概要：パラメーターストアとは

AWS Systems Manager Parameter Store（SSMパラメーターストア）は、設定情報や秘密情報をセキュアに保管し、必要なタイミングで参照するためのサービスです。

これを使うことで、CloudFormationテンプレートの中で動的な値を取得でき、異なる環境（開発、ステージング、本番など）で共通のテンプレートを使い回すことが可能です。

パラメーターストアの使用メリット

  • 動的な値の取得: テンプレートにハードコードせず、環境に応じて適切な値を取得可能。
  • セキュリティ: データの暗号化が可能で、APIアクセスもIAMで制御できる。
  • 一元管理: 各環境の設定値をSSMパラメーターストアに一元化することで、デプロイ時の修正箇所を削減。

パラメーターストアのセットアップとCloudFormationでの使用方法

ステップ1: パラメータをパラメーターストアに登録

まず、SSMパラメーターストアにパラメータを追加します。

ここでは、データベースのパスワードを例にします。

bash

aws ssm put-parameter --name "/prod/dbPassword" --value "super-secure-password" --type "SecureString"
aws ssm put-parameter --name "/dev/dbPassword" --value "dev-password" --type "SecureString"

• /prod/dbPassword: 本番環境のパスワード。

• /dev/dbPassword: 開発環境のパスワード。

• SecureString: パラメータを暗号化して保存するためのオプションです。

ステップ2: CloudFormationテンプレートでの参照

CloudFormationテンプレートで、SSMパラメーターストアから値を動的に取得します。

パラメータの種類がSecureStringである場合、以下の形式を使用して値を取得できます。

yaml

Resources:
  Database:
    Type: "AWS::RDS::DBInstance"
    Properties:
      MasterUsername: "admin"
      MasterUserPassword: !Sub "{{resolve:ssm-secure:/prod/dbPassword:1}}"
      DBInstanceClass: "db.t3.micro"
      Engine: "mysql"

上記のように、!Sub "{{resolve:ssm-secure:/prod/dbPassword:1}}"という書き方で、パラメーターストアから暗号化された値を取得します。

これにより、開発と本番で異なるパスワードを使い分けることが可能です。

動的設定を利用した環境別テンプレートの自動化

パラメーターストアを活用することで、環境ごとの設定値（例: VPC ID, サブネット, IAMロールなど）も動的に管理可能です。

異なる環境で同じテンプレートを使う際、パラメーターストアからその環境に合った設定値を取得するように設計すると便利です。

例えば、開発環境と本番環境で異なるVPC IDを使いたい場合、次のようにパラメーターストアに設定します。

bash

aws ssm put-parameter --name "/dev/vpcId" --value "vpc-0123456789abcdef0" --type "String"
aws ssm put-parameter --name "/prod/vpcId" --value "vpc-0987654321fedcba0" --type "String"

CloudFormationテンプレートで以下のように参照します。

Resources:
  MyEC2Instance:
    Type: "AWS::EC2::Instance"
    Properties:
      InstanceType: "t2.micro"
      SubnetId: !Sub "{{resolve:ssm:/prod/vpcId:1}}"
      ImageId: "ami-0abcdef1234567890"

このようにすることで、テンプレート内で同じ構造を維持しつつ、環境に応じて異なるVPC IDが適用されます。

セキュリティ強化のためのポイント

1. 暗号化の活用:

SecureStringオプションでデータを保存し、AWS KMS（Key Management Service）を使用して暗号化することで、データの機密性を保護します。

パスワードやアクセスキーなどの重要な情報は必ず暗号化して保存します。

2. アクセス制御:

IAMポリシーを使って、SSMパラメーターストアへのアクセスを制限します。

例えば、開発環境のユーザーが本番環境のパラメータにアクセスしないように制御できます。

ポリシー例

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:GetParameter",
        "ssm:GetParameters"
      ],
      "Resource": [
        "arn:aws:ssm:us-west-2:123456789012:parameter/prod/*"
      ]
    }
  ]
}

3. クロススタック参照とスタックセットの使用

クロススタック参照: 効率的なリソース共有のために

CloudFormationのクロススタック参照を利用すると、複数のスタック間でリソースを共有でき、冗長なリソース作成を避けることができます。

これは、特に共有するリソース（例: VPC、IAMロール、セキュリティグループ）がある場合に便利です。クロススタック参照により、インフラの管理が効率化し、再利用性が高まります。

クロススタック参照の構成手順

ステップ1: リソースをエクスポートする

リソースをクロススタック参照するには、まずエクスポートするスタックで出力値（Outputs）として指定します。

たとえば、VPC IDを他のスタックで使用できるようにエクスポートします。

VPCスタックテンプレート (vpc-stack.yaml)

Resources:
  MyVPC:
    Type: "AWS::EC2::VPC"
    Properties:
      CidrBlock: "10.0.0.0/16"

Outputs:
  VPCId:
    Value: !Ref MyVPC
    Export:
      Name: MyVPCId

このテンプレートを使ってVPCスタックをデプロイすると、他のスタックで「MyVPCId」という名前でこのVPC IDを参照できます。

ステップ2: エクスポートしたリソースを他のスタックでインポートする

別のスタックでこのVPC IDを使用するためには、ImportValue関数を使用します。

例えば、アプリケーションスタックでVPC内にサブネットやインスタンスを作成する場合にこのVPC IDを参照します。

アプリケーションスタックテンプレート (app-stack.yaml)

Resources:
  MySubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      CidrBlock: "10.0.1.0/24"
      VpcId: !ImportValue MyVPCId

このように、VPCスタックが提供する「MyVPCId」を利用することで、アプリケーションスタックがVPC内のサブネットを効率的に設定できます。

スタックセット: 複数のリージョンやアカウントへの展開

スタックセットは、複数のAWSリージョンやアカウントに同じCloudFormationスタックをデプロイするのに役立ちます。

これにより、グローバルなインフラ構成が簡単に管理でき、スケーラブルな展開が可能になります。

スタックセットの構成手順

1. スタックセットの作成

AWSマネジメントコンソールまたはCLIから、まずスタックセットを作成します。

スタックセットには、リージョン間で展開されるリソース（例: IAMロール、S3バケットなど）を含めます。

yaml

# IAMロールを含むサンプルスタックセットテンプレート
Resources:
  StackSetRole:
    Type: "AWS::IAM::Role"
    Properties:
      RoleName: "StackSetAdminRole"
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: "Allow"
            Principal:
              Service: "cloudformation.amazonaws.com"
            Action: "sts:AssumeRole"

2. ターゲットアカウントとリージョンの指定

スタックセット作成後、ターゲットとするAWSアカウントとリージョンを指定してインスタンスを作成します。

これにより、同一テンプレートが指定のリージョンやアカウントで展開されます。

3. パーミッションの設定

スタックセットを実行するためには、信頼されたアカウントが必要です。

スタックセット管理アカウントとデプロイ先のターゲットアカウント間で、クロスアカウントIAMロールを設定し、適切な権限を付与します。

実例：複数アカウント間でのIAMロールの展開

複数のAWSアカウントでIAMロールを共通設定する場合、スタックセットを使用すると便利です。

例えば、各アカウントに同じ管理者ロールを展開したい場合にスタックセットを利用します。

  • 管理者アカウントでスタックセットを作成し、ターゲットアカウントを指定してロールを展開。
  • 信頼関係の設定を行い、管理者アカウントがターゲットアカウントのリソースにアクセスできるようにします。

スタックセットとクロススタック参照のベストプラクティス

1. リソースの再利用と依存管理を意識した設計

必要なリソースは1つのスタックに集約し、他のスタックがそれを参照することで、インフラをシンプルかつ柔軟に管理できます。

クロススタック参照を活用して、冗長性のない効率的な設計を行います。

2. スタックセットのターゲットアカウントとリージョンの戦略的選択

グローバルなデプロイが必要なリソースと、リージョン限定のリソースを明確に分け、スタックセットの展開対象を厳選することでコストとパフォーマンスの最適化を図ります。

3. 変更管理とモニタリングの徹底

スタックセットを使用して複数リージョンやアカウントに展開する場合、変更が全てのターゲットに反映されることを確認し、モニタリングで適用状況を追跡します。CloudFormationのイベントログを活用して、各スタックのデプロイ状態を把握するのが有効です。

4. AWS CDK (Cloud Development Kit) によるコードベースでのインフラ管理

はじめに：AWS CDKとは

AWS CDK（Cloud Development Kit）は、プログラミング言語（TypeScript、Python、Java、C#など）を使ってAWSインフラをコードベースで管理するためのフレームワークです。

従来のCloudFormationテンプレートに比べて、コードの再利用性や構造化がしやすく、CI/CDと組み合わせた変更管理がしやすくなります。

AWS CDKの利点

  1. コードの再利用性: 関数やクラスでインフラを定義でき、他のプロジェクトでも同じコードを再利用可能。
  2. モジュール化: 設定を簡単にモジュール化して、小規模なインフラ部品を組み合わせる形で拡張が可能。
  3. 動的な設定: パラメータの条件分岐や動的設定が容易で、より柔軟なインフラ管理が可能。
  4. バージョン管理: プログラムのコードとしてインフラを管理することで、変更履歴やバージョン管理がしやすくなります。

AWS CDKの基本的なセットアップ

ステップ1: AWS CDKのインストール

まず、AWS CDKをインストールします。以下のコマンドでCDKをインストールします。

bash

npm install -g aws-cdk

ステップ2: プロジェクトの初期化

新しいプロジェクトを作成し、ディレクトリを初期化します。

ここではTypeScriptを使用した例を示しますが、Pythonや他の言語でも似た手順です。

bash

mkdir my-cdk-app
cd my-cdk-app
cdk init app --language typescript

このコマンドで、基本的なプロジェクト構成が自動で作成され、libディレクトリ内にスタックの定義ファイルが生成されます。

基本的なデプロイ例

VPCとS3バケットの作成例

以下は、VPCとS3バケットをデプロイする簡単なコード例です。

lib/my-cdk-app-stack.tsファイルに以下の内容を追加します。

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as s3 from 'aws-cdk-lib/aws-s3';

export class MyCdkAppStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // VPCの作成
    const vpc = new ec2.Vpc(this, 'MyVpc', {
      maxAzs: 2 // 最大のアベイラビリティゾーン数
    });

    // S3バケットの作成
    const bucket = new s3.Bucket(this, 'MyBucket', {
      versioned: true, // バージョニングを有効化
      removalPolicy: cdk.RemovalPolicy.DESTROY, // スタック削除時にバケットを削除
    });
  }
}

このコードでは、VPCとS3バケットを作成しています。

VPCには2つのアベイラビリティゾーンを指定し、S3バケットにはバージョニングを有効にしました。

AWS CDKを使うと、これだけのコードでCloudFormationに対応するテンプレートが自動生成され、複数リソースを簡潔に管理できます。

デプロイの実行

1. AWS認証情報の設定

デプロイ前に、AWS CLIで認証情報を設定します。

2. デプロイの準備

コードをデプロイ可能なCloudFormationテンプレートに変換します。

以下のコマンドでテンプレートを確認します。

bash

cdk synth

このコマンドにより、生成されるCloudFormationテンプレートが表示され、設定を確認できます。

3. デプロイの実行

次に、以下のコマンドでデプロイします。

bash

cdk deploy

cdk deployにより、AWSリソースが実際に作成されます。

実行時に、作成されるリソースの確認が求められることがあります。

テンプレートとコードベース管理の違い

AWS CDKを使用することで、インフラのコードベース管理が可能になり、以下のようなメリットがあります。

  • 管理のしやすさ: 設定の変更や追加が簡単で、ソースコードのバージョン管理も容易。
  • 動的設定: 環境変数や条件式を組み合わせ、柔軟な設定が可能。
  • テンプレート生成の自動化: AWS CDKは、デプロイ時に自動でCloudFormationテンプレートを生成するため、テンプレートの作成と管理を手動で行う必要がありません。

CDKによる高度な管理

AWS CDKは、単純なリソース作成だけでなく、複雑な依存関係を含むアーキテクチャを簡潔に管理するためのツールです。

特に、複数の環境でインフラを構築する際や、条件に応じた設定変更を行う場合に優れた柔軟性を発揮します。

  • スタックの分割と依存関係: 他のスタックを参照して、依存関係の管理が可能。
  • CI/CDの組み込み: コードベースの変更をCI/CDパイプラインで管理し、自動化デプロイを実現。

5. AWS CloudFormation Stack Drift Detectionの利用とメンテナンス

スタックドリフトとは？

スタックドリフトとは、CloudFormationで定義したリソースの状態と、実際のAWSリソースの状態が一致しないことを指します。

ドリフトが発生すると、インフラが意図した構成からずれ、予期しない動作やセキュリティリスクが発生する可能性があります。

AWS CloudFormation Stack Drift Detection機能を使うことで、リソースがテンプレート通りに保持されているかを検証し、必要に応じて整合性を回復する対応が取れます。

スタックドリフトの検出方法

ステップ1: ドリフト検出の実行

AWS管理コンソール、CLI、またはAPIを使用して、任意のスタックでドリフト検出を開始できます。

AWS管理コンソールでの操作手順は次の通りです：

1. CloudFormationコンソールでドリフトを確認したいスタックを選択。

2. [Actions]メニューからDetect driftを選択し、検出を開始します。

CLIを使用する場合は、以下のコマンドを実行します：

aws cloudformation detect-stack-drift --stack-name <スタック名>

このコマンドでスタックのドリフト検出が実行され、リソースの整合性をチェックします。

ステップ2: ドリフト結果の確認

ドリフト検出が完了すると、リソースごとにドリフトの状態が表示されます。

主なステータスには次の4種類があります：

  • IN_SYNC: テンプレートとリソースが一致している。
  • DRIFTED: テンプレートとリソースに差異がある。
  • NOT_CHECKED: ドリフト検出を実行していないリソース。
  • DELETED: テンプレートで定義されているが、削除されているリソース。

ドリフトの詳細は、各リソースの変更内容（例: セキュリティグループルールの変更、VPCサブネットのCIDR変更など）として表示されます。

ドリフトの典型的な問題例と対処法

1. 手動変更によるドリフト

例：IAMポリシーのルールを管理コンソールで手動で追加した場合など。

• 対処方法:
　　必要に応じて、CloudFormationテンプレートを更新してリソースを再デプロイするか、不要な手動変更を削除して整合性を回復します。

2. 自動スケーリングなどの設定変更

例：Auto Scaling Groupで意図的にインスタンス数を増やした場合。

• 対処方法:
　　一時的な変更であれば、ドリフトの発生を許容するか、テンプレートに反映する方法を検討します。

3. サードパーティサービスによる変更

例：運用モニタリングツールがリソースを更新する場合など。

• 対処方法:
　　サードパーティサービスとの連携を見直し、テンプレートで一元管理するか、ドリフト許容範囲を定義します。

ドリフトの通知設定

AWS CloudFormationに直接通知機能はありませんが、AWS CloudWatchと連携させることで、ドリフト検出完了時や異常が発生した際に通知を受け取ることができます。

1. CloudWatch Eventsを設定し、CloudFormationでのドリフト検出イベントをトリガーにします。

2. 通知先として、SNSトピックを設定し、メールやSMS、またはWebhookを使用して通知を受け取れるようにします。

例: CloudWatchイベントルールの設定

aws events put-rule --name "CloudFormationDriftDetection" --event-pattern '{ "source": ["aws.cloudformation"], "detail-type": ["AWS API Call via CloudTrail"], "detail": { "eventName": ["DetectStackDrift"] } }'

これにより、ドリフト検出が完了した際にイベントが発生し、SNSトピック経由で通知を受け取ることができます。

頻繁な更新が発生する環境におけるドリフト管理

頻繁に変更が発生する環境（開発環境やステージング環境など）では、定期的なドリフト検出をスケジュールすることで、構成のずれを早期に発見できます。

例えば、AWS LambdaとCloudWatch Eventsを利用して、毎日または毎週のドリフト検出を自動化する仕組みを構築するのも効果的です。

  • Lambda関数でdetect-stack-drift APIを呼び出し、ドリフト検出を自動実行。
  • CloudWatch Eventで定期的なトリガーを設定し、定期的に実行。

6. Terraformとの比較とAWSでの使用例

CloudFormationとTerraformの概要

CloudFormationとTerraformはどちらもInfrastructure as Code（IaC）のツールですが、それぞれ異なる特徴と使い方があります。

CloudFormationはAWS専用で、AWSのサービスに深く統合されています。

一方、TerraformはHashiCorpによって開発されたオープンソースツールで、AWSだけでなくAzure、GCPなど複数のクラウドサービスを統一したコードで管理できるため、マルチクラウド環境に強みがあります。

CloudFormationとTerraformの長所と短所

特徴CloudFormationTerraform
サポート対象AWS専用、AWSの新サービスに迅速に対応マルチクラウド対応（AWS、Azure、GCP、他多数）
インターフェースJSONやYAMLフォーマットのテンプレートで記述HCL（HashiCorp Configuration Language）で記述。シンプルかつ読みやすい
ドリフト検出CloudFormation Stack Drift Detection機能で、設定と実環境の不一致を検出ドリフト検出機能は直接提供されていないが、Terraform Planでの確認が可能
モジュール化テンプレートのモジュール化は可能だが、柔軟性に限りがある高いモジュール化機能。複数のファイルやモジュールを簡単に再利用可能
状態管理AWSが状態を管理（S3等に保存する必要がない）terraform.tfstateで状態を管理。S3や他のリモートバックエンドでの保存が必要
ロールバック自動ロールバック機能があり、デプロイ中のエラー時にリソースが元に戻るロールバック機能はないが、手動でterraform destroyを実行することで削除が可能
スピードと効率AWS環境でのデプロイは高速複数クラウドの設定が可能だが、速度はCloudFormationより劣る場合がある
学習曲線YAMLやJSONに慣れている場合は比較的学習しやすいHCLはシンプルだが、新たに学ぶ必要がある

AWS環境におけるTerraformの使用例

Terraformは特にマルチクラウド戦略を採用する企業や、AWS外のサービスとの連携が必要な環境で有用です。以下は、AWS上でのTerraformの基本的な使用例です。

使用例: S3バケットのデプロイ

Terraformを用いてS3バケットを作成するコードの例を示します。

main.tf

provider "aws" {
  region = "us-west-2"
}

resource "aws_s3_bucket" "example" {
  bucket = "my-example-bucket"
  acl    = "private"
  
  tags = {
    Name        = "Example S3 Bucket"
    Environment = "Dev"
  }
}

1. 初期化

Terraformを初期化してプロバイダプラグインを設定します。

terraform init

2. プラン作成

terraform planコマンドで作成予定のリソースを確認できます。

リソースが意図した通りに構成されるか確認するための重要なステップです。

terraform plan

3. 適用

terraform applyで、定義したリソースをデプロイします。

terraform apply

この例では、AWS上にS3バケットが作成され、定義通りにタグが設定されます。

CloudFormationとTerraformのハイブリッドアプローチ

CloudFormationとTerraformを併用することで、それぞれのツールの利点を活かしたインフラ構成が可能です。

特にAWSに特化したリソース管理にはCloudFormation、AWS外のリソース管理やマルチクラウド管理にはTerraformを利用することで、柔軟な運用が可能になります。

ハイブリッドアプローチの例

  1. CloudFormationでIAMロールやVPC、AWSサービス関連のリソースを管理。
  2. TerraformでCloudFormation外のリソース（例: 他のクラウドサービス、サードパーティツール）や、AWSと他クラウド間の接続を管理。

たとえば、AWS上でVPCやIAMロールをCloudFormationでデプロイし、AzureやGCP上のリソースをTerraformでデプロイする構成も考えられます。

実装例：CloudFormationとTerraformの連携

1. CloudFormationスタックでIAMロールとVPCをデプロイ

Resources:
  MyVPC:
    Type: "AWS::EC2::VPC"
    Properties:
      CidrBlock: "10.0.0.0/16"

  IAMRole:
    Type: "AWS::IAM::Role"
    Properties:
      RoleName: "MyTerraformRole"
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: "Allow"
            Principal:
              Service: "ec2.amazonaws.com"
            Action: "sts:AssumeRole"

2. TerraformでAWSリソースと他クラウドのリソースを管理

Terraformを使用してAWSリソースや他のクラウドプロバイダーのリソースを同時に管理できます。

これにより、マルチクラウド環境のインフラ一元管理が可能です。

provider "aws" {
  region = "us-west-2"
}

provider "azurerm" {
  features {}
}

# AWSのS3バケット
resource "aws_s3_bucket" "example" {
  bucket = "my-example-bucket"
}

# Azureのリソース
resource "azurerm_resource_group" "example" {
  name     = "my-resource-group"
  location = "West Europe"
}

ツール選定のアドバイス

  • AWS専用のインフラ管理がメインの場合：
    CloudFormationを使用すると、AWSサービスとの統合がスムーズで、学習コストも低くなります。
  • マルチクラウド戦略やAWS外のツールとの統合が重要な場合：
    Terraformのマルチクラウド対応と柔軟な構成管理を活用し、AWS以外のクラウドやリソースを含む構成を統一的に管理するのが効果的です。
  • 併用する場合：AWSリソースはCloudFormationで管理し、他クラウドのリソースはTerraformで管理するハイブリッドアプローチを取ると、それぞれのツールの強みを生かした運用が可能です。

まとめ

複雑なインフラ構成の自動化には、高度なツールやベストプラクティスの理解が欠かせません。

このカリキュラムでは、CloudFormationやAWS CDK、Terraformを駆使して、スケーラブルかつ自動化されたインフラを構築するための技術を深めました。

テンプレートのモジュール化や動的設定、スタックドリフト検出といったテクニックを活用することで、効率的なインフラ管理が可能になります。

SHARE

blog 関連記事

すべて見る
採用バナー