きたきたきた～
生成AIアプリのフロントエンドとして鉄板のStreamlitですが、AWSにデプロイするには諸々の制約があり、Fargateで行うのが一般的だと思います。Lambda Web Adapterでなんとかならないと、10回ぐらい試したのですが、WebSocketにどうしても対応できず、諦めておりました。
そこに救世主が現れました。
Lambda MicroVMsです。
Lambda MicroVMsの概要は他の方に任せて、Streamlitをデプロイする方法を解説します！
仕組み
どうしてMicroVMsで実現できるようになったのかですが、MicroVMsの以下の特徴がいい感じに機能しています。
- 短期間インスタンスが立ち上がり、リクエストが同じインスタンスに届く（最長8時間）
- リクエストが無いと一時停止する。停止中はCPUなどの課金が発生しない
- WebSocket対応
- 任意のポート番号、任意のURLパスに対応
これまでのLambdaではこれらができませんでした。
MicroVMs独特の仕様
MicroVMの動作には、まず、DockerfileなどをまとめたZipファイルをS3に格納し、これをイメージとして登録します。
2026/6/28時点で、S3に格納する方法しかサポートされていません。CloudFormationのドキュメントにはECRリポジトリも可能っぽく書いてますが、エラーになりました。
そしてイメージをもとにMicroVMsを起動します。起動することで専用のエンドポイント（mvm-01234567-abcd-ef01-2345-6789abcdef01.lambda-microvm.us-east-1.on.aws）が生成されます。
通常のLambdaと異なり明示的に起動させる手順が必要です。
そして起動したMicroVMsインスタンスにアクセスするにはHTTPヘッダーに以下の情報を含める必要があります。
- MicroVMs単位で発行した認証トークン（
X-aws-proxy-auth） - ポート番号（
X-aws-proxy-port）※8080以外を使用する場合
「MicroVMの起動」「特定のHTTPヘッダーの付与」の２つを実現するために、 Lambda@Edge を使用します。
アーキテクチャ
久しぶりにDrawIOで構成図を書きました。手書き楽しい！
Lambda@Edgeでは以下の処理を行います。
- Origin request
リクエストをオリジンへ転送する際に呼び出されるLambda。ここでMicroVMsの起動を行ったり、認証トークンの生成とHTTPヘッダーへの追加を行います。
セッション情報がない場合は /session/start に302リダイレクトします。
/session/start へのアクセスの場合はまずMicroVMsを起動する。
そして、認証トークンを生成します。
DynamoDBに保存します。
Cookieをセットし、しばらくお待ちください画面を返却します。
Cookieにセッション情報がある場合は、HTTPヘッダーを付与してオリジンにリクエストを転送します。
- Origin response
オリジンからレスポンスが返却された際に呼び出されるLambda。MicroVMsが停止した後にリクエストをするとエラーになるので、Cookieの削除と新しいMicroVMsを再作成するようにします。
オリジンから502や504エラーが返却された場合は、Cookieをクリアし、 /session/start に302リダイレクトします。これにより、新しいMicroVMs作成のフローを再実行させます。
Lambda@Edge、使ってみると意外と簡単ですね！
あとはWAFをつけたりCognitoで認証したり、必要に応じてパワーアップさせましょう。
Streamlitアプリ
Streamlitアプリは普通に作ります。
Strands AgentsとClaude Haiku 4.5（Mantleエンドポイント）でつくてみました。
Dockerfileとpyproject.toml、uv.lockを用意し、ZIPに圧縮してMicroVMsとして登録できます。
StreamlitアプリからBedockにアクセスする場合は、RunMicrovm APIのexecutionRoleArnにBedrockへのアクセス権限を付与します。
動作させてみた。
初回の起動（MicroVMの起動・アプリの起動・初回Bedrock呼び出し）にちょっと時間がかかりますが、2回目以降のリクエストは問題ありません。
CDKで簡単にデプロイできるコードはこちらです。