この記事について
- AWS 公式が公表している週刊 AWS やアップデート情報の中から、ネットワークリソース関連の情報を集約して把握するため、Claude を活用してサマリーを生成・出力しています。
- 週刊 AWS および AWS の最新アップデートを継続的にキャッチアップする習慣をつけるため。
- 各記事に対する感想は、自身で記載して投稿しています。
- タイトルに【備忘】と付けているのは、後から見返せるよう記録として残しておきたいためです。
はじめに
2026/08/03 週の AWS アップデートにおいて、ネットワーク関連として注目度が高いのは AWS Lambda の VPC 外関数向けネットワーク帯域幅拡張（最大 3,000 Mbps） です。
ネットワーク関連アップデート
週刊AWS – 2026/8/3週
AWS Lambda – VPC 外関数向けに最大 3,000 Mbps のネットワーク帯域幅
- 対象サービス: AWS Lambda（ネットワーク帯域幅）
- 概要: VPC に接続していない Lambda 関数に対して、最大 3,000 Mbps のネットワーク帯域幅が利用可能になりました。これまで VPC 外の Lambda 関数は帯域幅に制約があり、大量データ転送を伴うユースケースでボトルネックになるケースがありました。今回の拡張により、S3 や DynamoDB などへの高スループットアクセスが必要なワークロードにおいてもパフォーマンスが向上します。
-
ポイント:
- VPC 接続なしで高帯域幅が得られるため、VPC 設定コストや運用負荷を抑えつつスループット向上が可能
- データ転送量の多いバッチ処理・ETL・メディア変換ワークロードへの恩恵が大きい
- VPC 内 Lambda との使い分けを改めて検討するきっかけになるアップデート
感想
AWS Lambda が VPC 外の関数向けに最大 3,000 Mbps のスケーラブルネットワーク帯域幅を発表
業務で触れる機会はそう多くないものの、AWS Lambda は個人的に好きなサービスのひとつです。
これまでスケールの話題といえばメモリや CPU が中心でしたが、今回はネットワーク領域が拡張されたという内容です。
では、何が変わったのでしょうか？
VPC にアタッチしていない関数に限り、帯域がメモリ量に応じてスケールするようになりました。
公式クォータドキュメントに記載されている内容は以下の通りです。
Network bandwidth per execution environment: 625 Mbps. For functions not attached to a VPC, you can request an increase through the Service Quotas console. After approval, network bandwidth scales proportionally with memory, starting at 2,048 MB of memory and reaching a maximum of up to 3,000 Mbps at 10,240 MB. — Lambda quotas
日本語訳
実行環境あたりのネットワーク帯域幅：625 Mbps。
VPCに接続されていない関数については、サービスクォータコンソールから帯域幅の増量をリクエストできます。
承認後、ネットワーク帯域幅はメモリ容量に比例して拡張され、メモリ2,048 MBから始まり、10,240 MBで最大3,000 Mbpsに達します。
これまでと今後を比較した表も纏めてみました
| 項目 | これまで | 今後 |
|---|---|---|
| 実行環境あたりの帯域 | 625Mbps 固定 | メモリに比例してスケール(2,048 MB で 625 Mbps → 10,240 MB で最大 3,000Mbps) |
| メモリ増加による帯域改善 | なし(CPUのみ増える) | あり(CPU に加えてネットワークもスケール) |
| 適用対象 | 全関数一律 | VPC外の関数のみ／メモリ 2,048 MB以上 |
| VPCアタッチ関数 | 625 Mbps | 625 Mbpsのまま(対象外) |
| 有効化の要否 | ー(固定値) | Service Quotas から引き上げ申請が必要(自動適用ではないことに注意) |
| 対象リージョン | ー | 全商用リージョン |
| 追加料金 | ー | なし |
VPC内に適用している関数については対象外とのことで少し残念ではありますが、
大容量転送ワークロードの実行が可能となったことは新たなメリットの１つとして挙げられるようになったのは良いと思いました。
その他注目リリース
- Amazon DynamoDB がリアルタイムベクトル検索をサポート: DynamoDB 単体でベクトル検索が完結できるようになり、RAG 構成のシンプル化が期待できる注目アップデート
- Amazon Bedrock AgentCore の runtime instances が一般提供開始: 東京リージョンを含む各リージョンで最大 14 日間のエージェントセッションを自前の EC2 上で実行可能になり、長期エージェントワークロードの実用化が進む
- Amazon Aurora Serverless がバースト性ワークロード向けにスケーリングを高速化: 突発的なトラフィック増加への応答性が向上し、サーバーレス DB のユースケースがさらに拡大
- OpenAI GPT-5.6 Sol/Terra/Luna が Amazon Bedrock で 100 万トークンコンテキストウィンドウに対応: 超長文コンテキスト処理が Bedrock 上で利用可能となり、大規模ドキュメント解析・コード解析用途での活用が広がる
感想
AgentCore ランタイムインスタンスの一般提供を開始
AgentCore も 業務では触れる機会はまだなく、
以前、JAWS-UG 沖縄のイベントにてワークショップにも参加しましたが、
いまだにキャッチアップができておらず、これから少しずつ知見を深めていこうとしています（😥 いつできるやら、そろそろ重い腰上げなくては）
マネージドインスタンスであるため、下記が主に制限されているとのこと。
- ユーザー自身の起動・パッチ・終了などの標準 EC2 ライフサイクル操作を行えない
- デフォルトではEC2 コンソール表示・API list から隠れる
- ただし、managed resource visibility 設定で変更は可能とのこと
代表的なユースケース
| ユースケース | Instances を選ぶ理由 |
|---|---|
| 数日間走り続ける長時間自動化・変換・移行ジョブ | 8 時間の上限を超える。停止／再開しながら数日スパンで進行 |
| マルチエージェント協調 （コード生成 → レビュー → テスト → ドキュメント → セキュリティスキャン） |
複数エージェントが同一ホスト・共有 FS でメッセージ交換なしに協調 |
| GPU が必要な計算集約タスク （モデル推論、3D レンダリング、シミュレーション、メディア処理） |
GPU インスタンス＋ドライバ自動プロビジョニング |
| OS への直接アクセスが必要なワークロード （ビルド、セキュリティスキャン、GUI 自動化） |
マネージド EC2 上で永続状態と OS アクセスを確保 |
| データを自アカウントに留めたい / 既存の統制・EC2 割引を効かせたい | インスタンスが自アカウントで動作。Savings Plans / RI / ODCR 適用可 |
| オーケストレーターは軽量 microVM、ワーカーは Instances という組み合わせ | 同一 AgentCore API で 2 タイプを併用。オーケストレーターは高速スケール、ワーカーは重処理 |
長時間 AgentCore を利用するケースでの利用では非常にメリットになり、
また閉域網での利用でセキュリティも効果があるのではと思いました。
ただ対応リージョンがまだ少ないのと（東京リージョンは利用可能。大阪リージョンは未対応）、
前述にも記載していますが、マネージドインスタンスの制限がネックになる。
IaC について確認したところ、CloudFormation, AWS CLI, AWS CDK, Terraform も順次対応しているようでした。