9月14日の週は、AWSがプラットフォームエンジニアリングを製品として売りに出した週だった。Elastic Beanstalk Cluster Modeはアプリケーション群を共有のフルマネージドEKSに載せ、新しいgetting-started体験は新規ビルダーに空のアカウントではなく設定済みのプロジェクトを渡す。 その下では、コンピュートが2つの方向で安くなり(T8iインスタンス、ECS Express ModeのARM64)、PrivateLinkはネットワークセグメント全体を共有するトンネルエンドポイントを得て、無視すれば監視を静かに壊す2つのID関連の変更が着地した。移行ツールは今週は静かだった(AWS TransformもDMSも動きなし)ので、プラットフォームの話が先頭に来る。

Elastic Beanstalk Cluster Mode: PaaSの論点、再び

9月17日、AWS Elastic BeanstalkがCluster Modeを導入した。複数のアプリケーションがAmazon EKSを基盤とする共有インフラの上で、フルマネージドで、1つの運用ベースラインのもとに動く。Java、.NET、Python、Node.js、PHP、Ruby、Goのソース(あるいはDockerfile、あるいはイメージ)をアップロードすると、Beanstalkは必要に応じてCloud Native Buildpacksでコンテナ化し、環境には自動ロールバック付きのトラフィックシフト型デプロイ、イベント駆動のオートスケーリング、Secrets Manager統合、OpenTelemetryによる可観測性、AI支援のトラブルシューティングが付く。Standard環境とCluster Mode環境は同じアプリケーションの中で共存するので、環境を1つずつ移行できる。

アプリケーション単位のコストの議論は、どの社内プラットフォームチームも共有EKSクラスターの予算を取るために持ち出してきたものだ。違いは誰が運用するかにある。AWSが、ワークロードの寿命の間ずっと運用し、あなたはノードもkubeconfigもアップグレードウィンドウも一度も目にしない。

小さなサービスが20個あってKubernetesに手を出す気がないなら、Cluster Modeはおそらく正しいデフォルトだ。すでにEKSを所有するプラットフォームチームがいるなら、Cluster Modeは同じワークロードをめぐってそのチームと競合し、提供する制御はより少ない。カスタムのアドミッションポリシーなし、ノードチューニングなし、CNIの選択なし。障害モードは共有プラットフォームが常に抱えるものと同じで、19個のアプリケーションには正しく20個目には間違っているベースラインのアップグレードだ。ただし今度は、その20個目は何もピン留めできない。制御を失っても構わないアプリケーションでパイロットすること。

より安いコンピュート、2つの道

9月17日、EC2 T8iインスタンスが一般提供になった。カスタムの第6世代Intel Xeon 6、第6世代Nitroカード、4つのサイズ(nano、micro、small、medium)、T3比で最大30%優れた価格性能、最大70%多いコンピュート、1.25倍のネットワーク帯域、2.4倍のEBS帯域。StandardとUnlimitedモードを持つ同じCPUクレジット方式なので、T3からの移行はインスタンスタイプの変更以外に何もない。t8i.microとt8i.smallはFree Tierに含まれる。

9月18日、ECS Express ModeがCPUアーキテクチャにARM64を追加した。「このイメージにURLをくれ」という経路がGravitonに着地できるようになり、AWSはx86比で最大40%優れた価格性能だとしている。新規および既存のExpress Modeサービスに対して、コンソール、CLI、SDK、IaCから設定できる。

どちらも、誰かが変更を加えたときにだけお金が節約される。大半のアカウントのT3フリートは踏み台、ビルドランナー、忘れられた社内ツールであり、Terraformの変数を1つ変えてインスタンスリフレッシュをかけるのが仕事の全部だ。Express ModeのARM64については前提条件がマルチアーキテクチャのイメージで、障害モードはamd64しか出荷していないベースイメージやネイティブ依存だ。docker buildx build --platform linux/amd64,linux/arm64でビルドしてマニフェストリストに仕事をさせ、それからアーキテクチャを切り替えること。

PrivateLink Tunnel Endpoints: サービスではなくCIDRを共有する

9月18日、AWS PrivateLinkがTunnel Endpointsを発表した。新しいVPCエンドポイントタイプだ。これまで外部の相手とリソースを共有するには、リソースごとに1つのResource Configurationが必要だった。今はResource Configurationが自分のネットワーク内のCIDR範囲を表せる。AWS RAM経由で共有すると、相手側はトンネルエンドポイントを作り、GENEVEカプセル化でその範囲内の何にでも到達する。トンネルエンドポイントごとの時間課金に加えて、処理データのGBあたり課金がある。

これはPrivateLink(1つのサービス、1つのエンドポイント、ルーティングの露出なし)と、Transit Gatewayやピアリング(完全なルーティング、双方向、そしてCIDRの交渉)の間の隙間を埋める。管理サブネット内の40台のホストに届く必要のあるベンダーは、以前なら重い方の選択肢を強いていた。今は指名したちょうどその範囲へのトンネルを得る。

GBあたりの課金があるので、これはコントロールプレーンの経路であって、バルクデータの経路ではない。誰かがバックアップをここに通す前にコストをモデル化すること。そして「CIDR範囲」は「サービス」より広い許可だ。その範囲内のセキュリティグループとNACLの規律は、いまや外部に向けた攻撃対象面の一部になるので、公開する範囲はDMZとして扱い、それに応じたサイズにすること。

ダッシュボードを壊す2つのID変更

9月14日、ルートユーザーのサインインがN. Virginiaに加えてUS East (Ohio)とUS West (Oregon)からも提供されるようになり、トラフィックは3つすべてに分散される。レジリエンスには良いが、ルートサインインのCloudTrail ConsoleLoginイベントは、処理したリージョンがどこであれそのリージョンに記録されるようになった。ルートログインのアラームがus-east-1のトレイル上のメトリクスフィルターなら、いまや捕捉できるのはルートログインのおよそ3分の1だ。今週中に組織トレイルへ移すか、他の2リージョンを追加すること。

9月15日、STSがセッショントークンの上限を単一の4,096バイトの上限に統合した。トークンサイズと、渡されるセッションポリシーおよびタグに対する別々の上限を置き換えるものだ。STSはトークンサイズと使用率をレスポンスで返し、CloudTrailに記録し、CloudWatchメトリクスを発行するようになった。新しいオプションパラメータで意図的に大きなトークンを発行できるので、プロキシやヘッダーがそれに耐えるかをテストできる。「packed policy too large」に当たったことがあるなら、これがその修正であり、テストパラメータはセッションタグに押し出される前にスタックが上限を扱えることを証明してくれる。

今週のその他

通底するテーマ

Cluster Modeと新しいビルダー体験は、2つのスケールで見た同じ製品だ。AWSがデフォルトを選び、それに伴う運用責任を引き受ける。代償は、全員のために選ばれたデフォルトは誰にも完璧には合わないことで、それが噛みつく場所(ノードチューニング、1リージョンを前提にしたルートログインのアラーム、2つの上限を前提にしたセッショントークン)は、まさに今週の小さめのローンチが触れた場所だ。AWSがプラットフォームを運用してもプラットフォームの仕事は消えない。ものを作ることから、そのデフォルトのどれが自分にとって間違っているかを知ることへ移るだけだ。

次に読む

同じ週のAIとエージェント側の読み解きはercan.aiで。AWS、クラウドアーキテクチャ、CI/CDパイプライン、Linux、GitHubやGitLab、そしてその周辺のプラットフォーム業務で実践的な支援が必要なら、コンサルティングはercanermis.comからどうぞ。

参考資料