今回の内容

AWS Step Functions（以下「Step Functions」）のファイル処理系Mapアクション（CSV/JSONファイルなど）における、「同時実行数」関連の設定項目について調べてみました

概要

こんにちは。

Step Functionsで（S3バケットなどにある）、下図のようなCSVやJSONファイルを処理するワークフローを書くことがあるかもしれません（Step Functionsのテンプレートにもあるくらいですし）

その際、各アクションに「同時実行数」に関して、以下の設定項目が用意されています。

親アクション（File Analysys）

• バッチあたりの最大項目数
• 同時実行の制限

子アクション（Map）

• 同時実行数の制限を設定

これらについて、詳細と実際の挙動が良くわからなかったので、調べてみました。

親アクション

バッチあたりの最大項目数

これは、「1回の処理（=子アクションにデータを渡す処理）につき、CSVやJSONファイルから何個のデータを取得するか」を意味します。

例えば、100個のデータがあるCSVファイルについて、「バッチあたりの最大項目数」を10に設定した場合、「子アクションにデータを渡す処理」は10回発生することになります。

なおこの「子アクションにデータを渡す」処理は、ワークフロー全体で1回に処理できるデータ個数（後述）を満たすまで、ずっと続けられます。

同時実行の制限

これは、子アクション（上図で言えば「Map」内の処理）を何個同時に実行するか、を指します。
言い換えれば「子アクションを何並列で実行するか」となります。

例えば「バッチあたりの最大項目数」を5に設定した場合、Map内の処理を5並列同時に実行します。

重要なのは、「ワークフロー全体で1回に処理できるデータ個数 = バッチあたりの最大項目数 * 同時実行の制限」 という事です。

なので先ほどの100個のデータがあるCSVファイルについて、

• 「バッチあたりの最大項目数」を10に設定
• 「同時実行の制限」を5に設定

した場合（※1）、ワークフロー全体で1回に処理できるデータ個数は10 * 5 = 50個となりますので、ワークフロー全体を2回実行することで全データ処理を完了できます。

子アクション

同時実行数の制限を設定

これは親アクションの「同時実行の制限」と同じで、孫アクション（=上図で言うLambda実行）を何個同時に実行するか（=何並列で実行するか）になります。

例えば親アクションで（※1）を設定した状態で「同時実行数の制限を設定」を2に設定した場合、10個のデータを2個並列実行で処理するので、各孫アクションにおいて、Lambda実行は5回実行されます。

なお注意点として、ここでの「同時実行数の制限を設定」の値は「ワークフロー全体で1回に処理できるデータ個数」には影響しません。

※親アクションの「バッチあたりの最大項目数」を超える値は設定できないので。例えば「バッチあたりの最大項目数」を10の状態で「同時実行数の制限を設定」を1にしようが10にしようが、ワークフロー全体で1度に処理できる個数は10個で変わりません。

図解

上記を図でまとめると、下図の通りになります。

まとめ

以上、Step Functionsのファイル処理系Mapアクションにおける「同時実行数」の設定項目についての詳細と挙動でした。

自分が業務で触っていてちょっとややこしかった部分だったので、自分の理解の復習もかねて、このブログを書きました。

もし他の方でもこの辺がややこしい、と思っている方がいらっしゃったら、その方にとって参考になれば幸いです。

では、今回はこの辺で

はじめに

皆さん、あけましておめでとうございます。（もう2月ですが...）
今年もよろしくお願い致します。

先日、今年初の活動として、1/24（土）に群馬県高崎市で開催された「JAWS-UG 北陸新幹線 #5 in 群馬」にて、Lambda Durable Functionsについて発表しました。

https://jawsug-gunma.connpass.com/event/373298/jawsug-gunma.connpass.com

※発表資料はこちら
speakerdeck.com

ただこの発表では実装、特にAWS CDKについて触れられなかったので、この記事で「AWS CDKでLambda Durable Functionsを作成する方法」を紹介したいと思います。

参考サイト

• durableConfig(AWS CDKリファレンス)
• Lambda durable functions(AWS公式サイト)
• aws-durable-execution-sdk-js-examples(Durable execution SDKリポジトリより)

やること

• AWS CDK（aws-cdk-lib）のバージョンアップ＆@aws/durable-execution-sdkのインストール
• CDKのコードを書く
• 動作確認

AWS CDK（aws-cdk-lib）のバージョンアップ＆@aws/durable-execution-sdkのインストール

Lambda Durable Functionsの作成にはAWS CDKのバージョン2.232以上が必要なので、必要に応じてバージョンアップをしてください。

またLambda Durable Functionのソース作成では「@aws/durable-execution-sdk」が必要なので、上記「参考サイト」のLambda durable functions(AWS公式サイト)を参考にインストールを行ってください。（TypeScriptとPythonがあります）

CDKのコードを書く

Lambda Durable Functionsについては、AWS CDKに専用のコンストラクタがあるわけではなく、Lambdaコンストラクタに専用のpropsを設定する形になります。

詳細は下のソースコードをベースに説明します。 （必要な定義のみ記載）

// import文は省略しています
// 1．ロールを作成する
const durableRole = new Role(this, 'DurableFunctionRole', {
  assumedBy: new ServicePrincipal('lambda.amazonaws.com'),
  managedPolicies: [
    ManagedPolicy.fromAwsManagedPolicyName(
      'service-role/AWSLambdaBasicDurableExecutionRolePolicy'
    ),
  ],
});
  
// 2.Lambda Durable Functionsを作成
// aws_lambda.FunctionコンストラクタでもOKです
const durableFunc = new NodejsFunction(this, 'DurableFunction', {
  entry: path.resolve(__dirname, '../lambda/durable.ts'),
  runtime: Runtime.NODEJS_24_X,
  timeout: cdk.Duration.seconds(30),  
  // これが重要！
  durableConfig: {
    executionTimeout: cdk.Duration.minutes(15),
    retentionPeriod: cdk.Duration.days(1),
  },
  role: durableRole,
});
  
// 3. エイリアスの作成
const durableFuncAlias = durableFunc.addAlias("latest");

1．ロールを作成する

Lambda Durable Functionsの実行には、下記アクションの実行権限が必要になります。

• lambda:CheckpointDurableExecution
• lambda:GetDurableExecutionState

これはAWS管理ポリシー「AWSLambdaBasicDurableExecutionRolePolicy」で設定されているので、このポリシーをアタッチしたロールを作成しておきます。

※なお、この「AWSLambdaBasicDurableExecutionRolePolicy」ポリシーには「AWSLambdaBasicExecutionRole」ポリシーの設定も含まれています

2. Lambda Durable Functionsを作成

先述の通り、CDKにはLambda Durable Functions専用のコンストラクタはありません。

ポイントは durableConfig propsで、この定義があるLambda関数はLambda Durable Functionsとして認識されます。

この durableConfig で設定する項目は以下2項目です。（最後の「Q&A」で補足説明をしています）

項目	説明	必須or任意	設定範囲
executionTimeout	Lambda Durable Functionsで作成したワークフローを実行できる最大期間（=ワークフローの生存期間）	必須	1～31,622,400秒(=366日)
retentionPeriod	チェックポイントなどの情報を保存可能な期間	任意	1～90日（デフォルト14日）

durableConfig の注意点は、以下2つです。

• 該当Lambda関数の新規作成時に設定する必要があります。
  • 一度作成した（デプロイした）Lambda関数に後から「durableConfig」を追加しても、Lambda Durable Functionsとはなりません。
• 逆に、一度作成したLambda Durable Functionsの定義から「durableConfig」を削除しても、通常のLambda関数になるわけではありません。
  • その場合「Construct IDが同じ別のLambda関数が定義された」という扱いになり、デプロイエラーになります。
  • 上記対策として「Construct IDを変える」「一度Lambda Durable Functionsを削除する」などが必要です。（前者の場合、元のLambda Durable Functionsは手作業で削除が必要）

また実際のLambda Durable Functionsのソースコードですが、下記AWS公式サイトの「2. Paste the following code into the index.mjs tab, replacing the code that Lambda created」に記載のコードをそのままコピペします。

docs.aws.amazon.com

その後 const orderId = event.orderId; のevent.orderId の箇所に、何か適当なorderIdの値を決め打ちで設定しておきます。

3. エイリアスの作成

Lambda Durable Functionsの実行には「修飾ARN」（バージョン番号付きのARN）が必須となるため、エイリアス(=最新バージョンのエイリアス)を必ず作成しておきます。

なお「修飾ARN」については、最後の「Q&A」で説明します。

動作確認

ここまで来たら、cdk deploy などでデプロイを実施します。

正常にデプロイ出来たら、マネジメントコンソールで該当のLambda Durable Functionsを開き「イベント名」に適当な名前を入れてテストを実行します。

※ durableConfig.executionTimeout を15分より大きい値に設定した場合、非同期実行しかできません

何もなければ、正常終了するはずです。

これでAWS CDKでのLambda Durable Functionsの作成が完了しました。お疲れさまでした。

Q&A

timeoutとexecutionTimeoutの違いは？

それぞれ、下記のとおりです。

項目	説明	最大値
timeout	（Lambda Durable Functionsの）Lambda関数自体の1回あたりの最大実行時間	15分
executionTimeout	Lambda Durable Functionsで作成したワークフローを実行できる最大期間	366日（≒1年）

注意すべき点として、Lambda Durable Functionsの「最長1年」というのは「waitなどによる実行→中断→再開→中断→再開...を繰り返しながらワークフローを完了させられる期間」（=ワークフローが存在できる期間）が最長1年という事です。

よく「Lambda単体の実行時間が1年になった」と勘違いされますが「Lambda単体の実行時間」は今まで通り最長15分のままです。

retentionPeriodの最大が3か月だけど、ワークフローの実行は最長1年じゃないの？

ワークフローの実行自体は最長1年ですが、各チェックポイントの情報を保存できる期間は（retentionPeriodの）「最長3か月」になります。

これについては「3か月以上も放置されるワークフローなら、むしろ一度リセットして最初からやり直した方が良い」という事かもしれません。（あるいはチェックポイントの情報の保存にかかるコストを加味しての挙動かも）

「修飾ARN」と「非修飾ARN」って何？

「3. エイリアスの作成」で触れた「修飾ARN」について、ARNには「修飾ARN」と「非修飾ARN」の2つがあり、それぞれ以下の通りです。

項目	説明	例
修飾ARN	末尾にバージョン番号やエイリアスなどが付いたARN	arn:aws:lambda:us-east-1:123456789012:function:hogehogefunction:10
被修飾ARN	末尾にバージョン番号やエイリアスなどが付かないARN	arn:aws:lambda:us-east-1:123456789012:function:hogehogefunction

一般的に「ARN」としてよく利用されるのは「非修飾ARN」ですが、Lambda Durable Functionsの実行には「修飾ARN」での指定が必須となります。

ただ、Lambda関数を変更するたびに変わるバージョン番号を毎回設定するのは面倒なので、エイリアスを作成して毎回最新バージョンが指定されるようにしています。

ちなみに、被修飾ARNでLambda Durable Functionsを実行しようとすると「You cannot invoke a durable function using an unqualified ARN」というエラーが発生します。

また通常のLambdaトリガ起動の設定（API Gateway, S3, Lambda関数URLなど）をCDKに設定した際も、デプロイ時にこのエラーが出ます。

この対策については、次回のブログで記載予定です。

まとめ

以上、AWS CDKでLambda Durable Functionsを作成する方法でした。

今回色々書きましたが、正直AWS CDKでLambda Durable Functionsを作成すること自体はそこまで難しくないと思います。（むしろ難しいのはソースコードの方）

なので、これを機会にまだLambda Durable Functionsに触れたことがない方は、ぜひLambda Durable Functionsに触れてみてはいかがでしょうか？

宣伝

今週2/16（月）～ 2/20（金）のお昼に、弊社（KDDIアジャイル開発センター）にて「KAG AI WEEK」というオンラインイベントを5日連続で開催します。

https://kddi-agile.connpass.com/event/384248/kddi-agile.connpass.com

私も4日目の2/19（木）に「ブログを手書きするのが大変だから、音声AIツール『Wispr Flow』を使って音声入力させてみた話」というタイトルでお話しさせていただきますので、よろしくお願いいたします。（なおタイトルからもわかる通り、AI技術にdeep diveするような内容ではありません）

では、今回はこの辺で。

はじめに

※この記事はAWS CDK Advent Calendar 2025 10日目の記事です。

qiita.com

皆さん、Workflow Studio 使ってますか？

AWS Step Functions（以下「Step Functions」）のワークフローをGUIで編集できる、めちゃくちゃ便利なツールです。

VS Codeの「AWS Toolkit」拡張機能をインストールすれば、ローカルのVS Code上でも実行できるので、ますますStep Functionsのワークフロー作成が便利になりました。

ただ、Workflow StudioとCDKを一緒に使う場合、下記の点が問題になります。

1. Workflow StudioからCDKの値（プロパティなど）を参照できない
   • Workflow StudioとCDKは連動しているわけではない
2. Workflow StudioにCDKの動的な値（例えばCDKで作成したS3バケットのARNなど）は設定できない
   • あくまで動的な値が作成されるのはデプロイ後なので

しかしWorkflow Studioを使用していると「Workflow StudioのプロパティにCDKの動的な値を設定したい」というケースが出てきます。

今回はその「Workflow StudioのプロパティにCDKの動的な値を設定する方法」についてお話しします。

前提

Workflow Studioのワークフローファイルの拡張子は*.asl.json, *.asl.yaml, *.asl.yml の3つがありますが、この記事では *.asl.json で統一します。（他の拡張子でも記載内容はそのまま適用できます）

例えばどういうケース？

ワークフローからWeb APIリクエストを行う際に使用する「Call HTTPS APIs」アクションでは「接続ARN」として、Web APIリクエストで使用するEventBridge ConnectionのARNを指定する必要があります。*1

このEventBridge ConnectionをCDKで定義している場合、「接続ARN」にこのEventBridge ConnectionのARN（connectionArn）を設定したいのですが、先述の理由でそれができません。

ただ、これができないと

1. 一度「接続ARN」にダミーの値を設定してデプロイする
2. デプロイ後、マネジメントコンソールからEventBridge ConnectionのARNを確認する
3. 2で確認したEventBridge ConnectionのARNを「接続ARN」に設定して再度デプロイする

という3ステップが必要になり面倒なので*2、これを解決する方法はないか...というのが今回の本題になります。

解決方法

この問題の解決方法は、以下の2つです。（他にもあるかもしれませんが）

1. *.asl.json ファイルの内容をデプロイ時に置換する
2. JSONataで実行時の入力文字列を取得するようにする

1. *.asl.jsonファイルの内容をデプロイ時に置換する

Workflow Studioのワークフローの実態は *.asl.json というjsonファイルです。
つまり、このjsonファイルの内容をデプロイ時に動的に書き換えてしまえばよいわけです。

具体的には、このようなソースを記載します。（なおこの時、「接続ARN」にダミーの決め打ち値を設定しておきます）

import fs from "node:fs";  
import path from "node:path";  
import { StateMachine, DefinitionBody } from "aws-cdk-lib/aws-stepfunctions";  
import { Connection, Authorization } from "aws-cdk-lib/aws-events";  
  
// EventBridge Connectionを作成    
const connection = new Connection(this, 'Connection', {
  authorization: Authorization.apiKey(...),
});
  
// *.asl.jsonファイルを読み込み、内容を置換。
// CONNECTION_DUMMY_ARNには先ほど「接続ARN」に設定したダミーの決め打ち値を定義しておく
const stateMachineDefinition = fs
      .readFileSync(path.resolve(__dirname, "./asl/example.asl.json"), "utf8")
      .replaceAll(CONNECTION_DUMMY_ARN, connection.connectionArn);
  
// ステートマシンを定義する。
// この時definitionBodyを「DefinitionBody.fromString」とし、引数に
// 置換後の*.asl.jsonファイルの文字列を設定する。
const stateMachine = new StateMachine(this, 'StateMachine', {
      definitionBody: DefinitionBody.fromString(stateMachineDefinition),
      ...(以下略)
});

ポイントは DefinitionBody.fromString() で、これを使用する事で definitionBody の値を文字列で指定することが可能です。（大抵の定義では DefinitionBody.fromFile() で*.asl.json ファイルを読み込むことがほとんどですが）

2. JSONataで実行時の入力文字列を取得するようにする

これは使用ケースが限定されますが、「接続ARN」の値をJSONataで設定しておき、EventBridge ConnectionのARNをステートマシン実行時に受け取るように設定する...というものです。

例えばAPI Gateway経由でステートマシンを実行する場合は、以下になります。

1 「接続ARN」の値を {% $states.input.connectionArn %}と設定する

2 AwsIntegration などIntegration系クラスのリクエストテンプレート(requestTemplates)に、下記のように設定する

// import文は省略
const stateMachineIntegration = new AwsIntegration({
  service: "states",
  action: "StartExecution",
  integrationHttpMethod: "POST",
  options: {
    requestTemplates: {
      // API Gatewayにリクエストが送られたときにEventBridge ConnectionのARNをinput.connectionArnとしてStep Functionsに渡す
      "application/json": `{
        "input": `$util.escapeJavaScript({'connectionArn' : ${connection.connectionArn}})`,
        "stateMachineArn": "${stateMachineStandard.stateMachineArn}"
      }`,
    },
  }
});

ただし先述の通り、この方法は「使用ケースが限定的」「設定が少々複雑（リクエストテンプレートを設定する、など）」などの点があるため、個人的には「1. *.asl.jsonファイルの内容をデプロイ時に置換する」の方法が良いと思います。

まとめ

以上「Workflow StudioのプロパティにCDKの値を動的に設定する」方法でした。

正直、1の方法も最初は微妙かな...と思ったのですが*3、いろいろ調べた結果、現在はこの方法が一番のようです。（AWSのSAさんにも確認しました）

なおこの話に関しては、2025/11/21（金）開催の JAWS-UG CDK支部#23 札幌でもCDKしたいっしょ でも発表しておりますので、もしよろしければそちらの登壇資料も併せてご確認ください。

speakerdeck.com

では、今回はこの辺で。

今回のお話

8月にとある大型本番リリース作業があったためとても多忙で、ずいぶん間が空いてしまいました。すいません。

前々回および前回の記事で、AWS CDK Toolkit Libraryの基本、および「CDK CLIで行っていたあの機能、AWS CDK Toolkit Libraryではどうやるの？」という事を書きました。

最終回となる今回は、エラーハンドリング、そしてちょっと高度な「IIoHost」について紹介しようと思います。

※AWS CDK Toolkit LibraryのAWS公式サイトはこちら。 aws.amazon.com

エラーハンドリング

CDK Toolkit Libraryには、ToolkitError クラスにあらかじめエラーハンドリング用のヘルパー関数が用意されており、 容易にエラーハンドリング処理を実装できます。

具体的には以下の通りです。（すべてstatic関数です）*1

ヘルパー関数	説明	備考
isToolkitError(error)	CDK Toolkitライブラリのエラーかどうかを判定する	以下エラーの親クラス
isAuthenticationError(error)	クレデンシャル違いなど、認証に関するエラーかどうかを判定する
isAssemblyError(error)	CDKの定義間違いなので発生したエラーかどうかを判定する。
isContextProviderError(error)	ContextProvider(≒cintext)に起因するエラーかどうか判定する	ContextProviderは、synth時のcdk.context.json出力などに関係するクラス。
withCause(message, error)	errorをcause（エラーの根本原因）としてオリジナルエラーをToolkitErrorとして返す	これはエラー種類の判定ではない

下記がサンプルコードになります（一部AWS公式サイトより）
下記サンプルコードの通り、ToolkitErrorは、コンストラクタなどから自分で生成することもできます。

ちなみにCDK Toolkit Libraryのエラーは、エラータイプのinstanceofチェックに頼らず、ヘルパー関数を使用する事がAWS公式より案内されています。

import { ToolkitError } from '@aws-cdk/toolkit-lib';
  
try {
  // なんか処理
  await toolkit.deploy(cloudAssemblySource, {
    stacks: { strategy: StackSelectionStrategy.ALL_STACKS }
  });
  
} catch (error) {
  if (ToolkitError.isAuthenticationError(error)) {
    // 認証エラー（クレデンシャル不一致など）
    console.error('Authentication failed. Check your AWS credentials.');
  
  } else if (ToolkitError.isAssemblyError(error)) {
    // CDKの定義が違う
    console.error('CDK app error:', error.message);
  
  } else if (ToolkitError.isToolkitError(error)) {
    // context周りでエラー
    console.error('CDK Toolkit error:', error.message);
  
  } else if (ToolkitError.isToolkitError(error)) {
    // 上記に該当しないToolkitErrorのエラー
    console.error('CDK Toolkit error:', error.message);
    
    // withCauseで、cause付きのToolkitErrorを取得する
    throw ToolkitError.withCause(error.message, error);
    
  } else {
    // ToolkitErrorではない、予期しないエラー
    console.error('Unexpected error:', error);
    
    // こんな感じで、ToolkitErrorエラーの作成もできる
    throw new ToolkitError('予期しないエラー', 'unknown', error)
  }
}

IIoHostによるメッセージとインタラクション

CDK Toolkit Libraryではオペレーションを実行時、下記「メッセージ」および「リクエスト」という2つの主要なメカニズムを介して通信します。

• メッセージ：オペレーションの実行状況などを通知する。（例：「デプロイの進行中」など）
• リクエスト：ユーザーからの入力または確認が必要な決定ポイントで、これらを確認する機会を提供する。（例：「このスタックをデプロイしていいですか？」など）

これらを構成するのに必要なのが IIoHost インターフェースです

IIoHostインターフェースについて

IIoHost インターフェースは、以下2つの構成で成り立っています。

• notify：上記「メッセージ」を処理します。
• requestResponse：上記「リクエスト」を処理します。

ソースコードでは、下記の内容になっています。

import type { IoMessage, IoRequest } from './io-message';
export interface IIoHost {
    notify(msg: IoMessage<unknown>): Promise<void>;
    requestResponse<T>(msg: IoRequest<unknown, T>): Promise<T>;
}

またCDK Toolkit Libraryのコンストラクタでは、以下のようにIIoHostを定義します。

const toolkit = new Toolkit({
  ioHost: {
    notify: async function (msg) {...(なんか処理)},
    requestResponse: async function (msg) {...(なんか処理)},
  }
});

notifyについて

notify には、IoMessage 型の引数msg の内容に応じたメッセージ処理を記載します。

AWS公式のサンプルでは下記のように msg.level に応じたログを出力する処理が記載されており、アプリのログ出力とも似通った分かりやすい内容となっています。

notify: async function (msg) {
  // notify関数の例
    switch (msg.level) {
      case 'error':
        console.error(`[${msg.time}] ERROR: ${msg.message}`);
        break;
      case 'warning':
        console.warn(`[${msg.time}] WARNING: ${msg.message}`);
        break;
      case 'info':
        console.info(`[${msg.time}] INFO: ${msg.message}`);
        break;
      case 'debug':
        console.debug(`[${msg.time}] DEBUG: ${msg.message}`);
        break;
      case 'trace':
        console.debug(`[${msg.time}] TRACE: ${msg.message}`);
        break;
      default:
        console.log(`[${msg.time}] ${msg.level}: ${msg.message}`);
      }
    },

ちなみにmsgにはlevelの他にも、以下のようなプロパティがあります。

プロパティ	説明	備考
time	日時情報（Date型）
action	実行した処理(deploy, synth, listなど)
code	メッセージコード
message	メッセージ本文
span	メッセージスパン	同じ操作に意味的に関連した複数メッセージのグループ。それ以外では無意味
data	メッセージに添付されたデータ

requestResponseについて

requestResponse は、ユーザーからの入力または確認が必要な場合に送信されるリクエストに対する挙動（=レスポンス処理）を記載します。

なおこのrequestResponse は、CDK Toolkit Library において非常に重要です。

なぜならCDK Toolkit Libraryでは、このような処理に対する初期値が「何も確認しない」になっているからです。（CDK CLIで言えば、--require-approval の 初期値が never になっているのと同じ）

そのため、例えば toolkit.destroy（=スタックの削除）のような危険な処理もユーザーに確認することなく、ダイレクトで実行されてしまいます。

そこで、これを防ぐために requestResponse でちゃんと確認するように設定する必要があります。

サンプルとしては以下です。（AWS公式より）

requestResponse: async (msg) => {

  // （例）本番だけは何も確認しない場合        
  if (environment === 'production') {
    console.log(`Auto-approving for production: ${msg.message}`);
      // msg.defaultResponseは「デフォルトの挙動を行う（=何も確認しない）」ための専用のプロパティ
      return msg.defaultResponse;
  }
  
    // 何かしら確認のためのプロンプトなどを出す処理を行う
    // ちなみに引数のmsgは、defaultResponseプロパティを持つ事以外notifyのmsgと同じです。 
    return showPromptForApproval(msg.message);
}

なおこのIIoHost ですが、下記のいずれかの方法で定義できます。

• Toolkit コンストラクタに notify や requestResponse を直で定義する
• NonInteractiveIoHost クラスを継承したカスタムクラスを自分で定義し、それをToolkit コンストラクタのIIoHostに設定する

ちなみに後者を使用すると「変更する必要がある動作のみをカスタマイズしながら、既存の実装を活用できる」というメリットがあります。

これはAWS公式にサンプルコードがありますので、そちらを参照ください。

まとめ

以上、AWS CDK Toolkit LibraryのエラーハンドリングとIIoHostについての設定についてでした。

今日の内容、特にIIoHostのRequestResponse はちょっと難しい内容かもしれませんが、RequestResponse は非常に重要な設定なので、必ず最初に設定しておいた方が良いと思います。

ちなみに今回RequestResponseの部分について説明が駆け足になってしまいましたが、詳しく知りたい方は、山梨 蓮さん（X：@ren_yamanashi）がブログで非常に詳しく説明してくれていますので、ぜひそちらもご参照ください。

zenn.dev

最後に

9/12（金）に大阪で開催される「JAWS-UG CDK支部#22 大阪でもCDKしたいねん」にて、LTをさせていただきます。

jawsug-cdk.connpass.com

内容としては、前回＆今回ブログで書いたような「CDK CLIでできてたあの機能、CDK Toolkit Libraryではどうやるの？」という内容になると思います。

また10/11（土）に金沢で開催される「JAWS Festa 2025」において、ありがたいことにCFPが採用され、登壇させていただくことになりました。

jawsfesta2025.jaws-ug.jp

正式なタイトルは、公式ページをお楽しみください。

それでは、今回はこの辺で。