概要
AWS CDK v2.246.0では、Amazon BedrockのFoundation ModelにMiniMaxおよび**GLM(Zhipu AI)**のモデル識別子が追加されました。また、DynamoDBのgrant*メソッドで未対応のサービスプリンシパルが指定された場合に早期エラーを発生させるバリデーションが導入され、Windows環境のNode.js 22+でlambda-nodejsのローカルバンドルが失敗する問題も修正されています。加えて、v2.245.0で導入されたプロパティ変更のスタックトレース機能は、過剰な非推奨警告を引き起こしていたためリバートされました。
新機能
Bedrock: MiniMax / GLM Foundation Model 識別子の追加 (#37348)
FoundationModelIdentifierクラスに、Amazon Bedrockで利用可能になったMiniMaxおよびZhipu AI(GLM)モデルの識別子が追加されました。これまでListFoundationModels APIでは返ってくるものの、CDKには定数が定義されていなかったモデルIDが対応された形です。
追加された識別子:
| モデルID | 定数 |
|---|---|
minimax.minimax-m2 | MINIMAX_MINIMAX_M2 |
minimax.minimax-m2.1 | MINIMAX_MINIMAX_M2_1 |
minimax.minimax-m2.5 | MINIMAX_MINIMAX_M2_5 |
zai.glm-4.7 | ZAI_GLM_4_7 |
zai.glm-4.7-flash | ZAI_GLM_4_7_FLASH |
zai.glm-5 | ZAI_GLM_5 |
使用例:
import * as bedrock from 'aws-cdk-lib/aws-bedrock';
// MiniMax M2.5 モデルを参照
const minimaxModel = bedrock.FoundationModel.fromFoundationModelId(
this,
'MiniMaxModel',
bedrock.FoundationModelIdentifier.MINIMAX_MINIMAX_M2_5, // minimax.minimax-m2.5
);
// GLM-5 モデルを参照
const glmModel = bedrock.FoundationModel.fromFoundationModelId(
this,
'GlmModel',
bedrock.FoundationModelIdentifier.ZAI_GLM_5, // zai.glm-5
);
// GLM-4.7 Flash(高速版)
const glmFlashModel = bedrock.FoundationModel.fromFoundationModelId(
this,
'GlmFlashModel',
bedrock.FoundationModelIdentifier.ZAI_GLM_4_7_FLASH, // zai.glm-4.7-flash
);
この変更は純粋に定数の追加のみであり、既存コードへの影響はありません。
バグ修正
DynamoDB: サポートされていないサービスプリンシパルで早期エラー (#37335)
table.grant*(new ServicePrincipal(...))を呼び出した際、未対応のサービスプリンシパルがDynamoDBリソースベースポリシーに書き込まれ、CloudFormationデプロイ時に"Invalid policy document: Policy contains invalid service principal"で失敗する問題が修正されました。
背景:
v2.222.0以降、#35554(addToResourcePolicyの実動作化)と#35817(grantフレームワークによるDynamoDBリソースポリシーの自動検知)の組み合わせにより、以前は無視されていたServicePrincipal宛のgrantがリソースポリシーに反映されるようになっていました。しかしDynamoDBのリソースポリシーは、ごく一部のサービスプリンシパルしか受け付けないため、多くの場合で無効なテンプレートが生成されていました。
DynamoDBがサポートする既知のサービスプリンシパル:
| サービスプリンシパル | 用途 |
|---|---|
redshift.amazonaws.com | Redshift zero-ETL統合 |
replication.dynamodb.amazonaws.com | マルチアカウントのグローバルテーブル |
glue.amazonaws.com | SageMaker Lakehouse zero-ETL(AWS Glue経由) |
修正内容:
Table / TableV2のgrant, grantReadData, grantWriteData, grantReadWriteData, grantFullAccessにおいて、grantee が未対応のServicePrincipalだった場合、synth時点でValidationErrorを投げるようになりました。許可リストに含まれるサービスプリンシパルは従来通り透過的に動作します。
修正後の正しい使い方:
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
import * as iam from 'aws-cdk-lib/aws-iam';
const table = new dynamodb.TableV2(this, 'Table', {
partitionKey: { name: 'pk', type: dynamodb.AttributeType.STRING },
});
// OK: 許可リストに含まれるサービスプリンシパル
table.grantReadData(new iam.ServicePrincipal('redshift.amazonaws.com'));
table.grantReadWriteData(new iam.ServicePrincipal('replication.dynamodb.amazonaws.com'));
table.grantFullAccess(new iam.ServicePrincipal('glue.amazonaws.com'));
// NG: 未対応のサービスプリンシパル → synth時にValidationErrorが発生
// table.grantReadData(new iam.ServicePrincipal('lambda.amazonaws.com'));
Lambda等の任意サービスに権限を付与したい場合:
Lambda関数やECSタスクのようなAWSサービスに対してDynamoDBアクセスを与えたい場合は、本来そのサービスの**実行ロール(IAMロール)**に対してgrantするのが正しい使い方です。リソースポリシーに書き込みたい特殊なケースでは、addToResourcePolicyを直接使ってください。
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as iam from 'aws-cdk-lib/aws-iam';
// ✅ 推奨: Lambda関数の実行ロールにgrant(アイデンティティベースのポリシー)
const fn = new lambda.Function(this, 'Fn', {
runtime: lambda.Runtime.NODEJS_20_X,
handler: 'index.handler',
code: lambda.Code.fromInline('exports.handler = async () => {};'),
});
table.grantReadWriteData(fn); // 内部的にfn.roleに権限が付与される
// ✅ どうしてもリソースポリシーに記述が必要な場合
table.addToResourcePolicy(new iam.PolicyStatement({
actions: ['dynamodb:GetItem'],
principals: [new iam.ServicePrincipal('custom.amazonaws.com')],
resources: ['*'],
}));
lambda-nodejs: Windows環境でspawnステップがpowershell経由で実行される (#37412)
v2.245.0で導入されたspawnSyncベースのローカルバンドリング(9bf4263)が、Windows + Node 22+環境でEINVALエラーを引き起こしていた問題が修正されました。
原因:
Node.js 22以降、WindowsのspawnSyncは.cmdシム(npx.cmdなど)を直接spawn経路で解決できなくなっており、EINVALで失敗します。
修正内容:
win32環境でのspawnステップを、powershell.exe -NoProfile -Command経由でルーティングするように変更されました。シェルステップ(cmd /c)の挙動は変更されていません。
影響範囲:
Windows環境でNodejsFunctionのローカルバンドリング(Dockerを使わないバンドル)を利用している場合、このリリースにアップグレードするだけでEINVALエラーが解消します。コードの変更は不要です。
import * as nodejs from 'aws-cdk-lib/aws-lambda-nodejs';
import * as lambda from 'aws-cdk-lib/aws-lambda';
// Windows + Node 22+ でもローカルバンドリングが動作する
const fn = new nodejs.NodejsFunction(this, 'Fn', {
runtime: lambda.Runtime.NODEJS_20_X,
entry: 'src/handler.ts',
// bundling を指定しなければローカルバンドリングが優先される
bundling: {
minify: true, // 最小化を有効化
sourceMap: true, // ソースマップを生成
target: 'node20', // バンドル対象のNode.jsバージョン
forceDockerBundling: false, // false(デフォルト)だとローカルbundling
},
});
core: プロパティ非推奨警告のノイズを抑制(#37285 のリバート) (#37415)
v2.245.0で導入された「L1コンストラクトのプロパティ変更に対するソーストレース付与」機能(#37285)が、非推奨プロパティに関する警告を過剰に出力していた問題に対応し、この機能ごとリバートされました。
背景:
#37285は、L1コンストラクトのプロパティ変更にスタックトレースを紐づけて、どこからプロパティが書き換えられたのかを追跡できるようにする改善でした。しかし、L1の非推奨プロパティを内部的に触るだけでも警告が出るケースが多発し、実用を阻害していました(#37407)。
影響:
- v2.245.0で「プロパティ変更のソーストレース」機能に依存していたコードは、v2.246.0では動作しません。
- ただし、この機能は内部的なデバッグ補助であり、通常のCDKアプリケーション利用では影響ありません。
- 非推奨警告のノイズはv2.246.0で解消されます。
関連ファイル: packages/aws-cdk-lib/core/lib/stack-trace.ts、tools/@aws-cdk/spec2cdk/lib/cdk/resource-class.tsほか。
Alphaモジュール (2.246.0-alpha.0)
このリリースのAlphaモジュールには、リリースノート上で特筆すべき独立した変更はありません。Alphaモジュールはaws-cdk-libと同じバージョニングで配布されているため、上記の安定版の修正・新機能の恩恵は2.246.0-alpha.0のAlphaパッケージにも反映されます。
まとめ
AWS CDK v2.246.0は、Bedrockの新モデル対応と複数のバグ修正を中心としたリリースです。
主なポイント:
- Bedrock新モデル: MiniMax(M2, M2.1, M2.5)とZhipu AI GLM(4.7, 4.7-flash, 5)の6つのFoundation Model識別子が追加。
- DynamoDBの安全性向上: 未対応のサービスプリンシパル宛
grant*呼び出しはsynth時にValidationErrorで失敗。対応プリンシパルはredshift/replication.dynamodb/glueの3種。 - Windows + Node 22+対応: lambda-nodejsのローカルバンドリングがpowershell経由に変更され、
EINVALエラーが解消。 - プロパティ非推奨警告のノイズ抑制: v2.245.0のソーストレース機能(#37285)をリバートし、非推奨警告の過剰発生を解消。
アップグレード時の注意:
- DynamoDBテーブルに対し
new ServicePrincipal('lambda.amazonaws.com')等をgranteeとして渡しているコードは、synth時に失敗するようになります。Lambda等に権限を付けたい場合は、その関数自体(実行ロール)をgrant*の引数に渡してください。 - v2.245.0で追加されたL1プロパティ変更のスタックトレース機能に依存していた場合は動作しなくなります。通常利用では影響ありません。