AWS CDK v2.219.0 リリース解説

概要

AWS CDK v2.219.0 では、ECS Managed Instances Capacity Provider の新しい L2 コンストラクト、CodeBuild Fleet における VPC とカスタムインスタンスタイプのサポート、およびオーバーフロー動作の設定機能が追加されました。また、Service Catalog の L1 リソースに破壊的変更が含まれています。

新機能

ECS: Managed Instances Capacity Provider の L2 コンストラクト

#35648

ECS で新たに提供される Managed Instances Capacity Provider の L2 コンストラクトが追加されました。この機能により、GPU、アクセラレーテッドコンピューティング、特定の CPU 命令セット、大量の vCPU など、特定のコンピューティング能力を必要とするワークロードを、完全にマネージドなインフラストラクチャとセキュリティパッチの自動適用というサーバーレスのメリットを維持しながら実行できます。

主な特徴

• 特定のインスタンスタイプの指定: GPU やアクセラレーテッドコンピューティング向けのインスタンスタイプを指定可能
• インスタンス要件によるフレキシブルな構成: vCPU、メモリ、アーキテクチャなどの属性ベースで最適なインスタンスを自動選択
• EC2 機能へのアクセス: Reserved Instances (RI) や On-Demand Capacity Reservations (ODCR) を活用可能
• 完全マネージド: インフラストラクチャの管理とセキュリティパッチが自動化

新しいプロパティとコンストラクト

ManagedInstancesCapacityProvider コンストラクト:

• cluster: 関連付ける ECS クラスター
• capacityProviderName: Capacity Provider の名前（オプション）
• infrastructureRole: インフラストラクチャ管理用の IAM ロール（オプション、自動生成可能）
• managedScaling: マネージドスケーリングの設定
• instanceType: 使用する EC2 インスタンスタイプ
• instanceRequirements: インスタンス要件（instanceType の代わりに使用可能）

InstanceRequirements インターフェース:

• vCpuCount: vCPU 数の範囲（min/max）
• memoryGiB: メモリサイズの範囲（min/max）
• cpuArchitectures: CPU アーキテクチャ（x86_64、ARM64 など）
• acceleratorTypes: アクセラレータータイプ（GPU、FPGA など）
• その他、詳細なインスタンス属性を指定可能

コード例: 特定のインスタンスタイプを使用

import * as ecs from 'aws-cdk-lib/aws-ecs';
import * as ec2 from 'aws-cdk-lib/aws-ec2';

const vpc = new ec2.Vpc(this, 'Vpc');

// ECS クラスターの作成
const cluster = new ecs.Cluster(this, 'Cluster', {
  vpc,
});

// Managed Instances Capacity Provider の作成（特定のインスタンスタイプを指定）
const capacityProvider = new ecs.ManagedInstancesCapacityProvider(
  this,
  'ManagedInstancesCapacityProvider',
  {
    cluster,
    capacityProviderName: 'my-managed-instances-provider',

    // 特定のインスタンスタイプを指定（GPU インスタンスなど）
    instanceType: ec2.InstanceType.of(
      ec2.InstanceClass.P3,
      ec2.InstanceSize.XLARGE2,
    ),

    // マネージドスケーリングの設定
    managedScaling: {
      targetCapacityPercent: 80,        // ターゲット容量の使用率: 80%
      minimumScalingStepSize: 1,        // 最小スケーリングステップ: 1 インスタンス
      maximumScalingStepSize: 10,       // 最大スケーリングステップ: 10 インスタンス
    },
  },
);

// クラスターに Capacity Provider を追加
cluster.addManagedInstancesCapacityProvider(capacityProvider);

// タスク定義の作成
const taskDefinition = new ecs.TaskDefinition(this, 'TaskDef', {
  compatibility: ecs.Compatibility.EC2,
  cpu: '2048',
  memoryMiB: '4096',
});

taskDefinition.addContainer('app', {
  image: ecs.ContainerImage.fromRegistry('my-gpu-app:latest'),
  memoryLimitMiB: 4096,
  // GPU を使用するコンテナ設定
  gpuCount: 1,
});

// サービスの作成（Capacity Provider を使用）
const service = new ecs.Ec2Service(this, 'Service', {
  cluster,
  taskDefinition,
  capacityProviderStrategies: [
    {
      capacityProvider: capacityProvider.capacityProviderName,
      weight: 1,
      base: 1,
    },
  ],
});

コード例: インスタンス要件による柔軟な構成

import * as ecs from 'aws-cdk-lib/aws-ecs';
import * as ec2 from 'aws-cdk-lib/aws-ec2';

// Managed Instances Capacity Provider の作成（インスタンス要件を指定）
const capacityProvider = new ecs.ManagedInstancesCapacityProvider(
  this,
  'FlexibleCapacityProvider',
  {
    cluster,
    capacityProviderName: 'flexible-provider',

    // インスタンス要件による柔軟な指定
    instanceRequirements: {
      // vCPU 数: 4〜16
      vCpuCount: {
        min: 4,
        max: 16,
      },

      // メモリ: 8〜32 GiB
      memoryGiB: {
        min: 8,
        max: 32,
      },

      // CPU アーキテクチャ: ARM64 を優先
      cpuArchitectures: [
        ec2.CpuArchitecture.ARM64,
        ec2.CpuArchitecture.X86_64,
      ],

      // アクセラレータータイプ: GPU が必要
      acceleratorTypes: [ec2.AcceleratorType.GPU],

      // インスタンス世代: 現行世代のみを使用
      instanceGenerations: [ec2.InstanceGeneration.CURRENT],
    },

    managedScaling: {
      targetCapacityPercent: 100,
      minimumScalingStepSize: 1,
      maximumScalingStepSize: 5,
    },
  },
);

重要なポイント

1. インフラストラクチャロールの自動生成: infrastructureRole を指定しない場合、必要な IAM ロールが自動的に生成されます
2. Reserved Instances の活用: EC2 の RI や ODCR を活用してコスト最適化が可能
3. インスタンスタイプと要件の選択: instanceType または instanceRequirements のいずれかを指定します（両方は指定不可）

CodeBuild: Fleet へのカスタムインスタンスタイプと VPC サポート

#34572

CodeBuild Fleet で特定の EC2 インスタンスタイプの指定と VPC の構成が可能になりました。これにより、ビルド環境をより詳細にカスタマイズできます。

主な変更点

FleetComputeType enum への追加:

• CUSTOM_INSTANCE_TYPE: カスタムインスタンスタイプを使用

ComputeConfiguration への追加プロパティ:

• instanceType: 使用する EC2 インスタンスタイプ

Fleet への VPC サポート:

• vpc: VPC の設定
• securityGroups: セキュリティグループの設定
• role: VPC ネットワークインターフェースをプロビジョニングするための IAM ロール（自動生成可能）

コード例: カスタムインスタンスタイプの使用

import * as codebuild from 'aws-cdk-lib/aws-codebuild';
import * as ec2 from 'aws-cdk-lib/aws-ec2';

// カスタムインスタンスタイプを使用する Fleet の作成
const fleet = new codebuild.Fleet(this, 'Fleet', {
  fleetName: 'my-custom-fleet',

  // カスタムインスタンスタイプを指定
  computeType: codebuild.FleetComputeType.CUSTOM_INSTANCE_TYPE,

  computeConfiguration: {
    // 特定の EC2 インスタンスタイプを指定
    instanceType: ec2.InstanceType.of(
      ec2.InstanceClass.C6I,         // Compute Optimized 第6世代 Intel
      ec2.InstanceSize.XLARGE8,
    ),
    // ディスクサイズ: 100 GB
    disk: 100,
  },

  // 基本容量: 2 インスタンス
  baseCapacity: 2,

  // 環境設定
  environmentType: codebuild.EnvironmentType.LINUX_CONTAINER,
});

// Fleet を使用するプロジェクトの作成
const project = new codebuild.Project(this, 'Project', {
  fleet,
  source: codebuild.Source.gitHub({
    owner: 'myorg',
    repo: 'myrepo',
  }),
  buildSpec: codebuild.BuildSpec.fromObject({
    version: '0.2',
    phases: {
      build: {
        commands: ['npm run build'],
      },
    },
  }),
});

コード例: VPC 内での Fleet の構成

import * as codebuild from 'aws-cdk-lib/aws-codebuild';
import * as ec2 from 'aws-cdk-lib/aws-ec2';

const vpc = new ec2.Vpc(this, 'Vpc');

// セキュリティグループの作成
const securityGroup = new ec2.SecurityGroup(this, 'FleetSecurityGroup', {
  vpc,
  description: 'Security group for CodeBuild Fleet',
  allowAllOutbound: true,
});

// VPC 内で動作する Fleet の作成
const fleet = new codebuild.Fleet(this, 'VpcFleet', {
  fleetName: 'vpc-fleet',

  computeType: codebuild.FleetComputeType.CUSTOM_INSTANCE_TYPE,
  computeConfiguration: {
    instanceType: ec2.InstanceType.of(
      ec2.InstanceClass.M5,
      ec2.InstanceSize.LARGE,
    ),
    disk: 50,
  },

  // VPC の設定
  vpc,
  securityGroups: [securityGroup],

  baseCapacity: 1,
  environmentType: codebuild.EnvironmentType.LINUX_CONTAINER,
});

重要な注意事項

• Fleet で VPC を設定した場合、Project 側の VPC 設定は CloudFormation により無効になります
• VPC を使用する場合、必要な IAM 権限が Fleet の IAM ロールに自動的に付与されます

CodeBuild: Fleet のオーバーフロー動作の設定

#35480

CodeBuild Fleet のオーバーフロー動作を設定できるようになりました。これにより、Fleet の容量を超えるビルドリクエストが発生した場合の動作を制御できます。

主な変更点

FleetOverflowBehavior enum の追加:

• QUEUE: リクエストをキューに入れて待機（デフォルト）
• ON_DEMAND: オンデマンドでビルドを実行

FleetProps への追加プロパティ:

• overflowBehavior: オーバーフロー時の動作を指定

コード例: オーバーフロー動作の設定

import * as codebuild from 'aws-cdk-lib/aws-codebuild';

// オーバーフロー時にキューイングする Fleet（デフォルト動作）
const queueingFleet = new codebuild.Fleet(this, 'QueueingFleet', {
  fleetName: 'queueing-fleet',
  computeType: codebuild.FleetComputeType.SMALL,
  baseCapacity: 2,

  // オーバーフロー時はキューに入れる
  overflowBehavior: codebuild.FleetOverflowBehavior.QUEUE,

  environmentType: codebuild.EnvironmentType.LINUX_CONTAINER,
});

// オーバーフロー時にオンデマンドで実行する Fleet
const onDemandFleet = new codebuild.Fleet(this, 'OnDemandFleet', {
  fleetName: 'on-demand-fleet',
  computeType: codebuild.FleetComputeType.MEDIUM,
  baseCapacity: 1,

  // オーバーフロー時はオンデマンドで実行
  overflowBehavior: codebuild.FleetOverflowBehavior.ON_DEMAND,

  environmentType: codebuild.EnvironmentType.LINUX_CONTAINER,
});

使用例: ハイブリッド戦略

// ベースキャパシティは小さく、オーバーフロー時はオンデマンドでスケール
const hybridFleet = new codebuild.Fleet(this, 'HybridFleet', {
  fleetName: 'hybrid-fleet',
  computeType: codebuild.FleetComputeType.LARGE,

  // 通常時は 1 インスタンスで運用
  baseCapacity: 1,

  // ピーク時はオンデマンドで対応
  overflowBehavior: codebuild.FleetOverflowBehavior.ON_DEMAND,

  environmentType: codebuild.EnvironmentType.LINUX_CONTAINER,
});

// この Fleet を使用するプロジェクト
const project = new codebuild.Project(this, 'HybridProject', {
  fleet: hybridFleet,
  source: codebuild.Source.gitHub({
    owner: 'myorg',
    repo: 'myrepo',
  }),
  buildSpec: codebuild.BuildSpec.fromObject({
    version: '0.2',
    phases: {
      build: {
        commands: ['npm ci', 'npm test', 'npm run build'],
      },
    },
  }),
});

使い分けのガイドライン

• QUEUE（キューイング）:

  • コスト最適化を重視する場合
  • ビルドのレイテンシーが許容できる場合
  • 安定したワークロード

• ON_DEMAND（オンデマンド）:

  • ビルド時間を最小化したい場合
  • 不規則なピークがある場合
  • CI/CD のスピードが重要な場合

バグ修正

CloudFront: EdgeFunction のスタックタグ伝播の修正

#35518

CloudFront の EdgeFunction がスタックタグを正しく伝播しない問題が修正されました。これにより、組織のポリシーでスタックタグの設定が必須となっている場合でも、EdgeFunction の作成に使用されるネストされたスタックに親スタックのタグが正しく継承されるようになりました。

修正内容

• EdgeFunction が作成するネストされたスタック（Lambda@Edge を us-east-1 にデプロイするためのスタック）に、親スタックのタグが自動的に伝播されるようになりました

影響範囲

この修正により、以下のような環境での EdgeFunction の使用が可能になります：

• AWS Organizations のポリシーでスタックタグの設定が必須となっている環境
• CloudFormation の ChangeSet 作成にスタックタグが要求される環境

コード例

import * as cloudfront from 'aws-cdk-lib/aws-cloudfront';
import * as origins from 'aws-cdk-lib/aws-cloudfront-origins';
import { Tags } from 'aws-cdk-lib';

// スタックにタグを設定
Tags.of(this).add('Environment', 'Production');
Tags.of(this).add('Department', 'Engineering');

// EdgeFunction の作成（タグは自動的に伝播されます）
const edgeFunction = new cloudfront.experimental.EdgeFunction(
  this,
  'EdgeFunction',
  {
    runtime: lambda.Runtime.NODEJS_20_X,
    handler: 'index.handler',
    code: lambda.Code.fromAsset('lambda'),
  },
);

// Distribution の作成
const distribution = new cloudfront.Distribution(this, 'Distribution', {
  defaultBehavior: {
    origin: new origins.HttpOrigin('example.com'),
    edgeLambdas: [
      {
        functionVersion: edgeFunction.currentVersion,
        eventType: cloudfront.LambdaEdgeEventType.VIEWER_REQUEST,
      },
    ],
  },
});

破壊的変更

AWS Service Catalog: L1 リソースのプロパティ変更

#35646

L1 リソースは CloudFormation Resource Schemas から自動生成されており、実際の CloudFormation の状態を忠実に反映するように構築されています。今回のリリースでは、以下の変更が含まれています：

変更内容

AWS::ServiceCatalog::PortfolioPrincipalAssociation:

• PortfolioId プロパティが必須になりました
• PrincipalARN プロパティが必須になりました

AWS::ServiceCatalog::PortfolioProductAssociation:

• Id 属性が削除されました

影響範囲

これらの変更は、Service Catalog の L1 リソース（CfnPortfolioPrincipalAssociation および CfnPortfolioProductAssociation）を直接使用しているコードに影響します。L2 コンストラクトを使用している場合は影響を受けません。

移行ガイド

// Before (v2.218.0 以前)
const association = new servicecatalog.CfnPortfolioPrincipalAssociation(
  this,
  'Association',
  {
    // PortfolioId と PrincipalARN が省略可能だった
  },
);

// After (v2.219.0 以降)
const association = new servicecatalog.CfnPortfolioPrincipalAssociation(
  this,
  'Association',
  {
    // 必須プロパティとして明示的に指定
    portfolioId: 'port-1234567890abc',
    principalArn: 'arn:aws:iam::123456789012:role/MyRole',
    principalType: 'IAM',
  },
);

Alpha モジュール

v2.219.0-alpha.0 では、特に記載すべき変更はありません。

まとめ

AWS CDK v2.219.0 では、ECS Managed Instances の新しい L2 コンストラクト、CodeBuild Fleet の VPC およびカスタムインスタンスタイプのサポート、オーバーフロー動作の制御機能など、コンテナワークロードとビルド環境の柔軟性を大幅に向上させる機能が追加されました。

特に ECS Managed Instances は、GPU やアクセラレーテッドコンピューティングを必要とする特殊なワークロードを、完全マネージドな環境で実行できるため、機械学習やデータ処理などのユースケースにおいて大きな価値を提供します。CodeBuild Fleet の機能強化により、ビルド環境のカスタマイズ性とコスト最適化の選択肢が増えました。

Service Catalog の破壊的変更については、L1 リソースを直接使用している場合は必要なプロパティを明示的に指定するように更新してください。