8月24日の週には、2028年になってもまだ意味を持つ出来事が2つあった。AWSがDuckDBを開発するアムステルダムの企業DuckLabsの買収に合意し、データベース自体は独立した財団の下でMITライセンスのまま残ること。そしてAmazon ECSが、エージェントとコントロールプレーンの接続が切れたコンテナインスタンスを検知して修復するようになったことだ。 その周辺では、Lambdaが火曜日に3つのローンチを重ね(プレビューランタイム、完全なリソースベースポリシー、MicroVMsのPrivateLink対応)、EKSはクラスターあたり最大10個のOIDCプロバイダーを受け付けるようになり、移行側ではAWS TransformがFedRAMP Class Cのスコープに入り、Elastic Disaster Recoveryには順序付きのRecovery Plansが加わった。EC2は20歳になった。

DuckLabs: 1台のマシンに収まるデータのためのエンジンをAWSが買う

発表文は、本番でDuckDBを使っている人が気にする点について慎重に書かれている。MITライセンスのオープンソースのまま、独立したFoundationの下に残り、Hannes MühleisenとMark Raasveldtが引き続き技術的な方向を率いる。AWSが掲げた理由はエージェントだ。エージェントはアナリストと同じやり方で、1テラバイト以下のデータに小さな反復クエリを投げて探索する。根拠はAWS自身のもので、Amazon QuickはすでにS3 Tables上でDuckDBを動かし、25億件以上のクエリを処理して平均レイテンシを30%下げている。

プラットフォームチームにとっての率直な読み方は2つある。第一に、データ担当がすでにノートブックで動かしているインプロセスエンジンが、何らかの形でAthena、Redshift、EMR、Glue、SageMakerの内部に現れることになる。つまりAWS上の「スモールデータ」の経路は、2GBのParquetファイルを待ち構えるSparkクラスターではなくなる。コストにとっては良い知らせだ。第二に、オープンソース企業の買収にはプレスリリースの内容に関係なく同じ問いが付いてまわり、ここでの答えはライセンスと財団の構造にある。MITということは、ガバナンスが逸れたときにフォークが容易ということだ。新機能が最初にどこに着地するか、公開リポジトリかAWSサービスかを見ておくこと。見るべき兆候はそこであって、ライセンスの文言ではない。

ECS: 見えなかった障害にヘルスイベントが付く

エージェントがコントロールプレーンとの接続を失ったECSコンテナインスタンスは、独特な壊れ方をしている。上のタスクはまだ動いているかもしれず、インスタンスはEC2のステータスチェックを通るが、ECSはそこに何も配置できず、停止も観測もできない。EBSの劣化、熱イベント、ネットワーク障害のいずれでも起こりうる。ECSはこれを継続的に監視するようになり、AGENT_CONNECTIVITYのコンテナインスタンスヘルス変更イベントを発行する。対象はFargate、ECS Managed Instances、ECS on EC2で、すべての商用リージョンとGovCloud (US)リージョンで追加費用はない。

重要なのはその分かれ目だ。FargateとManaged Instancesでは、ECSが復旧まで自分で行う。ワークロードをドレインし、代替キャパシティをプロビジョニングし、障害インスタンスを取り除く。ECS on EC2ではイベントと、その後の仕事が手元に届く。これは正しい設計で、EC2ではキャパシティプロバイダーはあなたのものであり、インスタンスの終了が安全かどうかをECSは知りえない。ただしこのローンチが役に立つのは、配線した場合に限るということでもある。最小構成は、このイベントに対するEventBridgeルールからaws autoscaling set-instance-health --health-status Unhealthyを呼ぶことだ。残っているEC2キャパシティプロバイダーをManaged Instancesに移す理由が欲しかったなら、これは具体的な理由になる。同じ週にAWS Batchがコンピューティング環境としてManaged Instancesを得た。CreateComputeEnvironmentのmanagedInstancesProviderブロック経由だ。

Lambdaの火曜日: ランタイム、ポリシー、プライベートエンドポイント

Node.js 26とPython 3.15がパブリックプレビューのランタイムとして到着した。設計上の判断が有用で、識別子はnodejs26.xとpython3.15、GAになっても同じものなので、関数は自動的にGAへ移る。この便利さの代償が罠になる。プレビューランタイムはLambdaのSLAとAWS Supportの対象外で、破壊的変更の可能性もある。つまり今日、共有のSAMテンプレートでpython3.15を指定した関数は、明日にはサポート外ランタイムの本番関数になる。CIでゲートすること。

完全なIAMリソースベースポリシーは、プリンシパルを1つずつ追加する権限モデルを、複数のプリンシパルとアクションを1つのポリシードキュメントで扱い、IAM条件キーを一式使えるモデルに置き換える。3つのサービスと外部アカウントから呼ばれる関数を管理したことがある人なら、旧モデルが誰にも読めないリソースポリシーを生んでいたことを知っている。これでポリシーがレビュー可能になり、CloudFormationとSAMを通じてdiffも取れる。さらにLambda MicroVMsがPrivateLinkに対応したので、VPC内のリソースからAWSネットワークを出ずにイメージを作成し、MicroVMを起動し、各MicroVMのHTTPエンドポイントを叩ける。これは、規制対象のチームがエージェントのサンドボックスとして使う際の障壁だった。

移行とDR: TransformがFedRAMPスコープに、DRSにランブックが付く

AWS TransformがFedRAMP Class C(旧Moderateベースライン)のスコープに入った。US East (N. Virginia)から使い、US EastまたはUS Westを対象とする場合が条件で、MGNコンポーネントは別途Class Dの要件を満たす。ツールのコンプライアンスで止まっていた公共部門の移行にとって、これが詰まりの解消になる。DRSのRecovery Plansでは、サーバーを待ち時間付きの順次ステップにまとめ、承認ゲートを加え、全体を無停止の訓練として実行し、進行をライブで見られる。Wikiのページに書かれていた「データベースの次にアプリ」という順序が、サービスが実行するオブジェクトになった。DR訓練が2回目を迎える唯一の方法でもある。

今週のその他

通底するテーマ

ECSのローンチとDuckDBの買収はどちらも、実際の仕事の多くが自社サービスの設計対象より小さな規模で起きていることをAWSが認めたものだ。コンテナインスタンス1台が沈黙するのはダッシュボードに載せるには小さすぎ、無視するにはありふれすぎている。1テラバイトのParquetはSparkには小さすぎ、そうでないふりをするにはありふれすぎている。2つの修正は同じ形をしている。小さな障害や小さなデータセットに気づき、ネイティブに処理し、顧客にクラスターやcronジョブを組ませて対処させるのをやめる。Lambdaのランタイムプレビューとリソースポリシーが同じ週に属するのは、それらもロングテールの話だからだ。誰もオーナーでなく、4つのプリンシパルから呼ばれ、2026年に誰かが設定したランタイムで動く関数。プラットフォームが信頼を得るのはロングテールであって、基調講演ではない。

次に読む

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

参考資料