8月10日の週は、プラットフォームチームが手で下していた判断をAWSが引き受ける週だった。そのうち2つは、デフォルトを受け入れる前にもう一度見直す価値がある。 EC2のapplication status checksにより、EC2自身がインスタンス上のHTTPエンドポイントを叩き、その結果をAuto Scalingに渡せるようになった。そしてIAM role managerがGAになり、コンソールをクリックしていく間にサービスが必要とするIAMロールを作ってくれる。今週はさらに、ACMがメール検証の終了日を定め、MSKがクラスターをZooKeeperからKRaftへインプレースで移行できるようになった。AWS Transformのローンチはなく、モダナイゼーション関連はMSKの件と、より静かなElastic Disaster Recoveryの修正だった。

EC2のapplication status checks: ロードバランサーなしのヘルスチェック

これまでEC2のステータスチェックは2つだった。system(ホスト)とinstance(ゲストOS)だ。新しいapplication status checkは3つ目の層を加える。プロトコル、ポート、パスと、正常とみなすレスポンスコードを定義し、チェックをインスタンスIDまたはタグで関連付けると、EC2が60秒ごとにHTTPまたはHTTPSリクエストを送り、他の2つの隣に結果を報告する。Auto Scalingグループは失敗したインスタンスを置き換えられる。全商用リージョンとGovCloud (US)で利用可能。

当然の疑問は、ALBのターゲットグループがすでに同じパスをヘルスチェックしているのに、なぜこれが欲しいのかだ。答えは、ロードバランサーの後ろにいないすべてのインスタンスだ。SQSから引くワーカー、スケジューラー、デーモンが死んでもインスタンスはICMPに応答し続けるDockerホスト。こうしたマシンは今日、EC2が持つあらゆるシグナルで「正常」であり、オンコールは顧客からそうでないことを知る。設計で備えるべき障害モードは逆方向のものだ。下流(データベース、キャッシュ)に依存するヘルスエンドポイントは、下流が一瞬揺れたときにフリート全体を落とす。ASGが問題のなかったインスタンスを置き換えてしまうからだ。叩くパスは浅く保つこと。またタグベースの関連付けは、タグのタイプミスで黙ってフリートの半分が未チェックのまま残ることを意味するので、展開後にaws ec2 describe-instance-statusで監査すること。

IAM role manager: 便利で、Lambdaのデフォルトは広い

Role managerは対応コンソール(ローンチ時点で6つ、LambdaとEventBridgeを含む)で設定している内容を見て、デフォルトロールを作るか、アカウント内にすでに条件を満たす既存ロールがあればそれを再利用する。新しいAcquireRole APIがAWSマネージドのロールテンプレートと照合する。ロールは完全にあなたが制御する通常のIAMロールで、IAMコンソールのアカウントレベルの設定1つであり、新しいAWS体験で作成されたアカウントではデフォルトで有効になっている。GovCloud (US)と中国では利用できない。

判断を左右すべき細部はセキュリティブログの記事にある。Lambda関数の権限はコードが存在する前には分からないため、関数が受け取るロールはPowerUserAccessを持つ。IAM、Organizations、アカウント設定は除くが、それ以外のすべてを含む。AWSの答えは、後でIAM Access Analyzerを走らせて絞り込むことだ。開発サンドボックスの話としては妥当で、本番の話としては悪い。「後で」は決して出荷されないステップだからだ。アカウントがすでにTerraformやCDKでロールをプロビジョニングしているなら、無効にし、メンバーアカウントが再び有効にできないようSCPを使うこと。記事はSCPで制御できることを確認している。サンドボックス向けに有効にしたいなら、同じ週のaccount access managerと組み合わせること。アカウント内のIAMロールをIdentity Centerのユーザーとグループに割り当てるもので、少なくともその広いロールを持つ人間はフェデレーションされる。

ACMのメール検証は2027年に終わり、日程は段階的

CA/Browser Forumの2025年11月の決定を受け、ACMはメール検証のパブリック証明書のサポートを3段階で終える。2027年1月1日以降は新規リージョンでメール検証なし、2027年3月31日以降はどこでもメール検証の新規リクエストなし、2027年9月30日以降は既存のメール検証証明書の更新なし。業界の期限前に発行された証明書は期限まで有効なので、その日に壊れるものはない。壊れるのは1年後の更新で、誰もリクエストした覚えのない証明書だ。

今やれば移行は安い。ACMコンソールを検証方法Email、種類Amazon Issuedでフィルターするか、スクリプトで拾い、各証明書をaws acm update-certificate-optionsでその場で切り替える。ARNが保たれるので、リスナーやディストリビューションの編集は不要だ。72時間の窓の中でCNAMEを追加すれば、ACMは新しい方法で更新する。HTTP検証もあるが、CloudFront限定だ。これは2027年ではなくQ3のチケットとして扱うこと。

MSK: 新しいクラスターなしでZooKeeperからKRaftへ

Kafka 3.9.xはZooKeeperをサポートする最後の系列で、Kafka 4.xはKRaftのみだ。したがってZooKeeperのままのプロビジョンドMSKクラスターには、すべて移行が待っている。MSKはこれをインプレースで行う。新しいインフラなし、データコピーなし、クライアントの再設定なしで、AWSによればクラスターは全期間利用可能なままだ。まず3.9.xにいる必要がある。European Sovereign Cloudを除き、プロビジョンドMSKが動くすべての場所で利用できる。これは機能がくっついていないせいで優先されることのない種類のモダナイゼーションで、だからこそワンボタンの道が重要になる。四半期がかりのプロジェクトを変更ウィンドウ1つに変えるからだ。

今週のその他

通底するテーマ

application status checksとrole managerは、同じ動きの2方向だ。一方はEC2にアプリケーションを観察させ、あなたの代わりに行動できるようにする。もう一方はIAMに、あなたが何かを観察する前に代わりに行動させる。前者は良い取引だ。悪いヘルスチェックの爆発半径は1つのフリートで、しかも騒がしいからだ。後者はより悪い取引だ。広いロールの爆発半径はアカウントで、しかも静かだからだ。ACMの期限とMSKの移行は、プラットフォーム業務の華のない半分、つまり更新とバージョンの下限こそが本物の障害の住む場所だという注意喚起だ。日付の付いた3件を今週カレンダーに入れ、role managerについては時間のあるときに議論すればいい。

次に読む

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

参考資料