本ブログは 2026 年 7 月 29 日に公開された AWS Blog “ Secure your npm and pip package updates in Amazon Linux ” を翻訳したものです。 npm や PyPI からパッケージをインストールして使用している場合、パッケージが公開されてからの数時間が最もリスクの高い期間です。スキャナーは公開前のパッケージを分析できないためです。Node.js と Python のパッケージに影響を与えた最近のサプライチェーンイベントは、数時間以内に検出され、削除されています。しかし、それらのパッケージが一般に公開されていた間にユーザーがインストールしていた可能性があり、セキュリティインシデントにつながるおそれがありました。この後で示すデータからわかるように、ユーザーがそれらのパッケージの利用を 1 日待っていれば、最近のサプライチェーンセキュリティイベントはいずれも影響を及ぼさなかったはずです。 この記事では、お使いの環境がこのリスクにさらされるのを防ぐ 1 行の設定として、npm と pip の依存関係のクールダウンを紹介します。この設定により、パッケージマネージャーは過去 24 時間以内に公開されたバージョンをスキップするようになります。その結果、予期しないパッケージがシステムに到達する前に、セキュリティコミュニティがそれらを検出して削除する時間を確保できます。これらの設定で、デフォルトの構成を保護できます。一方、パッケージの更新には、セキュリティリスクに対処するためのセキュリティ修正を受け取るという、もう 1 つのユースケースがあります。この場合は、パッケージをより新しいバージョンに更新します。この記事では、クールダウン設定をオーバーライドする方法も紹介します。この方法を使用すると、新たにインストールするパッケージの更新は遅延させたまま、最新のセキュリティパッチをインストールできます。コードの欠陥の重大度を評価し、既知のリスクがある場合はセキュリティ修正を適用することをお勧めします。重大度に基づくセキュリティ修正の扱い方や、重大度に応じたセキュリティ修正の SLA の指定方法は、このブログ記事の範囲外です。 背景: 相反する 2 つのリスク Amazon Linux のパッケージで提供されるソフトウェアは、リリース前に Amazon のパッケージメンテナーによるレビューを受け、ガードレールを通過します。オープンソースソフトウェアも、同様のプロセスとガードレールの下で開発、保守されています。一方、npm と PyPI のレジストリは誰でもパッケージを公開でき、レビューも必須ではありません。そのため、なりすましや盗まれた認証情報などが原因で、予期しないパッケージがレジストリに追加される可能性があります。つまり、2 つのリスクの板挟みになります。古いソフトウェアにはパッチが適用されていない脆弱性が蓄積していく一方で、新しいパッケージにはまだ検出されていない予期しない脆弱性が含まれている可能性があります。最善のアプローチは、最新のリリースをすぐには採用せずに十分に新しい状態を保ちながら、推奨されるセキュリティ修正を適用することです。次の図は、2 種類のリスクの関係を抽象的に示しています。予期しない更新はガードレールを回避する可能性があるため、サプライチェーンのリスクはパッケージの公開直後に最も高くなります。パッケージの公開後は、監査でその内容をレビューし、時間の経過とともに潜在的な欠陥を特定できます。セキュリティ修正を適用しなければ、コードのあらゆる欠陥によるリスクが積み重なっていきます。 図 1: ソフトウェアのライフタイムを通じたリスク。パッチが適用されていない脆弱性のリスクは、時間の経過とともに増加します。また、公開されたばかりのソフトウェアは、サプライチェーンのリスクも高くなります。 問題: 最初の 1 日のリスクが最も高い サプライチェーンイベントには一貫したパターンがあります。想定外の作成者が、予期しないパッケージまたはパッケージバージョンを公開し、自動化されたシステムやユーザーがそれを取り込むのを待ちます。セキュリティ研究者や自動スキャナーは通常、数時間以内にこれらのパッケージを検出して削除しますが、その時点で既にシステムはリスクにさらされています。 Datadog の 2026 State of DevSecOps レポート によると、JavaScript アプリケーションの 54% が、少なくとも 1 つの依存関係を、そのリリースから 1 日以内にインストールしています。この時間枠こそが、サプライチェーンのリスクが最も高い期間です。最近のイベントを見ると、検出がいかに迅速に行われているかがわかります。 イベント リスクにさらされる期間 Nx s1ngularity (2025 年 8 月) 4～5 時間 axios (2026 年 3 月) 2～3 時間 Bitwarden CLI (2026 年 4 月) 93 分 TanStack (2026 年 5 月) 30 分 node-ipc (2026 年 5 月) 24 時間未満 解決策: 当日に公開されたパッケージをスキップする 依存関係のクールダウンは、最近公開されたバージョンをスキップするようパッケージマネージャーに指示する仕組みです。レジストリに公開されてから設定した期間 (例えば 1 日) が経過していないバージョンはインストールされないため、セキュリティコミュニティが予期しないバージョンを検出して削除する時間を確保できます。 1 日のクールダウンを設定すれば、前述の表に記載したイベントをすべてブロックできます。注目すべきは、これらのイベントのいくつかでは有効な来歴証明 (provenance attestation) が生成され、ビルド検証にも合格していた点です。つまり、来歴チェックだけではこれらのイベントを阻止できませんでした。クールダウンは信頼ではなく経過時間に基づいてブロックするため、認可メカニズムとは独立して機能します。 npm (v11.10.0 以降) と pip (v26.1 以降) は、どちらもクールダウンをサポートしています。Amazon Linux 2023 では、 リリース 2023.12.20260608 以降、Node.js 24 と Python 3.14 でこれらのパッケージを提供しています。 固定されたバージョンを指定した npm ci または pip install -r requirements.txt によるロックファイルベースのインストールでは、最新のパッケージ更新は取り込まれません。これらのインストールには、クールダウンは適用されません。クールダウンが影響するのは、新規または更新されたパッケージの解決のみです。詳細については、 「ロックファイルベースのインストールとクールダウン」 セクションを参照してください。 前提条件 次のソリューションを実装するには、以下の前提条件を満たしている必要があります。 Node.js 24 と npm 11.10.0 以降 (nodejs24-24.14.1-1.amzn2023.0.1 以降に含まれる) Python 3.14 と pip 26.1 (python3.14-pip-26.1.1-1.amzn2023.0.1 以降に含まれる) pip-audit (Python パッケージをスキャンするツールで、既知の欠陥に基づいてクールダウンをオーバーライドするスクリプトに必要)。インストールするには、 python3.14 -m pip install pip-audit を使用します。 Node.js と Python の今後のバージョンでは、新しいコマンドが導入されます。以下のツールコマンドは、Node.js 24 と Python 3.14 を使用する Amazon Linux 2023 で動作します。記載しているコマンドは特定のパッケージバージョンを対象としているため、それ以降のリリースを使用する場合はコマンドを調整してください。 npm のクールダウンを設定するには Node.js のバージョンに応じたグローバル設定ディレクトリを作成します。 sudo mkdir -p /usr/lib/nodejs24/etc クールダウン設定を含む npm 設定ファイルを追加します。 sudo npm-24 config set min-release-age 1 --location=global 次のコマンドを実行して、クールダウンが有効になっていることを確認します。 npm-24 config list 出力に before = "<timestamp from 24 hours ago>" と表示されれば、npm が 1 日のクールダウンを日付フィルターに変換したことを確認できます。 詳細については、 npm min-release-age のドキュメント を参照してください。 pip のクールダウンを設定するには クールダウン設定を含むシステム全体の pip 設定ファイルを作成します。 sudo python3.14 -m pip config set --global global.uploaded-prior-to P1D 設定を確認します (Python 3.14 および pip 26.1 以降の場合)。 python3.14 -m pip config list 出力に global.uploaded-prior-to='P1D' と表示されます。 古いバージョンの pip (25.x) はこの設定を警告なしで無視するため、この設定はすぐにデプロイしても問題ありません。 クールダウンなしでパッケージの最新バージョンをインストールするには セキュリティ修正を受け取りたい場合など、パッケージの最新バージョンをインストールするにはどうすればよいでしょうか? 以下のセクションでは、ツールのコマンドラインでフラグをオーバーライドする方法を説明します。緊急の更新が必要なパッケージを特定するには、使用しているパッケージマネージャーに対応する監査コマンドを実行します。 npm audit または python3.14 -m pip_audit npm パッケージの場合 クールダウンをオーバーライドしてパッケージをインストールします。 npm-24 install <package-name> --min-release-age=0 pip パッケージの場合 クールダウンをオーバーライドしてパッケージをインストールします。 python3.14 -m pip install <package-name> --uploaded-prior-to="P0D" 緊急の更新が必要なパッケージを更新する 既知のセキュリティリスクがあるパッケージには、セキュリティ修正を適用することをお勧めします。セキュリティ修正を適用するために、クールダウンを完全に無効にする必要はありません。監査ツールで既知の問題があるパッケージを特定し、それらのパッケージに限ってクールダウンをオーバーライドします。 前提条件: Python 3 と pip-audit がインストールされていることを確認してください (python3.14 -m pip install pip-audit)。 重要: これらのスクリプトは考え方を示すためのものです。本番環境で使用する場合は、エラー処理、ログ記録、テストを追加してください。また、自動化されたパイプラインでパッケージを更新する前に、パッケージをレビューしてください。 npm パッケージの場合 次のスクリプトは、既知のセキュリティ修正がある npm パッケージを特定するために必要な手順を示しています。npm audit コマンドは、該当するパッケージを JSON 形式で出力します。次に、npm install コマンドでこのリストのパッケージを更新します。このとき、最新バージョンが取得されるようにクールダウンをオーバーライドします。 npm audit --json | python3 -c " import json, sys, subprocess data = json.load(sys.stdin) for pkg in data.get('vulnerabilities', {}): subprocess.run(['npm-24', 'install', f'{pkg}@latest', '--min-release-age=0']) " pip パッケージの場合 次のスクリプトは、既知のセキュリティ修正がある pip パッケージを特定するために必要な手順を示しています。pip_audit コマンドは、該当するパッケージを JSON 形式で出力します。次に、クールダウンをオーバーライドする pip install コマンドで、このリストのすべてのパッケージを更新し、最新バージョンを取得できるようにします。 python3.14 -m pip_audit --format=json | python3.14 -c " import json, sys, subprocess from packaging.version import Version data = json.load(sys.stdin) for dep in data.get('dependencies', []): pkg = dep['name'] vulns = dep.get('vulns', []) if not vulns: continue fix_versions = [v for vuln in vulns for v in vuln.get('fix_versions', [])] if not fix_versions: print(f'{pkg}: vulnerable but no fix published, skipping') continue fix = max(fix_versions, key=Version) print(f'Updating {pkg} -> {fix}') subprocess.run(['python3.14', '-m', 'pip', 'install', f'{pkg}=={fix}', '--uploaded-prior-to=P0D']) " ロックファイルベースのインストールとクールダウン 固定されたバージョンを指定して npm ci または pip install -r requirements.txt を使用する場合、クールダウンは適用されません。これらのコマンドは、パッケージが公開されてからの経過時間にかかわらず、ロックファイルで指定された内容をインストールします。クールダウンが影響するのは、新規または更新されたパッケージの解決のみです。 業界での採用: PyPI と Node.js のエコシステム全体で広がるクールダウンの利用 主要なパッケージマネージャーや企業が、依存関係のクールダウンを採用し始めています。2026 年 5 月時点で、広く使われている複数のパッケージ管理ツールにクールダウン機能が搭載されています。具体的には、pnpm (高速な Node.js パッケージマネージャー)、Renovate (依存関係の自動更新ツール)、StepSecurity (サプライチェーンセキュリティプラットフォーム) です。 pnpm 11 では、 minimumReleaseAge がデフォルトで有効になっています。pnpm は、クールダウンをオプトインではなくオプトアウト方式にした最初の主要なパッケージマネージャーの 1 つです。 Renovate の config best-practices プリセットには 2025 年から 3 日間の npm クールダウンが含まれており、多くの企業で採用されています。 StepSecurity Secure Registry は、エンタープライズ顧客向けに、設定可能なクールダウン期間を採用しています。StepSecurity は、デフォルトとして 10 日間の遅延を推奨しています。 AWS によるオープンソースサプライチェーンの保護への取り組み AWS は、予期しないパッケージがお客様に届く前に検出できるよう、アップストリームのパッケージレジストリをスキャンしています。 Amazon Inspector は、ソフトウェアの脆弱性とネットワークの露出がないかワークロードを継続的にスキャンするセキュリティ管理サービスで、AI 支援の検出ルールを使用してアップストリームのパッケージレジストリもスキャンしています。2025 年には、Amazon Inspector の研究者が、トークンファーミングキャンペーンに関連する 15 万件以上の予期しない npm パッケージを特定 しました。 AWS Security は、 Shai-Hulud ワーム と axios イベント に関する詳細な対応ガイダンスを公開しました。 AWS は、 Open Source Security Foundation の 1,250 万ドル規模のオープンソースセキュリティ助成金 に拠出し、エコシステム全体に利益をもたらすプロアクティブなスキャンインフラストラクチャに資金を提供しています。 予期しないパッケージは通常、公開から数時間以内に検出されます。1 日のクールダウンを設定しておけば、この検出期間中にそれらのパッケージをインストールしてしまうことはありません。 推奨事項 Amazon Linux 2023 の設定を保護するには、以下を実施してください。 1 日のクールダウンを設定する : 前述のセクションで示したとおり、npm と pip に設定します。外部レジストリには人によるレビューがないため、防御側が問題を検出できる時間を確保してください。 必要に応じてオーバーライドする : 緊急のセキュリティパッチを適用する場合は、コマンドごとのフラグを使用します。 npm audit または pip_audit を実行する : 定期的に実行し、すぐに対応が必要なパッケージを特定します。 クールダウンは 1 行の設定で有効にでき、すぐに保護が適用されます。 まとめ この記事で紹介したソリューションを実装すると、npm と PyPI の環境を、予期しないコードが入り込むケースの大半から保護できます。1 日の更新遅延により、最新のセキュリティ修正を適用できる状態を保ちながら環境を保護できます。環境をさらに保護する方法については、次のリソースを参照してください。 Node.js セキュリティのベストプラクティス npm min-release-age のドキュメント Pip Secure installs のドキュメント pip uploaded-prior-to のドキュメント OpenSSF Best Practices Amazon Linux 2023 のドキュメント Norbert Manthey Norbert は Amazon Linux チームのセキュリティエンジニアで、Amazon EC2 のハイパーバイザーとオペレーティングシステム全体にわたるプロアクティブなセキュリティに注力しています。オペレーティングシステムのデフォルト設定の強化、静的分析と AI 駆動の分析によるコードの問題の早期検出、Amazon Linux に同梱されるパッケージのサプライチェーンセキュリティの向上に取り組んでいます。また、これらのプロセス改善の自動化、ソフトウェア開発ライフサイクルへの組み込み、シフトレフトを提唱しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS をお届けします！ 10 月も後半に入り、朝晩はすっかり肌寒くなってきましたね。年末が近づくこの時期、「今年のうちに AWS 認定を取っておきたい」と考えている方も多いのではないでしょうか。 そんな方に向けて、Pearson VUE で Pearson Global Retake というキャンペーンが実施されています。対象の試験に不合格だった場合に、同じ試験を 1 回無料で再受験できるもので、AWS 認定も対象に含まれています。初回の受験は 11 月 17 日までに済ませる必要があり、無料の再受験は年明けの 2027 年 1 月 4 日から 4 月 7 日の間に受けます。利用には事前の申し込み (オプトイン) が必要で、対象外の試験もあるので、予約の前に条件を確認しておいてください。「もし落ちても次がある」と思えると、受験の一歩目が踏み出しやすくなりますね。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年10月12日週の主要なアップデート 10/12(月) Amazon OpenSearch Service がインデックスレベル暗号化をサポート Amazon OpenSearch Service で、インデックスごとに異なる AWS KMS カスタマーマネージドキーを使った保存時暗号化ができるようになりました。従来はドメイン全体で 1 つの KMS キーしか使えませんでしたが、本機能により同一ドメイン上でデータの所有者や機密性に応じてキーを分離できます。マルチテナントアプリケーションでテナントごとに専用キーで暗号化する、といった構成が 1 ドメインで組めます。OpenSearch 3.3 以降を実行する新規ドメインが対象で、東京リージョンを含む 14 リージョンで利用できます。機能自体の追加料金はなく、標準の AWS KMS と OpenSearch Service の料金で利用できます。 Amazon Bedrock AgentCore の短期メモリで取り込み・取得・ストレージのデータ量に基づく従量課金制を導入 Amazon Bedrock AgentCore Memory の短期メモリ (STM) の料金体系が、従来のイベント件数ベースの定額制 (0.25 USD/1,000 イベント) から、データ量に基づく従量課金制に変わりました。新料金は ingestion (書き込み) 1.00 USD/GB、retrieval (取得) 0.20 USD/GB、storage (保存) 0.10 USD/GB-月の 3 つのディメンションで構成されます。ingestion と retrieval は 1 イベントあたり最小 12 KB、最大 64 KB として課金され、storage は各イベントの実サイズで課金されます。小さなイベントを頻繁に書き込む会話型エージェントでは、月額コストが従来よりも抑えられるケースがあります。長期メモリ (LTM) の料金は変更ありません。AgentCore Memory が提供されるすべてのリージョンで適用されます。 AWS Lambda が Lambda Web Functions を発表 AWS Lambda に新しいコンピュート形態である Lambda Web Functions が追加されました。コードがポートをリッスンして HTTP リクエストを直接処理するモデルで、Express、Fastify、Hono などの Node.js フレームワークをアダプターなしでそのままデプロイできます (Next.js は standalone モードで、ホストとポートを指定する小さなエントリーファイルを追加すれば動作します)。1 つの実行環境が最大 128 の同時リクエストを処理し、課金はリクエスト数、アクティブ CPU 時間、実行環境のメモリ保持時間の組み合わせになります。DB や外部 API の応答を待つ時間には CPU 課金が発生しません。バージニア北部、オハイオ、オレゴン、東京、アイルランドの 5 リージョンで利用できます。 Amazon CloudFront が AWS Lambda Web Functions のオリジンサポートを開始 Amazon CloudFront のオリジンとして AWS Lambda Web Functions を直接指定できるようになりました。CloudFront を前段に置くことで、エッジでの TLS 終端、キャッシュ、ACM 証明書によるカスタムドメインを、アプリケーションコードの変更なしで利用できます。Origin Access Control (OAC) を設定すると、CloudFront 経由以外のアクセスを IAM 認証で拒否でき、CloudFront のエッジネットワークによるネットワーク層 DDoS 対策と AWS WAF によるアプリケーション層の保護を組み合わせられます。OAC は専用の署名動作により視聴者の Authorization ヘッダーをそのままオリジンへ渡すため、JWT や Cookie などアプリ独自のサインインフローは変更不要です。追加料金はなく、CloudFront 中国リージョンを除く全リージョンで利用できます。 10/13(火) Agent Toolkit for AWS でコーディングエージェントが SageMaker AI の高度な専門知識を活用可能に AWS AI/ML skill が Agent Toolkit for AWS のコアスキルとして提供されました。Kiro、Claude Code、Codex、Cursor などのコーディングエージェントが、モデルの選定、トレーニング、最適化、デプロイといった Amazon SageMaker AI の操作を自然言語ワークフローで実行できるようになります。従来 AWS Labs (awslabs/agent-plugins) で提供されていた skills とプラグインは Agent Toolkit for AWS に一本化され、今後はこちらが唯一のサポート対象の統合ポイントになります。skill は SageMaker Studio JupyterLab にプリインストールされており、追加料金なしで利用できます (エージェントが使用する AWS リソースの料金のみ発生します)。 Amazon SageMaker Studio がソーシャルサインインに対応し、新規 AI/ML 開発者の利用開始を簡素化 Amazon SageMaker Studio が、Google、GitHub、Apple の既存アカウントによるサインアップに対応しました。新規顧客は従来の AWS アカウント作成、コンソール操作、IAM 設定を行わずに、また多くの場合クレジットカード登録もなしで、設定済みの Studio 環境で基盤モデルのファインチューニング、評価、デプロイを開始できます。AWS 無料利用枠の無料クレジット (登録時に 100 USD、追加で最大 100 USD) が付与され、検証済み顧客は G5、G6、G6e、G4dn インスタンスへのデフォルト GPU アクセスをクォータ申請なしで利用できます。チームメンバーをメールで招待でき、招待された側も自分のメールアドレスでサインインして共有環境にアクセスできます。本機能は SageMaker Studio がサポートされるすべての AWS 商用リージョンで利用できます。 AWS Lambda durable functions が durable operation 数とチェックポイントペイロードの上限を引き上げ AWS Lambda durable functions の実行あたりの durable operation 数の上限が 3,000 から 30,000 に、チェックポイントペイロードサイズの上限が 256 KB から 1 MB に引き上げられました。operation 数の増加により、反復ループの拡大、長期間のポーリング、ステップ失敗時のロールバック処理など、1 回の実行でより多くの処理を行えます。1 MB のチェックポイントは Lambda 非同期呼び出し、Amazon SQS、Amazon EventBridge の最大ペイロードサイズと一致するため、これらのイベントソースから受け取ったイベント全体を 1 回の operation で永続化できます。新しい上限は durable functions が利用可能なすべてのリージョンに適用されます。 10/14(水) AWS Security Hub が優先順位付けのためのリソース重要度をサポート AWS Security Hub のエクスポージャー優先順位付けに、リソース重要度 (resource criticality) が追加されました。自動化ルールで「特定アカウントの全コンピュートリソースを Very High にする」といった明示的な設定ができるほか、設定なしでもタグとリソース名から重要度を自動推論します。重要度は Resources ページの列およびエクスポージャー検出の Impact assessment タブに表示され、ソート、フィルター、グループ化に使えます。Security Hub Essentials に追加料金なしで含まれ、全ユーザーに対して常時有効のため、有効化作業は不要です。Security Hub が利用可能なすべての AWS リージョンで利用できます。 AWS Lambda の再帰ループ検出が Amazon EventBridge カスタムイベントバスに対応 AWS Lambda の再帰ループ検出機能が、Amazon EventBridge カスタムイベントバスを経由する再帰ループの検出と自動停止に対応しました。Lambda Event Function がカスタムイベントバスにイベントを書き戻し、それが同じ関数を再度起動する構成で、同一イベントチェーンの呼び出しが約 16 回に達すると Lambda が後続の呼び出しを停止します。この機能はすべてのアカウントでデフォルトで有効であり、設定変更や追加料金は不要です。意図的に再帰を使う設計の場合は、PutFunctionRecursionConfig API で関数単位の無効化が可能です。EventBridge カスタムイベントバスが利用可能なすべての AWS 商用リージョンで利用できます。 10/15(木) AWS Resilience Hub の検出結果とテスト結果を AWS DevOps Agent でレビュー可能に 次世代 AWS Resilience Hub が AWS DevOps Agent と統合されました。レジリエンステストを実行すると DevOps Agent による調査が開始され、症状、根本原因、影響、観測された復旧アクション (Amazon Application Recovery Controller (ARC) のリージョン切り替え (Region switch) など) を含む構造化された分析結果を確認できます。また、障害モード評価 (failure mode assessment) の各検出結果から、その検出結果のコンテキストを引き継いだ状態で DevOps Agent との対話セッションを開始し、質問や調査を通じて緩和策を作成できます。利用を始めるには、Resilience Hub コンソールでサービスを選択し、サービス設定で DevOps Agent を構成します。東京リージョンでも利用可能です。 Amazon CloudFront が VPC origins の dual-stack サポートを発表 Amazon CloudFront の VPC origins が dual-stack (IPv4 / IPv6) に対応しました。これにより、プライベートサブネット内の Application Load Balancer (ALB)、Network Load Balancer (NLB)、EC2 インスタンスに対して、ビューワーからオリジンまでエンドツーエンドで IPv6 トラフィックを届けられます。従来、CloudFront から VPC origins への接続は IPv4 のみで、IPv6 でオリジンに接続するにはオリジンをパブリックサブネットに置く必要がありました。本アップデートにより、オリジンを非公開に保ったまま IPv6 のアーキテクチャ要件や規制要件を満たせます。VPC origins がサポートされるすべての AWS 商用リージョンで利用でき、追加料金はありません。 AWS Transform for full-stack Windows modernization が Aurora PostgreSQL のクロスリージョンデプロイに対応し、新たに 7 リージョンで利用可能に AWS Transform for full-stack Windows modernization が、変換後の Amazon Aurora PostgreSQL データベースを別リージョンへデプロイするクロスリージョンデプロイに対応しました。あわせて、従来のバージニア北部リージョンに東京リージョンを含む 7 リージョンが加わり、合計 8 リージョンで利用可能になりました。SQL Server の DDL ファイルをアップロードし、変換プランでターゲットリージョンを指定するだけで、スキーマ変換と Aurora PostgreSQL クラスターのデプロイを別リージョンに対して実行できます。依存する .NET アプリケーションの接続文字列や ADO.NET、Entity Framework のデータアクセスコードも同じワークフローで PostgreSQL 互換に更新されます。データレジデンシー、レイテンシー、ディザスタリカバリの要件に応じてデプロイ先を選択できるようになりました。 10/16(金) AWS Transform が Azure から AWS へのクラウドネイティブコード変換を発表 AWS Transform の .NET モダナイゼーションエージェントで、Azure SDK から AWS SDK へのアプリケーションコード変換機能の一般提供を開始しました。Azure Functions から AWS Lambda、Azure Blob Storage から Amazon S3、Azure Queue Storage から Amazon SQS への変換に対応し、Azure Cosmos DB から Amazon DynamoDB への変換はプレビューとして利用できます。エージェントがソースコード内の Azure SDK を自動検出し、アセスメントレポートとモダナイゼーションプランに変換オプションを提示するため、ユーザーは内容を確認、調整したうえで変換を実行できます。変換対象はアプリケーションコードのみで、Azure 側のクラウドインフラの移行は対象外です。バージニア北部、ムンバイ、東京、ソウル、シドニー、カナダ中部、フランクフルト、ロンドンの 8 リージョンで利用できます。 Reflection の Beam モデルが Amazon SageMaker JumpStart と AWS Trainium で利用可能に 米国の AI 企業 Reflection が初のオープンウェイトモデル Beam を公開し、Amazon SageMaker JumpStart から利用できるようになりました。Beam は総パラメータ 501B (アクティブ 23B) のスパース MoE モデルです。Reflection によると、SWE-bench Verified で 80.9% を記録するなど、コーディング、推論、エージェント系ベンチマークでオープンウェイトモデルとして高い水準の性能を持ちます。Apache 2.0 ライセンスのため、顧客は自社の AWS アカウント内でモデルを検査、カスタマイズ、運用でき、データを外部 API に送信せずにコーディングエージェントや自動化ワークフローを構築できます。あわせて AWS Trainium3 への移植と最適化も発表され、GPU 以外のコスト効率の高いデプロイ選択肢が示されました。現時点ではバージニア北部とオハイオの 2 リージョンで利用できます。 それでは、また来週お会いしましょう！ 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan のソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きな AWS サービスは Amazon Lightsail と Kiro で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。

2026 年 10 月 12 日、コードをイベントハンドラーに書き直さずに標準の HTTP ウェブアプリケーションを Lambda で実行できる新しいフォームファクターである AWS Lambda Web Functions を発表しました。Express、Hono、Fastify、Next.js、または任意の Node.js フレームワークで構築された標準のポートリスニングサーバーを 1 つのコマンドでデプロイできます。Lambda は、スケーリング、マルチリージョン分布、アクティブな CPU 請求を自動的に処理します。アダプター、管理するインフラストラクチャ、フレームワークのロックインはありません。 今回の発表により、AWS Lambda は 3 つの異なるフォームファクターを提供するようになりました。各フォームファクターは同じ Firecracker 分離テクノロジーに基づいて構築され、異なるプログラミングモデル向けに設計されています。 Lambda Event Functions は、すでに Lambda 関数として知られているものです。イベント駆動型の単一同時ハンドラーモデルとウォールクロック課金方式を採用しています。「イベント関数」という名前は、そのプログラミングモデル、つまり関数がイベントを受け取って処理し、応答を返すということを強調するためです。イベント駆動型プログラミングモデルは、イベント処理、キューコンシューマー、および他の AWS サービスによってトリガーされる呼び出しに最適です。 Lambda Web Functions は、マルチコンカレント実行とアクティブ CPU 課金が可能な HTTP ネイティブプログラミングモデルを使用しています。コードはポートでリッスンし、標準の HTTP リクエストを処理します。このプログラミングモデルは、複数の同時リクエストと I/O の多い処理が標準となっているウェブアプリケーション、API バックエンド、インタラクティブな HTTP ワークロードに最適です。 Lambda MicroVMは 、信頼できないコードやユーザーが生成したコードを実行するための顧客管理のライフサイクルを備えた、分離されたステートフルなサンドボックス環境を提供します。 この3つは互いに補完し合っています。アプリケーションでは、非同期バックエンド処理にはイベント関数、ユーザー向け API とサーバー側レンダリングレイヤーには Web Functions、インタラクティブなコード実行機能には MicroVM を使用する場合があります。これらはすべて同じ AWS アカウント内で同じ運用モデルを共有します。 なぜウェブファンクションなのか 最新のウェブアプリケーションでは、開発者が標準フレームワークを自由に使用して迅速に反復できるようにしながら、高速で一貫した応答時間で世界中のユーザーにサービスを提供する必要があります。今日これを構築するには、通常、複数のインフラストラクチャコンポーネントを組み立て、マルチリージョン展開を構成し、レイテンシーベースのルーティングを設定し、I/O待機による支払いを回避するための請求モデルのチューニングが必要です。開発者は、すでに所有しているHTTPサーバーをデプロイするのではなく、特定のコンピューティングモデルに合わせてアプリケーションコードを調整していることに気付くことがよくあります。 Lambda ウェブ関数はこの複雑さを解消します。各実行環境は複数のリクエストを同時に処理します（環境ごとに最大128の同時リクエスト）。つまり、各リクエストを新しいリクエストにマッピングする代わりに、大量の受信トラフィックがウォーム環境を共有できます。Web Functions はコードが使用する CPU 時間を計測するため、データベースクエリや API 呼び出しの待機時間が CPU をほとんど消費しません。メモリは、実行環境が存在する限り計測されます。サーバーサイドレンダリング、API バックエンド、トークン応答をストリーミングする AI 推論エンドポイントなど、I/O の多いウェブワークロードでは、これによりコンピューティングコストを削減できます。 試してみましょう はじめに、単純な Express.js サーバーを作成しました。これは node index.js を使用してローカルで実行するのと同じコードで 、Lambda 固有のアダプターやラッパーは必要ありません。 「エクスプレス」からエクスプレスをインポート; const アプリ = エクスプレス (); const [ホスト, ポート] = process.env.aws_lambda_http_Endpoint.split (':'); app.get ('/', (req, res) => { res.json ({メッセージ:'ラムダウェブ関数からこんにちは!'}); }); app.listen (ポート、ホスト、() => { console.log(`Server running on port ${port}`); }); ローカルでの実行との唯一の違いは、 AWS_LAMBDA_HTTP_ENDPOINT 環境変数です。Lambda はこの変数を、サーバーがリッスンする必要があるホストとポートに設定します。ローカルで実行するには、自分で設定します。たとえば、 AWS_LAMBDA_HTTP_ENDPOINT=127.0.0.1:3000 node index.js のように設定します。 コードの準備ができたら、 AWS コマンドラインインターフェイス (AWS CLI) を使用してデプロイしました。 aws lambda-web deploy --name my-web-app --code ./my-app 1 つのコマンド。事前のリソース設定はありません。CLIはソースをバンドルし、Webファンクションを作成し、最初のリビジョンを公開し、Webファンクションエンドポイントをアタッチして、1分以内にライブHTTPSURLを返しました。 リビジョンは、デプロイしたコードの不変のスナップショットです。エンドポイントは、トラフィックをリビジョンにルーティングしたり、トラフィックをリビジョン間で分割したりする HTTPS URL です。これらは、反復作業を行い、新しいコードへトラフィックをどのように移行させるかを制御するために使用するリソースです。 私はすぐにそれをテストしました： <shard-id>$ curl https://<domain-id>. .lambda-web.us-east-1.on.aws/ {「メッセージ」:「Lambda Web Functionsからこんにちは!」} 次に、自分のアプリケーションがヨーロッパとアジアのユーザーに低レイテンシーでサービスを提供できるようにしたかったのです。複数のリージョンで再デプロイしました。 aws lambda-web deploy --name my-web-app --code ./my-app \ --regions us-east-1,eu-west-1,ap-northeast-1 Lambda Web Functions は私のコードを 3 つのリージョンすべてに複製し、レイテンシーベースのルーティングを自動的に設定しました。これで、各リクエストは、ベストエフォート方式で 1 つのグローバル URL ( <domain-id>.lambda-web.global.on.aws ) を介して、呼び出し側のレイテンシーが最も低いリージョンにルーティングされるようになりました。。 コードを更新して同じデプロイコマンドを再度実行すると、CLIは既存の関数を検出し、新しいリビジョンをアップロードして、エンドポイントにそのリビジョンを指定しました。コード変更から本番稼働までの合計所要時間: 秒。 より段階的なロールアウトが必要なプロダクションワークフローでは、1 回の API 呼び出しでリビジョン間でトラフィックをシフトできます。 aws lambda-web update-web-function-endpoint \ --function-name my-web-app \ --endpoint-name dev \ --auto-deployment-mode Disabled \ --revision-weights 『[{「revisionId」: 「<current-revision-id>」, 「weight」: 90}, {「revisionId」: 「<new-revision-id>」, 「weight」: 10}]』 これにより、エンドポイントトラフィックの90％が現在のリビジョンに、10％が新しいリビジョンに送られるため、追加のツールなしでカナリアデプロイメントを行うことができます。 Amazon CloudFront と併用するとさらに便利に 静的コンテンツと動的コンテンツを組み合わせるアプリケーションの場合、ウェブ関数は Amazon CloudFront と併用するとうまく機能します。ウェブ関数エンドポイントを CloudFront ディストリビューションのオリジンとして選択できます。静的アセットはキャッシュから提供され、動的リクエストはWeb Functionにルーティングされるため、動的部分のサーバーレスコンピューティングで静的コンテンツのCDNパフォーマンスを実現できます。 ウェブ機能により、CloudFront のプライベートオリジンエクスペリエンスが向上します。 今回の起動では、代わりに CloudFront オリジンアクセスコントロール (OAC) をウェブ関数エンドポイントにアタッチします。CloudFront はオリジンへのリクエストに署名し、エンドポイントはディストリビューションのみがそれを呼び出すことを許可します。エンドポイントを公開したり、アプリケーションにカスタム認証を追加したりしなくても、CloudFront がすでに Amazon Simple Storage Service (Amazon S3) に提供しているのと同じプライベートオリジンパターンが得られます。 今すぐご利用いただけます AWS Lambda Web Functions は現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (東京)、および欧州 (アイルランド) でご利用いただけます。ウェブ関数は起動時に Arm64 で Node.js 24 (nodejs24.x) を実行し、Amazon 仮想プライベートクラウド (VPC) 接続をサポートします。これにより、関数が VPC 内に存在するリソースにアクセスできるようになります。 始めるには、最初の Web 関数を 1 分以内にデプロイしてください。 aws lambda-web deploy --name hello-world --hello-world 料金の詳細については、 AWS Lambda の料金表ページをご覧ください 。詳細については、 Lambda ウェブ関数のドキュメントを参照してください 。 原文は こちら です。