お知らせ 2026年7月からオンラインでサーバーレスに関するワークショップを4件開催します。ぜひ、ご参加ください。 7/7 10:00〜12:00 Kiroによるサーバーレス開発 7/9 10:00〜12:00 イベント駆動アーキテクチャ・アプリケーションの構築 7/14 10:00〜12:00 AWS Lambda durable functions によるコード型ワークフロー 7/16 10:00〜12:00 AWS Lambda マネージドインスタンス 本記事は、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 をご覧ください。

本記事は 2026 年 05 月 20 日に公開された “ Introducing ExtendDB: An open source DynamoDB-compatible adapter with pluggable storage backends ” を翻訳したものです。 本日、Apache 2.0 ライセンスの下でリリースされた、プラガブルなストレージバックエンドを備えたオープンソースの Amazon DynamoDB 互換アダプターである ExtendDB を発表します。ExtendDB は DynamoDB のワイヤープロトコルを実装し、最初のバックエンドとして PostgreSQL に対応してリリースされます。そのため、DynamoDB で動作するすべての AWS SDK、CLI、ツールは ExtendDB でも変更なしで動作します。 本記事では、ExtendDB の紹介、利用開始の手順、アーキテクチャの説明を行います。これは開発、テスト、実験用途向けの v0.1 リリースです。 背景 Amazon DynamoDB は、あらゆる規模で 1 桁ミリ秒のパフォーマンスを発揮する、サーバーレスでフルマネージドな NoSQL データベースです。DynamoDB 上に構築するチームは、そのデータモデリングパターン、条件式、トランザクション、ストリームについて深い専門知識を培います。それを取り巻く CI パイプラインを構築し、運用ランブックを作成し、エンジニアのトレーニングを行います。これらのチームがエッジ、オンプレミス、切断された環境へと活動範囲を広げるにつれ、同じ API と開発者エクスペリエンスを持ち込みたいというニーズが生まれます。 ある大手航空会社は、ほとんどのアプリケーションを AWS 上で実行し、DynamoDB を主要なデータストアとして利用しています。しかし、ゲートおよび機内システムは、ネットワーク障害が発生しても稼働し続ける必要があり、搭乗、手荷物照合、機内販売についてはクラウドへのラウンドトリップ遅延を許容できません。これらのシステムは、同じアクセスパターン、同じ条件付き書き込み、同じトランザクション保証を必要とします。互換性のあるランタイムがないため、このチームは異なるデータアクセスレイヤー、異なる運用手順、異なる専門知識要件を持つ 2 つの別々のアプリケーションスタックを保守しています。 現在、AWS の外で DynamoDB ワークロードを実行することは、データアクセスレイヤーを書き直すことを意味します。DynamoDB Local はユニットテスト向けの単一プロセスのツールです。ExtendDB は初期段階のプロジェクトとして、より広範なローカル開発およびオンプレミスシナリオを対象としています。 ユースケース ExtendDB はマネージド DynamoDB サービスが利用できない、または現実的でないシナリオに対応します。 ローカル開発とCI/CD クラウドへの依存性ゼロで、ラップトップ上または継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインで DynamoDB ワークロードを実行できます。統合テストは数秒で開始でき、決定論的に実行され、クリーンに終了します。 オンプレミスおよびエアギャップ環境 クラウド接続のない開発者、オンプレミスワークロードを実行するチーム、エッジのオペレーターは、自身のインフラストラクチャ上で DynamoDB のアクセスパターンを実行できます。 マルチクラウドおよびハイブリッド インフラストラクチャプロバイダー間でのポータビリティを試しているチームは、PostgreSQL が利用可能なあらゆる場所で DynamoDB API を利用できます。次の図は、ExtendDB から DynamoDB へのマイグレーションがエンドポイント URL の変更だけで済むことを示しています: ExtendDB とは ExtendDB は DynamoDB ワイヤープロトコルの実装で、Rust で書かれており AWS のエンジニアによって開発されています。アプリケーションとストレージバックエンドの間に位置するトランスレーターと考えてください。PostgreSQL リファレンスバックエンドを使用する場合、アプリケーションは DynamoDB プロトコルで通信し、ExtendDB が SQL に変換し、PostgreSQL がストレージを処理します。 ExtendDB はワイヤーレベルで DynamoDB JSON プロトコル を実装します。既存のアプリケーションコード、SDK、ツールは変更なしで接続できます。すべてのデータは PostgreSQL に保存されるため、 pg_dump 、レプリケーション、ポイントインタイムリカバリ、標準的な監視など、すでに知っている運用ツールを利用できます。 ストレージレイヤー は Rust の trait として定義されています。水平スケールに適した Apache Cassandra など、追加のバックエンドをコアを変更することなく実装できます。 ExtendDB は外部ランタイム依存性のない 単一バイナリ にコンパイルされます。 TLS は必須であり、初回実行時に自己署名証明書を自動生成します。ローカル IAM ライクなクレデンシャルストアを備えた SigV4 認証 により、アプリケーションコードは DynamoDB サービスに対して使用するのと同じ署名ロジックを使用します。 サポートされるオペレーション カテゴリ オペレーション テーブル CreateTable、DeleteTable、DescribeTable、ListTables、UpdateTable アイテム PutItem、GetItem、DeleteItem、UpdateItem (条件式付きの SET、REMOVE、ADD、DELETE) Query と Scan キー条件、フィルター式、プロジェクション、ページネーション、セカンダリインデックスの選択 バッチとトランザクション BatchGetItem、BatchWriteItem、TransactGetItems、TransactWriteItems ストリーム ListStreams、DescribeStream、GetShardIterator、GetRecords TTL UpdateTimeToLive、DescribeTimeToLive インポート / エクスポート ImportTable、ExportTableToPointInTime タグ TagResource、UntagResource、ListTagsOfResource アカウントとクレデンシャルの管理は、コマンドラインまたは https://127.0.0.1:8000/console/ の Web 管理コンソールから行えます。 利用開始 ExtendDB は Linux と macOS で動作します。Rust 1.85+ と PostgreSQL 14+ が必要です。 git clone https://github.com/ExtendDB/extenddb.git cd extenddb cargo build --release init コマンドは、稼働中の PostgreSQL インスタンスに接続し、必要なデータベースとスキーマを作成し、管理者用クレデンシャルを生成し、TLS 証明書をプロビジョニングし、設定ファイルを書き出します: ./target/release/extenddb init ./target/release/extenddb serve --config extenddb.toml 次に、DynamoDB アクセス権を持つ IAM ユーザーを作成します。 init コマンドは、 extenddb manage で使用する管理者パスワードとデフォルトのアカウント ID を出力します: ./target/release/extenddb manage --user admin --password '<admin-password>' \ create-user --account-id <account-id> --user-name myuser ./target/release/extenddb manage --user admin --password '<admin-password>' \ put-user-policy --account-id <account-id> --user-name myuser \ --policy-name full-access \ --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"dynamodb:*","Resource":"*"}]}' ./target/release/extenddb manage --user admin --password '<admin-password>' \ create-access-key --account-id <account-id> --user-name myuser これによりアクセスキー ID とシークレットが返されます。CA バンドルとともにこれらをエクスポートします: export AWS_ACCESS_KEY_ID="AKIA..." export AWS_SECRET_ACCESS_KEY="extenddb..." export AWS_CA_BUNDLE=~/.extenddb/tls/cert.pem ExtendDB は https://127.0.0.1:8000 でリッスンしています。標準的な DynamoDB コマンドを使用します: aws dynamodb create-table \ --table-name Orders \ --attribute-definitions AttributeName=PK,AttributeType=S AttributeName=SK,AttributeType=S \ --key-schema AttributeName=PK,KeyType=HASH AttributeName=SK,KeyType=RANGE \ --billing-mode PAY_PER_REQUEST \ --endpoint-url https://127.0.0.1:8000 \ --region us-east-1 aws dynamodb put-item \ --table-name Orders \ --item '{"PK":{"S":"CUSTOMER#123"},"SK":{"S":"ORDER#2026-001"},"total":{"N":"49.99"}}' \ --endpoint-url https://127.0.0.1:8000 \ --region us-east-1 aws dynamodb query \ --table-name Orders \ --key-condition-expression "PK = :pk" \ --expression-attribute-values '{":pk":{"S":"CUSTOMER#123"}}' \ --endpoint-url https://127.0.0.1:8000 \ --region us-east-1 AWS SDK はエンドポイント URL の設定をサポートしています。エンドポイント URL を変更するだけで、その他はすべて変更不要です。 アーキテクチャ ExtendDB は責務を Rust の crate に分離しています。 core crate は、純粋な同期 Rust として型、検証、式の評価を処理します。 engine crate は DynamoDB API のセマンティクスを実装します。 storage-postgres crate は PostgreSQL バックエンドであり、任意のバックエンドが実装すべきインターフェースを定義する storage trait に対して構築されています。 server crate は HTTP サーバー、管理 API、Web コンソールを提供し、これらを統合します。 次のアーキテクチャ図は、ExtendDB の高レベルの概要を示しています: 制限事項 ExtendDB は DynamoDB ではありません。これは互換性のある実装であり、マネージドサービスの代替ではありません。パフォーマンス特性、スケーリング動作、運用上の特性は異なります。マネージドサービスの保証が必要な場合は DynamoDB を使用してください。 データベースが必要であり、その可用性、バックアップ、メンテナンスはユーザーの責任です。TLS は必須です。ExtendDB は SigV4 署名検証とポリシー評価を備えた独自の IAM ライクな実装を含みます。これはスタンドアロンのシステムです。ExtendDB で作成されたクレデンシャルとポリシーは AWS IAM とは完全に分離されており、両者の間で共有することはできません。グローバルテーブルとクロスリージョンレプリケーションは、これらが DynamoDB 固有のマネージド機能であるため実装されていません。 参加するには 本記事では、PostgreSQL をバックエンドとするオープンソースの DynamoDB 互換アダプターである ExtendDB を紹介しました。ローカル開発、CI/CD テスト、オンプレミスデプロイメント、エアギャップ環境のいずれであっても、AWS の外で DynamoDB アクセスパターンを必要とするワークロードがある場合、ExtendDB は既存のアプリケーションコードと SDK で動作する互換性のある実装を提供します。 ExtendDB は初期段階にあり、私たちはオープンに開発を進めています。 GitHub リポジトリ をクローンし、 Getting Started ガイド に従って、数分で DynamoDB 互換エンドポイントをローカルで実行できます。コントリビュート方法の詳細については、 Contribution Guide を参照してください。ギャップを発見した場合や、ストレージバックエンドをコントリビュートしたい場合は、issue を起票するか、プルリクエストを送信してください。 著者について Lee Hannigan Lee はアイルランドのドニゴールを拠点とするシニア Amazon DynamoDB データベースエンジニアです。彼はビッグデータと分析技術の強固な基盤の上に、分散システムにおける豊富な専門知識を持っています。彼の役割では、DynamoDB のパフォーマンス、スケーラビリティ、信頼性の向上に注力し、お客様や社内チームがその機能を最大限に活用できるよう支援しています。 Deepthi Mohan Deepthi は DynamoDB チームのプリンシパルプロダクトマネージャーです。

本記事は 2026 年 5 月 28 日 に公開された「 The next generation of Amazon OpenSearch Serverless: Built from the ground up for agents 」を翻訳したものです。 対象読者向けの注記: 本記事は技術的な詳細を掘り下げたローンチ記事です。変更点とその理由を簡潔にまとめた概要は、関連する AWS News Blog の記事をご覧ください。 本日、Amazon OpenSearch Serverless のアーキテクチャをゼロから刷新したことを発表します。新しいアーキテクチャでは、オートスケーリングが従来比で最大 20 倍に高速化し、コンピューティングをゼロまでスケールできるようになりました。ピーク負荷に合わせてクラスターをプロビジョニングする場合と比べてコストは最大 60% 削減できます。Amazon OpenSearch Service は、ベクトル、レキシカル、ハイブリッド、エージェント検索を統合したフルマネージドのオープンソース検索エンジンで、低レイテンシーかつ正確で関連性の高い結果を提供します。Amazon OpenSearch Serverless は、その自動スケーリング型のデプロイオプションです。 最近のワークロードはますます動的で予測しにくくなっています。E コマースプラットフォームでは、フラッシュセール時にトラフィックが 10 倍に急増します。人工知能 (AI) エージェントは、複数ステップのタスクを推論する過程で数百もの同時ベクトルクエリをトリガーし、その後アイドル状態になります。マルチテナント SaaS アプリケーションでは、活動パターンが大きく異なる数十のテナントを処理します。こうしたワークロードには、需要に合わせてスケールアップし、需要が下がればリソースを解放できるインフラが必要です。 そこで、 Amazon OpenSearch Serverless のアーキテクチャをゼロから再構築しました。新しいアーキテクチャでは、コンピューティングとストレージを分離しています。インフラのプロビジョニングは分単位ではなく秒単位で完了し、アプリケーションがアイドル状態のときにはコンピューティングをゼロまでスケールダウンします。本記事では、新しいアーキテクチャの内容、アプリケーションへの影響、ハンズオンチュートリアルでの使い始め方を解説します。 新しいローンチに伴い、Amazon OpenSearch Serverless では 2 つのアーキテクチャに名前が付きました。既存のコレクションは Classic コレクションと呼びます。新しいアーキテクチャは NextGen と呼び、AWS コンソールから新しいコレクションを作成するときのデフォルトになります。API で NextGen アーキテクチャを使用するには、CLI で --generation NEXTGEN を指定します。Classic アーキテクチャを引き続き使用する場合は、CLI で --generation CLASSIC を指定するか、オプションの --generation パラメータを省略します。 アプリケーションへの影響 新しいアーキテクチャは、パフォーマンス、コスト、シンプルなユーザー体験という 3 つの柱で改善をもたらします。 パフォーマンス: 秒単位のオートスケーリング OpenSearch Compute Unit (OCU) は、インデックス作成と検索のワークロードを支えるコンピューティング容量の単位です。Amazon OpenSearch Serverless は、追加の OCU を秒単位でプロビジョニングできるようになりました。トラフィックが到着したときには、ワーカーがすでに高負荷に陥ってから対応するのではなく、需要に合わせて事前にリソースを追加します。同じ仕組みで、トラフィックが下がるとインフラを素早くスケールダウンします。新しいアーキテクチャは、容量のスケール速度が以前のアーキテクチャの 最大 20 倍 に達するため、トラフィックの急増時にも一貫したパフォーマンスをユーザーに提供でき、容量が不要になれば支払いも止まります。 コスト効率: 使った分だけ支払う インデックス作成、検索、ストレージ、ベクトルインデックスの GPU アクセラレーションは、それぞれ独立して計測・課金されるため、ワークロードの各次元を個別に把握し、最適化できます。 コンピューティングとストレージの分離: OpenSearch Serverless ではコンピューティングとストレージが完全に分離されており、コレクションに保存されているデータ量とは無関係に OCU をスケールアップ・スケールダウンできます。これは、インデックス作成 OCU と検索 OCU の両方からアクセスできる新しいストレージ層によって実現されています。複数のインデックスにデータを格納していても、データのインデックス作成や検索を実際に行っていなければ、コンピューティングコストは発生しません。アイドル時間が長いワークロードでは、ピーク容量に合わせて OpenSearch Service ドメインをプロビジョニングする場合と比べて、新しいアーキテクチャによりインフラコストを最大 60% 削減できます。 ゼロまでのスケール: アイドルタイムアウト期間 (10 分) の間にリクエストが到着しないと、サービスはコンピューティングリソースを解放し、OCU の使用量はゼロまでスケールダウンします。トラフィックが再開すると、約 10 秒で容量が復活します。スケールダウン中も、サービスは到着したリクエストをキューに入れ、容量が利用可能になり次第処理するため、リクエストを破棄することはありません。スケジュールされたバッチジョブやマーケティングキャンペーンの前など、トラフィックの急増が予想される場合は、本番トラフィックを送信する前に軽量なクエリ (例: size=1 の match_all ) を送信してコレクションをウォームアップしておけます。これにより、最初の実リクエストでユーザーが体感するレイテンシーを抑えられます。インデックス作成と検索は独立してスケールします。検索リクエストがなければ、検索 OCU はゼロまでスケールしますが、インデックス作成リクエストがあれば OpenSearch Serverless はインデックス作成 OCU を維持します。逆向きでも同じです。 ベクトルワークロード向けの GPU アクセラレーション: 新しいアーキテクチャで作成したベクトルコレクションでは、OpenSearch Serverless が GPU バックエンドのコンピューティングを自動的に使用して、Hierarchical Navigable Small World (HNSW) ベクトルインデックスの構築を加速し、CPU のみで構築する場合と比べてインデックス作成時間を大幅に短縮します。GPU アクセラレーションは、全体のインデックス作成時間とコストを削減できる機会があれば自動的に有効になります。Classic アーキテクチャでは、API を介してコレクションレベルで GPU アクセラレーションのオプトイン・オプトアウトが必要でした。NextGen コレクションで特定のインデックスの GPU アクセラレーションを無効にしたい場合は、 インデックスレベルでリモートインデックスビルド設定をオフ にできます。GPU の使用量は請求書に別の項目として表示されるため、いつアクセラレーションが有効で、いくらかかったかを完全に把握できます。GPU アクセラレーションの仕組みやパフォーマンスベンチマークの詳細は、 Amazon OpenSearch Service の GPU アクセラレーションで 10 億スケールのベクトルデータベースを 1 時間以内に構築する を参照してください。 シンプルな体験: 本番環境までのステップ削減 OpenSearch Serverless を日々運用する体験もシンプルになりました。 新しいアーキテクチャでは、コレクションをプロビジョニングして数秒でリクエストを送信し始められます。容量計画もサイジングの判断もインフラのウォームアップ待ちも不要です。これにより、AI エージェントがオンデマンドでベクトル検索や検索ステップを起動し、遅延なくレスポンスを期待できる、エージェントワークロードに Amazon OpenSearch Serverless が自然と適合します。 使い始めをさらに高速化するため、コンソールに Express Create を導入しました。コレクション名とコレクションタイプを指定し、Express Create を選ぶと、ネットワーク、暗号化、アクセスポリシーの事前設定なしで、コレクションが数秒でアクティブになります。ワークロードに必要であれば、後から追加できます。 コレクショングループとコレクションは、AWS Command Line Interface (AWS CLI) や AWS SDK を使ってプログラムから作成することもできます。AWS CloudFormation のサポートも近日提供予定です。 新しいアーキテクチャでは、 on.aws ドメイン上に 2 つのエンドポイント形式が導入されました。コレクション単位のエンドポイント ( <collectionId>.aoss.<region>.on.aws ) は、コレクション 1 つにつきエンドポイント 1 つという、これまでと同じ動作です。アカウント単位のリージョナルエンドポイント ( <accountId>.aoss.<region>.on.aws ) は新しく、1 つのホスト名で全コレクションを処理し、対象のコレクションは各リクエストで x-amz-aoss-collection-name または x-amz-aoss-collection-id ヘッダーで指定します。コレクション数に関係なく、コネクションプール 1 つ、Transport Layer Security (TLS) セッション 1 つ、管理するエンドポイント 1 つで済みます。テナントごとに独自のコレクションを割り当てるマルチテナントワークロードでは、大きな改善になります。両方のエンドポイントは標準の AWS PrivateLink を使用するため、他の AWS サービスと同様に、VPC コンソールや EC2 API から Virtual Private Cloud (VPC) エンドポイントを作成できます。Private Domain Name System (DNS) は自動で構成されるため、元のアーキテクチャで必要だった Amazon Route 53 プライベートホストゾーン、転送ルール、カスタム DNS インフラが不要になります。クロス VPC、クロスアカウント、オンプレミスからのアクセスは、追加のセットアップなしに標準の vpce-* DNS 名で動作します。 コレクショングループは、コレクションを整理する新しい単位 です。 コレクショングループ を使うと、複数のコレクション間でコンピューティング容量を共有でき、トラフィックパターンが補完的な小規模コレクションのコストを削減できます。同じグループ内のコレクションに異なる AWS Key Management Service (AWS KMS) キーを割り当てることもでき、コスト効率とコレクション単位の暗号化分離の両方を得られます。新しいアーキテクチャでコレクションを作成する場合、コレクショングループは必須です。 バージョンとアップグレードを管理する手間なく、OpenSearch オープンソースリリースの利点も得られます。サービスはアップストリームのリリースを自動的に追跡します。 Amazon OpenSearch Serverless は Vercel Marketplace でも利用可能になっており、開発者は Vercel プロジェクトから検索インフラを直接追加できます。委任アクセスを通じて既存の AWS アカウントをリンクするか、AWS が初めての場合は USD $100 の AWS クレジット付きの Limited Scope Account を通じて使い始められます。 この統合では、適切なデフォルト、ゼロまでのスケール課金、パブリックエンドポイント、AWS マネージド暗号化を備えたコレクションが作成され、接続情報が Vercel プロジェクトの環境変数として自動的に設定されます。フルテキスト検索でも、セマンティックや AI を活用した検索でも、ユースケースに応じて Search または Vector Search のコレクションタイプを選べます。 アーキテクチャの仕組み 新しい Amazon OpenSearch Serverless アーキテクチャは、コンピューティングとストレージを完全に分離します。OCU はステートレスで、インデックス作成 OCU と検索 OCU の両方からアクセス可能な分散共有ストレージ層から読み書きします。ストレージ層は高い耐久性を念頭に設計されており、データを処理するコンピューティングノードとは独立してデータを利用可能に保ちます。 この設計は、実用上 2 つの効果をもたらします。 高速なプロビジョニング。 ブートストラップするローカルディスクがないため、新しい OCU は数秒でリクエストの処理を開始します。OCU は共有ストレージ層をマウントし、すぐに処理を開始します。 効率的なスケールダウン。 データが OCU 上に存在したことがないため、保存されたデータに影響を与えずにアイドル容量を解放できます。トラフィックが下がるとコンピューティングリソースが解放され、それに応じてコストも下がります。 アーキテクチャの比較 次の表で、元のアーキテクチャと新しいアーキテクチャの主な違いをまとめます。 機能 Classic アーキテクチャ NextGen アーキテクチャ 最小容量 2 OCU (常時稼働) 0 OCU (ゼロまでのスケール) スケーリング速度 分単位 秒単位 ストレージ コンピューティングノードごとのローカルストレージ 分散共有ストレージ (分離) コレクションの整理 個別コレクション (デフォルト) コレクショングループ (オプション) コレクショングループ (必須) ゼロからのコールドスタート 該当なし (常時稼働) 約 10 秒 エンドポイント コレクション単位のエンドポイント リージョナルエンドポイント (アカウントごとに静的) OpenSearch Service ドメインに対するコスト ベースライン 最大 60% 低コスト スケーリング速度 (Classic 比) ベースライン ベースラインの最大 20 倍 ウォークスルー: ベクトルコレクションの作成とゼロまでのスケールの観察 このウォークスルーでは、Express Create でベクトル検索コレクションを作成し、埋め込みを持ついくつかのサンプルドキュメントをインデックスし、k-nearest neighbor (k-NN) クエリを実行し、Amazon CloudWatch でコレクションがゼロまでスケールする様子を観察します。全体で約 10 分かかります。 前提条件 Amazon OpenSearch Serverless コレクションを作成する権限を持つ AWS アカウント。 適切な認証情報で構成された AWS Command Line Interface (AWS CLI)。 curl 7.75 以降 (組み込みの --aws-sigv4 サポート用)。 ステップ 1: セキュリティポリシーを構成する 暗号化、ネットワーク、データアクセスポリシーを作成します。コレクションを作成する前にこれらが存在している必要があります。 # Create an encryption policy aws opensearchserverless create-security-policy \ --name product-vectors-encryption \ --type encryption \ --policy '{"Rules":[{"ResourceType":"collection","Resource":["collection/product-vectors"]}],"AWSOwnedKey":true}' \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" # Create a network policy (public access for this tutorial) aws opensearchserverless create-security-policy \ --name product-vectors-network \ --type network \ --policy '[{"Rules":[{"ResourceType":"collection","Resource":["collection/product-vectors"]},{"ResourceType":"dashboard","Resource":["collection/product-vectors"]}],"AllowFromPublic":true}]' \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" # Get your principal ARN PRINCIPAL_ARN=$(aws sts get-caller-identity --query 'Arn' --output text) # Create a data access policy aws opensearchserverless create-access-policy \ --name product-vectors-data \ --type data \ --policy "[{\"Rules\":[{\"ResourceType\":\"index\",\"Resource\":[\"index/product-vectors/*\"],\"Permission\":[\"aoss:CreateIndex\",\"aoss:DescribeIndex\",\"aoss:UpdateIndex\",\"aoss:DeleteIndex\",\"aoss:ReadDocument\",\"aoss:WriteDocument\"]}],\"Principal\":[\"\${PRINCIPAL_ARN}\"]}]" \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" 注: AWS コンソールの Express Create ワークフローを使用すると、これらのポリシーは自動的に作成されます。 重要: データアクセスポリシーを作成した後、コレクションへの API 呼び出しを行う前に、ポリシーが伝播するまで約 30〜60 秒待ちます。403 Forbidden エラーが発生した場合は、待ってから再試行してください。 ステップ 2: コレクショングループとコレクションを作成する ゼロまでのスケール容量制限を持つコレクショングループを作成し、その中にベクトル検索コレクションを作成します。 # Create a collection group with scale-to-zero enabled (min OCU = 0) aws opensearchserverless create-collection-group \ --name product-search-cg \ --generation NEXTGEN \ --standby-replicas ENABLED \ --capacity-limits "minIndexingCapacityInOCU=0,maxIndexingCapacityInOCU=4,minSearchCapacityInOCU=0,maxSearchCapacityInOCU=4" \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" # Create a vector search collection in the group aws opensearchserverless create-collection \ --name product-vectors \ --type VECTORSEARCH \ --collection-group-name product-search-cg \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" コレクションのステータスは数秒で ACTIVE に遷移します。 ステップ 3: ベクトルインデックスを作成する コレクションエンドポイントを取得し、3 次元ベクトルを使った k-NN インデックスを作成します。 ENDPOINT=$(aws opensearchserverless batch-get-collection \ --names product-vectors \ --query 'collectionDetails[0].collectionEndpoint' \ --output text \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2") awscurl --service aoss --region us-east-2 \ -XPUT "${ENDPOINT}/items" \ -H "Content-Type: application/json" \ -d '{ "settings": {"index.knn": true}, "mappings": { "properties": { "description": {"type": "text"}, "embedding": {"type": "knn_vector", "dimension": 3, "method": {"name": "hnsw", "space_type": "cosinesimil", "engine": "faiss"}} } } }' 注: コレクションがゼロまでスケールしている場合、容量がスケールアップする間、最初のリクエストには数秒かかる可能性があります。リクエストがタイムアウトした場合は、10〜15 秒待ってから再試行してください。 ステップ 4: 埋め込みを持つサンプルドキュメントをインデックスする awscurl --service aoss --region us-east-2 \ -XPOST "${ENDPOINT}/items/_bulk" \ -H "Content-Type: application/json" \ -d ' { "index": { "_id": "1" } } { "description": "Wireless noise-cancelling headphones", "embedding": [0.8, 0.2, 0.1] } { "index": { "_id": "2" } } { "description": "Portable Bluetooth speaker", "embedding": [0.7, 0.3, 0.2] } { "index": { "_id": "3" } } { "description": "Over-ear studio monitor headphones", "embedding": [0.9, 0.1, 0.05] } ' ステップ 5: k-NN クエリを実行する クエリベクトルに最も近い 2 つの近傍を検索します。クエリを実行する前に、ベクトルインデックスのビルドのため、インデックス作成後 30 秒待ちます。 awscurl --service aoss --region us-east-2 \ -XGET "${ENDPOINT}/items/_search" \ -H "Content-Type: application/json" \ -d '{ "query": { "knn": { "embedding": { "vector": [0.85, 0.15, 0.08], "k": 2 } } } }' レスポンスでは、最も類似する 2 つのアイテム、つまりクエリベクトルに最も近い埋め込みを持つヘッドフォンのドキュメントが返されます。 このクエリは OpenSearch UI でも実行できます。Amazon OpenSearch Service コンソールでコレクションに移動し、OpenSearch UI Application URL を選択します。次に こちらのブログ の手順に従ってワークスペースを作成します。その後、Dev Tools に移動して、次のクエリを貼り付けて実行します。 GET items/_search { "query": { "knn": { "embedding": { "vector": [0.85, 0.15, 0.08], "k": 2 } } } } ステップ 6: ゼロまでのスケールを観察する 一定期間活動がない (インデックス作成や検索のトラフィックがない) と、コレクショングループは 0 OCU までスケールダウンします。次のコマンドで確認します。 aws opensearchserverless batch-get-collection-group \ --names product-search-cg \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" レスポンスで、コレクションがスケールダウンした後、 currentCapacity.search.capacityInOcu と currentCapacity.indexing.capacityInOcu が 0 と表示されます。 Amazon OpenSearch Service コンソールの コレクショングループ ページに移動することもできます。コレクショングループを選択し、 モニタリング セクションまでスクロールします。 インデックス作成容量 (OCU) と 検索容量 (OCU) という 2 つのチャートを確認できます。10 分間アイドル状態 (インデックス作成や検索リクエストがない状態) が続くと、両方のメトリクスがゼロまで下がり、サービスがコレクションのコンピューティングリソースをすべて解放したことが確認できます。 クリーンアップ 継続的な課金を避けるため、このウォークスルーで作成したリソースは終わったら削除します。最初にコレクションを削除してコレクショングループを空にし、次にグループを削除し、最後にセキュリティポリシーとアクセスポリシーを削除します。 # Look up the collection ID, then delete the collection COLLECTION_ID=$(aws opensearchserverless batch-get-collection \ --names product-vectors \ --query 'collectionDetails[0].id' \ --output text \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2") aws opensearchserverless delete-collection \ --id "${COLLECTION_ID}" \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" # Look up the collection group ID, then delete the collection group GROUP_ID=$(aws opensearchserverless batch-get-collection-group \ --names product-search-cg \ --query 'collectionGroupDetails[0].id' \ --output text \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2") aws opensearchserverless delete-collection-group \ --id "${GROUP_ID}" \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" # Delete the security and access policies aws opensearchserverless delete-security-policy \ --name product-vectors-encryption \ --type encryption \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" aws opensearchserverless delete-security-policy \ --name product-vectors-network \ --type network \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" aws opensearchserverless delete-access-policy \ --name product-vectors-data \ --type data \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" 既存のコレクションのアップグレード 新しいアーキテクチャに移行するには、新しいコレクショングループとコレクションを作成し、データを再インデックスします。再インデックスの手順は Amazon OpenSearch Ingestion を使った Amazon OpenSearch Serverless での再インデックスの実行 に詳しく解説しています。クエリとインデックスマッピングは同じままで、変わるのはコレクションエンドポイントだけです。新しい静的リージョナルエンドポイントなら、これは 1 回限りの更新で済みます。 新しいアーキテクチャは SEARCH と VECTORSEARCH のコレクションタイプをサポートします。TIMESERIES はローンチ時にはサポートされません。 まとめ 新しい Amazon OpenSearch Serverless アーキテクチャは本日から利用可能です。Express Create を使えば最初の OpenSearch Serverless コレクションを数秒で作成し、本番トラフィックに対応するようスケールでき、アイドル状態になれば OpenSearch Serverless のコンピューティングコストはゼロまで下がります。 詳細は次を参照してください。 Amazon OpenSearch Service ドキュメント 。 Amazon OpenSearch Service コンソール 。 Amazon OpenSearch Service 料金ページ 。 質問やフィードバックがあれば、サポートケースを開くか、AWS アカウントチームを通じて連絡してください。皆さんが構築するものを楽しみにしています。 著者について Sohaib Katariwala Sohaib は AWS の Senior Specialist Solutions Architect で、イリノイ州シカゴを拠点に Amazon OpenSearch Service を担当しています。データと分析に関するあらゆる事柄に関心があります。特に、お客様がデータ戦略の中で AI を活用し、現代的な課題を解決できるよう支援することを楽しみにしています。 Raj Ramasubbu Raj は AWS の Senior Analytics and AI Specialist Solutions Architect で、ビッグデータ、分析、AI/ML に注力しています。お客様と協力して、高いスケーラビリティ、パフォーマンス、セキュリティを備えたクラウドベースのソリューションを設計・構築しています。 Arjun Nambiar Arjun は Amazon OpenSearch Service の Product Manager です。多種多様なソースから Amazon OpenSearch Service へ大規模にデータを取り込めるようにする取り込み技術に注力しています。Arjun は大規模分散システムやクラウド中心の技術に関心があり、ワシントン州シアトルを拠点としています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。