ステップ2：ECSクラスターとALBの構築

今回のステップの概要とこのカリキュラムとの関連について

このステップでは、前回構築したVPC上に、ECS on FargateクラスターとApplication Load Balancer（ALB）をAWS CDKで構築します。具体的には、コンテナを動かすためのECSクラスター、外部からのアクセスを受け付けるALB、そしてセキュリティグループとIAMロールをTypeScriptコードで記述します。

コンテナアプリケーションのインフラにとって、ECSクラスターとALBは「商品を並べる棚と、お客様を案内する受付係」のような役割を果たします。ECSクラスターは、Dockerコンテナを動かすための「棚」であり、複数のコンテナを効率的に配置・管理します。ALBは、外部からのHTTP/HTTPSリクエストを受け付け、適切なコンテナに振り分ける「受付係」です。物理的な店舗で言えば、お客様が正面玄関（ALB）から入店し、受付係が商品棚（ECSタスク）まで案内するイメージです。

従来、これらのリソースもAWSコンソールで手作業で作成していましたが、AWS CDKを使えば、VPCと同様にTypeScriptコードで記述し、自動構築できます。さらに、CDKのL2 Constructsを使用することで、複雑な設定をシンプルなコードで表現できます。

このステップで学ぶこと

• ECSクラスターのコード化とFargateの設定
• Application Load Balancerとターゲットグループの構築
• セキュリティグループによるネットワークアクセス制御
• IAMロールとタスクロールの設定

リソースの関わりと構成説明

ステップ2で作成するリソースは、コンテナアプリケーションを動かすための「実行基盤」と「ロードバランサー」を構築するものです。それぞれのリソースがインフラにどのように関わるのかを説明します。

ECS on Fargateクラスターとインフラの関わり

ECS（Elastic Container Service）「Fargateクラスター」は、Dockerコンテナを動かすための「実行基盤」のような役割を果たします。物理的な店舗で言えば、「商品を並べる棚」に相当します。Fargateは、サーバーレスなコンテナ実行環境で、EC2インスタンスを管理する必要がありません。コンテナに必要なCPUとメモリを指定するだけで、AWSが自動的にリソースを割り当て、コンテナを起動します。これにより、インフラ管理の負担を大幅に軽減し、アプリケーション開発に集中できます。

Application Load Balancer（ALB）とインフラの関わり

ALB（Application Load Balancer）「アプリケーションロードバランサー」は、外部からのHTTP/HTTPSリクエストを受け付け、複数のECSタスクに負荷を分散する「受付係」のような役割を果たします。物理的な店舗で言えば、「正面玄関の受付カウンター」に相当します。ユーザーがブラウザでWebサイトにアクセスすると、まずALBがリクエストを受け付け、健全なECSタスクに転送します。1つのタスクに障害が発生しても、ALBが自動的に他の健全なタスクにトラフィックを振り分けるため、サービスが継続します。これにより、高可用性と負荷分散を実現できます。

セキュリティグループとインフラの関わり

セキュリティグループ「仮想ファイアウォール」は、AWSリソースへのネットワークアクセスを制御する「門番」のような役割を果たします。物理的な店舗で言えば、「警備員が入退場を管理するゲート」に相当します。ALB用のセキュリティグループでは、「インターネットからのHTTP（ポート80）とHTTPS（ポート443）のアクセスのみ許可」というルールを設定し、ECSタスク用のセキュリティグループでは、「ALBからのアクセスのみ許可」というルールを設定します。これにより、外部から直接ECSタスクにアクセスすることを防ぎ、セキュリティを確保できます。

IAMロールとタスクロールとインフラの関わり

IAMロール「タスクロール」は、ECSタスクがAWSサービスにアクセスするための「権限証明書」のような役割を果たします。物理的な店舗で言えば、「従業員が倉庫にアクセスするための鍵」に相当します。例えば、コンテナアプリケーションがS3バケットからファイルを読み込んだり、DynamoDBにデータを保存したりする場合、タスクロールに適切な権限（ポリシー）をアタッチします。これにより、アクセスキーをコード内にハードコーディングする必要がなく、セキュアにAWSサービスを利用できます。

実際の手順

実際の手順では、たくさんの設定値を入力することになります。 本文中に設定値が指定されていない場合は、デフォルト値のまま作業を進めてください。

1. ECSクラスターの構築

Fargate対応のECSクラスターをCDKコードで作成します。

1-1. ECSクラスターのCDKコード追加

1. lib/cdk-iac-project-stack.ts ファイルを開き、ECSクラスターのコードを追加します

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as ecs from 'aws-cdk-lib/aws-ecs';
 
export class CdkIacProjectStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);
 
    // VPCの作成（ステップ1から継続）
    const vpc = new ec2.Vpc(this, 'MyVpc', {
      maxAzs: 2,
      natGateways: 1,
      subnetConfiguration: [
        {
          cidrMask: 24,
          name: 'Public',
          subnetType: ec2.SubnetType.PUBLIC,
        },
        {
          cidrMask: 24,
          name: 'Private',
          subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
        },
      ],
    });
 
    // ECSクラスターの作成
    const cluster = new ecs.Cluster(this, 'MyCluster', {
      vpc: vpc,
      clusterName: 'my-fargate-cluster',
      containerInsights: true, // CloudWatch Container Insightsを有効化
    });
 
    // クラスター名を出力
    new cdk.CfnOutput(this, 'ClusterName', {
      value: cluster.clusterName,
      description: 'ECS Cluster Name',
    });
 
    new cdk.CfnOutput(this, 'VpcId', {
      value: vpc.vpcId,
      description: 'VPC ID',
    });
  }
}

1-2. CDKコードの検証とデプロイ

1. 変更内容を確認します

cdk diff

以下のような出力が表示され、ECSクラスターが作成されることを確認できます。

Stack CdkIacProjectStack
Resources
[+] AWS::ECS::Cluster MyCluster MyClusterXXXXXXXX
[+] AWS::IAM::Role MyCluster/DefaultServiceRole ...
...

2. ECSクラスターをデプロイします

cdk deploy --region us-east-1

デプロイが完了すると、以下のような出力が表示されます。

✅ CdkIacProjectStack
 
Outputs:
CdkIacProjectStack.ClusterName = my-fargate-cluster
CdkIacProjectStack.VpcId = vpc-0123456789abcdef0

2. Application Load Balancerの構築

外部からのHTTP/HTTPSリクエストを受け付けるALBを作成します。

2-1. ALBのCDKコード追加

1. lib/cdk-iac-project-stack.ts に、ALBとセキュリティグループのコードを追加します

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as ecs from 'aws-cdk-lib/aws-ecs';
import * as elbv2 from 'aws-cdk-lib/aws-elasticloadbalancingv2';
 
export class CdkIacProjectStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);
 
    // VPCの作成（省略）
    const vpc = new ec2.Vpc(this, 'MyVpc', {
      // ... 省略 ...
    });
 
    // ECSクラスターの作成（省略）
    const cluster = new ecs.Cluster(this, 'MyCluster', {
      // ... 省略 ...
    });
 
    // ALB用のセキュリティグループを作成
    const albSecurityGroup = new ec2.SecurityGroup(this, 'AlbSecurityGroup', {
      vpc: vpc,
      description: 'Security group for ALB',
      allowAllOutbound: true,
    });
 
    // HTTP（ポート80）のインバウンドを許可
    albSecurityGroup.addIngressRule(
      ec2.Peer.anyIpv4(),
      ec2.Port.tcp(80),
      'Allow HTTP traffic from anywhere'
    );
 
    // Application Load Balancerの作成
    const alb = new elbv2.ApplicationLoadBalancer(this, 'MyAlb', {
      vpc: vpc,
      internetFacing: true, // インターネット向け
      securityGroup: albSecurityGroup,
      vpcSubnets: {
        subnetType: ec2.SubnetType.PUBLIC, // パブリックサブネットに配置
      },
    });
 
    // ALBのDNS名を出力
    new cdk.CfnOutput(this, 'AlbDnsName', {
      value: alb.loadBalancerDnsName,
      description: 'ALB DNS Name',
    });
 
    new cdk.CfnOutput(this, 'ClusterName', {
      value: cluster.clusterName,
      description: 'ECS Cluster Name',
    });
 
    new cdk.CfnOutput(this, 'VpcId', {
      value: vpc.vpcId,
      description: 'VPC ID',
    });
  }
}

2-2. ターゲットグループの作成

1. ALBがトラフィックを転送するためのターゲットグループを作成します

    // ... 省略（前述のコード） ...
 
    // Application Load Balancerの作成（省略）
    const alb = new elbv2.ApplicationLoadBalancer(this, 'MyAlb', {
      // ... 省略 ...
    });
 
    // ターゲットグループの作成
    const targetGroup = new elbv2.ApplicationTargetGroup(this, 'MyTargetGroup', {
      vpc: vpc,
      port: 80,
      protocol: elbv2.ApplicationProtocol.HTTP,
      targetType: elbv2.TargetType.IP, // Fargateタスクはタイプ「IP」
      healthCheck: {
        path: '/api/health',
        interval: cdk.Duration.seconds(30),
        timeout: cdk.Duration.seconds(5),
        healthyThresholdCount: 2,
        unhealthyThresholdCount: 3,
      },
    });
 
    // ALBリスナーの作成（HTTP ポート80）
    const listener = alb.addListener('HttpListener', {
      port: 80,
      protocol: elbv2.ApplicationProtocol.HTTP,
      defaultAction: elbv2.ListenerAction.forward([targetGroup]),
    });
 
    // ALBのDNS名を出力
    new cdk.CfnOutput(this, 'AlbDnsName', {
      value: alb.loadBalancerDnsName,
      description: 'ALB DNS Name',
    });
 
    // ... 省略（以降のコード） ...

2-3. ALBのデプロイと確認

1. 変更内容を確認します

cdk diff --region us-east-1

2. ALBとターゲットグループをデプロイします

cdk deploy --region us-east-1

デプロイが完了すると、ALBのDNS名が出力されます。

✅ CdkIacProjectStack
 
Outputs:
CdkIacProjectStack.AlbDnsName = CdkIac-MyAlb-XXXXXXXXXXXX.us-east-1.elb.amazonaws.com
CdkIacProjectStack.ClusterName = my-fargate-cluster
CdkIacProjectStack.VpcId = vpc-0123456789abcdef0

3. AWSコンソールでALBを確認します
   • EC2ダッシュボードを開き、左メニューから「ロードバランサ―」を選択
   • 「CdkIac-MyAlb-XXXXXXXXXXXX」という名前のALBが作成されていることを確認
   • ALBの「リスナーとルール」タブをクリックし、リスナー（HTTP:80）とターゲットグループが設定されていることを確認

const certificate = acm.Certificate.fromCertificateArn(
  this,
  'Certificate',
  'arn:aws:acm:us-east-1:123456789012:certificate/xxxxx'
);
 
alb.addListener('HttpsListener', {
  port: 443,
  protocol: elbv2.ApplicationProtocol.HTTPS,
  certificates: [certificate],
  defaultAction: elbv2.ListenerAction.forward([targetGroup]),
});

3. セキュリティグループとIAMロールの設定

ECSタスク用のセキュリティグループとIAMロールを作成します。

3-1. ECSタスク用セキュリティグループの作成

1. lib/cdk-iac-project-stack.ts に、ECSタスク用のセキュリティグループを追加します

    // ... 省略（前述のコード） ...
 
    // ALB用のセキュリティグループを作成（省略）
    const albSecurityGroup = new ec2.SecurityGroup(this, 'AlbSecurityGroup', {
      // ... 省略 ...
    });
 
    // ECSタスク用のセキュリティグループを作成
    const ecsSecurityGroup = new ec2.SecurityGroup(this, 'EcsSecurityGroup', {
      vpc: vpc,
      description: 'Security group for ECS tasks',
      allowAllOutbound: true, // 外部へのアクセスを許可（APIコールやパッケージダウンロードに必要）
    });
 
    // ALBからのアクセスのみ許可
    ecsSecurityGroup.addIngressRule(
      albSecurityGroup,
      ec2.Port.tcp(80),
      'Allow traffic from ALB'
    );
 
    // ... 省略（以降のコード） ...

3-2. IAMロールの作成

1. lib/cdk-iac-project-stack.ts に、ECSタスク実行ロールとタスクロールを追加します

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as ecs from 'aws-cdk-lib/aws-ecs';
import * as elbv2 from 'aws-cdk-lib/aws-elasticloadbalancingv2';
import * as iam from 'aws-cdk-lib/aws-iam';
 
export class CdkIacProjectStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);
        // ... 省略 ...
        
    // ALBリスナーの作成（HTTP ポート80）
    const listener = alb.addListener('HttpListener', {
        // ... 省略 ...
    });
 
    // ECSタスク実行ロールの作成
    const taskExecutionRole = new iam.Role(this, 'TaskExecutionRole', {
      assumedBy: new iam.ServicePrincipal('ecs-tasks.amazonaws.com'),
      managedPolicies: [
        iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AmazonECSTaskExecutionRolePolicy'),
      ],
    });
 
    // ECSタスクロールの作成（アプリケーションがAWSサービスにアクセスするための権限）
    const taskRole = new iam.Role(this, 'TaskRole', {
      assumedBy: new iam.ServicePrincipal('ecs-tasks.amazonaws.com'),
    });
 
    // タスクロールにS3読み取り権限を追加（例）
    taskRole.addToPolicy(
      new iam.PolicyStatement({
        effect: iam.Effect.ALLOW,
        actions: ['s3:GetObject', 's3:ListBucket'],
        resources: ['*'],
      })
    );
 
    // ALBのDNS名を出力
    new cdk.CfnOutput(this, 'AlbDnsName', {
      // ... 省略（以降のコード） ...

3-3. セキュリティグループとIAMロールのデプロイ

1. 変更内容を確認します

cdk diff --region us-east-1

2. デプロイします

cdk deploy --region us-east-1

3. AWSコンソールでセキュリティグループとIAMロールを確認します
   • VPCダッシュボードの「セキュリティグループ」でECS用セキュリティグループを確認
   • IAMダッシュボードの「ロール」の検索欄に「TaskExecutionRole」または「TaskRole」と入力して、タスク実行ロールとタスクロールが存在することを確認

このステップで何をしたのか

このステップでは、ECS on FargateクラスターとApplication Load Balancerを構築しました。具体的には、Fargateで動作するECSクラスター、外部からのHTTPリクエストを受け付けるALB、ターゲットグループとヘルスチェック設定、セキュリティグループによるネットワークアクセス制御、そしてタスク実行ロールとタスクロールによる権限管理を行いました。

このインフラでどのような影響があるのか

この構成により、コンテナアプリケーションを動かすための「実行基盤」と「ロードバランサー」が完成しました。ECSクラスターにより、サーバーレスにコンテナを実行できる環境が整い、ALBにより、外部からのトラフィックを受け付け、複数のコンテナに負荷を分散できるようになりました。

これは、物理的な店舗で言えば、「商品を並べる棚（ECSクラスター）」と「お客様を案内する受付カウンター（ALB）」が完成した状態です。次のステップでは、実際のコンテナアプリケーション（Next.js）を作成し、このECS環境にデプロイして、ブラウザからアクセスできるようにします。

技術比較まとめ表

学習において重要な技術的違い

1. サーバーレスコンテナ実行環境の違い

• AWS：ECS Fargateで、EC2インスタンスの管理が不要。コンテナのCPU・メモリを指定するだけで自動的にリソースが割り当てられる
• オンプレミス：Kubernetesのノード（サーバー）を手動で構築・管理する必要がある。OS更新、セキュリティパッチ、ノードのスケーリングをすべて自社で実施

2. ロードバランサーの管理とスケーリング

• AWS：ALBはマネージドサービスで、トラフィック量に応じて自動的にスケーリング。障害時の自動復旧、SSL/TLS終端、ヘルスチェック機能を標準搭載
• オンプレミス：NginxやHAProxyを手動で構築し、冗長化設定（KeepAlived等）、スケーリング設定、SSL証明書管理をすべて自社で実施

3. ネットワークセキュリティの柔軟性

• AWS：セキュリティグループはソフトウェア定義のファイアウォールで、CDKコードで管理可能。変更は即座に反映され、ロールバックも容易
• オンプレミス：ハードウェアファイアウォールやiptablesの設定変更には、ネットワーク機器へのログイン、設定ファイルの編集、テスト、適用という手順が必要。変更に数時間〜数日かかる

4. 権限管理とセキュリティ

• AWS：IAMロールで一時認証情報を使用し、アクセスキーをコードに埋め込む必要がない。ロールの権限変更は即座に反映され、CloudTrailで監査ログを記録
• オンプレミス：APIキーやアクセストークンを環境変数や設定ファイルで管理する必要があり、キー漏洩のリスクが高い。ローテーションは手動で実施

実践チェック：CDKコードと実行結果で証明しよう

下記のチェック項目について、実際にCDKコードを記述し、cdk deploy で構築できていることを確認し、各項目ごとに該当画面のスクリーンショットを撮影して提出してください。

• ECSクラスターのCDKコードが正しく記述され、my-fargate-cluster という名前のクラスターが作成されている

• Container Insightsが有効化されており、CloudWatchでECSメトリクスを確認できる

• ALB用のセキュリティグループが作成され、インターネット（0.0.0.0/0）からのHTTP（ポート80）が許可されている

• Application Load Balancerが作成され、パブリックサブネットに配置されている

• ALBのDNS名（xxx.elb.amazonaws.com）が cdk deploy の出力に表示されている

• ターゲットグループが作成され、ヘルスチェックパス /api/health、間隔30秒が設定されている

• ALBリスナー（HTTP:80）が作成され、ターゲットグループにトラフィックを転送する設定になっている

• ECSタスク用のセキュリティグループが作成され、ALBからのHTTP（ポート80）のみが許可されている

• タスク実行ロールが作成され、AmazonECSTaskExecutionRolePolicy マネージドポリシーがアタッチされている

• タスクロールが作成され、S3読み取り権限（例として追加）が設定されている

提出方法： 各項目ごとにスクリーンショットを撮影し、まとめて提出してください。 ファイル名やコメントで「どの項目か」が分かるようにしてください。 CDKコードのスクリーンショットでは、ECS、ALB、セキュリティグループ、IAMロールの部分が見えるようにしてください。

構成図による理解度チェック

ステップ1の構成図に、このステップで作成したリソースを追記して、現在のインフラ構成を完成させましょう。

なぜ構成図を更新するのか？

ステップ2では、VPCの上にECSクラスター、ALB、セキュリティグループ、IAMロールという多くのリソースを追加しました。これらのリソースがどのように連携し、トラフィックがどのように流れるのかを視覚的に理解することが重要です。

構成図を更新することで、「外部からのHTTPリクエストがALBに到達し、ALBがターゲットグループを通じてECSタスクに転送する」という一連の流れを確認できます。また、「セキュリティグループがALBとECSタスクの間のアクセスを制御している」という関係性も明確になります。

• トラフィックフローの理解: 外部 → ALB → ターゲットグループ → ECSタスクという流れを視覚化する
• セキュリティ境界の理解: セキュリティグループがどのように通信を制御しているかを確認する
• リソース間の関係性: ECSクラスター、ALB、ターゲットグループ、IAMロールがどのように連携しているかを理解する

構成図の書き方

ステップ1で作成した構成図をベースに、以下のリソースを追記してみましょう。

1. ECSクラスター: VPC内のプライベートサブネットに配置（まだタスクは配置されていないので、クラスターのアイコンのみ）
2. Application Load Balancer: VPC内のパブリックサブネットに配置
3. ターゲットグループ: ALBとECSタスクの間に配置（ステップ3でタスクを追加するため、現時点では空）
4. セキュリティグループ: ALB用とECS用のセキュリティグループをそれぞれ表示し、通信経路を矢印で示す
5. 通信経路: インターネット → IGW → ALB → ターゲットグループ → ECSタスク（次ステップで追加）

💡 ヒント: セキュリティグループは、ファイアウォールのアイコンで表現し、許可されている通信のポート番号（80）を記載すると分かりやすいです。IAMロールは、鍵のアイコンで表現し、タスク実行ロールとタスクロールを区別して記載しましょう。

理解度チェック：なぜ？を考えてみよう

AWSの各リソースや設計には、必ず”理由”や”目的”があります。 下記の「なぜ？」という問いに自分なりの言葉で答えてみましょう。 仕組みや設計意図を自分で説明できることが、真の理解につながります。 ぜひ、単なる暗記ではなく「なぜそうなっているのか？」を意識して考えてみてください。

Q. ECS on FargateとECS on EC2の違いは何ですか？どのような場合にFargateを選び、どのような場合にEC2を選ぶべきですか？

Q. ALBのヘルスチェックで、healthyThresholdCount: 2 と unhealthyThresholdCount: 3 を設定した理由は何ですか？これらの値を変更すると、どのような影響がありますか？

Q. セキュリティグループで、ECSタスク用セキュリティグループのインバウンドルールに「ALBからのアクセスのみ許可」と設定しました。なぜ「すべてのIPアドレス（0.0.0.0/0）からのアクセスを許可」としないのですか？

Q. タスク実行ロールとタスクロールの2つのIAMロールを分けている理由は何ですか？1つのロールにまとめてはいけないのですか？

Q. ALBを internetFacing: true でインターネット向けに公開し、パブリックサブネットに配置しました。一方、ECSタスクはプライベートサブネットに配置します（次ステップ）。なぜこのような構成にするのですか？

今回のステップで利用したAWSサービス名一覧

• Amazon ECS：Dockerコンテナを大規模に実行・管理するフルマネージドなオーケストレーションサービス
• AWS Fargate：サーバーレスなコンテナ実行環境、EC2インスタンス管理が不要
• Application Load Balancer：レイヤー7のロードバランサー、HTTP/HTTPSトラフィックに最適化
• セキュリティグループ：ステートフルな仮想ファイアウォール、インバウンド・アウトバウンドルールで通信を制御
• IAMロール：AWSリソースがAWSサービスにアクセスするための権限、一時認証情報を使用
• CloudWatch Container Insights：ECSクラスターとタスクのメトリクスを可視化する監視機能