AWS Lambda MicroVMsでスナップショット由来の乱数・UUID重複を検証してみた

• URL: https://dev.classmethod.jp/articles/lambda-microvms-snapshot-random-uuid-duplication
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: Lambda MicroVMs はスナップショット由来の一意性問題を抱えている。スナップショット作成時（グローバルスコープ実行）に生成した値は同一スナップショットから起動した全 VM で完全一致。random.random()・uuid.uuid4()（グローバル）・time.time()・random 状態ハッシュが 3 台 VM で全同一。/run フック時に secrets.token_hex()・uuid.uuid4() で生成した値は 3 台で全異なるが、random 状態は Mersenne Twister がスナップショット由来のまま全 VM で同じ軌道を辿り、同じ呼び出し順序なら同一値を返す。リクエスト時 /generate で secrets・uuid.uuid4() は安全だが、random.random() は危険。セキュリティトークンは secrets、一意識別子はリクエスト時 uuid.uuid4()、per-VM 論理 ID は runHookPayload で明示的注入が適している。

詳細

Python Flask アプリで BUILD_RANDOM・BUILD_UUID・BUILD_TIME・BUILD_RANDOM_STATE_HASH をグローバルで生成し、RUN_SECRET・RUN_UUID・RUN_RANDOM_STATE_HASH を /run フック内で生成。3 台の /uniqueness エンドポイント比較で、グローバル生成値は全 VM で 0.3995975096870906（random）、4f12ad9f-4985-44de-…（uuid）、1782232870.950651（time）と完全一致。/run フック で random 状態ハッシュは依然全 VM で 78bed98a6cf5fbac と同一。サスペンド→レジューム後も /run フック内の secrets.token_hex() は毎回異なる値を返したが、random.random() はスナップショット状態から継続しており同一 VM 内では前回値から続き、異なる VM 間では各々同じシーケンスを辿る。RunMicrovm API の –run-hook-payload で JSON を per-VM で渡すと /run リクエストボディに microvmId(システム付与）と runHookPayload が届く。フックのパスは公式ガイド「/run」ではなく実際は「/aws/lambda-microvms/runtime/v1/run」に届いた点注意。