AWS向けのソフトウェアを作るとき、実際のクラウドに毎回つないで確認するのは手間もコストもかかります。今回GitHubで公開されている「AWS Emulator」は、その面倒をローカルでかなり肩代わりしてくれる道具です。AWSのAPIを手元で再現し、開発機やCIで安全に試せるようにする。地味ですが、実務ではかなり効いてくる種類のプロジェクトだと思います。しかも単なるローカル代替ではなく、テレメトリの扱い方や埋め込み実行の設計まで含めて、開発者向けの思想がはっきり見えるのが面白いところです。
元記事のAWS Emulatorは、AWSのAPIをローカルで動かすエミュレーターです。開発中のコードをAWS本番に向けて書くのではなく、自分のマシン、開発サーバー、あるいはCI上で、AWSに似た応答を返すローカル環境に向けて試せます。AWSアカウントは不要で、リクエストはAWSではなくエミュレーターに飛びます。つまり、実際のAWSリソースを触る前に、かなりの部分を手元で検証できるわけです。しかも追加のサービス利用料はかかりません。AWS上にデプロイしたときだけ、通常どおりAWSリソース分の費用が発生します。
使い方は一つではありません。もっとも基本的なのはサーバーモードで、エミュレーターを起動し、AWS CLIやAWS SDKが向く先を環境変数で切り替えます。LinuxではRPMかDebianパッケージを入れて aws-emulator を動かし、WindowsやmacOSではDockerコンテナで立ち上げる案内になっています。起動したエミュレーターは HTTPS の 127.0.0.1:9297 で待ち受け、自己署名証明書を使います。もう一つの形が embedded mode で、Rustのテストにエミュレーターをそのまま組み込むやり方です。この場合はエンドポイントURLも証明書も環境変数も不要で、SDKクライアントにエミュレーターのHTTPクライアントを直接つなぎます。
READMEでは、AI coding agent 向けの導線もかなり前面に出ています。aws agent-toolkit add-skill --skill-name aws-emulator --region us-east-1 でスキルを入れ、エージェントにセットアップを任せる形です。これには AWS CLI version 2.35.0 以降が必要とされています。人間が手順を覚えるだけでなく、エージェントに“どう使うか”まで伝えるところに、最近の開発フローの変化が見えます。
一方で、これは万能な代用品ではありません。AWS Emulator自身が「build and test」のためのもので、production workloads や security のテストには使うなと明記しています。どこまでAWSと一致しているかは release ごとに fidelity scores が公開され、動かないAPIや挙動は issues/ 配下で追跡されています。さらに、ソースからビルドするには Rust toolchain、C compiler、少なくとも100GBの空きディスク、そしてマルチコア機が必要です。サービスごとにcrateが分かれているため、最初のフルビルドは重い。その代わり、変更後の再ビルドはかなり速くなるという設計です。テレメトリはデフォルトで有効で、使い方の把握に役立てるとしていますが、CLIオプション、環境変数、設定ファイル、embedded mode のAPIでオフにもできます。PRは受け付けず、バグ報告や fidelity gap の報告を GitHub Issues で行う運用です。
この手のエミュレーターは、ぱっと見だと「AWSの料金を節約するための道具」に見えます。もちろんそれも正しいのですが、実際の効き目はそれだけではないと思います。開発者にとって本当に厄介なのは、AWSに対する試行錯誤が遅いことです。ちょっとしたAPIの呼び出し順、環境変数の設定、例外処理の違いで、ローカルでは動くのに本番前で詰まることがある。ローカルエミュレーターがあると、その“詰まり”をかなり早い段階で潰せます。CIにも持ち込みやすいので、チーム全体で同じ前提を共有しやすいのも強いところです。
ただ、ここで重要なのは「AWSそのもの」ではなく「AWSに似たもの」を作っている点です。元記事でも fidelity scores を出していて、できることとまだ足りないところをかなり正直に扱っています。これは良い姿勢だと思います。なぜなら、エミュレーターに100%を期待すると、かえって危ないからです。クラウドは境界条件がやたら多いので、完全一致は難しい。だからこそ、どこまで一致しているかを数値やissueで見せるやり方は、利用者にとって健全です。過信を防ぎながら、使える範囲を見極められるからです。
面白いのは embedded mode です。普通のローカルスタックなら、まずサーバーを立てて、そこにクライアントを向けるのが自然です。でもAWS Emulatorは、Rustテストの中にそのまま組み込める形を用意している。これは単なる便利機能ではなく、テストの置き場所を変える発想だと思います。外部プロセスとして扱うより、テストバイナリの一部にしてしまったほうが、隔離しやすいし、テストごとに独立した状態を持たせやすい。READMEが「one isolated instance per test」と言っているのは、その思想をよく表しています。
もちろん代償はあります。ビルド時間です。READMEは、embedded mode では emulator のサービス crate が自分のコードと一緒にコンパイルされるため、最初の cargo test が重くなると明言しています。100GBの空きディスクという案内もかなり生々しい。ここは軽く見ないほうがいい部分です。ローカルで便利になるほど、ビルド基盤への要求は上がる。これは最近の大きなテスト基盤全般に共通するトレードオフで、速さを買うのではなく、初回コストを払って継続的な再利用を得る形です。CIで target/ をキャッシュしたり、sccache を使ったりする推奨まで書いてあるのは、その現実をよく分かっているからでしょう。
もう一つ引っかかるのはテレメトリです。AWS Emulatorは使用状況データをAWSへ送るよう設定されていて、しかもデフォルトで有効です。記録に含まれないものとして、リクエストやレスポンスの中身、コード、認証情報、個人データは挙げていて、識別や帰属ができる情報は極力取らないと説明しています。とはいえ、開発者向けのローカルツールでデフォルト有効は、感情的には反発を招きやすい設計でもあります。
私は、ここはかなり実務的な判断だと思います。ローカルエミュレーターは、使われ方の実態が見えないと改善しづらい。どのサービスがよく使われ、どこでつまずき、どの機能が不足しているのかを知るには、一定の利用データが必要です。一方で、使う側から見れば、ローカルに置く道具が外に情報を送るのは気持ちのいい話ではありません。だからこそ、READMEでオフにする方法を複数列挙し、embedded mode や設定ファイルでも止められるようにしているのは最低限の配慮だと思います。面白いのは、ただ「送ります」と言うのでなく、「ツールを組み込む人は利用者に説明し、オフにする手段を提供してほしい」とまで書いている点です。作り手としては、かなり責任を意識している印象があります。
最後に少し珍しいのが、PRを受け付けないと明記していることです。GitHub上で公開され、issues と README を整え、ライセンスもCC0 1.0で広く使えるようにしているのに、貢献はPRではなく issue ベース。これは参加の入口を絞る一方で、品質や整合性を保ちたい意図がありそうです。たぶん、巨大なサービスごとのエミュレーションは、外から手を入れると一気に破綻しやすいのでしょう。各サービスの仕様、ワイヤプロトコル、状態管理、拒否のオーバーライドなど、全体の整合を保ちながら進めるには、かなり中央集権的な管理が向いているのかもしれません。
オープンソースなのに参加の形を制限するのは、聞こえは少し硬いです。けれど、この規模の基盤だと、むしろそのほうが現実的なこともある。誰でもすぐコードを送れるプロジェクトではなく、「使って、差分を報告し、足りないところを見つける」ことに協力してもらうプロジェクトとして設計されているわけです。AWSのような巨大サービス群を相手にするなら、そのほうが長く保つのではないか、と思います。
参考: GitHub - aws/aws-emulator: AWS Emulator is a local emulator of the AWS APIs.
