8月17日の週で最も影響の大きいローンチは、通知が届くまで大半のチームが気づかないものだ。Amazon EKSが証明機関のローテーションを管理するようになった。これが存在するのは、2018年に10年物のCAで作られた最初のEKSクラスターが、その終わりに近づいているからだ。 その横で、Direct Connectが受信プレフィックスの上限を100から1,000に引き上げ、Europe (London)に4つ目のアベイラビリティゾーンが加わり、IAM Policy AutopilotがTerraformのplanファイルを読めるようになった。今週はAWS TransformもDMSのローンチもないので、移行の観点はネットワーキングの件になる。プレフィックス制限は大規模なハイブリッドカットオーバーの本物の障壁だった。

EKSのCAローテーション: 誰もチケットに入れなかった期限

すべてのEKSクラスターにはAPIサーバー証明書に署名するCAがあり、ローンチ以来作られたすべてのクラスターは10年間有効なCAを持っている。最初のものは2018年半ばにさかのぼる。そのCAが期限切れになると、それを信頼しているものは何もコントロールプレーンと話せなくなる。kubelet、kubectl、CIランナー、忘れていたオペレーター。新しいマネージドローテーションは安全装置付きのライフサイクルを与える。EKSが後継CAを追加し、AWSマネージドのコンポーネントがそれを信頼するよう更新し、EKS Auto ModeのインスタンスとFargateノードを自動で処理し、期限切れを事前に通知し、あなたが一度も行わなければ独自のスケジュールで後継CAを有効化し、以前のCAへのロールバックを残す。追加費用なし、全商用リージョン、CLI、EKS API、CloudFormation、コンソールから操作できる。

このリストはAWSがやらないことに注目して読むこと。自前のワーカーノードが後継CAを信頼するよう置き換えるのは引き続きあなたの仕事で、すべての外部クライアントの更新も同様だ。つまりCIシステムに焼き込まれたすべてのkubeconfig、すべての踏み台、certificate-authority-dataを固定したすべてのサードパーティツールだ。自動有効化は敬意を払うべき部分だ。期限切れに対する安全網だが、クライアントをローテーションする前に発火すれば、そのクライアントはAWSが選んだタイミングで壊れる。正しい動きは、今のうちに各クラスターと誰が話しているかを棚卸しし、自己管理ノードグループを通常のリフレッシュとして入れ替え、変更ウィンドウの中で自分で後継CAを有効化することだ。アカウント内で最も古いクラスターから始めること。aws eks describe-clusterとクラスターのcreatedAtがそれを教えてくれる。

Direct Connect: 1,000プレフィックスとキャパシティプール

プライベートVIFやトランジットVIFは、オンプレミスから広告されるルートプレフィックスを最大100までしか受け付けなかった。10年分のサブネットの増殖を抱えるデータセンターにとって、それは攻めた集約かVIFをまたいだ分割を意味し、移行の最中には、移行より長生きする「一時的な」サマリールートを意味した。受信プレフィックス制御により、専用接続とホスト接続のVIFごとにIPv4で最大1,000、IPv6で最大1,000のプレフィックスを割り当てられる。割り当ては専用接続とDirect Connectゲートウェイレベルの新しいキャパシティプールから引き出す。接続プールはリンク速度に応じて、LAGプールはメンバー数に応じてスケールする。追加費用なし、商用リージョン、GovCloud (US)、両中国リージョン。

触る前に理解すべきなのはプールモデルだ。キャパシティは共有予算なので、1つのVIFに900プレフィックスを割り当てたチームは、その接続上の他の全員のぶんのプールを使い切ったことになる。割り当てはコンソールのクリックではなくIaCとして扱い、最初のチームが頼んでくる前に分け方を決めておくこと。

リージョン: eu-west-2dとラスベガスのLocal Zone

Europe (London)にeu-west-2dが追加された。8月19日、Trn3とP6のアクセラレーテッドキャパシティに加えて汎用コンピュートを備える。新しいAZは無視しやすく、無視すると高くつく。VPCがティアごとに3つのサブネットとハードコードされたAZ名で作られているなら、誰かがサブネットを追加するまで4つ目のゾーンはAuto ScalingグループにもEKSノードグループにも見えない。その翌日、ラスベガスのLocal Zone(us-west-2-las-2a)がGAになった。C7i、M7i、R7i、C8gnインスタンス、gp3/gp2/io1/sc1/st1のEBSタイプ、ECS、EKS、ALB、Direct Connectを備える。

IAM: Terraform向けPolicy Autopilotと、ぶつからなくなったクォータ

IAM Policy Autopilotは、アプリケーションコードから絞り込んだポリシーを導出するre:Invent 2025発のオープンソースツールで、今やTerraformのplanファイルを受け取り、そのplan内のリソースに対する作成、読み取り、更新、削除に限定したベースラインポリシーを、可能なところでは具体的なARN付きで生成する。ローカルで動き、awslabs/iam-policy-autopilotにある。埋める溝は本物だ。Terraformパイプラインのデプロイロールはたいていアカウントで最も広いロールで、その理由はまさに、何が必要かを誰も列挙できなかったからだ。planから導出したベースラインは弁明可能な出発点になる。ただし注意点として、ある1つのplanからのベースラインは、次のplanに存在しないリソースのdestroyを網羅しない。別件で、ロールあたりのマネージドポリシーのデフォルト上限が10から20に倍増し、申請で25まで使える。「ポリシーが大きすぎるからもう1つアタッチする」という回避策の一群が引退する。

今週のその他

通底するテーマ

今週のローンチのうち3つは、プラットフォームが小さかった頃に決められた上限の話だ。2018年には永遠に見えた10年物のCA、ハイブリッドがデータセンター1つを意味した頃の100プレフィックスのVIF、誰もマネージドポリシーを十数個アタッチしなかった頃の10ポリシーのロール。AWSはそれぞれを引き上げるか自動化しており、歓迎すべきことだが、負担は消えない。移動するだけだ。CAローテーションはクライアントをあなたに残し、プレフィックスプールは割り当てポリシーを残し、Autopilotのベースラインはdestroyの経路を残す。プラットフォーム層の自動化はハードリミットを設計上の判断に変換し、設計上の判断にはオーナーが要る。

次に読む

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

参考資料