2026年6月22日から28日の週は、プラットフォームチームがタグとwikiページで代用してきた3つのガバナンスプリミティブを届けた。コピー、リージョン、アカウント共有を越えて残るAMIウォーターマーク。信頼できないコードを専用の仮想マシンに閉じ込めるLambda MicroVMs。そして、正当なサーバーからクライアントへのパケットを無言で落としていたNetwork Firewallのデフォルトの修正だ。 移行側では、AWS Transformがどの商用リージョンにもワークロードを着地させられるようになり、OpenSearchとMSKがそろってエージェント主導の移行経路を出した。

今週はSummitがないので、ローンチは小さく、そして役に立つ。各トップ項目は、去年ならポリシー文書に書いて、守られることを祈っていた類のものだ。

移行: どのリージョンでも、そしてエージェント主導の経路が2つ

AWS Transform for migrationsはすべてのAWS商用リージョンを移行ターゲットとしてサポートする。公開は6月22日。ターゲットリージョンとはランディングゾーン、ネットワーク、リホストされたサーバーがデプロイされる場所で、発表は16リージョンを追加する。US West (N. California)、Africa (Cape Town)、Asia Pacific (Bangkok、Hong Kong、Hyderabad、Jakarta、Kuala Lumpur、Melbourne、New Zealand、Taipei)、Canada (Calgary)、Europe (Milan、Spain、Zurich)、Mexico (Querétaro)、Middle East (Tel Aviv)。欧州の読者にとっては、Zurich、Milan、Spainが「法務が指定する場所にエージェントが着地させられない」をブロッカーからドロップダウンの選択肢に変える。

同じ週のデータベース隣接の2つのローンチは、MGN改名のパターンに従っている。移行ロジックが、エージェントが運転するものの中へ移る。Amazon OpenSearch ServiceがAI支援の移行を提供する(6月23日)。Migration AssistantにKiro、Claude Codeなどから使えるエージェント主導のワークフローが加わり、セルフマネージドのSolr、Elasticsearch、OpenSearchからOpenSearch ServerlessまたはManaged Clustersへの移行計画、インフラのデプロイ、履歴データとライブトラフィックの移行を行う。キャプチャ&リプレイはSolrもカバーするようになった。Amazon MSK AI Agent Skills(6月22日)は、Kiro、Claude Code、Cursorに、サイジング、トラブルシューティング、監視、そして外部KafkaクラスターのMSK Expressへの移行に関する専門的なガイダンスを与える。

配布手段としてのスキルのトレードオフはバージョン管理だ。リポジトリ内のランブックにはコミット履歴があるが、実行時に取得されるベンダーのスキルはdiffを取れないプロンプトである。一度きりの移行なら問題ない。40の同一クラスターなら、エージェントが最初にやったことを自分の所有物としてエクスポートすること。

AMIウォーターマーク: コピーで失われない系譜

Amazon EC2がAMI Watermarksを発表した。6月24日のことだ。プライベートAMIにカスタム識別子を埋め込むと、そこから派生するすべてのAMIに引き継がれる。他リージョンへのコピー、実行中インスタンスから作成したイメージ、他アカウントと共有したイメージ。各ウォーターマークは元のAMI ID、所有者、リージョン、作成タイムスタンプを持つ。肝は強制の側だ。ウォーターマークをAllowed AMIsと組み合わせて、承認済みウォーターマークを持つイメージからの起動に限定し、Declarative Policiesで組織全体に適用する。EC2 Image Builderはパイプラインの中でウォーターマークを付けられる。GovCloudと中国を含む全リージョンで、無料。

これが閉じる穴は具体的だ。ゴールデンAMIプログラムはAllowed AMIsで「アカウントXからのみ起動」を強制する。あるチームがパッケージを1つ追加するためにゴールデンイメージを自分のアカウントへコピーした瞬間、系譜は失われ、ポリシーはそれをブロックする(するとそのチームはゴールデンイメージを使うのをやめる)か、そのアカウントを許可する(するとポリシーは何も意味しなくなる)かのどちらかになる。コピーを越えて残るウォーターマークがあれば、代わりに「ゴールデンイメージから派生したものなら何でも起動可」と言える。

それが何を証明するかは正確に押さえておくこと。ウォーターマークは来歴であって完全性ではない。イメージが承認したビルドから派生していることは示すが、派生イメージやその後のインスタンス上で何も変わっていないことは示さない。タグベースの系譜管理は置き換えるが、Inspector、SSMコンプライアンス、イメージ署名は置き換えない。

Lambda MicroVMs: 信頼できないセッションごとに1台のVM

AWSはLambda MicroVMsを導入した。6月22日。ユーザーまたはジョブごとに、独自のカーネルを持つFirecrackerで隔離されたVMを与えるサーバーレスプリミティブで、メモリとディスクの状態を保ったままのサスペンドとレジューム(合計実行時間は最大8時間)、HTTP/2、gRPC、WebSocketsに対応する専用HTTPSエンドポイントを備える。MicroVMあたりの上限は16 vCPU、32 GBメモリ、32 GBディスク、ARM64のみ。ローンチ記事によれば、Dockerfileからaws lambda-microvms create-microvm-imageでイメージをビルドし、aws lambda-microvms run-microvmとアイドルポリシーで起動し、動いている間はベースラインのコンピュート料金を払う。US East (N. Virginia、Ohio)、US West (Oregon)、Europe (Ireland)、Asia Pacific (Tokyo)で利用できる。

これについてはAWS Lambda MicroVMs: serverless にステートフルで隔離されたサンドボックスが加わるで長く書いた。短く言えば、設計上の問いは「関数かMicroVMか」ではなく「自分のシステムの中で、自分が書いていないコードを動かしているのは何か」だ。ノートブック、顧客のプラグイン、LLMが生成するあらゆるものは、ライフサイクルを持つVM境界の後ろに置くべきで、今週までそれは自前のFirecrackerフリートかテナントごとのコンテナを意味していた。エージェント側の視点はercan.aiにある。

Network Firewallが接続を壊していたデフォルトを修正

AWS Network Firewallがデフォルトのドロップアクションを更新した。6月22日。新しいファイアウォールポリシーのステートフルアクションのデフォルトは「Application drop established (server-directed only)」になった。以前のデフォルト「Application drop established (bidirectional)」は、ウィンドウ更新、キープアライブ、リセットといった正当なサーバーからクライアントへのTCPパケットを無言で落とすことがあり、誰も再現できない断続的な接続失敗として現れていた。既存のポリシーは自動では変更されない。AWSは更新手順のドキュメントを示し、ポスト量子の断片化したTLSハンドシェイクのために双方向アクションが必要な環境は、切り替えるか、TCPドロップルールにto_serverフラグを追加できると述べている。

今日動くべきなのはこれだ。機能ではなくデフォルトの変更だからである。古い例からコピーしたTerraform内のすべてのaws_networkfirewall_firewall_policyは古いデフォルトを抱えている。ステートフルのデフォルトアクションをgrepし、新しい推奨と比較し、まずステージングで変更を流すこと。Network Firewallの後ろにある何かについて原因不明の断続的タイムアウトのチケットが開いているなら、いまその原因を見つけたのかもしれない。

今週のその他

  • GuardDutyのAIによる調査が10リージョンでプレビュー入り(6月23日)。各検出結果に信頼度スコア付きの判定、MITRE ATT&CKへのマッピング、90日分の関連アクティビティ、そして抑制、封じ込め、修復の推奨が付く。コンソール、CLI、API、AWS MCP Serverから利用できる。
  • CloudWatch Logsのマネージドsyslog取り込み(6月23日)。RFC 5424、RFC 3164、Cisco FTD/ASAをTCP、TCP+TLS、UDPでVPCエンドポイントへ受け付け、エージェント不要で、facility、severity、hostnameを抽出する。
  • EKS向けOTel Container Insights(6月23日)。cAdvisor、Kube State Metrics、NVIDIA DCGMレシーバー経由で30秒間隔のインフラメトリクスをKubernetesラベル付きで収集し、PromQLエンドポイントを提供する。CloudWatch Observabilityアドオンv6.2.0以降が必要。
  • MySQLのオープンガバナンス。Oracleが非Oracleの4議席を持つステアリングコミッティを発表し、そのうち1つがAWSだ。先週のExtended Support延長を考えると、AWSはMySQLを長く運用するつもりだ。

通底するテーマ

今週の4つのトップ項目のうち3つは、これまで願望だった性質を強制可能にする。イメージがどこから来たか、信頼できないコードがどこで動くか、ファイアウォールが接続の戻り側をどう扱うか。4つ目、全商用リージョンでのTransformは、データレジデンシーについて同じことをする。どれも刺激的ではない。すべてが、一度存在してしまえば以前のやり方をインシデント後レビューで怠慢に見せる種類の制御だ。

次に読む

MicroVMsとGuardDutyの調査機能のエージェント側の読み解きはercan.aiにある。AWS、クラウド、CI/CDパイプライン、Linux、GitHub/GitLabなどのコンサルティングは、ercanermis.comからどうぞ。

参考資料