Amazon Web Services ブログ
AWS Emulator を使用してローカルで AWS に対してアプリケーションをテストする
2026 年 11 月 11 日、Amazon Web Services (AWS) のローカルエミュレーターであり、マシン上で実行できる AWS Emulator を発表しました。AWS コマンドラインインターフェイス (AWS CLI)、AWS SDK、およびコーディングエージェントは、ラップトップからクラウドで使用するのと同じ AWS API を使用して、ローカルの HTTPS エンドポイントを介して通信します。AWS エミュレータには追加のサービス料金はかかりません。AWS にデプロイする場合、料金は AWS リソースに対してのみ発生します。そのソースは GitHub にあります。Linux では RPM または Debian パッケージからインストールし、macOS と Windows では Docker で実行します。
仕組み
エミュレータをインストールして起動し、ツールをローカルエンドポイントに向けます。AWS Emulator が起動すると、独自の認証情報、設定ファイル、および証明書が生成され、~/.aws/emulator/9297/ に書き込まれます。AWS SDK が AWS ではなくラップトップと通信するように環境変数を設定すると、アプリケーションコードは変更されません。
そこから、既存のテスト、CLIスクリプト、およびコーディングエージェントは、これまでのように機能し続けます。Amazon DynamoDB テーブルを作成し、項目を書き込み、それを読み戻すユニットテストも同じテストであり、デプロイなしでマシン上で実行されます。コーディングエージェントは、リージョンへのデプロイを待たずに、リソースを作成し、結果を確認し、繰り返し処理を行うことができます。
エミュレータは Rust で実装されているため、ラップトップの CPU とメモリをあまり使用しません。GitHub の AWS API モデルリポジトリに API モデルがある AWS サービスの API をサポートし、それらのモデルから構築されているため、AWS SDK が使用するものと同じモデルで、リクエストや返されるエラーは AWS と同じ形になります。
開発者、特に Kiro や Claude Code などのコーディングエージェントを扱う開発者であれば、このループを使用して、本当に複雑な AWS インタラクションをローカルでテストできます。
試してみましょう
はじめに、Amazon Linux 2023 にパッケージをインストールしました。このパッケージは aws-emulator コマンドを /usr/bin/ に追加するので、このコマンドはパス上にあります。
PKG=https://downloads.aws.com/aws-emulator/packages/aws-emulator/LTS/latest sudo dnf install -y $PKG/aws-emulator-x86_64.rpm aws-emulator -v
macOS と Windows では、ドキュメントに記載されている短い Dockerfile から Docker イメージを作成し、コンテナーでエミュレーターを実行します。既製のイメージは公開しません。
aws-emulator でエミュレータを起動しました。127.0.0.1:9297 で HTTPS を提供するので、自分のコンピューターしかアクセスできず、アドレス、設定ファイル、証明書ファイルを示す JSON 行としてログを書き込みます。
aws-emulator
別のターミナルで、AWS CLI をエミュレータに向ける環境変数を設定し、実際の AWS 認証情報を提供できる変数を設定解除しました。
export AWS_ENDPOINT_URL=https://127.0.0.1:9297 export AWS_SHARED_CREDENTIALS_FILE=~/.aws/emulator/9297/emulator_credentials export AWS_CONFIG_FILE=~/.aws/emulator/9297/config export AWS_EC2_METADATA_DISABLED=true export AWS_DISABLE_HOST_PREFIX_INJECTION=true export AWS_REGION=us-east-1 export AWS_DEFAULT_REGION=us-east-1 unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_PROFILE
エミュレータは、起動するたびに新しいキーを生成します。アクセスキー ID は EMULATOR で始まるため、実際の AWS キーと間違えることはなく、他のキーで署名されたリクエストは拒否されます。シェルがエミュレータと通信していることを確認するために、ヘルスエンドポイントと呼び出し元の ID を確認しました。エミュレータは、000000000000 という単一のアカウントを使用します。
curl --cacert ~/.aws/emulator/9297/ca.pem https://127.0.0.1:9297/__admin/health aws sts get-caller-identity
次に、バケットを作成し、小さなオブジェクトにコピーしてリストしました。
$ aws s3 mb s3://local-getting-started make_bucket: local-getting-started $ echo "hello from the emulator" > hello.txt $ aws s3 cp hello.txt s3://local-getting-started/ アップロード: ./hello.txt から s3://local-getting-started/hello.txt $ aws s3 ls s3://local-getting-started/
AWS CLI をラップトップに向けて、すでに使用しているのと同じコマンドと、それらに応答するローカルエンドポイントを使用できました。
次に、実際の作業方法を確認したかったので、エミュレータがまだ実行されている状態で Kiro を開いて、Amazon DynamoDB テーブルを作成し、項目を書き込み、読み戻すように依頼しました。これらはすべて、AWS アカウントではなく AWS Emulator に対して行われます。
kiro> ローカルの AWS Emulator (このシェルでは環境変数が
すでに設定されています) を使用して、
文字列キー "id" を持つ DynamoDB テーブル "kiro-demo" を作成し、
アイテム {id: "item-1", msg: "hello from kiro"} を格納した後、
get-item コマンドでそれを読み出してください。
$ aws dynamodb create-table --table-name kiro-demo \
--attribute-definitions AttributeName=id,AttributeType=S \
--key-schema AttributeName=id,KeyType=HASH \
--billing-mode PAY_PER_REQUEST
$ aws dynamodb put-item --table-name kiro-demo \
--item '{"id": {"S": "item-1"}, "msg": {"S": "hello from kiro"}}'
$ aws dynamodb get-item --table-name kiro-demo --key '{"id": {"S": "item-1"}}'
既存のテストスイートで同じセットアップを使用するには、エミュレータを起動し、テストを実行するスクリプトに同じ環境変数を設定し、通常どおり実行します。
処理中のエミュレータの使用
エミュレータをローカルプロセスとして実行すると、環境変数を通じて AWS CLI および AWS SDK と連携する HTTPS エンドポイントが得られます。一部の SDK では、エミュレータ証明書を信頼するための追加設定が必要です。たとえば、AWS SDK for Java のトラストストアなどです。テストには、2 つ目の選択肢があります。AWS Emulator には、ネットワーク経由で別のサーバーと通信するのではなく、テストプロセス内で直接インスタンス化し、HTTP クライアントを介して SDK に接続する組み込みモードが付属しています。各組み込みインスタンスは独自の状態を保持するため、テストはバケット、テーブル、またはキューを共有せず、それらの多くを並行して実行できます。埋め込みモードは AWS SDK for Rust で使用できます。GitHub から aws-emulator-embedded クレートを取得し、Cargo.toml ファイルの [dev-dependencies] セクションに追加します。次の例では、Amazon DynamoDB テーブルを作成し、項目を書き込み、それを読み込みます。これらはすべてプロセス内で行われます。
use aws_emulator_embedded::{AwsEmulatorEmbedded, EmbeddedOptions};
use aws_sdk_dynamodb::types::{
AttributeDefinition, AttributeValue, BillingMode, KeySchemaElement, KeyType,
ScalarAttributeType,
};
#[tokio::test]
async fn put_then_get_returns_the_item() {
let emulator = AwsEmulatorEmbedded::new(EmbeddedOptions::default());
let config = aws_config::defaults(aws_config::BehaviorVersion::latest())
.http_client(emulator.http_client())
.region(aws_config::Region::new("us-east-1"))
.credentials_provider(emulator.aws_credentials_provider())
.load()
.await;
let ddb = aws_sdk_dynamodb::Client::new(&config);
ddb.create_table()
.table_name("emulator-demo-table")
.attribute_definitions(
AttributeDefinition::builder()
.attribute_name("id").attribute_type(ScalarAttributeType::S)
.build().unwrap())
.key_schema(
KeySchemaElement::builder()
.attribute_name("id").key_type(KeyType::Hash)
.build().unwrap())
.billing_mode(BillingMode::PayPerRequest)
.send().await.unwrap();
ddb.put_item()
.table_name("emulator-demo-table")
.item("id", AttributeValue::S("item-1".into()))
.item("msg", AttributeValue::S("hi".into()))
.send().await.unwrap();
let got = ddb.get_item()
.table_name("emulator-demo-table")
.key("id", AttributeValue::S("item-1".into()))
.send().await.unwrap();
assert_eq!(got.item().unwrap().get("msg").unwrap().as_s().unwrap(), "hi");
}エミュレータをローカルプロセスとして実行する場合、AWS と同じように、すべてのリクエストに Signature Version 4 (Sigv4) で署名する必要があります。また、スクリプトまたはコンテナが準備が整うまで待ってからテストを実行できるように、同じポートに /__admin/health エンドポイントを公開します。デフォルトでは、匿名の使用状況データやエラーデータも送信されますが、オフにすることもできます。
忠実度の測定方法
エミュレーターは、それに対して合格したテストが AWS にも合格する場合にのみ役立ちます。そのため、その一致度を忠実度テストで直接測定します。忠実度テストは、AWS SDK を使用してオブジェクトの保存、読み取り、削除などのワークフローを実行し、AWS の動作を確認する短いプログラムです。各忠実度テストを実際の AWS と照合して検証します。忠実度テストに合格するのは、ステータスコード、本文、正確なエラーコードとメッセージを含むすべての呼び出しへの応答と、ワークフローが作成するリソースとデータについて、エミュレータが AWS と一致する場合のみです。
リリースごとに、各サービスで合格したフィデリティテストの数を n 件中 k 件として公開しています。たとえば、50 件中 40 件ということは、サービスの 50 件のフィデリティテストのうち 40 件が合格したことを意味します。まだ合格していないものも含めて、一連の忠実度テストは GitHub の aws-emulator-evaluation-suite リポジトリで公開されているため、検証内容を確認して自分で忠実度テストを実行できます。スコアは、改善傾向にある製品のスナップショットとして読み取ることができます。忠実度テストを追加すると、エミュレータが改善されてもスコアが下がることがあります。
エミュレータがまだ操作を実装していない場合、HTTP 501 (Not Implemented) が返されるため、テストはすぐに失敗します。エミュレータの動作が AWS と異なる場合は、GitHub の AWS Emulator リポジトリでイシューを開いてお知らせください。
エミュレータの構築方法
AWS Emulator は、Amazon Bedrock AgentCore ランタイムインスタンス、AWS CodePipeline、および AWS CodeCommit を使用して AWS API モデルのエージェントによって構築および保守されているため、これらのモデルが変更されても AWS で最新の状態に保たれます。
あるエージェントグループは、エミュレータの応答を実際の AWS と比較したり、エミュレータのコードを公開されている Smithy モデルと静的に比較したりしてギャップを探し、見つかったギャップごとに問題を報告します。別のグループが問題を取り上げてテストを書き、動作を実装し、変更の正確性、パフォーマンス、およびセキュリティを確認します。変更の準備が整うと、ソースリポジトリにプッシュされ、そのプッシュにより AWS CodePipeline の実行がトリガーされ、変更がパブリック GitHub リポジトリに公開される前に忠実度テストが実行されます。
安全に保つ方法
コードはエージェントによって記述されるため、独立したセキュリティエージェントが変更を敵対的にレビューします。修正が行われている間も、リリースパイプラインで何かが出荷される前の最終チェックとしても同様です。
お客様自身が使用する場合のセキュリティは、引き続き共同の責任です。エミュレータは、お使いのマシン上で安全に動作するように構築されています。デフォルトでは自分のコンピュータでのみリッスンし、独自のキーで署名されていないリクエストは拒否されます。実行場所、入力するデータ、本番前のテスト方法を決定できます。アプリケーションが安全かどうかをテストするためにエミュレータを使用しないでください。AWS のアイデンティティとアクセス管理 (IAM) ポリシーやリソースベースのポリシーは AWS のように評価されないため、AWS が拒否したリクエストはエミュレータで成功する可能性があります。本番環境に移行する前に、実際の認証情報をテストジョブの環境から外し、セキュリティ設定とアプリケーション全体を AWS でテストしてください。
今すぐ利用可能
AWS エミュレータは11 月 11 日に一般公開されました。追加のサービス料はかかりません。AWS にデプロイする場合、料金は AWS リソースに対してのみ発生します。Linux の RPM または Debian パッケージからインストールしたり、macOS や Windows の Docker で実行したり、ソースからビルドしたりできます。環境変数を設定すると、AWS SDK や AWS CLI と連携して動作します。発売時には、いくつかの制限があります。AWS のように IAM ポリシーを評価することはなく、各エミュレータは単一のアカウントとして機能し、クロスアカウントやクロスリージョンの動作はありません。AWS との一致度は、サービスや機能によって異なります。使用しているサービスをエミュレータがどの程度カバーしているかを確認するには、AWS Emulator ドキュメントの忠実度スコアを確認してください。
リージョンの可用性を確認したい場合は、AWS Builder Center の「リージョン別の AWS 機能」ページを参照してください。API を呼び出したり、ドキュメントを検索したり、リージョンごとの提供状況を確認したり、この新機能に関するトラブルシューティングを確認したりする場合は、お好みの AI ツールで AWS MCPサーバーとプラグインを使用してみてください。
開始するには、AWS Emulator のドキュメントを参照してください。
原文はこちらです。