本記事は、2026 年 5 月 1 日 に公開された A guide to Airflow worker pool optimization in Amazon MWAA を翻訳したものです。翻訳はクラウドサポートエンジニアの山本が担当しました。 Amazon Managed Workflows for Apache Airflow (Amazon MWAA) は、AWS のフルマネージド Apache Airflow サービスです。Amazon MWAA で Airflow ワーカープールの設定を最適化することは、ワークフロー運用をスケールするうえで重要でありながら見過ごされやすいポイントです。タスクが長時間キューに滞留している場合、ワーカー不足が原因だと考えがちですが、実際には別の根本原因が潜んでいることがあります。スケールの判断は単純ではありません。DevOps エンジニアやシステム管理者は、ワーカーを追加すればパフォーマンスの問題が解決するのか、それとも根本原因に対処せずに運用コストが増えるだけなのかを見極める必要があります。 本記事では、Amazon MWAA におけるワーカースケーリングの判断パターンを、タスクプールの仕組みとワーカー割り当ての関係に焦点を当てて解説します。具体的なシナリオと実践的な判断フレームワークを示し、ワーカーの追加がパフォーマンス課題の適切な解決策かどうか、また適切な場合にどうスケーリングを実装するかの指針を提供します。 主なパターン 本セクションでは、ワーカーの追加が必要かどうかを検討するきっかけとなる、代表的な問題パターンを紹介します。 高い CPU 使用率 Airflow は、外部サービス上のタスク実行を調整・スケジュールするワークフロー管理プラットフォームです。 AWS Glue 、 AWS Batch 、 Amazon EMR など、さまざまなデータ処理システム間のタスクをトリガーおよびモニタリングする中央オーケストレーターとして機能します。Airflow の強みは、データ処理そのものではなく、複数のシステムやサービス間でタスクの依存関係や実行順序を管理できる点にあります。 分析やビッグデータ基盤では、リソースが飽和すると自動的に容量の追加が必要だという誤解がよくあります。しかし Amazon MWAA では、スケーリングの判断に先立って、ワークフローの特性と最適化の余地を理解することが重要です。 ワークフローの規模が拡大すれば、Airflow クラスターのリソース使用率は当然高くなります。ワーカーが常にフル稼働している状況では、コンピューティングリソースの追加が最も手早い対処に見えるかもしれません。しかし、リソース追加は根本的な問題を解決するのではなく、問題を先送りにしてしまうだけです。 たとえば、Amazon MWAA で単一のタスクがワーカーの利用可能な CPU を 100% 消費している場合、ワーカーを追加しても問題は解決しません。タスクが最適化されていないか、より小さな部分に分割されていないためです。そのため、最小ワーカー数を増やしても期待した効果は得られず、運用コストが増加するだけです。 Amazon MWAA ワーカーの CPU またはメモリ使用率が常に 90% を超えている場合、重要な判断ポイントに達しています。対策を講じる前に、根本原因の理解が不可欠です。主に 3 つの対策があります。 水平スケーリング: ワーカーを追加して負荷を分散する。 垂直スケーリング: より大きな環境クラスにアップグレードして、ワーカーあたりのリソースを増やす。 DAG とスケジューリングパターンの最適化: 効率を高めリソース消費を削減する。 各アプローチは異なる根本的な問題に対処するものであり、容量の制約、リソース集約型のタスク設計、ワークフローの非効率のいずれに直面しているかを特定したうえで適切な方法を選択します。最適化戦略のガイダンスについては、 Performance tuning for Apache Airflow on Amazon MWAA を参照してください。 ワーカーの CPUUtilization と MemoryUtilization をモニタリングするには、 Accessing metrics in the Amazon CloudWatch console を参照し、対応するメトリクスを選択してください。 使用パターンを確認できる十分な時間枠を選択する。 期間を 1分  に設定する。 統計を 最大 に設定する。 長いキュー待ち時間 Airflow タスクがキュー状態で長時間滞留し、DAG が予定通りに完了しないことがあります。 Amazon MWAA では、各環境クラスに最小および最大ワーカーノード数が設定されています。各ワーカーには事前設定された同時実行数があり、任意の時点で各ワーカーが同時に実行できるタスク数を表します。この動作は celery.worker_autoscale=(max,min) で制御されます。 たとえば、最小 4 台の mw1.small ワーカーがあり、デフォルトの Airflow 設定の場合、20 個のタスクを同時実行できます (4 ワーカー × 5 max_tasks_per_worker)。システムが突然 20 を超えるタスクの同時実行を必要とすると、オートスケーリングイベントが発生します。Amazon MWAA はワーカーを効率的にスケールする方法を決定し、プロセスをトリガーします。ただし、オートスケーリングプロセスには新しいワーカーのプロビジョニングに追加の時間が必要なため、キュー状態のタスクが増加します。キューイングの問題を軽減するには、以下を検討してください。 ワーカーの CPU 使用率が低い場合、 celery.worker_autoscale=(max,min) の max 値を増やすと、各ワーカーがより多くのタスクを同時処理できるため、タスクのキュー滞留時間を短縮できます。Airflow ワーカーは、自身のシステムリソースの空き状況に関係なく、定義されたタスク同時実行数までタスクを受け取れます。その結果、オートスケーリングが作動する前にワーカーの CPU/メモリ使用率が 100% に達する可能性があります。 ワーカーのタスク同時実行数を増やしたくない場合、最小ワーカー数を増やすことも有効です。利用可能なワーカーが増えることで、より多くのタスクを同時実行できるようになります。 スケジューリングの遅延 新しい DAGの追加は、システムリソースに影響するだけでなく、スケジューリングのばらつきを発生させる可能性があります。環境全体のメトリクスが正常に見えても、リソースの競合によって一部の DAGの実行が遅延することがあります。このばらつきは、特定のタスクが常にキューで長く待機する一方、他のタスクはすぐに実行されるといった状況が発生します。 Amazon CloudWatch メトリクス で、特に DAG の実行数が多い期間において、実行開始時間のばらつきが増加している場合、環境の最適化が必要です。実行パターンとリソース使用率を分析した上で、以下を判断してください。 ワーカーの追加はワークロードの分散に役立ちますが、高いリソース使用率が DAG のパースやスケジューリングのオーバーヘッドではなく、主にタスク実行の負荷によるものである場合に最も効果的です。最小ワーカー数を増やすと、より多くのタスクを並列実行できます。たとえば、 AWS/MWAA/ApproximateAgeOfOldestTask の値が着実に増加している場合、ワーカーがキューからのメッセージを十分な速度で消費できていないことを意味します。さらに、 AWS/MWAA/QueuedTasks をモニタリングして同様のパターンを特定することもできます。 環境クラスのアップグレードにより、スケジューリング容量が向上します。スケジューラーに負荷の兆候が見られる場合や、すべてのコンポーネントでリソース使用率が高い場合は、より大きな環境クラスへのアップグレードが最適な解決策かもしれません。スケジューラーとワーカーの両方により多くのリソースが提供され、DAG の複雑さとボリュームの増加に対応できます。検証するには、 AWS/MWAA/CPUUtilization と AWS/MWAA/MemoryUtilization のクラスターメトリクスで Scheduler 、 BaseWorker 、 AdditionalWorker メトリクスを選択してください。 DAG スケジュールの再構成により、リソース競合を削減する。 重要なのは、ワークフローパターンを理解し、スケジューリングの遅延がワーカー容量の不足によるものか、その他の環境上の制約によるものかを特定することです。 アンチパターン ワーカーを追加することでパフォーマンスが改善するという誤った結論につながりやすい、よくあるアンチパターンを紹介します。 稼働率の低いワーカー Amazon MWAA のパフォーマンスボトルネックを評価する際は、環境をスケールアップする前に、リソース制約と DAG 設計の非効率を区別することが重要です。 Amazon MWAA 環境が 100 タスクを同時実行できる容量を持っていても、キューメトリクス ( AWS/MWAA/RunningTasks ) ではほとんどの時間で 20 タスクしかアクティブでなく、キュー状態のタスクも残っていないことがあります。その場合、ピークワークロード時に既存ワーカーの CPU とメモリ使用率が常に低いかどうかを Amazon CloudWatch で確認してください。リソース使用率が低い場合、通常は DAG 設計、スケジューリングパターン、または Airflow 設定が非効率であることを示しています。 対処には主に 2 つの選択肢があります。 1. ダウンサイズ : ワークロードの増加が見込まれない場合、クラスターが過剰にプロビジョニングされていると判断できます。まず余分なワーカーを削除し、最終的に環境クラスのダウンサイズを検討してください。 2. 最適化 : プールや同時実行数の Airflow 設定を通じて DAG スケジューリングを調整し、システムのスループットを向上させてください。 人為的なボトルネックを生む Airflow 設定の誤り Apache Airflow では、実際のリソース制約ではなく設定によってパフォーマンスボトルネックが発生することがよくあります。コンピューティングリソースの不足ではなく、同時実行数の設定ミスによって DAG の実行が遅延します。 Amazon MWAA を効率的に使用するには、ワーカーとスケジューラーのリソース使用率だけでなく、人為的なボトルネックとなる同時実行数設定も確認する必要があります。1 つの制限的な設定が、より大きな環境や追加ワーカーのスケーリング効果を打ち消してしまうことがあります。システムメトリクスに余裕があるにもかかわらずパフォーマンスが制限されている場合は、Airflow 設定を監査してください。 重要な考慮事項 : Amazon MWAA は、環境クラスを変更してもワーカーの同時実行数設定を自動的に更新しません。スケーリング時にこの動作を理解しておくことが重要です。最初に mw1.small 環境を作成した場合、各ワーカーはデフォルトで最大 5 つの同時タスクを処理できます。medium 環境クラス (デフォルトでワーカーあたり 10 の同時タスクをサポート) にアップグレードしても、インプレース更新された環境では同時実行数の設定は 5 のまま です。新しい環境クラスの容量を最大限に活用するには、同時実行数の設定を手動で更新する必要があります。 このため、環境クラスを更新する際は、同時実行数を制御する Airflow 設定も更新する必要があります。環境クラスのアップグレード後に同時実行数の設定を更新するには、Apache Airflow 設定オプションの celery.worker_autoscale 設定を変更してください。ワーカーが新しい環境クラスでサポートされる最大同時タスク数を処理できるようになります。 また、Amazon MWAA 環境が実際のリソース制限ではなく、 max_active_runs や DAG 同時実行数の制御によって制約されている場合もあります。設定ベースのスロットルは、ワーカーインスタンスにワークロードを処理する利用可能なコンピューティングリソースがあっても、タスクの実行を妨げます。 この 2 つには重要な違いがあります。設定による制限は並列処理の人為的な上限として機能し、真のリソース制限はワーカーが CPU またはメモリ容量をフルに使用していることを示します。どちらの制約が環境に影響しているかを理解することで、設定を調整すべきかインフラストラクチャをスケールすべきかを判断できます。 プール、同時実行数、max_active_runs などの Airflow 設定を調整することで、ワーカーをスケールせずにパフォーマンスの問題を解決できます。制御に使用できる設定の一部を以下に示します。 max_active_runs_per_dag (DAG レベル): 特定の DAG について同時に許可される DAG 実行数を制御します。2 に設定すると、ワーカー容量に余裕があっても同時に 2 つの DAG 実行しか実行できません。追加の実行はキューに入り、ワーカーがアイドル状態でも DAG の実行が遅くなります。 max_active_tasks: DAG 定義の concurrency フィールド (または環境レベルの設定) を制御し、システム全体の容量やワーカー数に関係なく、その DAG から同時に実行されるタスク数を制限します。 プール: プールは、特定の種類 (多くの場合リソース集約型) のタスクが同時に実行できる数を制限します。3 スロットのプールは、そのプールに割り当てられた 3 を超えるタスクをスロットルし、ワーカーをアイドル状態にします。 実行タイムアウトとリトライ: 適切に調整されていない場合、失敗したタスクが不必要にスロットを占有し、スタックしたタスクがワーカースロットをブロックしてキュー処理を遅延させる可能性があります。 スケジューリング間隔と依存関係: 重複する非効率なスケジューリングは、アイドル期間やリソースの過度な競合を引き起こし、実際のスループットに影響する可能性があります。 Airflow 設定の相互上書き Airflow には、同時実行数とスケジューリングを制御する複数のレイヤーがあります。環境レベル、DAG/タスクレベル、プール用のものがあります。より制限的な設定がより許容的な設定を上書きし、予期しないキューの蓄積を引き起こすことがあります。 DAG レベル vs 環境レベル: “max_active_runs_per_dag” (DAG レベル) が環境レベルの “max_active_runs_per_dag” やシステム全体の同時実行数より低い場合、DAG の設定が使用され、環境がより多くの処理を行えるにもかかわらずタスクがスロットルされます。 タスクレベルの上書き: 個々のタスク定義には “max_active_tis_per_dag” などの独自のパラメータを設定でき、グローバル設定より低く設定するとボトルネックを生み出す可能性があります。 優先順位: 任意のレベル (環境、DAG、タスク) で最も制限的な設定が、並列タスク実行の上限を実質的に決定します。 設定場所 設定 タスクスループットへの影響 環境レベル parallelism スケジューラーで実行される最大タスク総数 DAG レベル max_active_runs 同時 DAG 実行の最大数 タスクレベル concurrency その DAG の最大同時タスク数 パフォーマンスの問題はリソース枯渇のように見えることが多いですが、実際には過度に制限的な設定に起因しています。上記のパラメータをすべて慎重に監査してください。制限的な値を段階的に緩和し、クラスターのスケールを決定する前に効果をモニタリングできます。アイドル容量に対して支払うことなく、クラウドリソースを最適かつコスト効率よく使用できます。 メモリリークによる緩やかなリソース枯渇 Amazon MWAA でメモリリークや緩やかなリソース枯渇が発生する一般的なシナリオは、DAG やタスクが時間の経過とともに失敗したり遅くなったりする場合です。ワーカーのスケールや環境サイズの拡大では根本的な問題は解決しません。根本原因は容量不足ではなく、持続的な枯渇を引き起こすアプリケーションレベルのリークであるためです。 たとえば、Airflow がタスクの実行と DAG のパースを継続的に行うと、環境全体のメモリ消費が着実に増加する可能性があります。ワークロードが一定または減少しているにもかかわらず、Amazon MWAA メタデータデータベースの FreeableMemory メトリクスが低下するという形で現れることがあります。メモリリソースがスケジューラー/ワーカーおよびメタデータデータベースで制約されると、データベースクエリのパフォーマンスが徐々に低下し、Airflow はメタデータデータベースに重要な操作を大きく依存しているため、最終的に環境全体の応答性に影響します。アプリケーションがデータベース接続を適切に閉じずに作成し、リソース枯渇に至るのと似た状況です。 グラフ: FreeableMemory と MemoryUtilization の低下(上: メタデータデータベース、下: スケジューラー及びワーカー) 一般的な原因: コネクションプールの枯渇: データベース接続を適切に閉じない DAG は、コネクションプールの枯渇とデータベースのメモリリークを引き起こす可能性があります。 リソース集約型の操作: メタデータデータベースに対する複雑で長時間実行されるクエリや XCOM 操作は、過剰なメモリを消費する可能性があります。 非効率な DAG 設計: トップレベルに多数の Python 呼び出しを持つ DAG は、DAG パース中にデータベースクエリをトリガーする可能性があります。たとえば、タスクレベルではなく DAG レベルで variable.get() を呼び出すと、不要なデータベースの負荷が発生します。 推奨される解決策: Amazon CloudWatch モニタリングの実装: FreeableMemory に適切なしきい値で Amazon CloudWatch アラームを設定し、問題を早期に検出する。 定期的なデータベースメンテナンス: 不要になった履歴データをパージするスケジュールされたデータベースクリーンアップ操作を実行する。 DAG コードの最適化: variable.get() などのデータベース操作を DAG レベルからタスクレベルに移動するよう DAG をリファクタリングし、パースのオーバーヘッドを削減する。 接続管理: すべてのデータベース接続が使用後に適切に閉じられるようにし、コネクションプールの枯渇を防止する。 上記の推奨事項に従うことで、メタデータデータベースのメモリ使用率を健全に維持し、ワーカーをスケールせずに Amazon MWAA 環境の最適なパフォーマンスを維持できます。 まとめ Amazon MWAA 環境でワーカーを追加する判断には、単純なタスクキューメトリクスを超えた複数の要因の検討が必要です。本記事では、ワーカーの追加が特定のパフォーマンス課題に対処できる一方で、システムボトルネックへの最適な最初の対応ではないことが多い点を示しました。 ワーカーをスケールする前に考慮すべき重要なポイント: 根本原因の分析 高い CPU/メモリ使用率がタスク最適化の問題に起因するかどうかを確認する。 キューイングの問題がリソース制限ではなく設定の制約に起因するかどうかを調べる。 メモリリークやリソース枯渇のパターンがないか調査する。 設定の最適化 Airflow パラメータ (同時実行数の設定、プール、タイムアウト) を確認・調整する。 異なる設定レイヤー間の相互作用を理解する。 DAG 設計とスケジューリングパターンを最適化する。 最も成功している Amazon MWAA の実装は、体系的なアプローチに従っています。まず既存のリソースと設定を最適化し、データに基づくキャパシティプランニングで正当化された場合にのみワーカーをスケールします。信頼性の高いワークフローパフォーマンスを維持しながら、コスト効率の高い運用が実現します。 ワーカーのスケーリングは、Amazon MWAA 最適化ツールキットの 1 つのツールにすぎません。長期的な成功は、適切なモニタリング、プロアクティブなキャパシティプランニング、Airflow ワークフローの継続的な最適化を組み合わせたパフォーマンス管理戦略の構築にかかっています。 次の記事では、環境に追加の DAG を投入する前に実行すべきキャパシティプランニングの手順について説明します。追加の負荷に対する計画を立て、十分なヘッドルームを確保する方法を解説します。 開始するには、 Amazon MWAA の製品ページ と Performance tuning for Apache Airflow on Amazon MWAA ページをご覧ください。 ご質問がある場合や MWAA のスケーリング経験を共有したい場合は、以下にコメントを残してください。 著者について Boyko Radulov AWS のシニアクラウドサポートエンジニアで、Amazon MWAA と AWS Glue のサブジェクトマターエキスパートです。お客様と密接に連携し、コスト削減しながら AWS 上のワークロードの構築と最適化を支援しています。仕事以外では、スポーツと旅行に情熱を注いでいます。 Kamen Sharlandjiev Kamen は、プリンシパルビッグデータおよび ETL ソリューションアーキテクトで、Amazon MWAA と AWS Glue ETL のエキスパートです。複雑なデータ統合やオーケストレーションの課題に直面しているお客様の負担を軽減することをミッションとしています。 Venu Thangalapally シカゴを拠点とする AWS のシニアソリューションアーキテクトで、クラウドアーキテクチャ、データとアナリティクス、コンテナ、アプリケーションモダナイゼーションに深い専門知識を持っています。金融サービス業界のお客様と連携し、ビジネス目標をセキュアでスケーラブルかつコンプライアンスに準拠したクラウドソリューションに変換しています。 Harshawardhan Kulkarni AWS のパートナーテクニカルアカウントマネージャーで、Amazon MWAA のサブジェクトマターエキスパートです。アイルランドのダブリンを拠点に、EMEA のエンタープライズのお客様と連携し、複雑なワークフローやオーケストレーションの課題をナビゲートしながらベストプラクティスの実装を支援しています。 Andrew McKenzie AWS での経験から得た深い技術的専門知識を活用するデータエンジニア兼エデュケーターです。元 Amazon MWAA サブジェクトマターエキスパートとして、現在はデータソリューションの構築とデータエンジニアリングのベストプラクティスの教育に注力しています。

本記事は、2026 年 3 月 30 日に公開された Build high-performance apps with AWS Lambda Managed Instances を翻訳したものです。翻訳は Solutions Architect の 齋藤 拓巳 が担当しました。 最新のサーバーレスイノベーションを把握して、アプリケーションの変革に役立てましょう。 この第 31 回四半期レビューでは、2025 年第 4 四半期に発表された、見逃しているかもしれない AWS サーバーレスの重要なリリース、機能、リソースをご紹介します。 前回の ICYMI を見逃した方は、 2025 年第 3 四半期 の内容をご確認ください。 2025 年第 4 四半期カレンダー re:Invent 2025 におけるサーバーレス この記事では、re:Invent 2025 で発表された主要なサーバーレス関連のアナウンスを取り上げ、アプリケーションの改善に役立つ重要な機能アップデートを紹介するとともに、最新情報を把握するための有用なリソースを共有します。 AWS re:Invent 2025 には 60,000 人以上が現地参加し、基調講演には 200 万人以上のオンライン視聴者が集まりました。 イベントでは 3,000 人のスピーカーによる 3,500 のセッションが開催され、530 の AWS サービスおよび機能のアナウンスに関する情報が紹介されました。 基調講演 サーバーレスムーブメントの火付け役 サーバーレス関連のコンテンツは、Containers and Serverless (CNS) と Application Integration (API) の 2 つのトラックで構成されていました。 これらのトラックでは 150 種類のセッションが開催され、16,000 人を超える参加者が現地で視聴しました。 開発者向けの体験として、 Road to re:Invent Hackathon 、AWS Builder Loft、Builders Arena が用意されていました。 サーバーレステクノロジーで運営されるコーヒーショップ Serverlesspresso は、イベント期間中、Expo Hall と認定資格ラウンジの 2 か所で営業していました。 サーバーレスおよび開発者コミュニティの写真 厳選されたサーバーレス動画のリストは Serverless Land YouTube でご覧いただけます。 AWS Lambda durable functions マルチステップのサーバーレスワークフローにおける状態管理には、従来、複雑な外部オーケストレーションツールが必要でした。 AWS Lambda の durable functions は、開発者が Lambda を活用する方法を拡張します。 信頼性の高いマルチステップのアプリケーションや AI ワークフローを Lambda 内で直接構築できるようになりました。 AWS Lambda durable functions のコード durable functions は、実行中の重要なポイントで現在の状態と完了したステップを保存することで、自動的に進捗のチェックポイントを保存します。 これにより、長時間実行されるタスク中に最大 1 年間実行を一時停止でき、障害が発生した場合も最初からやり直すのではなく最後のチェックポイントから再開して復旧できます。しかも追加のインフラストラクチャ管理は一切不要です。 開発者は Python または TypeScript で構築し、自動リトライとチェックポイント機能を備えたステップで呼び出しをラップできるようになりました。 wait を使用すると、アイドル状態のコンピューティングに課金されることなく、数分、数時間、最大 1 年間まで実行を一時停止できます。 durable functions はリプレイメカニズムを使用して状態を維持し、障害を適切に処理します。 このメカニズムは、障害からの復旧時にチェックポイントから関数コードを再実行することで動作し、データを失うことなく状態の一貫性を確保します。 これにより、多くのユースケースで複雑な外部オーケストレーションツールが不要になります。 外部インフラストラクチャを管理することなく信頼性の高い状態管理が必要な AI ワークフローやマルチステップアプリケーションに特に役立ちます。 詳細については、 発表ブログ記事 をお読みいただくか、re:Invent ブレイクアウトセッションの動画をご覧ください: Deep Dive on AWS Lambda durable functions (CNS380) AWS Lambda Managed Instances Lambda は、 Lambda Managed Instances という新しいコンピューティングオプションを提供開始しました。これは Amazon EC2 の柔軟性とフルマネージドインフラストラクチャを組み合わせたものです。 AWS がインスタンスのプロビジョニング、スケーリング、メンテナンスを自動的に処理しながら、Graviton4、ネットワーク最適化インスタンス、その他の特殊なコンピューティングオプションを含む EC2 の幅広い機能にアクセスできます。 AWS Lambda Managed Instancesの設定 関数は、お客様のアカウントの専用 EC2 キャパシティ上で、お客様自身の Amazon Virtual Private Cloud (Amazon VPC) 内で実行されます。 OS パッチ適用、ロードバランシング、オートスケーリングなどの運用オーバーヘッドは引き続き AWS が管理します。 これにより、サーバーレスの運用モデルを維持しながら、特殊なハードウェアオプションにアクセスできます。 Compute Savings Plans や Reserved Instances などの EC2 料金モデルを Lambda ワークロードに活用することで、コストをさらに最適化できます。 各インスタンスは複数の同時リクエストを処理できるため、予測可能な料金体系と特定のハードウェア要件が重要な、大量かつ定常的なワークロードに特に適しています。 詳細については、 発表ブログ記事 をお読みいただくか、re:Invent ブレイクアウトセッションの動画 Lambda Managed Instances: EC2 Power with Serverless Simplicity (CNS382) をご覧ください。 その他の Lambda に関する発表 マルチテナント SaaS アプリケーションには、テナント間のデータ漏洩や、あるテナントのワークロードが他のテナントに影響を与えるノイジーネイバー問題といった課題があります。 また、カスタムの分離メカニズムの実装にも苦労してきました。 テナント分離モード は、テナントごとに個別の実行環境で関数の呼び出しを処理することで、これらの課題に対処します。 これにより、テナントレベルのコンピューティング環境の分離が自動的に管理されます。 AWS Lambda tenant isolation Lambda は Amazon SQS イベントソースマッピングに Provisioned Mode を追加しました。これにより、高スループットの SQS 処理ワークロードにおいて、予測可能なパフォーマンスとコールドスタートの削減を実現します。 非同期 Lambda 呼び出しで 最大 1 MB のデータを送信 できるようになりました。 従来の 256 KB から引き上げられ、より複雑なデータ処理シナリオの構築が可能になります。 Lambda 関数は IPv6 ネットワーキング をサポートするようになったため、VPC に接続された関数からインターネットや他の AWS サービスにアクセスする際に NAT Gateway が不要になりました。 NAT Gateway を介した Lambda のインターネット接続 (IPv4) と、Egress-Only インターネットゲートウェイを介した Lambda のインターネット接続 (IPv6) です。 Lambda の Rust サポート が一般提供 (GA) になり、実験的ステータスから移行しました。 これは AWS サポートおよび Lambda の可用性 SLA の対象となります。 Lambda は、 Python 3.14 、 Node.js 24 、 Java 25 をマネージドランタイムおよびコンテナベースイメージとして追加し、ランタイムサポートを拡充しました。 これにより、最新の言語機能を利用でき、長期サポートも確保されます。 Amazon ECS Amazon Elastic Container Service (Amazon ECS) Express Mode は、従来開発者の作業を遅らせていたインフラストラクチャのセットアップを自動化することで、コンテナ化されたアプリケーションのデプロイと管理を効率化します。 Amazon ECS Express Mode デプロイメント これにより、AWS のベストプラクティスを活用して自信を持ってデプロイしながら、アプリケーションの構築に集中できます。 Express Mode では、単一のコマンドで本番環境対応のコンテナ化された Web アプリケーションと API をデプロイできます。 シンプルな API を通じて、ドメイン、ネットワーキング、ロードバランシング、 AWS Identity and Access Management (IAM) ロール、オートスケーリングが自動的に処理されます。 アプリケーションが進化し、高度な機能が必要になった場合は、Amazon ECS を含むリソースのすべての機能をシームレスに設定してアクセスできます。 詳細については、 発表ブログ記事 をご覧ください。 Amazon ECS は、AI を活用した開発・運用体験を実現するフルマネージド型の MCP サーバー のパブリックプレビューを発表しました。 この Model Context Protocol (MCP) サーバーは、自動更新とパッチ適用、AWS IAM 統合による一元的なセキュリティ管理、 AWS CloudTrail を通じた包括的な監査ログ、そして AWS が実証済みのスケーラビリティ、信頼性、サポートといったエンタープライズグレードの機能を提供します。 Amazon Elastic Container Registry (ECR) の マネージドコンテナイメージ署名 は、セキュリティ体制を強化し、署名のセットアップにかかる運用上のオーバーヘッドを排除します。 コンテナイメージ署名により、イメージが信頼できるソースからのものであることを検証できます。 ECR は、イメージがプッシュされる際に、プッシュしたエンティティの ID を使用して自動的にイメージに署名します。 署名操作は CloudTrail を通じてログに記録されるため、完全な監査が可能です。 Amazon API Gateway Amazon API Gateway では、レスポンスペイロードをクライアントに 段階的にストリーミング することで、REST API の応答性を向上させることができます。 この新機能により、ストリーミングレスポンスを使用して、LLM 駆動のアプリケーション (AI エージェントやチャットボットなど) を構築する際のユーザーエクスペリエンスの向上、Web およびモバイルアプリケーションの Time-to-First-Byte (TTFB) パフォーマンスの改善、大容量ファイルのストリーミング、 Server-Sent Events (SSE) などのプロトコルを使用した増分的な進捗報告を伴う長時間実行オペレーションの実行が可能になります。 Amazon API Gateway streaming API Gateway は、 Application Load Balancer (ALB) との プライベート統合 を導入しました。 これにより、ALB をパブリックインターネットに公開することなく、VPC ベースのアプリケーションを REST API を通じて安全に公開できます。 API エンドポイントやカスタムドメイン名に 強化された TLS セキュリティポリシー を設定できるようになり、API のセキュリティ体制をより細かく制御できるようになりました。 Amazon EventBridge Amazon EventBridge に、カスタムアプリケーションや 200 以上の AWS サービスからのイベントを開発者が発見しサブスクライブできる 拡張ビジュアルルールビルダー が導入されました。 このコンソールベースのインターフェースは、EventBridge の スキーマレジストリ と包括的なイベントカタログ、直感的なドラッグアンドドロップキャンバスを統合し、イベント駆動型アプリケーションの構築を簡素化します。 開発者は、個々のサービスのドキュメントを探し回ることなく、すぐに利用可能なサンプルペイロードやスキーマを使ってイベントを閲覧・検索できます。 スキーマ対応のビジュアルビルダーが、イベントフィルターパターンやルールの作成をガイドし、構文エラーを削減して開発時間を短縮します。 EventBridge では、 SQS フェアキュー をターゲットとして指定することもできます。 AWS Step Functions AWS Step Functions では、 TestState API を通じて強化されたローカルテストが可能です。 AWS にデプロイすることなく、包括的なテスト機能にプログラムからアクセスできます。 これにより、開発マシン上でワークフロー定義をローカルに検証する自動テストスイートを構築できます。 お好みのテストフレームワークを使用して、エラーハンドリングパターン、データ変換、モックサービス統合をテストしましょう。 また、新しい メトリクスダッシュボード も追加され、アカウントレベルとステートマシンレベルの両方でワークフローの運用状況を可視化できるようになりました。 その他の発表 Savings Plans の柔軟な料金モデルが、 Database Savings Plans のローンチにより AWS マネージドデータベースサービスにも拡張されました。 1 年間の一定量の使用量 ($/時間) をコミットすることで、データベースコストを最大 35% 削減できます。 割引は毎時間、対象のデータベースサービス全体の適格な使用量に自動的に適用され、コミットメントを超える追加使用量はオンデマンド料金で課金されます。 Amazon DynamoDB が グローバルセカンダリインデックスでの複数属性複合キー をサポートするようになりました。 これまでは値を手動で連結して合成キーを作成する必要があり、新しいインデックスを追加する前にデータのバックフィルが必要になることもありました。 今後は、最大 8 つの既存属性を使用してプライマリキーを作成できるため、多様なアクセスパターンのモデリングや新しいクエリ要件への対応が容易になります。 Amazon Bedrock は、信頼性の高い AI エージェントを大規模にデプロイするための 品質評価とポリシーコントロールを備えた AgentCore を発表しました。 Bedrock には 18 のフルマネージドオープンウェイトモデル も追加され、開発者が利用できる AI モデルの選択肢が拡大しました。 Strands Agents SDK は、モデル駆動型のアプローチで AI エージェントをわずか数行のコードで構築・実行できるオープンソースフレームワークです。 TypeScript のサポートがプレビューとして 利用可能になり 、Strands Agents の構築に Python と TypeScript のどちらかを選択できるようになりました。 Amazon S3 Vectors が一般提供開始となりました。 S3 Vectors は、AI エージェント、推論、検索拡張生成 (RAG)、セマンティック検索を数十億ベクトル規模で実現する、専用設計されたコスト最適化済みのベクトルストレージを提供します。 サーバーレスに関するブログ記事 10 月 モノリスワークフローの分解: AWS Step Functions ワークフローのモジュール化 AWS Serverless MCP Server での AWS Lambda イベントソースマッピングツールの紹介 AWS Step Functions Distributed Map S3 プレフィックスを使用した Amazon S3 オブジェクトの大規模処理 11 月 AWS Lambda の IPv6 ネットワーキング AWS Step Functions Distributed Map によるビッグデータ処理のオーケストレーション AWS Step Functions Distributed Map を使用したネストされた JSON 配列処理の最適化 新しい Amazon API Gateway Portal で API の見つけやすさを向上させる Amazon API Gateway レスポンスストリーミングでレスポンシブな API を構築する AWS Lambda で Python 3.14 ランタイムが利用可能になりました AWS Lambda 上で Rust を使用したサーバーレスアプリケーションの構築 非同期 AWS サービスを AWS Step Functions ステートマシンと統合する際に、予測不能な処理時間を運用の一貫性を保ちながら処理する AWS Lambda が Java 25 をサポートしました Amazon API Gateway TLS セキュリティポリシーによる API セキュリティの強化 Kafka 向けサーバーレスストリーミングワークロードのスループット向上 Amazon API Gateway と Application Load Balancer のプライベート統合を使用してスケーラブルな REST API を構築する LLM レスポンスのストリーミングにおけるサーバーレス戦略 AWS Lambda の新しいテナント分離モードを使用したマルチテナント SaaS アプリケーションの構築 AWS Step Functions と Amazon Bedrock バッチ推論による大規模ドキュメント処理のオーケストレーション AWS Lambda で Node.js 24 ランタイムが利用可能になりました Serverless Office Hours 毎週火曜日の午前 11 時 (太平洋時間) に開催されるライブストリームにぜひご参加ください。サーバーレステクノロジーに関するライブディスカッション、Q&A セッション、深掘りセッションを行っています。 エピソードは serverlessland.com/office-hours でオンデマンドでもご視聴いただけます。 10 月 10 月 7 日 – Amazon API Gateway Routing Rules 10 月 14 日 – Amazon DynamoDB Global Tables 10 月 21 日 – Building agents with Amazon Bedrock AgentCore 10 月 28 日 – What’s new with Observability 11 月 11 月 4 日 – AI 仕様を正しく定義する！ 11 月 11 日 – AWS Lambda で Swift を実行する 11 月 18 日 – EventCatalog の最新情報 11 月 24 日 – pre:Invent 2025 12 月 12 月 9 日 – AWS Lambda Managed Instances 12 月 16 日 – AWS Lambda durable functions さらに詳しく知りたい方へ サーバーレスのランディングページ には、サーバーレスアプリケーションの構築に関する全般的な情報があります。 Lambda リソースページ には、ケーススタディ、ウェビナー、ホワイトペーパー、お客様事例、リファレンスアーキテクチャ、さらに多くの入門チュートリアルが掲載されています。 Serverless Developer Advocacy チームをフォローして、最新ニュースの確認、会話のフォロー、チームとの交流もできます。 Julian Wood: @julian_wood , https://www.linkedin.com/in/julianrwood/ Eric Johnson: @edjgeek , https://www.linkedin.com/in/singledigit/ Gunnar Grosch: @GunnarGrosch , https://se.linkedin.com/in/gunnargrosch Erik Hanchet: @ErikCH , https://www.linkedin.com/in/erikhanchett/ Salih Gueler: @salihgueler , https://www.linkedin.com/in/salihgueler/ Marcia Villalba: @mavi888uy , https://www.linkedin.com/in/marciavillalba 最後に、サーバーレスに関するあらゆる情報については Serverless Land をご覧ください。

本記事は、2026 年 1 月 30 日に公開された Serverless ICYMI Q4 2025 を翻訳したものです。翻訳は Solutions Architect の 齋藤 拓巳 が担当しました。 最新のサーバーレスイノベーションを把握して、アプリケーションの変革に役立てましょう。 この第 31 回四半期レビューでは、2025 年第 4 四半期に発表された、見逃しているかもしれない AWS サーバーレスの重要なリリース、機能、リソースをご紹介します。 前回の ICYMI を見逃した方は、 2025 年第 3 四半期 の内容をご確認ください。 2025 年第 4 四半期カレンダー re:Invent 2025 におけるサーバーレス この記事では、re:Invent 2025 で発表された主要なサーバーレス関連のアナウンスを取り上げ、アプリケーションの改善に役立つ重要な機能アップデートを紹介するとともに、最新情報を把握するための有用なリソースを共有します。 AWS re:Invent 2025 には 60,000 人以上が現地参加し、基調講演には 200 万人以上のオンライン視聴者が集まりました。 イベントでは 3,000 人のスピーカーによる 3,500 のセッションが開催され、530 の AWS サービスおよび機能のアナウンスに関する情報が紹介されました。 基調講演 サーバーレスムーブメントの火付け役 サーバーレス関連のコンテンツは、Containers and Serverless (CNS) と Application Integration (API) の 2 つのトラックで構成されていました。 これらのトラックでは 150 種類のセッションが開催され、16,000 人を超える参加者が現地で視聴しました。 開発者向けの体験として、 Road to re:Invent Hackathon 、AWS Builder Loft、Builders Arena が用意されていました。 サーバーレステクノロジーで運営されるコーヒーショップ Serverlesspresso は、イベント期間中、Expo Hall と認定資格ラウンジの 2 か所で営業していました。 サーバーレスおよび開発者コミュニティの写真 厳選されたサーバーレス動画のリストは Serverless Land YouTube でご覧いただけます。 AWS Lambda durable functions マルチステップのサーバーレスワークフローにおける状態管理には、従来、複雑な外部オーケストレーションツールが必要でした。 AWS Lambda の durable functions は、開発者が Lambda を活用する方法を拡張します。 信頼性の高いマルチステップのアプリケーションや AI ワークフローを Lambda 内で直接構築できるようになりました。 AWS Lambda durable functions のコード durable functions は、実行中の重要なポイントで現在の状態と完了したステップを保存することで、自動的に進捗のチェックポイントを保存します。 これにより、長時間実行されるタスク中に最大 1 年間実行を一時停止でき、障害が発生した場合も最初からやり直すのではなく最後のチェックポイントから再開して復旧できます。しかも追加のインフラストラクチャ管理は一切不要です。 開発者は Python または TypeScript で構築し、自動リトライとチェックポイント機能を備えたステップで呼び出しをラップできるようになりました。 wait を使用すると、アイドル状態のコンピューティングに課金されることなく、数分、数時間、最大 1 年間まで実行を一時停止できます。 durable functions はリプレイメカニズムを使用して状態を維持し、障害を適切に処理します。 このメカニズムは、障害からの復旧時にチェックポイントから関数コードを再実行することで動作し、データを失うことなく状態の一貫性を確保します。 これにより、多くのユースケースで複雑な外部オーケストレーションツールが不要になります。 外部インフラストラクチャを管理することなく信頼性の高い状態管理が必要な AI ワークフローやマルチステップアプリケーションに特に役立ちます。 詳細については、 発表ブログ記事 をお読みいただくか、re:Invent ブレイクアウトセッションの動画をご覧ください: Deep Dive on AWS Lambda durable functions (CNS380) AWS Lambda Managed Instances Lambda は、 Lambda Managed Instances という新しいコンピューティングオプションを提供開始しました。これは Amazon EC2 の柔軟性とフルマネージドインフラストラクチャを組み合わせたものです。 AWS がインスタンスのプロビジョニング、スケーリング、メンテナンスを自動的に処理しながら、Graviton4、ネットワーク最適化インスタンス、その他の特殊なコンピューティングオプションを含む EC2 の幅広い機能にアクセスできます。 AWS Lambda Managed Instancesの設定 関数は、お客様のアカウントの専用 EC2 キャパシティ上で、お客様自身の Amazon Virtual Private Cloud (Amazon VPC) 内で実行されます。 OS パッチ適用、ロードバランシング、オートスケーリングなどの運用オーバーヘッドは引き続き AWS が管理します。 これにより、サーバーレスの運用モデルを維持しながら、特殊なハードウェアオプションにアクセスできます。 Compute Savings Plans や Reserved Instances などの EC2 料金モデルを Lambda ワークロードに活用することで、コストをさらに最適化できます。 各インスタンスは複数の同時リクエストを処理できるため、予測可能な料金体系と特定のハードウェア要件が重要な、大量かつ定常的なワークロードに特に適しています。 詳細については、 発表ブログ記事 をお読みいただくか、re:Invent ブレイクアウトセッションの動画 Lambda Managed Instances: EC2 Power with Serverless Simplicity (CNS382) をご覧ください。 その他の Lambda に関する発表 マルチテナント SaaS アプリケーションには、テナント間のデータ漏洩や、あるテナントのワークロードが他のテナントに影響を与えるノイジーネイバー問題といった課題があります。 また、カスタムの分離メカニズムの実装にも苦労してきました。 テナント分離モード は、テナントごとに個別の実行環境で関数の呼び出しを処理することで、これらの課題に対処します。 これにより、テナントレベルのコンピューティング環境の分離が自動的に管理されます。 AWS Lambda tenant isolation Lambda は Amazon SQS イベントソースマッピングに Provisioned Mode を追加しました。これにより、高スループットの SQS 処理ワークロードにおいて、予測可能なパフォーマンスとコールドスタートの削減を実現します。 非同期 Lambda 呼び出しで 最大 1 MB のデータを送信 できるようになりました。 従来の 256 KB から引き上げられ、より複雑なデータ処理シナリオの構築が可能になります。 Lambda 関数は IPv6 ネットワーキング をサポートするようになったため、VPC に接続された関数からインターネットや他の AWS サービスにアクセスする際に NAT Gateway が不要になりました。 NAT Gateway を介した Lambda のインターネット接続 (IPv4) と、Egress-Only インターネットゲートウェイを介した Lambda のインターネット接続 (IPv6) です。 Lambda の Rust サポート が一般提供 (GA) になり、実験的ステータスから移行しました。 これは AWS サポートおよび Lambda の可用性 SLA の対象となります。 Lambda は、 Python 3.14 、 Node.js 24 、 Java 25 をマネージドランタイムおよびコンテナベースイメージとして追加し、ランタイムサポートを拡充しました。 これにより、最新の言語機能を利用でき、長期サポートも確保されます。 Amazon ECS Amazon Elastic Container Service (Amazon ECS) Express Mode は、従来開発者の作業を遅らせていたインフラストラクチャのセットアップを自動化することで、コンテナ化されたアプリケーションのデプロイと管理を効率化します。 Amazon ECS Express Mode デプロイメント これにより、AWS のベストプラクティスを活用して自信を持ってデプロイしながら、アプリケーションの構築に集中できます。 Express Mode では、単一のコマンドで本番環境対応のコンテナ化された Web アプリケーションと API をデプロイできます。 シンプルな API を通じて、ドメイン、ネットワーキング、ロードバランシング、 AWS Identity and Access Management (IAM) ロール、オートスケーリングが自動的に処理されます。 アプリケーションが進化し、高度な機能が必要になった場合は、Amazon ECS を含むリソースのすべての機能をシームレスに設定してアクセスできます。 詳細については、 発表ブログ記事 をご覧ください。 Amazon ECS は、AI を活用した開発・運用体験を実現するフルマネージド型の MCP サーバー のパブリックプレビューを発表しました。 この Model Context Protocol (MCP) サーバーは、自動更新とパッチ適用、AWS IAM 統合による一元的なセキュリティ管理、 AWS CloudTrail を通じた包括的な監査ログ、そして AWS が実証済みのスケーラビリティ、信頼性、サポートといったエンタープライズグレードの機能を提供します。 Amazon Elastic Container Registry (ECR) の マネージドコンテナイメージ署名 は、セキュリティ体制を強化し、署名のセットアップにかかる運用上のオーバーヘッドを排除します。 コンテナイメージ署名により、イメージが信頼できるソースからのものであることを検証できます。 ECR は、イメージがプッシュされる際に、プッシュしたエンティティの ID を使用して自動的にイメージに署名します。 署名操作は CloudTrail を通じてログに記録されるため、完全な監査が可能です。 Amazon API Gateway Amazon API Gateway では、レスポンスペイロードをクライアントに 段階的にストリーミング することで、REST API の応答性を向上させることができます。 この新機能により、ストリーミングレスポンスを使用して、LLM 駆動のアプリケーション (AI エージェントやチャットボットなど) を構築する際のユーザーエクスペリエンスの向上、Web およびモバイルアプリケーションの Time-to-First-Byte (TTFB) パフォーマンスの改善、大容量ファイルのストリーミング、 Server-Sent Events (SSE) などのプロトコルを使用した増分的な進捗報告を伴う長時間実行オペレーションの実行が可能になります。 Amazon API Gateway streaming API Gateway は、 Application Load Balancer (ALB) との プライベート統合 を導入しました。 これにより、ALB をパブリックインターネットに公開することなく、VPC ベースのアプリケーションを REST API を通じて安全に公開できます。 API エンドポイントやカスタムドメイン名に 強化された TLS セキュリティポリシー を設定できるようになり、API のセキュリティ体制をより細かく制御できるようになりました。 Amazon EventBridge Amazon EventBridge に、カスタムアプリケーションや 200 以上の AWS サービスからのイベントを開発者が発見しサブスクライブできる 拡張ビジュアルルールビルダー が導入されました。 このコンソールベースのインターフェースは、EventBridge の スキーマレジストリ と包括的なイベントカタログ、直感的なドラッグアンドドロップキャンバスを統合し、イベント駆動型アプリケーションの構築を簡素化します。 開発者は、個々のサービスのドキュメントを探し回ることなく、すぐに利用可能なサンプルペイロードやスキーマを使ってイベントを閲覧・検索できます。 スキーマ対応のビジュアルビルダーが、イベントフィルターパターンやルールの作成をガイドし、構文エラーを削減して開発時間を短縮します。 EventBridge では、 SQS フェアキュー をターゲットとして指定することもできます。 AWS Step Functions AWS Step Functions では、 TestState API を通じて強化されたローカルテストが可能です。 AWS にデプロイすることなく、包括的なテスト機能にプログラムからアクセスできます。 これにより、開発マシン上でワークフロー定義をローカルに検証する自動テストスイートを構築できます。 お好みのテストフレームワークを使用して、エラーハンドリングパターン、データ変換、モックサービス統合をテストしましょう。 また、新しい メトリクスダッシュボード も追加され、アカウントレベルとステートマシンレベルの両方でワークフローの運用状況を可視化できるようになりました。 その他の発表 Savings Plans の柔軟な料金モデルが、 Database Savings Plans のローンチにより AWS マネージドデータベースサービスにも拡張されました。 1 年間の一定量の使用量 ($/時間) をコミットすることで、データベースコストを最大 35% 削減できます。 割引は毎時間、対象のデータベースサービス全体の適格な使用量に自動的に適用され、コミットメントを超える追加使用量はオンデマンド料金で課金されます。 Amazon DynamoDB が グローバルセカンダリインデックスでの複数属性複合キー をサポートするようになりました。 これまでは値を手動で連結して合成キーを作成する必要があり、新しいインデックスを追加する前にデータのバックフィルが必要になることもありました。 今後は、最大 8 つの既存属性を使用してプライマリキーを作成できるため、多様なアクセスパターンのモデリングや新しいクエリ要件への対応が容易になります。 Amazon Bedrock は、信頼性の高い AI エージェントを大規模にデプロイするための 品質評価とポリシーコントロールを備えた AgentCore を発表しました。 Bedrock には 18 のフルマネージドオープンウェイトモデル も追加され、開発者が利用できる AI モデルの選択肢が拡大しました。 Strands Agents SDK は、モデル駆動型のアプローチで AI エージェントをわずか数行のコードで構築・実行できるオープンソースフレームワークです。 TypeScript のサポートがプレビューとして 利用可能になり 、Strands Agents の構築に Python と TypeScript のどちらかを選択できるようになりました。 Amazon S3 Vectors が一般提供開始となりました。 S3 Vectors は、AI エージェント、推論、検索拡張生成 (RAG)、セマンティック検索を数十億ベクトル規模で実現する、専用設計されたコスト最適化済みのベクトルストレージを提供します。 サーバーレスに関するブログ記事 10 月 モノリスワークフローの分解: AWS Step Functions ワークフローのモジュール化 AWS Serverless MCP Server での AWS Lambda イベントソースマッピングツールの紹介 AWS Step Functions Distributed Map S3 プレフィックスを使用した Amazon S3 オブジェクトの大規模処理 11 月 AWS Lambda の IPv6 ネットワーキング AWS Step Functions Distributed Map によるビッグデータ処理のオーケストレーション AWS Step Functions Distributed Map を使用したネストされた JSON 配列処理の最適化 新しい Amazon API Gateway Portal で API の見つけやすさを向上させる Amazon API Gateway レスポンスストリーミングでレスポンシブな API を構築する AWS Lambda で Python 3.14 ランタイムが利用可能になりました AWS Lambda 上で Rust を使用したサーバーレスアプリケーションの構築 非同期 AWS サービスを AWS Step Functions ステートマシンと統合する際に、予測不能な処理時間を運用の一貫性を保ちながら処理する AWS Lambda が Java 25 をサポートしました Amazon API Gateway TLS セキュリティポリシーによる API セキュリティの強化 Kafka 向けサーバーレスストリーミングワークロードのスループット向上 Amazon API Gateway と Application Load Balancer のプライベート統合を使用してスケーラブルな REST API を構築する LLM レスポンスのストリーミングにおけるサーバーレス戦略 AWS Lambda の新しいテナント分離モードを使用したマルチテナント SaaS アプリケーションの構築 AWS Step Functions と Amazon Bedrock バッチ推論による大規模ドキュメント処理のオーケストレーション AWS Lambda で Node.js 24 ランタイムが利用可能になりました Serverless Office Hours 毎週火曜日の午前 11 時 (太平洋時間) に開催されるライブストリームにぜひご参加ください。サーバーレステクノロジーに関するライブディスカッション、Q&A セッション、深掘りセッションを行っています。 エピソードは serverlessland.com/office-hours でオンデマンドでもご視聴いただけます。 10 月 10 月 7 日 – Amazon API Gateway Routing Rules 10 月 14 日 – Amazon DynamoDB Global Tables 10 月 21 日 – Building agents with Amazon Bedrock AgentCore 10 月 28 日 – What’s new with Observability 11 月 11 月 4 日 – AI 仕様を正しく定義する！ 11 月 11 日 – AWS Lambda で Swift を実行する 11 月 18 日 – EventCatalog の最新情報 11 月 24 日 – pre:Invent 2025 12 月 12 月 9 日 – AWS Lambda Managed Instances 12 月 16 日 – AWS Lambda durable functions さらに詳しく知りたい方へ サーバーレスのランディングページ には、サーバーレスアプリケーションの構築に関する全般的な情報があります。 Lambda リソースページ には、ケーススタディ、ウェビナー、ホワイトペーパー、お客様事例、リファレンスアーキテクチャ、さらに多くの入門チュートリアルが掲載されています。 Serverless Developer Advocacy チームをフォローして、最新ニュースの確認、会話のフォロー、チームとの交流もできます。 Julian Wood: @julian_wood , https://www.linkedin.com/in/julianrwood/ Eric Johnson: @edjgeek , https://www.linkedin.com/in/singledigit/ Gunnar Grosch: @GunnarGrosch , https://se.linkedin.com/in/gunnargrosch Erik Hanchet: @ErikCH , https://www.linkedin.com/in/erikhanchett/ Salih Gueler: @salihgueler , https://www.linkedin.com/in/salihgueler/ Marcia Villalba: @mavi888uy , https://www.linkedin.com/in/marciavillalba 最後に、サーバーレスに関するあらゆる情報については Serverless Land をご覧ください。