概要
AWS CDK v2.202.0 では、Lambda の Kafka イベントソースにおけるスキーマレジストリのサポート、CDK Pipelines の手動承認ステップの強化、EKS の Kubernetes 1.33 サポート、KMS Alias の grant メソッド実装など、多くの新機能とバグ修正が含まれています。Alpha モジュールでは、Amplify の Compute Role サポートとモノレポ構造でのカスタムレスポンスヘッダーのサポートが追加されました。
新機能
Lambda: Kafka イベントソースのスキーマレジストリサポート
Lambda 関数が MSK(Amazon Managed Streaming for Apache Kafka)または自己管理型 Kafka からイベントを読み取る際に、スキーマレジストリを使用してイベントをデシリアライズおよび検証できるようになりました。Confluent レジストリ、自己管理型レジストリ、または AWS Glue レジストリを使用できます。
重要: この機能を使用するには、イベントソースマッピングが Provisioned モード(provisionedPollerConfig を設定)である必要があります。
主要なプロパティ
schemaRegistryConfig: スキーマレジストリの設定schemaRegistryUri: スキーマレジストリの URIeventRecordFormat: イベントレコードのフォーマット(JSON、Avro など)accessConfigs: レジストリへのアクセス設定(Basic 認証など)schemaValidationConfigs: スキーマ検証の設定(KEY または VALUE を検証)
コード例
import * as lambda from 'aws-cdk-lib/aws-lambda';
import { ManagedKafkaEventSource } from 'aws-cdk-lib/aws-lambda-event-sources';
const myFunction = new lambda.Function(this, 'MyFunction', {
runtime: lambda.Runtime.NODEJS_20_X,
handler: 'index.handler',
code: lambda.Code.fromAsset('lambda'),
});
// MSK イベントソースにスキーマレジストリを設定
myFunction.addEventSource(new ManagedKafkaEventSource({
clusterArn: 'arn:aws:kafka:us-east-1:123456789012:cluster/my-cluster',
topic: 'my-topic',
startingPosition: lambda.StartingPosition.TRIM_HORIZON,
// Provisioned モードの設定(必須)
provisionedPollerConfig: {
minimumPollers: 1, // 最小ポーラー数
maximumPollers: 3, // 最大ポーラー数
},
// スキーマレジストリの設定
schemaRegistryConfig: {
schemaRegistryUri: 'https://my-schema-registry.example.com', // レジストリの URI
eventRecordFormat: lambda.EventRecordFormat.JSON, // イベントフォーマット
accessConfigs: [
{
type: lambda.SchemaRegistryAccessConfigType.BASIC_AUTH, // 認証タイプ
uri: 'https://my-schema-registry.example.com', // 認証エンドポイント
},
],
schemaValidationConfigs: [
{ attribute: lambda.SchemaValidationAttribute.KEY }, // KEY 属性を検証
],
},
}));
Glue レジストリの使用例
import * as glue from 'aws-cdk-lib/aws-glue';
import { GlueSchemaRegistry } from 'aws-cdk-lib/aws-lambda-event-sources';
const glueRegistry = new glue.CfnRegistry(this, 'MyRegistry', {
name: 'my-glue-registry',
});
myFunction.addEventSource(new ManagedKafkaEventSource({
clusterArn: 'arn:aws:kafka:us-east-1:123456789012:cluster/my-cluster',
topic: 'my-topic',
startingPosition: lambda.StartingPosition.TRIM_HORIZON,
provisionedPollerConfig: {
minimumPollers: 1,
maximumPollers: 3,
},
schemaRegistryConfig: new GlueSchemaRegistry({
registryArn: glueRegistry.attrArn, // Glue レジストリの ARN
eventRecordFormat: lambda.EventRecordFormat.AVRO, // Avro フォーマット
schemaValidationConfigs: [
{ attribute: lambda.SchemaValidationAttribute.VALUE }, // VALUE 属性を検証
],
}),
}));
IAM 権限: Glue レジストリを使用する場合、Lambda 関数の実行ロールに以下の権限が自動的に追加されます:
glue:GetRegistryglue:GetSchemaVersionglue:GetSchema
詳細: #34746
CDK Pipelines: 手動承認ステップの強化
CDK Pipelines の手動承認ステップに、外部リンク(URL)と SNS トピックを追加できるようになりました。これにより、承認者に追加のコンテキスト情報を提供したり、カスタムの通知システムを統合したりすることができます。
主要なプロパティ
externalEntityLink: 承認者に表示する外部リンク(例: Jira チケット、diff レビューページ)notificationTopic: 承認が必要な際に通知を送信する SNS トピック
コード例
import * as pipelines from 'aws-cdk-lib/pipelines';
import * as sns from 'aws-cdk-lib/aws-sns';
const notificationTopic = new sns.Topic(this, 'ApprovalTopic', {
displayName: 'Pipeline Approval Notifications',
});
const pipeline = new pipelines.CodePipeline(this, 'Pipeline', {
synth: new pipelines.ShellStep('Synth', {
input: pipelines.CodePipelineSource.gitHub('myorg/myrepo', 'main'),
commands: ['npm ci', 'npm run build', 'npx cdk synth'],
}),
});
pipeline.addStage(
new MyApplicationStage(this, 'Production'),
{
pre: [
new pipelines.ManualApprovalStep('ApproveProduction', {
comment: 'Please review the changes before deploying to production',
// 外部リンクを追加(例: CDK Diff の結果)
externalEntityLink: 'https://example.com/review/diff-12345',
// SNS トピックで通知
notificationTopic: notificationTopic,
}),
],
}
);
この機能により、承認者は CodePipeline コンソールで外部リンクをクリックして詳細な変更内容を確認でき、SNS 経由でチームに通知を送信できます。
詳細: #34654
EKS: Kubernetes 1.33 サポート
Amazon EKS で Kubernetes バージョン 1.33 がサポートされました。新しいクラスターを作成する際に KubernetesVersion.V1_33 を指定できます。
コード例
import * as eks from 'aws-cdk-lib/aws-eks';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import { KubectlV33Layer } from '@aws-cdk/lambda-layer-kubectl-v33';
const vpc = new ec2.Vpc(this, 'MyVpc', { natGateways: 1 });
const cluster = new eks.Cluster(this, 'MyCluster', {
vpc,
version: eks.KubernetesVersion.V1_33, // Kubernetes 1.33 を指定
kubectlLayer: new KubectlV33Layer(this, 'KubectlLayer'), // kubectl レイヤーも v1.33 用を使用
defaultCapacity: 0,
});
// AL2023 のノードグループを追加
cluster.addNodegroupCapacity('Nodegroup', {
amiType: eks.NodegroupAmiType.AL2023_X86_64_STANDARD, // AL2023 AMI を使用
instanceTypes: [new ec2.InstanceType('t3.medium')],
minSize: 2,
maxSize: 4,
});
重要: Kubernetes 1.33 を使用する場合は、対応する kubectl Lambda レイヤー(@aws-cdk/lambda-layer-kubectl-v33)も使用する必要があります。
詳細: #34602
KMS: Alias.fromAliasName の grant メソッド実装(フィーチャーフラグ配下)
Alias.fromAliasName() でインポートした KMS キーエイリアスに対して、.grant*() メソッドが使用できるようになりました。これにより、クロススタックで KMS キーエイリアスを共有し、他のスタックで IAM 権限を自動的に付与できます。
この機能はフィーチャーフラグ @aws-cdk/aws-kms:aliasNameRefEnablesGrantMethods で制御されます。
主な利点
- KMS キー ID の代わりにエイリアス名を使用してクロススタック参照が可能
- S3 バケット、SNS トピック、SQS キューなどの L2 コンストラクトと統合時に自動的に権限付与
- CodePipeline などのサービスで、インポートされた KMS エイリアスを使用する際の権限設定が自動化
コード例
import * as kms from 'aws-cdk-lib/aws-kms';
import * as iam from 'aws-cdk-lib/aws-iam';
// 別のスタックで作成された KMS キーをエイリアス名でインポート
const importedKey = kms.Alias.fromAliasName(
this,
'ImportedKey',
'alias/my-key-alias'
);
// IAM ロールに対して暗号化・復号化の権限を付与
const role = new iam.Role(this, 'MyRole', {
assumedBy: new iam.ServicePrincipal('lambda.amazonaws.com'),
});
importedKey.grantEncryptDecrypt(role); // 権限が自動的に付与される
生成される IAM ポリシー:
{
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:Encrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:ResourceAliases": "alias/my-key-alias"
}
}
}
S3 バケットとの統合例
import * as s3 from 'aws-cdk-lib/aws-s3';
import * as codepipeline from 'aws-cdk-lib/aws-codepipeline';
const importedKey = kms.Alias.fromAliasName(
this,
'ImportedKey',
'alias/pipeline-key'
);
// KMS エイリアスで暗号化された S3 バケット
const artifactBucket = s3.Bucket.fromBucketAttributes(this, 'ArtifactBucket', {
bucketName: 'my-pipeline-artifacts',
encryptionKey: importedKey,
});
// CodePipeline が自動的に KMS 権限を取得
const pipeline = new codepipeline.Pipeline(this, 'Pipeline', {
artifactBucket: artifactBucket, // grant メソッドが自動的に呼び出される
});
有効化方法: cdk.json に以下を追加:
{
"context": {
"@aws-cdk/aws-kms:aliasNameRefEnablesGrantMethods": true
}
}
詳細: #34237
OpenSearch: アクセスポリシーのカスタムリソースログの改善
OpenSearch ドメインのアクセスポリシーを管理するカスタムリソースのログ出力が改善され、必要な情報のみがログに記録されるようになりました。これにより、CloudWatch Logs のコストを削減し、ログの可読性が向上します。
詳細: #34701
リファクタリングの例外: Lambda Version と API Gateway Deployment
Lambda の Version リソースと API Gateway の Deployment リソースは、CDK のリファクタリング機能から除外されるようになりました。これらのリソースは不変であり、変更が検出されると新しいバージョンが作成されるため、リファクタリングの対象から除外することで、意図しないリソースの再作成を防ぎます。
詳細: #34710
Alpha モジュール
Amplify: ブランチレベルの Compute Role サポート
Amplify のブランチに対して Compute Role を設定できるようになりました。これにより、ブランチごとに異なる IAM ロールを使用してビルドを実行できます。
コード例
import * as amplify from '@aws-cdk/aws-amplify-alpha';
import * as iam from 'aws-cdk-lib/aws-iam';
const app = new amplify.App(this, 'MyApp', {
sourceCodeProvider: new amplify.GitHubSourceCodeProvider({
owner: 'myorg',
repository: 'myrepo',
oauthToken: SecretValue.secretsManager('github-token'),
}),
});
// ブランチ用の Compute Role を作成
const computeRole = new iam.Role(this, 'BranchComputeRole', {
assumedBy: new iam.ServicePrincipal('amplify.amazonaws.com'),
description: 'Compute role for Amplify branch',
});
// ブランチに Compute Role を設定
const mainBranch = app.addBranch('main', {
stage: 'PRODUCTION',
computeRole: computeRole, // ブランチレベルで Compute Role を指定
});
詳細: #34708
Amplify: モノレポ構造でのカスタムレスポンスヘッダーサポート
Amplify アプリのモノレポ構造において、カスタムレスポンスヘッダーを設定できるようになりました。appRoot プロパティを使用して、ビルドスペックの appRoot に対応する出力 YAML を生成します。
コード例
import * as amplify from '@aws-cdk/aws-amplify-alpha';
const app = new amplify.App(this, 'MyMonorepoApp', {
sourceCodeProvider: new amplify.GitHubSourceCodeProvider({
owner: 'myorg',
repository: 'myrepo',
oauthToken: SecretValue.secretsManager('github-token'),
}),
// モノレポ構造のカスタムレスポンスヘッダー
customResponseHeaders: [
{
pattern: '**/*',
headers: {
'Strict-Transport-Security': 'max-age=31536000; includeSubDomains', // HSTS ヘッダー
'X-Frame-Options': 'DENY', // クリックジャッキング対策
'X-Content-Type-Options': 'nosniff', // MIME タイプスニッフィング防止
},
appRoot: 'apps/frontend', // モノレポの appRoot を指定
},
{
pattern: '/api/*',
headers: {
'Access-Control-Allow-Origin': 'https://example.com', // CORS 設定
'Access-Control-Allow-Methods': 'GET, POST, OPTIONS',
},
appRoot: 'apps/backend', // 別の appRoot
},
],
});
従来のアプリとの互換性: appRoot を省略すると、従来の単一アプリケーション形式の YAML が生成されます。
詳細: #31771
バグ修正
core: tree.json の分割で多数のファイルが生成される問題を修正
tree.json を分割する際に、過度に多くのファイルが生成される問題が修正されました。これにより、大規模なスタックでのデプロイパフォーマンスが向上します。
詳細: #34718
pipelines: publishAssetsInParallel=false 時の Asset アクションの表示名を修正
CDK Pipelines で publishAssetsInParallel が false の場合、Asset アクションに表示名が正しく設定されるようになりました。これにより、CodePipeline コンソールでアセット公開アクションの識別が容易になります。
詳細: #34049
route53: エイリアスレコードに TTL が指定された場合の警告を追加
Route 53 で、エイリアスターゲットを持つレコードセットに TTL が指定された場合、警告が表示されるようになりました。エイリアスレコードでは TTL は無視されるため、設定ミスを早期に検出できます。
詳細: #34526
まとめ
AWS CDK v2.202.0 は、Lambda の Kafka イベントソースの機能強化、CDK Pipelines の手動承認ステップの改善、EKS の最新 Kubernetes バージョンサポートなど、開発者の生産性を向上させる多くの新機能を提供します。特に、KMS Alias の grant メソッド実装により、クロススタックでの KMS キーの共有がより簡単になり、Lambda のスキーマレジストリサポートにより、Kafka イベントの検証とデシリアライゼーションが標準化されます。
Alpha モジュールでは、Amplify の機能が強化され、ブランチレベルの Compute Role 設定やモノレポ構造でのカスタムヘッダー設定が可能になりました。これらの改善により、より柔軟で安全なクラウドアプリケーションの構築が可能になります。