AWS What's New Digest

Appearance

2026年09月11日 ​

[RDS] Amazon RDS for Oracle now supports Supplemental Patch Bundle for July 2026 Release Update ​

概要 ​

Amazon RDS for Oracleが、Oracle Databaseの2026年7月リリース更新（RU）向けSupplemental Patch Bundle（SPB）をエンジンバージョン19cおよび26aiでサポートしました。SPBは以前のOracle Spatial Patch Bundleの名称変更で、特定機能向けの追加パッチをまとめたものです。

変更内容・新機能の詳細 ​

内容のポイント:

  • 対象エンジンバージョン: 19cおよび26aiに対して、19.0.0.0.ru-2026-07.spb-1.r1 と 26.0.0.0.ru-2026-07.spb-1.r1 のSPB対応エンジンが利用可能になりました。
  • 名称変更: 2026年4月のリリース以降、従来のOracle Spatial Patch BundleはSupplemental Patch Bundle（SPB）に名称が変更されています。
  • 含まれる修正例: Oracle Spatial関連、Oracle Data Pump、Oracle GoldenGateなど特定ユースケース向けにOracleが推奨する追加パッチが含まれます（各パッチの詳細はOracle/AWSのリリースノートを確認してください）。
  • 適用方法: 新規DB作成時または既存インスタンスのエンジンアップグレード時に、AWS マネジメントコンソールで「Supplemental Patch Bundle Engine Versions」チェックボックスを選択して適用します。適用はエンジンバージョンを上記SPB付きバージョンに変更することで行われます。
  • ロールアウト制御: AWS Organizationsのアップグレードロールアウトポリシーを利用して、自動マイナーバージョンアップデートを非本番→検証→本番へ段階的に適用する運用が可能です。
  • 注意事項: 各エンジンバージョンでサポートされるSPBの内容や影響は異なるため、Amazon RDS for Oracleのリリースノートで対象バージョンごとの詳細を確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: RDS for Oracle を利用するDB管理者、DBA、SRE、アプリケーション開発チーム
  • 利用シーンまたは効果: Oracle Spatial、Data Pump、GoldenGateなど特定機能を利用している場合に、Oracleが推奨する修正をまとめて適用できるため、機能安定性やセキュリティが向上する
  • 運用効果: AWS Organizationsのロールアウトポリシーと組み合わせることで、非本番環境での事前検証 → 本番反映の段階的適用が可能になり、リスク低減とアップデートの標準化が実現できる

技術的な注意点 ​

  • バックアップ推奨: アップグレード適用前にスナップショットやバックアップを取得し、ロールバック手順を確認してください
  • ダウンタイム: エンジンのアップグレードにはインスタンス再起動（ダウンタイム）が発生する可能性があります。メンテナンスウィンドウの設定を確認してください
  • 互換性: SPBには機能修正が含まれるため、アプリケーションやレプリケーション（GoldenGate等）の互換性影響を事前に検証してください
  • IAM権限: エンジンバージョンの変更や自動アップデート設定には、RDSの変更権限（rds:ModifyDBInstance等）が必要です。AWS Organizationsポリシーを用いる場合はOrganizations管理者側の設定権限も必要です
  • リージョン制限: 全リージョンで同時に提供されない可能性があります。対象リージョンでのSPB提供状況はリリースノートで確認してください
  • コスト: SPB適用自体に追加料金は通常発生しませんが、アップグレードに伴う作業コストや検証コスト、停止によるビジネス影響には注意してください。またBYOL（Bring Your Own License）の場合はOracleライセンス要件を確認してください
  • ロールアウト設定: 自動マイナーバージョンアップをOrganizationsのロールアウトポリシーで段階的に適用する場合、ポリシー設定とOU構成を事前に計画してください
  • リリースノート確認: 各エンジンバージョンごとのSPB内容（どのパッチが含まれるか）は変わるため、Amazon RDS for OracleのリリースノートとOracleのRU/SPBドキュメントを必ず参照してください

参考情報 ​

[Lambda] AWS Lambda recursive loop detection is now available in Europe Sovereign Cloud ​

概要 ​

AWS Lambdaの再帰（recursive）ループ検出機能がEurope Sovereign Cloudで利用可能になりました。Lambda関数とS3/SQS/SNSなどのイベントソース間で発生する意図しない再帰呼び出しを自動検出して停止します。

変更内容・新機能の詳細 ​

再帰ループ検出は、Lambda関数がトリガー元のイベントソースへ再度イベントを送ってしまうような誤設定やコード不具合による無限ループ状の呼び出しを自動で検出し、当該イベントの処理を停止します。対象となる代表的なイベントソースには Amazon S3、Amazon SQS、Amazon SNS などが含まれます。ループを検知すると処理を中止し、トラブルシューティング手順を含む AWS Health Dashboard の通知が送信されます。本機能はサポートされている SDK バージョンを使用している Lambda 関数ではデフォルトで有効です。意図的に再帰を行うユースケースがある場合は、PutFunctionRecursionConfig API を呼び出して個別の関数で検出を無効化できます。これにより予期せぬ大量実行による課金リスクを軽減できます。

影響範囲・利用シーン ​

  • 対象ユーザー: Lambda を利用したイベント駆動アプリケーションを運用する開発者、SRE、運用チーム
  • 利用シーン: S3/SQS/SNS 等をトリガーにした関数が誤って同じソースへイベントを書き戻してしまうケースの検出と自動停止
  • 運用効果: 予期せぬ再帰ループによる大量実行や過剰請求の防止、問題発生時に AWS Health を通じた通知で早期対応が可能

技術的な注意点 ​

  • IAM権限: PutFunctionRecursionConfig を使って設定変更するには lambda:PutFunctionRecursionConfig 等の権限が必要です。AWS Health の通知確認には適切な AWS Health の閲覧権限も必要です
  • リージョン制限: 本リリースは Europe Sovereign Cloud 向けの提供開始を示します。他の商用リージョンの対応状況は既存ドキュメントで確認してください（リージョンによっては既に提供済みの可能性があります）
  • SDK要件: 再帰検出は「サポートされている SDK バージョンを使用している関数」でデフォルト有効となります。古い SDK/ランタイムを利用している場合はアップデートが必要です
  • API注意点: 検出を無効化する PutFunctionRecursionConfig は関数単位の設定変更であるため、意図的に再帰を許可する関数のみ個別にオフにしてください
  • コスト: AWS は本機能自体の追加料金を明示していませんが、本機能によって大量実行による不要な課金を防げます。検出無効化によるループ発生はコスト増加を招くため注意が必要です

参考情報 ​

[General] AWS Transform for .NET now generates unit tests for modernized code ​

概要 ​

AWS Transform for .NETが、モダナイズしたコード向けに自動で単体テストコードを生成できるようになりました。Visual Studio上の同じ変換ジョブ内でテスト生成を行い、モダナイズ後にテストが付帯した状態で移行を完了できます。

変更内容・新機能の詳細 ​

AWS Transform for .NETは、.NET Frameworkから最新の.NETへモダナイズする際に、変換対象コードの“テスト可能性（testability）”を評価し、対象クラス（ビジネスロジックやコントローラーなど）やメソッドを選定して対応する単体テストコードを自動生成します。生成はオプトインで、変換ジョブ開始時または変換完了後に有効化できます。生成されたテストは変換済みのビルド可能なコードベースに追加され、手動でテストを作成してカバレッジを確保する必要を軽減します。機能はAWS Toolkit for Visual Studio拡張でサポートされ、AWS Transform for .NETが利用可能な全リージョンで使用できます。開始方法はVisual Studioで.NET変換を実行し、単体テスト生成を選択するだけです。詳細は「Modernizing .NET in the IDE（AWS Transformユーザーガイド）」を参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: .NET開発者、移行エンジニア、SRE／テストエンジニア
  • 利用シーン: .NET Frameworkアプリケーションの近代化（モダナイズ）作業時に、変換済みコードへ自動で単体テストを付与して移行後の品質担保を短縮する場面
  • 運用効果: モダナイズ完了時点でテストが揃うことで手動でのテスト作成工数を削減し、リグレッションや動作保証の初期検証を自動化できる
  • 開発ワークフローへの影響: Visual Studio内で一連の変換→テスト生成が完結するため、CIパイプライン導入前段階のテストカバレッジ確保が容易になる

技術的な注意点 ​

  • IAM権限: AWS Transform実行やAWS Toolkitがアクセスするための適切なIAM権限（Transformサービス、S3等へのアクセス権）を用意してください
  • リージョン制限: AWS Transform for .NETがサポートするすべてのリージョンで利用可能です。対象リージョンでTransformが提供されているか事前に確認してください
  • コスト: 新機能自体の課金は記事で明示されていませんが、AWS Transformや関連サービス（ストレージ、ログ収集、データ転送など）に伴うコストが発生する可能性があります。料金ページを確認してください
  • 前提条件: Visual StudioとAWS Toolkit for Visual Studio拡張が必要です。プロジェクトはTransformでサポートされる.NETプロジェクト形式である必要があります
  • テストの品質と確認: 生成されるテストは自動生成コードであり、モック設定や外部依存の扱い、ビジネスロジックの意図に対する検証は手動レビューが必要です。CIへ組み込む前に内容確認と必要な調整を行ってください
  • オプトイン/タイミング: 単体テスト生成はオプトインで、ジョブ開始時または変換後に有効化できます。ワークフローに合わせて選択してください

参考情報 ​

[API Gateway] Amazon API Gateway now supports 1 MB execution logs with configurable delivery destinations ​

概要 ​

Amazon API Gateway（REST API）の実行ログで、従来の1 KBから最大1 MBまでのログイベントをユーザー管理の配信先へ送れるようになりました。CloudWatch Logs、Amazon S3、Amazon Kinesis Data Firehoseへ同時に配信可能です。

変更内容・新機能の詳細 ​

これまでAPI Gatewayの実行ログはAPI Gatewayが管理する単一のCloudWatch Logsロググループに1 KBで切り捨てられて配信されていました。今回のアップデートにより、REST APIの実行ログを最大1 MBまで拡張して、自分のCloudWatch Logsロググループ、S3バケット、またはData Firehoseストリームへルーティングできるようになりました。複数配信先を同時に指定できるため、例としてはS3へParquet形式で長期保存・コスト効率の良い分析（Amazon Athena）用に送りつつ、CloudWatch Logsへは構造化JSONを送りリアルタイムのアラートやメトリクスに利用するといった使い分けが可能です。配信設定はAPI Gatewayコンソール、AWS CLI、またはAWS CloudFormationで行えます。配信された実行ログは“vended logs”レート（CloudWatchの販売ログ料金）で課金されます。機能はREST APIが利用可能なすべてのAWSリージョン（AWS GovCloudを含む）で利用可能です。導入時は配信先の保存ポリシー、暗号化、アクセス権限、コストやサービスごとの取り込み制限等も考慮してください。

影響範囲・利用シーン ​

  • 対象ユーザー: API開発者、バックエンドエンジニア、SRE/運用チーム、セキュリティ/監査担当者
  • 利用シーン: 詳細なリクエスト/レスポンスのトラブルシューティング、セキュリティ監査、長期ログ保存とコスト効率の良い分析（S3+Athena）、リアルタイムアラート（CloudWatch Logs）
  • 運用効果: ログの可視化が向上し、従来は切り捨てられていた大きなペイロードや詳細なヘッダ情報も取得可能になり、問題解析や監査、データ分析の精度が向上する

技術的な注意点 ​

  • IAM権限: API GatewayがCloudWatch Logs、S3、Firehoseへ書き込むための適切なIAMロール/ポリシー（PutObject、PutRecord/PutRecordBatch、logs:CreateLogStream/logs:PutLogEvents等）を設定する必要があります
  • リージョン制限: REST APIが利用できるすべてのリージョン（AWS GovCloud含む）で提供されています。ただし、リージョンごとのサービス制限や連携先（たとえばS3バケットのリージョン）に注意してください
  • コスト: 配信された実行ログはCloudWatchのvended logs課金が適用されます。S3保存、Firehose配信、Athenaクエリなどの追加コストも発生します。試験的に大量ログを流す前にコスト試算を行ってください
  • 対象APIタイプ: 本機能はREST API向けの拡張です。HTTP APIやWebSocket APIの挙動は別途確認してください
  • ログサイズ/フォーマット: 最大1 MBのログイベントをサポートします（従来は1 KBで切り捨て）。構造化JSONやParquet（S3へParquetで配信する場合はFirehoseの変換機能等の利用）など、配信先に応じたフォーマット選択が可能です
  • セキュリティ/プライバシー: 大容量ログには個人情報や機密情報が含まれる可能性があるため、ログのマスキング/フィルタリングやSSEによる暗号化、アクセス制御を検討してください
  • 配信先の制限: 配信先（CloudWatch Logs、S3、Firehose）側のAPI/取り込みサイズ制限やレート制限を確認してください。Firehoseを経由してParquetに変換する場合は追加の処理設定（変換やGlue連携等）が必要になることがあります
  • 導入手段: コンソール、AWS CLI、CloudFormationで設定可能。CloudFormationでの自動化時は該当リソースと必要IAMロールをテンプレートへ明示してください

参考情報 ​

[Lambda] AWS Lambda durable functions integrates with Pydantic AI ​

概要 ​

AWS Lambda Durable FunctionsがPydantic AIと統合され、Python製のAIエージェント（Pydantic AI）実行時に各モデル／ツール呼び出しをチェックポイントとして保存し、中断後は最後に完了したステップから再開できるようになりました。これにより再実行による追加コストや意図しない副作用を抑えられます。

変更内容・新機能の詳細 ​

今回の統合では、Pydantic AIエージェントが行う各モデル呼び出しやツール呼び出しが「耐久実行（durable execution）」のステップとして扱われ、Lambda Durable Functionsがその進捗を自動で保存（チェックポイント）します。実行がタイムアウトや中断で停止した場合、エージェントは最後に正常に完了したステップから再開し、既に終わったステップを重複して呼び出さないため、トークン消費や外部API呼び出しの二重課金・二重処理を回避できます。実行はAWS Lambda上で行われるためサーバ管理は不要で、使用したコンピュート分のみ課金されます。統合は任意のPythonベースのAWS Lambda Durable Functionで利用可能で、利用開始にはPydantic AIのインストールと同プロジェクトの「AWS Lambda durability」ドキュメントに従う必要があります。より詳細な実装・API仕様はDurable Execution SDKのリファレンスとLambda Durable Functionsの開発者ガイドを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: PythonでAIエージェント（Pydantic AI）を運用する開発者、MLエンジニア、SRE/運用チーム
  • 利用シーン: 長いチェーンのモデル呼び出しや多数ドキュメントの逐次処理、外部APIを含む調査ワークフローなど途中で中断されるとコストや副作用が発生する処理の実行
  • 運用効果: 中断後の復帰が容易になり、再実行によるトークン課金や外部サービスへの重複リクエストを削減。可用性・フォールトトレランスが向上しデバッグ／運用負荷を軽減

技術的な注意点 ​

  • IAM権限: Lambda実行ロールに対して、Durable Execution SDKが利用するログ出力やチェックポイント保存先（ドキュメントで指定されているストレージサービス）へのアクセス権を付与してください。具体的な権限は導入前に公式ドキュメントで確認を推奨します
  • リージョン制限: 本機能は「AWS Lambda Durable Functions が利用可能なリージョン」で利用可能です。利用を予定するリージョンで提供状況を確認してください
  • ランタイム／互換性: 任意のPythonベースのAWS Lambda Durable Functionで利用可能ですが、対応するPythonランタイムやPydantic AIのバージョン要件はPydantic AIおよびAWSのドキュメントで確認してください
  • コスト: Lambdaの実行時間に応じた通常の課金に加え、チェックポイント保存に伴うストレージやオペレーションの小額コストが発生する可能性があります（詳細はドキュメント参照）
  • データ整合性・副作用: Durable Functionsは完了済みステップを繰り返し実行しない設計ですが、外部サービスに対する副作用（課金処理、受注確定など）がある場合はエージェント側でも冪等性設計や確認ロジックを組み合わせることを推奨します
  • セキュリティとネットワーク: エージェントが外部APIや社内サービスにアクセスする場合はVPC設定やネットワーク経路、シークレット管理（Secrets ManagerやParameter Store）を事前に設計してください

参考情報 ​

[Mq] Amazon MQ now supports RabbitMQ 4.3 ​

概要 ​

Amazon MQ が RabbitMQ 4.3 をサポート開始しました。Quorum queue の強化（コンパクション、32段階の厳格プライオリティ、ネイティブ遅延リトライ、プロトコル単位の消費者タイムアウト等）とメモリ管理の改善が含まれます。

変更内容・新機能の詳細 ​

RabbitMQ 4.3 の主な追加・変更点は以下の通りです。Quorum queues のコンパクション機能によりキューのディスク使用量を削減でき、ディスク上の古いログや不要データを圧縮して保管効率を上げます。優先度は従来の相対的な2レベル相当から、32段階の "strict priority" をネイティブにサポートし、より細かな優先処理が可能です。ネイティブな遅延リトライ機構（failed messages を別置きして一定クールダウン後に再配送）をサポートし、外部の遅延プラグインや複雑な DLX 設定を減らせます。消費者タイムアウトはグローバルなプロトコルチャネル単位から quorum queue 単位（かつプロトコル別）に移動し、細かな制御が可能になりました。これら（消費者タイムアウト、遅延リトライ）は RabbitMQ Policies で設定・管理できます。さらにメモリ管理やバグ修正によるパフォーマンス改善が含まれます。一方で transient non-exclusive queues、Global QoS、Classic queues v1 storage は非サポートになり、classic queue には consumer timeout が適用されません。Amazon MQ 上で 4.3 を利用するには新しいブローカー作成時に RabbitMQ 4.3 を選び、m7g インスタンスタイプを使用します。パッチ（マイナー）管理は Amazon MQ が自動で行うため、ユーザーは major.minor（例: 4.3）を指定するだけでよく、4.3 は m7g が利用可能なリージョンで提供されています。

影響範囲・利用シーン ​

  • 対象ユーザー: メッセージングを利用するアプリケーション開発者、メッセージングアーキテクト、SRE/運用チーム
  • 利用シーン: 高優先度メッセージ処理（細かい優先度階層が必要なワークロード）、ディスク使用量の削減が求められる大規模キュー運用、遅延リトライやクールダウンをネイティブで管理したいケース
  • 運用効果: ディスク使用量削減とメモリ管理改善による安定性向上、ポリシーでの遅延リトライ・タイムアウト制御により運用ルールの簡素化が可能
  • 移行影響: transient non-exclusive queues や Global QoS、Classic queues v1 ストレージを使っている場合は設計変更や移行が必要
  • 可用性制約: m7g インスタンスタイプが利用できるリージョンに限定されるため、リージョン戦略に影響する可能性がある

技術的な注意点 ​

  • IAM権限: ブローカー作成・更新には Amazon MQ 作成/管理用の IAM 権限が必要です（Broker 作成、インスタンスタイプ指定、タグ付け等）。
  • リージョン制限: RabbitMQ 4.3 は Amazon MQ の m7g インスタンスが提供されているリージョンでのみ利用可能です。利用前に対象リージョンで m7g がサポートされているか確認してください。
  • コスト: 直接の新機能課金はありませんが、m7g インスタンスタイプを利用するためインスタンスの料金が従来と異なる可能性があります。ディスクや I/O パターンの変化（コンパクションによる I/O スパイクなど）でストレージコストやパフォーマンス要件に影響が出ることがあります。
  • 互換性/非推奨: transient non-exclusive queues、Global QoS、Classic queues v1 storage はサポートされません。classic queues には consumer timeout が適用されない点に注意してください。既存構成の検証と必要なマイグレーション手順を事前に計画してください。
  • 構成管理: 消費者タイムアウトや遅延リトライは RabbitMQ Policies で設定します。ポリシーの適用範囲（vhost/queue 名等）を設計に組み込んでください。
  • 運用/パッチ: Amazon MQ は RabbitMQ 4.3 のパッチ（マイナー）アップデートを自動管理します。ユーザーは major.minor を指定すればよく、パッチ更新のスケジュールとメンテナンスウィンドウを運用ポリシーに組み込んでください。
  • テスト推奨: 新しい優先度動作や遅延リトライの動作、コンパクションが既存ワークロードに与える I/O/レイテンシ影響を事前にステージング環境で負荷試験してください。

参考情報 ​

[Outposts] Announcing second-generation single-rack AWS Outposts ​

概要 ​

AWSは第2世代のシングルラック型AWS Outpostsを一般提供開始しました。42Uの自己完結型ラックで、最大2,688 vCPUと100 TBのEBSを内蔵し、スペースや電力が限られたオンプレ環境向けに低レイテンシ／データレジデンシ要件を満たします。

変更内容・新機能の詳細 ​

第2世代シングルラックOutpostsは、コンピュート、ストレージ、ネットワーキングを1台の42Uラックに統合したオンプレミス向けのマネージドハードウェアです。仕様として最大2,688 vCPUと100 TBのAmazon EBSストレージを提供し、最新のx86ベースEC2インスタンスファミリー（汎用：M7i、M8i、コンピュート最適化：C7i、C8i、メモリ最適化：R7i、R8i）およびOutposts向けのアクセラレーテッドネットワーキングインスタンス（Bmn-sf2e、Bmn-cx2、Bmn-cx3a）に対応します。シングルラックは、製造業やゲームなどラックスペースや電力が限られる拠点でも最新のAWS機能をオンプレで利用できるように設計されています。機能面ではマルチラックOutpostsと同様に、AWSのAPI、管理コンソール、自動化ツール、ガバナンスポリシー、セキュリティコントロールが一貫して利用可能であり、AWSリージョンとオンプレ環境間で同じ運用モデルを実現します。利用開始や地域対応状況についてはOutposts rackのFAQとOutpostsコンソールを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: 製造業、ゲーム、通信、ヘルスケアなどで低レイテンシ処理やデータレジデンシが必要なクラウド／オンプレ統合を行うシステム担当者
  • 利用シーン: ローカルリアルタイム処理、工場やスタジオのエッジ解析、規制でデータをオンプレに保持する必要があるワークロード、クラウド移行の段階的モダナイゼーション
  • 運用効果: AWSと同一のAPI/コンソールで管理できるため運用の一貫性が保たれ、アプリケーションの近接配置によりレイテンシ低減と帯域利用の最適化が可能
  • コスト影響: ハードウェア（Outpostsラック）利用料および標準のEC2/EBS/データ転送課金が発生するため、オンプレ資産運用とAWS課金の両面でコスト見積が必要
  • リージョン制限: 全リージョン／国で利用できるわけではありません。サポートされるリージョン・国はOutposts rack FAQで確認してください

技術的な注意点 ​

  • 設置要件: 42Uラックの物理スペース、電力（通常高電力供給／三相電源等）、冷却が必要。サイト準備（アクセス、床耐荷重など）を事前に確認
  • ネットワーク/接続: 管理プレーンのために親リージョンとのネットワーク接続（低遅延または十分な帯域）が必要。完全オフライン運用は制約がある場合あり
  • IAM権限: Outpostsの操作には専用のサービスリンクドロールやEC2/Outposts関連のIAM権限が必要。事前に権限設計を行う
  • インスタンス互換性: 第2世代シングルラックはx86（指定のM/C/R系ファミリーおよびBmn系アクセラレーテッド）をサポート。Graviton（ARM）系インスタンスは対象外の可能性があるため要確認
  • セキュリティ/運用分担: ハードウェア配送・設置はAWSが関与するケースが多いが、物理セキュリティや場内電源管理などは顧客責任となる部分があるため責任分界（RACI）を明確化
  • コスト: Outpostsはラック単位の課金モデルや契約形態があるため、導入前に料金ページや見積もりで総保有コスト（TCO）を確認
  • リージョン制限: 提供可否は国・地域ごとに異なるため、導入前にOutposts rack FAQで対応状況を確認

参考情報 ​

[Opensearch Service] Amazon OpenSearch Serverless is now available on v0 by Vercel ​

概要 ​

Amazon OpenSearch Serverless が Vercel の v0 プラットフォーム上で利用可能になりました。自然言語プロンプトでフルスタック検索・AIアプリを数分で生成・デプロイでき、OpenSearch Serverless がインフラ管理と自動スケーリングを担います。

変更内容・新機能の詳細 ​

v0 by Vercel のインターフェースから自然言語プロンプトで要件を記述するだけで、v0 がフルスタックアプリを生成し、Amazon OpenSearch Serverless のコレクションを自動でプロビジョニングしてデータをインデックス化し、生成したアプリはその OpenSearch Serverless エンドポイントを用いて検索クエリを実行します。サポートされる検索機能には全文検索とベクター検索が含まれ、RAG（retrieval-augmented generation）ワークロードに対応します。v0 は必要な環境変数や構成を自動で設定し、プロバイダー固有のエージェントスキルを読み込んで推奨パターンに従ったコードを生成します。リソースは新しい AWS アカウント下にプロビジョニングするか、既存の AWS アカウントへリンクして利用することができます。本ローンチでの利用可能リージョンは以下の通りです：US East (N. Virginia), US East (Ohio), US West (Oregon), US West (N. California), Canada (Central), South America (São Paulo), Europe (Ireland), Europe (London), Europe (Paris), Europe (Frankfurt), Europe (Stockholm), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Osaka)。詳細な手順や設定は Vercel の案内および Amazon OpenSearch Serverless のドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: フロントエンド/フルスタック開発者、MLエンジニア、プロトタイプ作成者、スタートアップおよびSRE/運用チーム
  • 利用シーン: 自然言語で要件を記述して短時間で検索・RAG対応のウェブアプリを生成する開発フロー（プロトタイプ〜本番）
  • 運用効果: インフラ管理負荷の低減と自動スケーリングにより、クラスター運用や容量設計の工数を削減可能
  • 開発効果: v0 が環境変数や接続設定、コードパターンを自動生成するため、開発開始までの時間を大幅短縮

技術的な注意点 ​

  • IAM権限: 既存の AWS アカウントにリンクする場合は、v0 が必要とする最小権限（OpenSearch Serverless の作成/管理・インデックス操作・Secrets/環境変数へのアクセス等）を付与するための IAM ロール/ポリシーを準備してください
  • リージョン制限: 本機能は記事で列挙されたリージョンで利用可能です。利用前に対象リージョンでの提供状況を確認してください
  • コスト: OpenSearch Serverless の利用は AWS 側の課金対象です（ストレージ、検索/インデックス処理等）。加えて Vercel 側のプランや追加サービスに伴う料金が発生する可能性があります
  • セキュリティ/データ保護: v0 が自動でデータをインデックス化するため、機密情報や個人情報を扱う場合は事前にデータフィルタリングや暗号化、アクセス制御の設計を行ってください。また、生成された環境変数やシークレットの取り扱いを確認してください
  • プロビジョニング方法: v0 は新規 AWS アカウント作成時のプロビジョニングか既存アカウントとのリンクのどちらかを選べます。既存アカウントを使う場合は権限範囲と監査ログの確認を推奨します
  • 可観測性と検証: v0 が生成したアプリやインデックス化処理は自動化されていますが、実運用前にインデックス内容・検索精度・パフォーマンス（レイテンシ、スループット）を検証してください
  • 互換性: 提供される検索機能は全文検索とベクター検索を含みます。RAG のための埋め込み生成や前処理は v0 が行う場合とユーザー側で準備する場合があるため、ワークフローを確認してください

参考情報 ​

[General] Amazon ECS expands IAM condition key support for RunTask and StartTask APIs ​

概要 ​

Amazon ECSがRunTaskおよびStartTask APIに対してCPU／メモリのIAM条件キー（ecs:task-cpu、ecs:task-memory）サポートを拡張しました。これによりタスク起動時のリソース上限を一貫してIAMポリシーで制御できます。

変更内容・新機能の詳細 ​

これまで ecs:task-cpu および ecs:task-memory の条件キーは RegisterTaskDefinition、CreateService、UpdateService のAPIでのみ評価されていました。本アップデートにより、RunTask および StartTask からタスクを起動する際にもこれらの条件キーが評価されるようになりました。つまり、タスク定義のデフォルト値だけでなく、RunTask/StartTask のオーバーライド（起動時に指定する cpu/memory の値）に対してもIAMポリシーで許可／拒否の条件付けが可能になります。これにより、管理者はサービス起動（CreateService等）と手動／バッチ的なタスク起動（RunTask/StartTask）の両方で単一のIAMベースのルールセットによりリソース割当を統一的に管理できます。本機能はAmazon ECSが利用可能な全リージョンで利用でき、追加料金はありません。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド／プラットフォーム管理者、セキュリティチーム、SRE
  • 利用シーン: RunTask/StartTask で起動されるオンデマンドバッチやデバッグ用タスクのCPU/メモリ上限をIAMで強制する（例：開発者が高コストなオーバーライドを指定できないようにする）
  • 運用効果: リソース過剰割当による予期せぬコスト増やノイズ的な性能問題を防止し、サービス起動・手動起動双方で一貫したポリシー適用が可能になる

技術的な注意点 ​

  • IAM権限: ecs:RunTask や ecs:StartTask を実行するIAM主体に対して、条件キーを含む許可/拒否ポリシーを設定してください。条件キー名は ecs:task-cpu および ecs:task-memory です。
  • リージョン制限: Amazon ECSが利用可能なすべてのリージョンで有効です（記事時点）。
  • コスト: 機能自体に追加料金は発生しませんが、条件でリソースを制限した場合のパフォーマンス影響やスケーリング影響を考慮してください。
  • 既存ポリシーの確認: 既存のIAMポリシーで同条件キーをRegisterTaskDefinitionやService系APIに対して使っている場合、RunTask/StartTaskに対しても同等の評価が行われるため、想定外の拒否や許可が発生しないか事前にポリシーを確認してください。
  • 動作の影響: 条件に合致しないオーバーライドを含むRunTask/StartTaskは拒否されるため、CI/CDや運用スクリプトの動作停止・エラーに繋がる可能性があります。自動化フローではテストを行ってください。

参考情報 ​

[Redshift] Amazon Redshift RG instances now available in Europe (Zurich) Region ​

概要 ​

Amazon RedshiftのGravitonベース新インスタンスタイプ「RG」が、AWS Europe (Zurich) リージョンで利用可能になりました。RA3と比べて最大2.4倍の処理性能と、vCPUあたり約30%低い価格が謳われています。

変更内容・新機能の詳細 ​

RGインスタンスはAWS Gravitonプロセッサ（ARMベース）を採用したRedshift向けインスタンスです。Redshiftのカスタムベクトル化データレイククエリエンジンを各クラスタノード上で動作させ、Apache IcebergやParquetフォーマットのデータをノード上で処理することで、データウェアハウスとデータレイクのデータに対して単一エンジンでSQL分析を実行できます。公開時点でのインスタンスサイズはrg.large、rg.xlarge、rg.4xlarge、rg.12xlargeの4種類です。既存のRA3クラスタからの移行手段としては、Snapshot & Restore、Elastic Resize、Classic Resizeがサポートされています。料金はオンデマンドと1年/3年のリザーブドインスタンス（All Upfront / Partial Upfront / No Upfront）の柔軟なオプションがあり、vCPUあたりの単価は従来世代より低く設計されています。導入前には公式ドキュメントとRA3→RGのアップグレードガイド、価格ページを参照してテスト・費用見積もりを行うことを推奨します。

影響範囲・利用シーン ​

  • 対象ユーザー: データウェアハウス／データレイクの分析基盤を運用するデータエンジニア、SRE、プラットフォームチーム
  • 利用シーン: Iceberg/Parquetを含むデータレイクとRedshift内データを単一クエリエンジンで高速に分析したいバッチ／インタラクティブワークロード
  • 運用効果: クエリ性能の向上（記事値で最大2.4x）、vCPUあたりコスト削減（記事値で約30%）、単一エンジン運用によるアーキテクチャ簡素化
  • 移行影響: 既存RA3クラスタからの移行はSnapshot & RestoreやResizeで可能だが、方法によってダウンタイムや作業手順が異なるため事前検証が必要

技術的な注意点 ​

  • IAM権限: クラスタ作成／変更、スナップショット作成・復元、リサイズ操作に必要な権限（例: redshift:CreateCluster, redshift:ModifyCluster, redshift:RestoreFromClusterSnapshot など）を確認してください
  • リージョン制限: 本記事は Europe (Zurich) リージョンでの利用開始を告知しています。ほかのリージョンでの提供状況はリージョンごとに異なるため、利用前に対象リージョンでの提供可否を確認してください
  • コスト: vCPUあたりの単価は低減していますが、総コストはインスタンスサイズ、ストレージ使用量、データ転送、Reservedの割引選択に依存します。事前に料金ページで試算してください
  • 互換性: RGはGraviton（ARM）ベースのため、x86向けにコンパイルされたユーザー定義関数（UDF）や外部ネイティブライブラリがある場合は動作しない可能性があります。ARM対応の代替が必要か確認してください
  • 移行注意点: Snapshot & Restoreはデータ移行に伴うダウンタイムが発生する可能性があります。Elastic Resizeは短時間でのスケール操作を提供しますが、すべてのケースで即時切替が保障されるわけではありません。移行前にステージング環境で性能と互換性検証を実施してください
  • データフォーマット: 記事で言及されているのはIcebergとParquetです。他フォーマットや外部データソースのクエリ特性は検証が必要です

参考情報 ​

AI要約はOpenAI APIによって生成されています。

Copyright © 2026