毎週大量に出る発表のうち、自分の仕事や学習に関わるものはどれか。一覧を眺めるだけでは判断がつかず、結局読まずに流してしまう。今週は 2026年10月12日〜18日の発表から、判断に関わる5件を選んで、「何ができなかったのが、できるようになったか」の形で整理した。
この記事の結論
- Lambda に、HTTP サーバーとして書いたコードをそのまま載せられる Lambda Web Functions が加わった。既存の関数は名前が変わるだけ。
- CloudFront が Lambda Web Functions をオリジンにできるようになった。この機能自体に追加料金はない。
- ECS に LiveTaskCount が加わり、RunningTaskCount の追加料金がなくなった。
- ElastiCache for Valkey に、CloudWatch の事前構築ダッシュボード ElastiCache Insights が入った。
- STS のセッショントークンの制限が 4,096 バイトの1つにまとまり、サイズを監視できるようになった。
何が起きたか
AWS Lambda Web Functions
コードがポートを待ち受けて HTTP リクエストを直接処理する、Lambda の新しい形。Express や Hono のような使い慣れたフレームワークを、アダプターや特別な設定なしで載せられる。想定されている用途は、AI 推論のエンドポイント、サーバーサイドレンダリングの Web アプリ、ストリーミング API、Webhook など。1つの実行環境が複数のリクエストを同時に処理するので、コールドスタートが減ると説明されている。課金はアクティブな CPU 時間と、実行環境が持つメモリで、DB や下流サービスの応答を待っている間の CPU は課金されない。VPC 接続と、最寄りのリージョンで処理するマルチリージョンのルーティングにも対応する。既存の Lambda 関数は「Lambda Event Functions」に名前が変わるが、コードの変更は要らない。発表時点のランタイムは Node.js のみで、提供リージョンは米国東部（バージニア北部・オハイオ）、米国西部（オレゴン）、東京、アイルランドの5つ。同時実行数や最大実行時間などの上限、単価は、開発者ガイドと料金ページで確認してほしい。公式発表
CloudFront：Lambda Web Functions をオリジンに
CloudFront の後ろに Lambda Web Functions を置けるようになった。エッジでの TLS 終端、キャッシュ、マネージド証明書つきのカスタムドメインを、アプリのコードを変えずに使える。Origin Access Control を使うと、CloudFront を経由しない直接のアクセスを防げる。独自の認証を持つアプリでも、元の認証情報がアプリに届くので、既存のサインインの流れを保てる。この機能自体の追加料金はなく、中国リージョン以外で使える。CloudFront と Lambda それぞれの通常の利用料金は、ここで言う追加料金とは別に見ておく。公式発表
Amazon ECS：LiveTaskCount と RunningTaskCount の課金廃止
ECS のサービスに、実際に動いているタスクの数を返す LiveTaskCount が加わった。追加料金なしで、Container Insights をオプトインしなくても使える。数えるのは起動中・稼働中・停止に向かっているタスクのすべて。たとえばスケールイン中で、コネクションドレイニングの最中のタスクも入る。一方、Container Insights の既存メトリクス RunningTaskCount は、現在の状態も目標の状態も RUNNING のタスクだけを数える。こちらは今回から追加料金がかからなくなった。料金変更は自動で適用され、対応は要らない。ECS が使える全リージョンで利用できる。公式のページには、料金変更の適用開始日が投稿日より前の日付で書かれていたため、請求への影響を厳密に見たい場合は、公式の料金ページで確認してほしい。公式発表
ElastiCache for Valkey：ElastiCache Insights
ノードベースの Valkey クラスターを対象に、ヘルス、メモリ、コンピュート、ネットワーク、コマンドのスループット、レイテンシー、キースペース、エラーを一画面で見られる CloudWatch のダッシュボードが加わった。元になるのは、ElastiCache が自動で発行する OpenTelemetry のメトリクス。クラスター、シャード、ノード、アベイラビリティーゾーンの単位で絞り込める。保存したダッシュボードを複製して、独自のダッシュボードの出発点にもできる。詳細モニタリングを有効にすると15秒間隔になり、その分は CloudWatch の OpenTelemetry メトリクスの料金がかかる。CloudWatch が OpenTelemetry メトリクスに対応しているリージョンで使える。公式発表
AWS STS：セッショントークンのサイズ制限の簡素化
STS は、パックされたポリシーのサイズ制限と、トークン全体のサイズ制限という2つの制限を、トークンの大きさ 4,096 バイトという1つの制限に置き換えた。超えたときの例外 PackedPolicyTooLargeException は同じだが、メッセージに現在のサイズと上限が出る。成功時のレスポンスに SessionTokenSize と SessionTokenUtilization が入り、CloudWatch の AWS/STS 名前空間と CloudTrail でもサイズを追える。MinimumSessionTokenSize を指定すると、トークンを大きくして、下流の仕組みが耐えられるかを事前に試せる。4,096 バイトは現時点の上限で、将来引き上げられる可能性があるので、コードに固定しないよう勧められている。公式ブログ（日本語）
仕組みとして何が変わったか
Lambda の「関数」はイベントを受けるハンドラーとして書くものだった。Web Functions では、HTTP サーバーそのものを置ける。
| 発表 | できなかったこと | できるようになったこと |
|---|---|---|
| Lambda Web Functions | 標準の HTTP サーバーを、ハンドラーに書き換えずに Lambda へ置く | ポートを待ち受けるサーバーをそのまま置く |
| CloudFront × Web Functions | （Web Functions が新しいため、組み合わせる前提がなかった） | エッジで TLS・キャッシュ・OAC をかける |
| ECS LiveTaskCount | 停止に向かうタスクを含めた台数を、追加設定なしで見る | 全状態のタスク数を無料のメトリクスで見る |
| ElastiCache Insights | 自分でダッシュボードを組む | 事前構築の一画面で状態を見る |
| STS トークン | どちらの制限に当たったか判別しにくい | 単一の上限と、サイズの可視化 |
責任の動きも見ておく。Web Functions では、HTTP サーバーとしてのリクエスト処理（同時実行を前提にしたコード、状態の持ち方）が、アプリ側の設計に戻ってくる。1つの実行環境が複数のリクエストを同時に受けるため、リクエストごとの状態をグローバル変数に置く書き方は避ける。
どんなものに活用できそうか
- 既存の Node.js アプリを Lambda に寄せる。 Express や Hono で書いた小さな API やサーバーサイドレンダリングのアプリを、書き換えずに Lambda に置く。使っていない時間の費用が抑えられる可能性がある。ただしランタイムが Node.js のみで、提供リージョンも5つに限られるので、先に条件を確かめる。
- CloudFront の背後に置いて入口を固める。 OAC で直接アクセスを塞ぎ、WAF を併用する。キャッシュできる応答はエッジで返す。
- オートスケーリングと容量計画の指標にする。 ECS のサービスで、スケールイン中のタスクも含めた台数を LiveTaskCount で見て、ドレイニングの長いサービスの余力を判断する。
- キャッシュの障害調査を一画面から始める。 ElastiCache for Valkey で、メモリや接続数が上限に近づいたノードを、ダッシュボードで先に絞る。
- 属性ベースのアクセス制御のトークンを点検する。 セッションタグやセッションポリシーを多用している環境で、
MinimumSessionTokenSizeを使い、ロードバランサーやデータベースの列幅が 4,096 バイトに耐えるかを確かめる。
使わない方がよい場面もある。Node.js 以外のランタイムが必要なアプリや、5リージョンの外で動かしたい処理には、Web Functions はまだ選べない。そのときは既存の選択肢（ECS や Lambda Event Functions）を使う。
立場ごとに何が変わるか
- 未経験: いまは関係ない。サービス名を覚える段階では、更新の中身より「Lambda は何のためのサービスか」を先に押さえるほうが効く。
- 学習中: Lambda は「イベントで動く関数」という説明が、「HTTP サーバーも置ける」に広がった。AWS 認定の試験は版ごとに範囲が決まるので、出題への反映は試験ガイドで確かめる。ECS のメトリクスと STS の仕組みは、SAA・DVA・SOA の分野の知識を現行の状態に更新する材料になる。
- 実務: Web Functions は、小さな Web アプリや API の置き場所の候補に加わる。ECS の LiveTaskCount と STS のサイズ監視は、すでに運用している環境の見直しにそのまま使える。
- プロ: 同時実行を前提にしたアプリの設計、CloudFront 経由に固定する入口の統制、トークンサイズが下流に与える影響の検証が、設計レビューの論点になる。
まとめ
今週の中心は、Lambda に HTTP サーバーをそのまま置ける形ができたこと。CloudFront の対応で、入口の設計まで一続きに考えられる。ECS・ElastiCache・STS の更新は、運用で「見えるもの」を増やす方向の変更だった。Web Functions は Node.js のみ・5リージョンという条件つきなので、飛びつく前に条件を確かめる。
CHECK 1ここまでの確認
Lambda Web Functions が、これまでの Lambda 関数と大きく違う点はどれか?
答えと解説
答え: 2. コードがポートを待ち受け、通常の HTTP サーバーとして動く
「何が起きたか」の Lambda Web Functions の項を読み直す。Express や Hono のような既存フレームワークを、アダプター無しで載せられるのが要点。
CHECK 2ここまでの確認
ECS の LiveTaskCount が数えるタスクとして正しいのはどれか?
答えと解説
答え: 2. 起動中・稼働中・停止に向かっているタスクのすべて
RunningTaskCount との違いは「停止に向かうタスクを含むか」。スケールイン中のドレイニング中のタスクも LiveTaskCount には入る。
CHECK 3ここまでの確認
STS のセッショントークンについて、今回の変更後に守る制限はどれか?
答えと解説
答え: 2. トークン全体の単一のサイズ制限（4,096 バイト）
2つあった制限が1つにまとまった。ただし上限は将来変わりうるので、数値をコードに固定しない。
参照ソース
- AWS Lambda announces Lambda Web Functions（2026年10月時点）
- Amazon CloudFront now supports AWS Lambda Web Functions as an origin（2026年10月時点）
- Amazon ECS adds LiveTaskCount and removes the charge for RunningTaskCount metric（2026年10月時点）
- Amazon ElastiCache for Valkey introduces ElastiCache Insights（2026年10月時点）
- AWS STS のセッショントークンのサイズ制限を簡素化、サイズのモニタリングにも対応（2026年10月時点）
