Innovation Sandbox on AWSを使ってみた ~CDKデプロイ~

はじめに

先日6/25-26に幕張メッセで行われたAWS Summit Japan 2026に参加してきました。
AWSさんの展示にて『Innovation Sandbox on AWS』というソリューションの存在を知りました。
今回のサミット参加で個人的に最も気になったものだったので、さっそくこのソリューションを使ってみました。

Innovation Sandbox on AWSとは

AWS Solutions Libraryで公開されているサンドボックス環境を管理するAWSソリューションです。

既存の AWS アカウントを一時的なサンドボックスとして貸し出し、使い終わったら自動でクリーンアップして再利用する、といったことができます。

以下のような特徴があります。

• サンドボックス環境の自動セットアップ — OU・SCP・ガードレールを自動で展開し、本番環境から隔離された実験環境を作る
• 予算管理 — 支出が閾値に達したらアラート送信 → アクセス制限 → リソース削除、という段階的なアクションを自動実行
• リース（貸し出し）制御 — 利用期間または予算上限を設定し、期限切れになったらアカウントを自動クリーンアップ・再利用
• Blueprint — CloudFormation StackSets で事前構成済みインフラをサンドボックス起動時に自動デプロイ
• Web UI — リース申請・承認・モニタリングをブラウザから管理できる
• アカウントは新規作成しない — 既存アカウントのプールを使い回す設計（新規 AWS アカウントの作成・削除は行わない）

アーキテクチャ

サンドボックス環境の利用者・管理者ともにIdentity Center経由でWebサイトへログインします。利用申請等を行い、サンドボックス環境の操作はサーバーレスサービスで構成されたAPIで行う、といった構成になっています。

コスト

ドキュメント によると、利用規模に比例して下記のような価格感となります（バージニアリージョンの場合）。

規模	想定構成	月額目安
Small	50アカウント／月30リース	約$36.40
Medium	300アカウント／月150リース	約$65.25
Large	1000アカウント／月500リース	約$149.20

ソリューションを構成するAWSサービスの中でもAWSコストが突出しているのはCodeBuildです。
Small→Medium→Largeで ＄6.75→＄33.75→＄112.50と、規模拡大時のコスト増加の大半をCodeBuildが占めています。
ただ、やはりサーバーレスサービスで構成されているだけあり、小規模利用であれば安価に利用できるように思えます。

いつ頃リリースされたものか

CHANGELOG.md を見ると、2025/5/22にv1.0.0、直近では2026/6/26にv1.2.12がリリースされていました。

ざっくり要約は下記のとおりです。

バージョン	リリース時期	主なトピック
1.0.0	2025-05-22	初版リリース
1.0.1	2025-06-19	外部 IdP のグループマッピング対応、IDC サービス層の高レイテンシ修正
1.0.4	2025-08-22	CloudFront アクセスログの条件付きデプロイ、eu-central-2 リージョン対応
1.0.5	2025-10-09	WAF の SizeRestrictions_QUERYSTRING ルール無効化（大規模アカウント対応）
1.1.0	2025-10-29	リース凍結解除、コストレポートグループ、リース割り当て、テンプレート公開/非公開設定
1.2.0	2026-02-25	Blueprint 管理（CloudFormation StackSets を再利用テンプレートとして登録・管理）、JWT 署名検証によるセキュリティ強化
1.2.8	2026-05-08	IDC からユーザーが削除された場合のリース終了・凍結対応
1.2.11	2026-06-15	BudgetProgressBar の表示バグ修正（Cloudscape ProgressBar に置き換え）
1.2.12	2026-06-26	ベースイメージ・依存ライブラリのセキュリティ更新

まさに求めていたものでは？

私が関わっているAWS環境には、複数人で共有する検証用AWSアカウントはありましたが、利用終了後にクリーンアップされるようなサンドボックス環境はなく、不要リソースの削除やコスト管理の面で統制が効かせられていない状況にありました。

サミットのAWS展示で私が理解したかぎりでは、

• 専用の申請サイトがある
• 利用期間設定ができる
• コスト上限が設定できる
• 利用終了後にクリーンアップされる
• AWSが公式で出しているソリューション

ということで、これはまさに求めていたものでは？ と感じました。

ソリューションの構成を紐解いてみる

CloudFormation スタック構成

ソリューションはCloudFormationまたはCDKを通じて展開できます。
いずれの方法でも作成されるリソースやスタックは同じで、以下の5種類のスタックで構成されています。

スタック	デプロイ先	主な役割
AccountPool	管理アカウント	サンドボックスアカウントのライフサイクル管理（OU・SCP・IAM ロール）
IDC	管理アカウントまたはIdentity Center委任管理アカウント	Web UI とサンドボックスへのアクセス管理（ユーザーグループ・権限セット）
Data	Hub アカウント（どのアカウントでもOK）	ステートフルデータ保管（DynamoDB テーブル・AppConfig）
Compute	Hub アカウント（どのアカウントでもOK）	ステートレスなコンピュートリソース（API Gateway・Lambda・EventBridge・Step Functions）
SandboxAccount	各サンドボックスアカウント	アカウントクリーンアップ用スポークロール（StackSet で自動展開）

スタック間には依存関係があり、AccountPool・IDC（順不同）→ Data → Compute、の順序でデプロイする必要があります。

ドキュメント からスタックの関係図を引用します。

デプロイ手段×アカウント構成のパターン

デプロイ手段とアカウント構成のパターンを整理すると下記のようになります。前項で引用したスタック関係図と見比べるとイメージしやすいかもしれません。

デプロイ手段	アカウント構成	操作	認証情報
CloudFormation	単一アカウント(=管理アカウント)	4つのスタックを同一アカウントで順に作成（AccountPool→IDC→Data→Compute）	切り替え不要（同一アカウント）
CloudFormation	アカウント個別	4つのスタックを対象アカウントで作成（AccountPoolスタック=管理アカウント / IDCスタック=IDCアカウント / Data・Computeスタック=Hubアカウント）	アカウントごとにサインインを切り替え
CDK	単一アカウント(=管理アカウント)	npm run deploy:all で一括デプロイ	切り替え不要（同一アカウント）
CDK	アカウント個別	deploy:account-pool / deploy:idc / deploy:data / deploy:compute を個別実行	各 deploy の前に対象アカウントの認証情報へ切り替え（AWS_PROFILE 等）

Control Tower環境下での利用に関して

ドキュメントに以下のようなことが記載されています。

• ソリューションによって作成されるOUはOrganizations経由で作成され、Control Towerの管理下にない
• Control Tower管理下OUの下にぶら下げた場合、Control Tower上でドリフト状態になる（想定された動作）

サンドボックスアカウントがデプロイされるOUはControl Tower管理の対象外とする、というのが良さそうです。
また、CfCTなどControl Tower管理ソリューションを使う場合は、SCPの2重管理による競合の可能性も考えられるため、このサンドボックス用OUを含めないよう注意したほうが良さそうです。

アカウントのライフサイクル

AccountPoolスタックのデプロイ時に、以下のOUが作成されます。ライフサイクルのフェーズごとにアカウントが所属するOUが変わり、SCPによってフェーズごとに許可する操作を制御する仕組みになっています。

アカウントは状態遷移に応じて上記OU間を移動します。

1. Entry: 管理者が手動登録し、クリーンアップでサニタイズ
2. Available: クリーンアップ成功後、リース可能な状態
3. Active: リース承認でアカウントが割り当てられ、利用開始
4. Frozen（任意）: 予算超過や手動操作でアクセス剥奪、解除でActiveに戻る
5. CleanUp: リース終了（手動または期限切れ）でリソース削除
6. Quarantine: クリーンアップ失敗やOUドリフト検知時、管理者の手動対応待ち
7. Exit: 任意のタイミングでソリューションから除外（eject）可能

デプロイの前提条件

デプロイするためにはいくつかの前提条件を満たしている必要があります。
以下は ドキュメント の簡単な要約です。

1. Hub アカウントの用意 — ソリューション専用の AWS アカウントを1つ用意する（他ワークロードとの共用不可）
2. ホームリージョンの確認 — 全スタックを同一リージョンにデプロイ。IDC を有効化済みの場合はそのリージョンを使う
3. AWS Organizations の構成済み — 組織が作成・設定されていること
4. Service Control Policies (SCP) の有効化 — Organizations で SCP が有効になっていること
5. AWS IAM Identity Center (IDC) の有効化 — 組織レベルで IDC を有効化し、ホームリージョンで設定済みであること
6. Amazon SES の設定 — Hub アカウントで SES を設定し、本番アクセスを申請済みであること
7. AWS RAM でリソース共有を有効化 — Organizations 内でのリソース共有を有効にすること
8. CloudFormation StackSets の信頼アクセスを有効化 — Organizations で StackSets の信頼アクセスを有効にすること
9. Cost Explorer の有効化 — 管理アカウントで Cost Explorer を有効化（有効化後 ≒24時間かかる）
10. Lambda 同時実行数の確認 — アカウントの同時実行上限が 1000 以上であること（不足する場合は Service Quotas からリクエスト）
11. 全アカウントが Organizations のメンバーであること — 対象アカウントが組織外だとデプロイが失敗する

デプロイしてみた

ソリューションのデプロイ

Windows11のWSL2(Ubuntu)の環境にてデプロイしてみました。

READMEの手順に沿ってデプロイします。

NPMパッケージをインストールします。

npm ci

以下のスクリプトで.env.exampleから.envを作成します。

npm run env:init

.envの変数に値を設定します。

スタックリソースの削除保護を制御できます。今回は検証なのでdevとし、削除保護無しとしました。

.env

# Deployment Mode (Optional)
DEPLOYMENT_MODE=dev # If set to "dev" deletion protection of stack resources is turned off.

ハブアカウントのアカウントIDと、ソリューション全体を識別するネームスペース文字列を指定します。

.env

# Common
HUB_ACCOUNT_ID=333333333333 # The AWS account that the Compute and Data stacks will be deployed to.
NAMESPACE="myisb" # The namespace that the stacks will be deployed to.

今回のソリューションを展開するOUの親OUを指定します。Organizationsルートも指定可能です。

.env

# Account Pool Stack CFN Parameters
PARENT_OU_ID="xxxxx" # The organization's root OU id is also acceptable.

サンドボックス環境で利用可能とするリージョンを指定します。ここで指定していないリージョンはSCPにより使用不可となります。

.env

AWS_REGIONS="ap-northeast-1,ap-northeast-3,us-east-1,・・・・" # The regions enabled in the sandbox accounts.

Identity Centerの情報を指定します。

.env

# IDC Stack CFN Parameters
IDENTITY_STORE_ID="d-1234567890" # The Identity Store Id of the Identity Source in IAM Identity Center.
SSO_INSTANCE_ARN="arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxx" # The ARN of the SSO instance in IAM Identity Center.

グループ名はオプションで、指定しない場合はデフォルト値が使用されます。

.env

ADMIN_GROUP_NAME="" # Custom admin group name for IAM Identity Center instance, defaults to <namespace>_IsbAdmins if left empty.
MANAGER_GROUP_NAME="" # Custom manager group name for IAM Identity Center instance, defaults to <namespace>_IsbManagers if left empty.
USER_GROUP_NAME="" # Custom user group name for IAM Identity Center instance, defaults to <namespace>_IsbUsers if left empty.

外部IDプロバイダとしてEntra IDを利用し、グループを自Identity Centerへ自動プロビジョニングしている環境の場合、このソリューションのデプロイ前にグループを自動プロビジョニングしておき、その名称と同じ名称を上記変数に設定しておく必要があります。

管理アカウントとIdentity Center委任管理アカウントを指定します。

.env

# Compute Stack CFN Parameters
ORG_MGT_ACCOUNT_ID=111111111111 # The AWS account that the AccountPool stack is deployed to.
IDC_ACCOUNT_ID=222222222222 # The AWS account that the IDC stack is deployed to.

ComputeスタックをデプロイするにはAcceptと指定する必要があります。

.env

ACCEPT_SOLUTION_TERMS_OF_USE=Accept # Must be set to "Accept" for the compute stack to be deployed. Terms are located here ./source/infrastructure/lib/assets/terms-of-use.txt

同意事項の具体的な内容は./source/infrastructure/lib/assets/terms-of-use.txtに記載されています。

AIで要約すると 「非本番専用の使い捨て実験環境であり、コスト上限もリソース全削除も保証されない。第三者に渡さず、追加ユーザーの後始末や不正監視は自己責任」 ということだそうです。
こう書かれて、ConfigでAcceptと明記しないと使えない、となるとちょっと身構えてしまいますが、AWSソリューション自体がそもそもAWSが保証をしてくれるものではなく、あくまでサンプルソリューションであることを考えると、このソリューションに限らず、まずは気になったものは手軽に使ってみて、自分で有効性を確かめていく、というスタンスでいれば、気にしなくてよいと思いました。

次にCDKデプロイをしていきます。
スタック間に依存関係があり、今回は異なるアカウントにスタックをデプロイするため、スタック単位で順番にCDKデプロイを実行していきます。
スタックごとにデプロイ先が異なる＝AWS認証情報も異なるため、事前にAWS CLIの~/.aws/configに各アカウント用のプロファイルを定義しておき、デプロイ実行時にプロファイルを指定しました。

AWS_PROFILE=isb-mgmt AWS_REGION=ap-northeast-1 npm run deploy:account-pool
AWS_PROFILE=isb-idc  AWS_REGION=ap-northeast-1 npm run deploy:idc
AWS_PROFILE=isb-hub  AWS_REGION=ap-northeast-1 npm run deploy:data
AWS_PROFILE=isb-hub  AWS_REGION=ap-northeast-1 npm run deploy:compute

上記がうまくいけば、ソリューションの展開は完了です。

運用メトリクスの収集

READMEに以下の記述がありますが、それをオプトアウトする方法がドキュメント上では見つけられませんでした。

このソリューションは、本ソリューションの使用状況に関する運用メトリクス（以下「データ」）をAWSに送信します。AWSはこのデータを利用して、お客様が本ソリューションおよび関連サービスや製品をどのように利用しているかをより深く理解します。AWSによるこのデータの収集は、AWSプライバシー通知の対象となります。

下記でメトリクス収集のためのリソースを実装しているため、もしオプトアウトしたい場合はこちらをコメントアウトすれば良さそうです。（※コメントアウトした場合、最新バージョンを取り込むときにコンフリクトなど発生する可能性があるため注意が必要です）

デプロイ時に詰まったところ

GitBashでデプロイエラー

CDKを用いたデプロイを最初はGitBashで実施しましたが、NPMスクリプト実行時にsourceコマンドが見つかりませんでした。そこで、GitBashでsource .env実行後にスクリプト実行したところ、デプロイコマンド実行時のタイミングで変数に値がセットされておらず、デプロイエラーが発生しました。

ただ、そもそもデプロイの前提条件でWindowsは対象になっていません。

MacOS or Amazon Linux 2 Operating System

NPMのスクリプトで利用されるシェルを変更する等で突破できそうな感じもありましたが、あまりここで独自の対処をしたくなかったため、WSL2を使うことにしました。

Lambda同時実行数が10

先述の「デプロイの前提条件」にあるとおりですが、同時実行上限が1000以上である必要がありますが、私の検証アカウントでは「適用されたアカウントレベルのクォータ値」が10になっていてデプロイに失敗しました。
Service Quotaから上限緩和申請しようとしたところ「AWS のデフォルトのクォータ値」の1000以上の値を指定する必要があり、1001で申請してみました。

サポートからの回答は下記のとおり・・・

クォータ引き上げリクエストを審査いたしました。誠に恐れ入りますが、現時点ではこのリクエストを承認することができません。

しかしマネコンを確認してみると、「適用されたアカウントレベルのクォータ値」が1000になっていました。1001はダメだけど1000にはしてもらえたということみたいです。

デプロイ後の手動設定

Innovation Sandboxが利用できる状態にするには、スタックの展開後にいくつか手動設定が必要です。

Identity Center

アプリケーションを追加します。

「セットしたいアプリケーションがある」、「SAML2.0」を選択します。

アプリケーションの表示名を指定します。

「IAM Identity Center サインイン URL」「IAM Identity Center サインアウト URL」をメモし、「IAM Identity Center 証明書」をダウンロードしておきます。

ACS URLに<ISB_WEB_URL>/api/auth/login/callback、SAMLオーディエンスにIsb-<NAMESPACE>-Audienceを指定します。はComputeスタックのアウトプットからCloudFrontのURLを、は.envから値を持ってきます。

属性マッピングを編集します。

下図のとおりに設定します。

アプリケーションにグループを割り当てます。

ソリューションの展開で作成されたグループを選択します。（※今回は.envで特にグループ名を指定しなかったのでデフォルトのグループ名）

グループにユーザーを追加します。

Web UI

IAM Identity Centerアクセス​​ポータルURLをメモします。

ハブアカウントのApp Configにて、アプリ「InnovationSandboxData-Config-Application-XXXXXXX」のプロファイル「InnovationSandboxData-Config-GlobalConfigHostedConfiguration-XXXXX」を選択し、バージョンを作成します。

maintenanceModeをfalseにします。

authセクションにこれまでメモしてきた値を設定します。

SES空メール送信する際の送信元メールアドレスを設定します。

ホスト設定バージョンを作成します。

デプロイを開始します。

作成したバージョンを指定してデプロイを開始します。

Secrets Managerのシークレット「/InnovationSandbox/${NAMESPACE}/Auth/IDPCert」を表示し、シークレットの値を取得します。

編集します。

先ほどダウンロードしたIdentity Center証明書ファイルの値を貼付して保存します。

以上で手動設定も完了です。

権限

管理者、マネージャー、ユーザーの3種類のロールがあり、それぞれで実施可能な操作や閲覧範囲が異なります。

今回の検証では手順簡略化のため、すべて管理者で進めます。

ログイン

Identity Centerのアクセスポータルのアプリケーションからログインします。

無事ログインできました。なお、Identity Centerにログイン済みであれば、CloudFrontのURLから直接アクセスすることもできます。

アカウント登録

Innovation Sandboxからは新規アカウントを作成することはできません。
既存アカウントを使うこともできますが、今回は新規アカウントをOrganizationsから作成しました。
サンドボックス用のアカウントをEntry OUに配置することで、Innovation Sandboxから操作できるようになります。

Web UIでアカウントを登録します。

先ほど作成したアカウントを選択し、登録します。

ここで、アカウント内のリソースがすべて削除される旨の警告が表示されます。問題なければ送信します。

登録直後はクリーンアップが実行されます。

クリーンアップに失敗して隔離状態になってしまいました。

失敗の原因を見ていきたいと思います。

ハブアカウントのStep Functions画面を開き、AccountCleanerStepFunctionStateMachine～というステートマシンの失敗している実行結果のIDをコピーします。

CloudWatch Logs Insightsで保存済みクエリからAccountCleanupLogsというクエリを選択し、PasteStateMachineExecutionIdHereという文字列を実行IDを書き換えてクエリを実行します。（このときUIが新しくなっていることに気づきました！）

検索結果は0件でした。

ロググループInnovationSandbox-Compute-ISBLogGroupCleanupの内容を見ていると下記のエラーメッセージがありました。

scanner is already registered, you cannot register it twice

Claude Codeで調査してみると・・・

エラーメッセージはaws-nukeが内部で使っているlibnukeが出していることがわかりました。

nuke-config.yamlのregionsに、Innovation Sandboxの.envで指定しているAWS_REGIONSの値が重複除去することなくそのまま利用されています。

.envを見返してみると、us-east-1が2つ・・・

env

AWS_REGIONS="ap-northeast-1,ap-northeast-3,us-east-1,us-east-1,us-west-2"

これが原因となり、アカウント登録する際にスキャナを重複登録しようとしてエラーになった、ということなようでした。

AWS_REGIONSの重複記述を修正し、AccountPoolスタックを更新しました。

その後、アカウントのクリーンアップをリトライしてみたところ

無事成功しました！

リース契約テンプレートの作成

リーステンプレートを作成していきます。

適当な名前を付け、承認を要求し、公開設定はPublicとしてみます。

ブループリントはまだ作成していないのでそのまま次へ進みます。

適当に予算の閾値を設定します。Send Alertはコストが閾値に達した時にメール送信、Freeze Leaseは新規リソースの作成を防止します。

適当にリース期間を設定します。

コストレポートは今回はいったん無しで進めます。

内容を確認してテンプレートを作成します。

アカウントリースのリクエスト

リースをリクエストします。

先ほど作成したリースのテンプレートを選択します。

利用規約の同意にチェックをして次へいきます。

内容を確認して、リクエストを送信します。

リースを承認する

リクエストを承認します。

リースを確認する

リースの状態が確認できました。

今回は管理者ロールユーザーで試しているため、Admin用ロールが付与されているのに加え、リースをしたことでUserロールが割り当てられました。なお、いずれのロールも、サンドボックスアカウントに対してはAdministratorAccessが付与されます。

リースアカウントを使う

Userロールでリースされたアカウントにログインしてみます。

.envで指定していないリージョンに入ると、SCPがちゃんと効いて操作不可となっているようです。

適当なリソースを作成してみます。

リース期間終了後

アカウントはクリーンアップを経てAvailableになっています。

リース画面はLease Duration Expiredとなり、Updateのみできる状態です。

Identity Centerのアクセスポータルでは、Userロールは無くなっています。

Adminロールでログインしてみると、リース中に作成したSNS Topicが削除されていることが確認できました。ちゃんとクリーンアップされたようです。

さいごに

今回とりあえず自分でデプロイして触ってみて、ドキュメントをいろいろのぞいてみて、何となく利用イメージができてきた気がします。
期待度が高かったため、CloudFormationによる単一アカウントの展開というシンプルな利用方法もありますが、Control Tower環境下への展開・複数アカウントへのリソース展開・CDKデプロイと、本番活用を見据えて最初からいろいろ試してみました。
次は実際にスモールスタートで運用をはじめてみて、良いところや（もしあれば）惜しいところ等、いろいろ発見していきたいと思います。
なお、ワークショップ もあるようなので、興味を持たれた方はこちらでまず体験してみるのもよいかもしれません。

弊社では一緒に働く仲間を募集中です！

現在、様々な職種を募集しております。
カジュアル面談も可能ですので、ご連絡お待ちしております！

募集内容等詳細は、是非採用サイトをご確認ください。