AWSがローカルエミュレーターAWS Emulatorを公開、手元のPCでAWSアプリをテスト

AWS EmulatorはAWSのAPIを手元のPCで動かす

AWSは2026年11月11日付のAWS News Blogで、Daniel Abib氏の記事としてAWS Emulatorを発表しました。これは、開発者が自分のマシン上で動かすAmazon Web Servicesのローカルエミュレーターです。AWS CLI、AWS SDK、そしてコーディングエージェントは、クラウドで使うものと同じAWS APIを使い、ローカルのHTTPSエンドポイント経由でこのエミュレーターに接続します。AWSによると、追加のサービス料金はなく、AWS上にデプロイしたときのリソースにだけ料金がかかります。ソースコードはGitHubで公開されています。LinuxではRPMまたはDebianパッケージでインストールし、macOSとWindowsではDockerで実行します。すぐ使えるイメージは配布されておらず、ドキュメントにある短いDockerfileから自分でビルドします。

ローカル実行の流れ

手順は単純です。パッケージを入れ、aws-emulatorコマンドを起動し、ツールの接続先をローカルのエンドポイントに向けます。起動時にエミュレーターは独自の認証情報、設定ファイル、証明書を生成し、~/.aws/emulator/9297/ に書き込みます。HTTPSは127.0.0.1:9297で待ち受けるため、アクセスできるのは自分のマシンだけです。続いてAWS_ENDPOINT_URLなどの環境変数を設定し、本物のAWS認証情報になりうる変数は解除します。アプリケーションのコードは変更しません。

キーは起動のたびに新しく作られます。アクセスキーIDはEMULATORで始まるので、本物と取り違えることはなく、ほかのキーで署名されたリクエストは拒否されます。アカウントは1つだけで、番号は000000000000です。記事の例では、S3バケットを作ってオブジェクトをコピーし、さらにKiroというコーディングエージェントにDynamoDBテーブルの作成、項目の書き込み、読み戻しを依頼しています。すべてローカルのエンドポイントに対して行われ、実際のアカウントは使われません。既存のテストスイートも同じ方法で使えます。エミュレーターを起動し、テストスクリプトで同じ変数を設定して、いつも通り実行します。

テスト向けの組み込みモード

テスト用にはもう1つの方法があります。組み込みモードでは、テストプロセスの内部でエミュレーターを生成し、SDKのHTTPクライアント経由でつなぎます。組み込みインスタンスはそれぞれ独自の状態を持つため、テスト同士でバケット、テーブル、キューを共有せず、多数を並列に動かせます。提供開始時点で組み込みモードに対応するのはAWS SDK for Rustのみで、aws-emulator-embeddedクレートを使います。別プロセスとして動かす場合、SDKによってはエミュレーターの証明書を信頼させる追加設定が必要です。記事はAWS SDK for Javaのトラストストアを例に挙げています。プロセスとして動かす場合、全リクエストにSigV4署名が必要で、/__admin/healthというヘルスチェック用エンドポイントも用意されています。スクリプトやコンテナは、準備ができるまで待ってからテストを始められます。

忠実度の測り方

ローカルで通ったテストがAWSでも通らなければ、エミュレーターは役に立ちません。そこでAWSは忠実度テストを使います。これはAWS SDKでワークフローを実行し、AWSの挙動を検証する短いプログラムです。各テストは本物のAWSに対して事前に検証されています。ステータスコード、本文、正確なエラーコードとメッセージ、ワークフローが作るリソースを含め、すべてのレスポンスがAWSと一致した場合だけ合格になります。AWSはリリースごとに、サービス別の結果をk/nの形式で公開します。テストの一覧はaws-emulator-evaluation-suiteリポジトリで公開され、まだ通らないテストも含まれます。テストが増えるとエミュレーターが改善していてもスコアが下がることがある、とも説明されています。未実装の操作はHTTP 501を返すため、テストは偶然通ることなく、すぐ失敗します。

エージェントによる構築とレビュー

AWSによると、エミュレーターはAWS APIモデルをもとに、エージェントが構築・保守しています。使われるのはAmazon Bedrock AgentCore Runtime Instances、AWS CodePipeline、AWS CodeCommitです。あるエージェント群が差分を見つけて課題を登録し、別のエージェント群がテストを書き、挙動を実装し、変更をレビューします。変更を送るとパイプラインが動き、忠実度テストを実行してから公開リポジトリに反映されます。独立したセキュリティエージェントが、修正中とリリースパイプラインで敵対的な視点から変更を確認します。これらはAWS自身の説明であり、記事に第三者による監査は示されていません。

事前に知っておきたい制限

記事は制限をはっきり述べています。エミュレーターはAWSのようにIAMポリシーやリソースベースのポリシーを評価しないため、AWSなら拒否されるリクエストがローカルでは成功することがあります。AWSは、アプリのセキュリティを確かめる目的で使わないよう求めています。各エミュレーターは1アカウントとして動き、アカウント間やリージョン間の挙動はありません。AWSとの近さはサービスや機能によって異なるため、使うサービスの忠実度スコアを確認してください。既定では匿名の利用・エラーデータを送信しますが、無効にできます。記事のコメント欄では、1人の読者が1件のコメントの中で、起動のたびに証明書が作り直されること、.NET SDKの署名付きチャンクによるS3アップロードの保存に問題があることなどを挙げています。これらは独立した検証を経ていない利用者の報告でありAWSの発表ではないため、AWSの回答があるまで未確認として扱ってください。

開発者にとっての意味

現在、本物のAWSアカウントでテストしているチームにとって、十分に忠実なローカル環境は費用と待ち時間を減らし、コーディングエージェントが安全に試行錯誤できる場所にもなります。ただし、ローカルで通っても本番で同じ動きをする証拠にはならず、特にセキュリティ規則はそうです。テストジョブに本物の認証情報を置かず、リリース前の最終確認はAWS上で行ってください。