AWS What's New Digest

Appearance

2026年09月09日 ​

[Aiml] Amazon Bedrock Managed Knowledge Base now supports Confluence Data Center as a native data source connector ​

概要 ​

Amazon Bedrock Managed Knowledge BaseがConfluence Data Centerをネイティブなデータソースコネクタとしてサポートしました。セルフホストのConfluence Data Center上のページやブログ記事を直接クロールしてBedrockのマネージド知識ベースへ取り込めます。

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

新しいConfluence Data Centerコネクタは、従来必要だったカスタムな取り込みパイプラインを不要にします。ユーザーはConfluenceインスタンスの認証情報を提供するだけで、コネクタがページ／ブログのクロール、メタデータ抽出、インクリメンタル同期（差分取り込み）を自動で実行します。クロールはスペースやコンテンツ種別でフィルタリングでき、必要なコンテンツだけを知識ベースに取り込むことで無駄なデータ蓄積とコストを抑制します。取り込まれたConfluenceの情報は、Bedrock上のRAG（retrieval-augmented generation）エージェントや内部アシスタントの根拠資料として利用でき、エンジニアリングドキュメント、ランブック、チームナレッジの活用を容易にします。

影響範囲・利用シーン ​

  • 対象ユーザー: Confluence Data Centerをセルフホストで運用している企業、社内向けAIアシスタントやRAGシステムを構築する開発チームやナレッジマネジメント担当者
  • 利用シーン: エンジニア向けドキュメント検索、運用ランブックに基づくチャットボット、社内FAQや手順書を根拠にした生成応答
  • 運用効果: カスタムインジェスト開発工数の削減、インクリメンタル同期による再取り込みコスト低減、フィルタで不要データを除外して知識ベースを集約・最適化

技術的な注意点 ​

  • IAM権限: Bedrock Managed Knowledge Baseの作成・更新やコネクタ操作に必要なAWS権限を付与してください（詳細はユーザーガイド参照）。Confluence側の認証情報管理はSecrets Managerなどを利用することを推奨します。
  • リージョン制限: Bedrock Knowledge Bases自体や本コネクタの提供リージョンは限定される可能性があります。導入前に対象リージョンでのサポート状況を確認してください。
  • コスト: データ取り込み、ストレージ、検索／リトリーバルの利用料金が発生します。インクリメンタル同期やフィルタを使って取り込むデータ量を制御することでコスト抑制が可能です。
  • ネットワーク／認証: セルフホストのConfluenceに対してコネクタがアクセスできるネットワーク経路が必要です（パブリックアクセス、VPN、VPC接続、プロキシ経由など）。アクセス許可やIP制限、証明書の設定等を確認してください。
  • データガバナンス: 取り込むコンテンツに機密情報や個人情報が含まれる場合、アクセス制御や監査、暗号化方針を事前に整備してください。取り込みフィルタと削除ポリシーを活用して不要情報の流入を防止してください。
  • 同期挙動: コネクタはメタデータ抽出とインクリメンタル同期を行いますが、同期間隔や一回のクロールで処理する量の上限など運用上の制約がある可能性があります。大量データ移行時は設計を検討してください。

参考情報 ​

[Elastic Block Store] Amazon EBS Volume Clones now supports copying volumes across accounts ​

概要 ​

Amazon EBS Volume Clonesがアカウント間でのEBSボリュームのコピー（再暗号化）をサポートしました。ターゲットアカウントのAWS KMSキーで再暗号化して異なるAWSアカウントへボリュームを複製できます。

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

新機能では、ソースアカウントのEBSボリュームをAWS Resource Access Manager (AWS RAM)でターゲットアカウントと共有し、ターゲット側で同じアベイラビリティゾーン内にコピーを作成するワークフローを提供します。コピー作成時にターゲットアカウントのAWS KMSキーを指定して再暗号化できるため、プロダクションと開発でKMSキーを分離した運用（キー分離ポリシー）に対応します。全てのボリュームタイプ（未暗号化、AWS管理暗号、カスタマーマネージドキーで暗号化されたボリュームを含む）でサポートされ、AWS マネジメントコンソール、AWS CLI、AWS SDKから利用可能です。リージョンは、EBS Volume Clonesをサポートするすべてのリージョン（商用リージョン、AWS GovCloud (US)、中国リージョン、対応するローカルゾーン等）で利用できます。実運用では、例として本番データベースのボリュームを分離した開発アカウントに複製して開発・検証用に使う、あるいは本番/非本番で別々のKMSキーを維持する必要のある組織に役立ちます。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドエンジニア、SRE、開発チームやセキュリティ/コンプライアンス担当者
  • 利用シーン: 本番ボリュームを分離した開発/検証アカウントに安全にコピーして再現環境を作る、あるいは環境ごとにKMSキーを分離してセキュリティ要件を満たす
  • 運用効果: アカウント境界を越えた安全なデータ複製により開発の迅速化とキー管理分離が可能に。手動でのスナップショットエクスポートや複雑なキー共有作業を削減できる

技術的な注意点 ​

  • IAM権限: AWS RAMでの共有受諾（ram:AcceptResourceShareInvitation等）と、ターゲット側でのEBSコピー作成に必要なEC2/EBS権限を事前に付与してください。また、コピー後に指定するターゲットKMSキーを利用するためのkms:Encrypt/kms:GenerateDataKey権限が必要です。
  • KMS権限: ターゲットアカウントのKMSキーは該当アカウントのIAM主体が利用できるようキー ポリシーおよびIAMポリシーを設定してください。ソースがカスタマーマネージドキーで暗号化されている場合でも本機能で再暗号化されますが、万一のアクセスエラーに備えソース側のKMSポリシーも確認してください。
  • AWS RAM: まずソースアカウントでボリュームをAWS RAMで共有し、ターゲットアカウントが共有を受諾する必要があります。共有可能なリソースタイプや許可設定を確認してください。
  • アベイラビリティゾーン制約: コピーは同じアベイラビリティゾーン内で作成されます。ターゲットアカウント側に同一AZでのリソース作成余裕（容量・サブネット等）が必要です。
  • 対応ボリューム: 未暗号化ボリューム、AWS管理キー暗号化、カスタマーマネージドキーで暗号化されたボリュームのいずれもサポートされます。コピー時にターゲットKMSキーで暗号化（あるいは未暗号化のまま）設定可能です。
  • リージョン制限: EBS Volume Clonesをサポートするリージョンで利用可能です。リージョン未対応の場合は利用できません。
  • コスト: EBSボリュームのストレージ料金、EBSのコピー/クローンに関連する通常の料金、及びKMSの利用料金が発生する可能性があります。リージョン間コピーでは追加料金や転送コストが別途発生する場合があります（本機能は同リージョン・同AZコピーが前提）。
  • 利用方法: AWS マネジメントコンソール、AWS CLI、AWS SDKで操作可能。手順は「ソースで共有」→「ターゲットで共有受諾」→「ターゲットでコピー作成（KMS指定）」の順です。
  • その他: コピー後はターゲットアカウント内の通常のEBSボリュームとして扱えます。セキュリティ上の懸念があるデータは事前にマスキングやマスキング自動化を検討してください。

参考情報 ​

[EKS] AWS Private CA EKS add-on and Connector for AD now available in AWS GovCloud (US) ​

概要 ​

AWS Private CAのKubernetes用コネクタがAmazon EKSのマネージドアドオンとして、またActive Directory用コネクタがAWS GovCloud (US-East/US-West)で利用可能になりました。政府機関向けワークロードで証明書発行・配布・更新の自動化が可能になります。

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

・EKSアドオン（AWS Private CA Connector for Kubernetes）: EKSコンソール/CLI/APIからの簡易インストールとライフサイクル管理に対応するマネージドアドオンとして提供されます。cert-managerと連携して、AWS Private CAへ証明書要求を行い、Kubernetes Secretへ配布・自動更新を実現します。これによりIngressコントローラのTLS有効化やIstio/Linkerdなどのサービスメッシュ内のサービス間通信の保護が容易になります。 ・Active Directoryコネクタ（AWS Private CA Connector for Active Directory）: AWS GovCloudの環境で、Active Directoryに参加しているユーザー/コンピュータ/オブジェクト向けにAWS Private CAを証明機関として自動発行させる機能を提供します。既存のMicrosoft証明書登録インターフェース（自動登録/グループポリシー/テンプレート）と連携し、スマートカード認証、LDAPS、802.1Xなど企業向けユースケースをサポートします。 ・セキュリティ: AWS Private CAは秘密鍵をFIPS 140-3 レベル3準拠のHSMで保護します。 ・対象リージョン: AWS GovCloud (US-East) および AWS GovCloud (US-West) にて利用可能。

影響範囲・利用シーン ​

  • 対象ユーザー: 政府機関や規制対応が必要な組織のクラウド運用者、セキュリティ／基盤チーム、Kubernetesプラットフォームエンジニア
  • 利用シーン: EKS上のIngressやサービスメッシュでのTLS自動化、Active Directoryに参加するデバイスやユーザーへの自動証明書発行（スマートカード、LDAPS、802.1X等）
  • 運用効果: 証明書の手動管理を削減し、証明書発行・配布・更新の自動化によりダウンタイムや人的ミスを低減。コンプライアンス要件のある環境で一貫した証明書管理が可能

技術的な注意点 ​

  • IAM権限: EKSでのアドオン管理やPrivate CA操作に必要なIAM権限（eks:AssociateAddon/eks:UpdateAddon、acm-pca関連権限など）を事前に確認・付与してください
  • cert-manager要件: Kubernetes側では互換性のあるcert-managerのインストールと適切なCRD/RBAC設定が必要です。サポートするcert-managerのバージョンを確認してください
  • Active Directory連携: AD側での自動登録設定（証明書テンプレート、グループポリシー、自動登録権限）や、コネクタがADに接続可能なネットワーク経路（VPN/Direct Connect/同一VPCなど）を確保する必要があります
  • ネットワークとポート: AD連携や証明書配布に必要なポート（LDAPS等）やファイアウォール設定を確認してください
  • リージョン制限: 現時点では AWS GovCloud (US-East) および AWS GovCloud (US-West) のみで利用可能です。他リージョンでは未提供の場合があります
  • コスト: AWS Private CAの管理費用および発行ごとの料金、EKSクラスターやデータ転送等の通常のAWSリソースコストが発生します。アドオン自体に追加料金がかからないケースでも基盤サービスの料金に注意してください

参考情報 ​

[Ec2] AWS Systems Manager now diagnoses more issues that cause EC2 instances to be unmanaged ​

概要 ​

AWS Systems Managerの診断機能が拡張され、これまでのネットワーク接続診断に加えて、EC2インスタンスおよびハイブリッドでアクティベートしたノードがSystems Managerにより“managed”にならない原因を追加で6カテゴリ特定できるようになりました。これにより、未管理状態の原因をより具体的に把握して早期に対処できます。

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

従来はネットワーク接続に関する診断のみを提供していましたが、今回の拡張で以下の6つのカテゴリを新たに診断できます：IAM権限、SSM Agentのバージョン、インスタンスのステータスチェック（system/instance reachabilityなど）、OS設定（ファイアウォールやサービス状態など）、Default Host Management Configuration（ホスト管理の既定設定）、およびハイブリッドアクティベーション（オンプレミスや他クラウドでのマネージドインスタンス登録）。

診断はSystems Managerの統合コンソールから実行し、各カテゴリごとに特定された問題をレポートします。各診断結果にはステップバイステップの修復手順が付属し、一部の問題についてはコンソール上から直接Automationランブックを実行して自動で修復できます。診断処理自体はSystems Manager Automationランブックとして実行されるため、Automationの通常課金が適用されます。機能はデフォルトで有効になっているすべてのAWSリージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド/ハイブリッド環境のインフラ運用者、SRE、セキュリティ/コンプライアンス担当者
  • 利用シーンまたは効果: 未管理（unmanaged）状態のEC2インスタンスやハイブリッドノードの原因特定と迅速な復旧（パッチ適用、Run Command、Session Manager接続、インベントリ収集の再開）
  • 運用効果: 原因が特定しやすくなることで対応時間が短縮され、Fleet全体をより速くSystems Managerで一元管理できるようになる

技術的な注意点 ​

  • IAM権限: 診断とAutomation実行にはSystems ManagerとAutomationを実行するためのIAM権限（ssm:Describe*, ssm:SendCommand, automation:StartAutomationExecution等）および必要に応じたEC2権限が必要です。ターゲットインスタンスのIAMインスタンスプロファイル（例: AmazonSSMManagedInstanceCore）も正しく設定されていることを確認してください。
  • SSM Agent/OS要件: SSM Agentのバージョン互換性やサービス起動状態、OS設定（ファイアウォール、SELinux等）が診断対象になります。Agentのアップデートや修復はインターネットアクセスまたは必要なエンドポイント（S3やSSMエンドポイント）へのアクセスが必要です。
  • ネットワーク/エンドポイント: 診断はネットワーク接続問題も引き続き検出します。VPCエンドポイント（Interface Endpoint）利用時はエンドポイント設定、NAT/プロキシやポリシーでのHTTPS(443)アウトバウンド許可を確認してください。
  • ハイブリッドアクティベーション: ハイブリッド（オンプレ等）ノードはActivation ID/Codeと有効な状態が必要です。Activationの有効期限や登録状態、SSM Agentの接続状態を確認してください。
  • リージョン制限: 記事によれば「デフォルトで有効なすべてのAWSリージョン」で利用可能です。GovCloudや中国リージョンなどデフォルト設定と異なるリージョンでは挙動や利用可否が異なる場合があるため事前確認を推奨します。
  • コスト: 診断はAutomationランブックとして実行されるため、AWS Systems Manager Automationの標準の実行課金が発生します（詳細は料金ページを確認してください）。
  • その他: 一部の自動修復ランブックはインスタンス上での操作（Agentの再起動、設定変更）を伴うため、運用上の影響（サービス中断等）を考慮して実行してください。

参考情報 ​

[Aiml] AWS Entity Resolution adds record-level confidence scores for ML matching ​

概要 ​

AWS Entity ResolutionがMLベースのマッチングワークフローでレコード単位の信頼度（confidence）スコアを提供開始しました。個々の解決レコードごとにマッチ品質を評価できるため、差別化したしきい値運用でより多くのレコードを安全にアクティベートできます。

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

これまではマッチグループ単位の信頼度スコアが全レコードに同一で付与されており、ほぼ確実なマッチと境界的なマッチを区別できませんでした。今回の変更により、MLベースのマッチングワークフローでは各レコードに対して個別の信頼度スコアが付与されます。これにより、自動マージに高い信頼度しきい値を使い、より緩いしきい値で追加のレコードをアクティベートするなど、用途ごとに差別化したポリシー運用が可能になります。インクリメンタルMLワークフローを利用している場合は、既存のRecordConfidenceLevel列がレコード単位のスコアを反映するように更新され、スキーマ変更は不要です。レコード単位のスコアは監査可能なエビデンスとして保持され、コンプライアンス対応や説明可能性（explainability）の向上にも寄与します。本機能はAWS Entity Resolutionが利用可能なリージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: データエンジニア、CDP/マーケティングチーム、CRM運用者、データガバナンス/コンプライアンス担当者
  • 利用シーン: 顧客レコードの重複解決（同一人物マージ）、アドレス可能オーディエンスの拡大、リード管理、カスタマー360の統合
  • 運用効果: レコードごとのスコアに基づき高信頼レコードは自動マージ、低めのしきい値で追加レコードをアクティベートすることでアクティベーション対象を拡大し、リード変換率や到達率を改善できる
  • 監査・説明性: 各レコードに証拠となる信頼度が残るため、監査対応や外部説明（内部監査・規制対応）が容易になる

技術的な注意点 ​

  • 適用範囲: MLベースのマッチングワークフローに対して提供されます（ルールベース/決定的マッチングの挙動については個別に確認してください）
  • スキーマ互換性: インクリメンタルMLワークフローでは既存のRecordConfidenceLevel列がレコード単位スコアを反映するため、スキーマ変更は不要です
  • IAM権限: Entity Resolutionのワークフロー実行や結果参照に必要なIAM権限を事前に確認・付与してください（ワークフロー実行・読み取り権限など）
  • リージョン制限: AWS Entity Resolutionが利用可能な全リージョンで利用可能です。対象リージョンでのサービス提供状況は公式リージョン一覧で確認してください
  • コスト: 本機能自体で追加料金が明示されているわけではありませんが、信頼度に基づく追加アクティベーションや下流処理の増加によりデータ転送・処理コストが増加する可能性があります
  • しきい値運用: 自動マージ用、高信頼の利用、分析／マーケ用の低めの利用など、ユースケースごとにしきい値をチューニングしてください。A/Bテストや段階的運用で影響を評価することを推奨します
  • 監査・データ保持: レコード単位のスコアとその根拠（ログ）を保存するポリシーを定め、個人データ保護規制（例: GDPR）や社内保持ルールに従って管理してください

参考情報 ​

[Connect] Amazon Connect Customer Profiles now sends events when customers enter or exit segments ​

概要 ​

Amazon Connect Customer Profilesが顧客のセグメント入退出をイベントとして送出できるようになりました。これにより、セグメント変化をほぼリアルタイムまたはスケジュール実行で受け取り、即時のキャンペーンやパーソナライズアクションに利用できます。

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

Customer Profilesはセグメントのメンバーシップ変更（入室／退出）を自動で検出してAmazon Kinesis Data Streamへストリームします。従来はセグメントを定期エクスポートして差分を検出する必要があり、数時間の遅延や運用コスト・ヒューマンエラーが生じていました。本機能では、標準条件で定義したセグメントはプロファイル属性の更新に応じてほぼリアルタイムで変化を検出し、Spark SQLで定義した“拡張セグメント（enhanced segments）”は設定した間隔のスナップショット実行でメンバーシップを評価して変更を通知します。各イベントにはプロファイルID、セグメント名、操作種別（joined/left）、検出モード（real-timeまたはscheduled）が含まれます。導入は、対象ドメインの設定でAmazon Kinesis Data Streamを構成し、各セグメントをサブスクライブするだけで開始できます。利用可能リージョンはCustomer Profilesが提供されているすべてのAWSリージョンです。

影響範囲・利用シーン ​

  • 対象ユーザー: コンシューマ向けキャンペーンを運用するマーケティングチーム、パーソナライズを行うプロダクトチーム、SRE/運用チーム
  • 利用シーン: 高額顧客や低満足顧客などのセグメント入退出をトリガーにした即時のメール/SMS配信、パーソナライズ表示、リテンション施策の起動
  • 運用効果: セグメント変化を数時間ではなく数秒〜数分で活用可能になり、キャンペーン到達率向上や早期介入による解約抑止が期待できる

技術的な注意点 ​

  • IAM権限: Customer ProfilesとKinesisに対する適切なIAM権限（ストリームのPutRecord/PutRecords、Customer Profilesの設定変更権限など）が必要です
  • リージョン制限: Customer Profilesが利用可能なすべてのリージョンで使用可能。ただし自ドメインのリージョンでKinesisストリームを作成してください
  • コスト: Kinesis Data Streamsの課金（シャード数・PUTトランザクション・データ転送）が発生します。処理量に応じてシャードを増やすとコストが上昇します
  • イベント内容: 各イベントはprofileId、segmentName、operation（joined/left）、detectionMode（real-time/scheduled）などを含むため、下流システムでの照合やフィルタが可能です
  • セグメントタイプと遅延: 標準条件セグメントはプロファイル更新にほぼリアルタイムで反映。Spark SQLベースの拡張セグメントはスケジュール実行（スナップショット）で評価するため、設定した間隔に依存します
  • 導入手順: ドメイン設定でKinesis Data Streamを登録し、各セグメントでイベント配信を有効化する。詳細は管理ガイドの手順に従ってください
  • スケーリング/運用: 高頻度のセグメント変化が想定される場合はKinesisのシャード設計とレコード処理側のスループット（コンシューマ処理）を検討してください

参考情報 ​

[Bedrock] OpenAI GPT-6 Astra is now generally available on Amazon Bedrock ​

概要 ​

OpenAIの最新大規模モデル「GPT-6 Astra」がAmazon Bedrockで一般提供開始になりました。最大100万トークンのコンテキストを扱い、より高度な推論・判断・ブラウザ操作・プロ品質の生成をビジネスワークフロー向けに提供します。

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

GPT-6 Astraは深い推論力、組織の文体やテンプレートに合わせた出力整形、ブラウザやコード操作を含む高度なマルチモーダル/ツール使用能力を持つOpenAIの最上位モデルです。Amazon Bedrockの推論エンジン上で稼働し、BedrockのAPI（コンソールまたはプログラム的なInvoke API等）から直接呼び出せます。特徴として最大1,000,000トークンのコンテキストウィンドウをサポートするため、大量文書の一括解析や長文履歴を必要とするエージェント設計に適しています。ChatGPT WorkやCodexはBedrock上のAstraをバックエンドとして利用可能で、OpenAIからは企業向けChatGPTプラグイン（ブラウザ利用拡張）が提供され、一般的な業務アプリケーションとの連携が強化されています。Bedrock側ではスケール、セキュリティ（IAM、VPCエンドポイント、暗号化）、アクセスガバナンス、CloudTrailによる呼び出し監査といった既存のAWSコントロールが利用できます。詳細な対応リージョン、エンドポイント、API仕様、inference profile（性能/コスト設定）、料金はAmazon Bedrockのドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: AI/MLエンジニア、アプリケーション開発者、SRE/運用、セキュリティ・コンプライアンス担当者、業務部門の高度な自動化ニーズを持つユーザー
  • 利用シーンまたは効果: 自律エージェントの構築、大量文書の横断検索・解析、複雑なソフトウェア不具合の調査、競合する入力を比較して判断が必要な業務プロセス、自動化されたプロ品質の文書・設計生成
  • 運用効果: より少ない手動介入で複雑なタスクを自動化できるため工数削減と品質向上が期待できる
  • コスト影響: 大容量コンテキストと高性能推論はコスト増につながる可能性があるため、inference profileやバッチ化・キャッシュ戦略で最適化が必要
  • 導入の留意点: ChatGPT WorkやCodex連携を含む統合では追加設定（プラグイン管理、API設定、企業ポリシー適用）が必要

技術的な注意点 ​

  • IAM権限: Bedrockのモデル呼び出しやリソース管理には適切なIAMポリシー（例: bedrock:InvokeModel 等）が必要。最小権限原則でロールを設計してください
  • リージョン制限: 全リージョンで即時提供されるとは限らないため、利用前にBedrockドキュメントで対応リージョンとエンドポイントを確認してください
  • コスト: 最大コンテキスト長・高スループット推論は課金が高くなる傾向があります。inference profileや並列度、リクエストあたりのトークン長を監視して最適化してください
  • セキュリティ/データ保護: 機密データを送信する場合はVPCエンドポイント、KMSによる暗号化、CloudTrailログの有効化、データ保持ポリシーを検討してください。出力の機密情報漏洩リスクに対するガードレール（フィルタリング、ポストプロセッシング）を実装すること
  • 性能/レイテンシ: 100万トークン規模の入力はメモリ・計算負荷およびレイテンシを増大させます。バッチ処理、ストリーミングや部分的な文脈投入など設計上の工夫が必要です
  • モデル出力の品質管理: 高度な推論能力がある一方で誤情報（hallucination）や望ましくない出力が発生する可能性は残るため、検証ループやルールベースのポストチェックを推奨します
  • 互換性/統合: ChatGPT WorkやCodexと連携する場合は各サービス側の設定（プラグイン管理、エンタープライズ設定）を確認してください
  • コンプライアンス: データ主権や業界規制の要件がある場合は、モデル呼び出しの送信先リージョンやログ保管先を確認し、必要に応じて法務/コンプライアンスチームと調整してください

参考情報 ​

[Timestream] Amazon Timestream for InfluxDB 3 now supports custom plugins ​

概要 ​

Amazon Timestream for InfluxDB 3がカスタムPythonプラグインの実行をサポートしました。管理されたInfluxDB 3（Core/Enterprise）上でリポジトリに置いたプラグインを実行し、データ処理をDB近傍で完結できます。

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

今回のアップデートにより、ユーザーが管理する公開/プライベートリポジトリに格納したPythonプラグインを、Timestream for InfluxDBの処理エンジンがトリガーに応じて取得・実行できるようになりました。プラグインは既存の処理エンジンがサポートするトリガータイプ上で動作し、データ変換、アラート生成、集約、外部サービスとの連携などのワークロード固有ロジックをデータベース側で実行可能にします。実行環境は管理されたPythonランタイムで、標準ライブラリとAmazonが検証したパッケージ群が含まれており、任意の外部インフラを立てずに処理を移譲できます。導入手順は、DBパラメータグループにプラグインリポジトリを設定しそれをクラスターに適用、influxdb3 CLIまたはHTTP APIでプラグイントリガーを作成する流れです。プライベートリポジトリへは、AWS Secrets Managerに格納したトークンで認証します。機能はAmazon Timestream for InfluxDBが利用可能な全リージョンで提供されています。

影響範囲・利用シーン ​

  • 対象ユーザー: InfluxDB 3 を運用するアプリケーション開発者、データエンジニア、SRE/運用チーム
  • 利用シーンまたは効果: データ受信時のカスタム変換・集約・アラート生成をDB側で実行し、別途ETLパイプラインや外部関数基盤を構築せずに遅延・運用コストを削減
  • 運用効果: ネットワーク往復や外部サービス運用を減らし、処理をデータに近い場所で実行することでレイテンシ削減と運用負荷の軽減が期待できる
  • 開発効果: Pythonで既存の処理ロジックを移植しやすく、デプロイはリポジトリ＋パラメータグループ＋トリガーの組合せで簡素化
  • リージョン影響: Amazon Timestream for InfluxDB が利用可能な全リージョンで利用可能

技術的な注意点 ​

  • IAM権限: プラグインの操作やリポジトリ参照、Secrets Manager参照などに必要なIAM権限を事前に設定してください（例: SecretsManager:GetSecretValue、Timestream/InfluxDB 管理権限）
  • リージョン制限: 機能はTimestream for InfluxDB提供リージョンで利用可能ですが、対象リージョンを事前に確認してください
  • コスト: プラグイン機能自体の明示的な追加料金は記事に記載されていませんが、実行によるクラスターのCPU/メモリ利用増加、Secrets Manager利用料、データ転送などがコストに影響します
  • リポジトリ/認証: プライベートリポジトリはAWS Secrets Managerに格納したトークンで認証します。リポジトリ設定はDBパラメータグループで管理されます
  • 実行環境制約: 実行は管理されたPython環境（標準ライブラリ＋Amazon検証済みパッケージ）で行われます。ネイティブ拡張(.so/.dll)やOSレベルの追加パッケージ、任意の非検証パッケージが利用できない可能性があるため、依存関係は事前に確認してください
  • デプロイ手順: 1) DBパラメータグループにプラグインリポジトリを設定 2) そのパラメータグループをクラスターに適用 3) influxdb3 CLIまたはHTTP APIでトリガーを作成（プライベートリポジトリの場合はSecrets Managerのトークンを指定）
  • デバッグ/ログ: 実行ログやエラーの扱い（CloudWatch連携等）の詳細はドキュメントで確認してください。ローカルでの動作検証と十分なロギング実装を推奨します

参考情報 ​

[SageMaker] Amazon SageMaker Feature Store now supports individual feature updates to lower write latency ​

概要 ​

Amazon SageMaker Feature Storeがレコード内の個別フィーチャー更新（feature-level writes）に対応しました。これによりレコード全体を書き換えずに特定のフィーチャーだけを更新でき、書き込みレイテンシとコストを低減できます。

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

新機能では、Feature StoreのランタイムAPIを通じて単一リクエストでレコード内の一つまたは複数のフィーチャーのみを更新できます。従来の「read-modify-write」パターン（レコードを読み出して変更し、全体を再書き込みする処理）を置き換えられるため、必要なフィーチャーだけを書き換え、それ以外は変更せずに残ります。これにより書き込み量とデータ転送が削減され、書き込み遅延が低下します。複数パイプラインが同じFeature Groupへ書き込む場面では、各パイプラインが自分の算出するフィーチャーだけを更新できるため、ストリーミング処理と夜間バッチ処理が同一レコードを独立して更新可能です。高スループットで単一フィーチャーを更新する用途に適しており、データ取り込みパイプラインにマージロジックを組み込む必要がなくなります。なお、この機能はFeature Storeが利用可能な全リージョンで提供されています。

影響範囲・利用シーン ​

  • 対象ユーザー: データサイエンティスト、機械学習エンジニア、データエンジニア、SRE/運用チーム
  • 利用シーン: ストリーミングジョブとバッチジョブが同一レコードの異なるフィーチャーを更新するケース、単一フィーチャーを高頻度で更新するオンライン/バッチ推論パイプライン
  • 運用効果: 書き込みレイテンシの低減、不要なレコード全体の再書き込みの削減によるコスト削減、パイプライン間のマージロジック削減により運用複雑性の低下

技術的な注意点 ​

  • IAM権限: Feature Store Runtimeの書き込みAPI（例: PutRecord 等）に対する適切なIAM権限を付与してください。既存のポリシーを確認し、必要に応じて更新が必要です。
  • リージョン制限: 本機能はAmazon SageMaker Feature Storeが利用可能なすべてのリージョンで有効です（リージョンに依存する機能や設定がある場合は事前確認を推奨）。
  • SDK/CLI: 新しい書き込みオプションを利用するには、最新のAWS SDK（boto3等）／AWS CLIにアップデートしておくと確実です。
  • 整合性と競合: 各書き込みはリクエストで指定したフィーチャーのみを更新しますが、同一フィーチャーに対する同時更新の競合解決（最後の書き込みが勝つ、タイムスタンプ管理など）については、ワークフロー設計時に想定して検証してください。
  • コスト: 個別フィーチャー更新によりデータ量・処理時間が減りコスト削減が見込めますが、APIコール数やストレージ、データ転送の料金は引き続き発生します。負荷パターンに応じて請求影響を評価してください。

参考情報 ​

[Govcloud Us] AWS Transform is now available in AWS GovCloud (US-West) ​

概要 ​

AWS Transform が AWS GovCloud (US‑West) リージョンで利用可能になりました。ガバメント機関や規制対象組織が、隔離された環境内で大規模なサーバー移行を計画・実行できるようになります。

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

AWS Transform は GovCloud (US‑West) にデプロイされ、AWS GovCloud (US) の境界内で動作する環境から大規模なサーバー移行を自動化できるようになりました。サポートされる移行ソースには VMware、ベアメタル、Hyper‑V、データベースワークロードが含まれ、サーバーのレプリケーション（複製）とカットオーバーを自動化して、手作業や人的リスクを低減します。今回のリージョンローンチでは、移行先として AWS GovCloud (US‑East) と AWS GovCloud (US‑West) の両方が選択可能です。一方で、モダナイゼーション（近代化）、カスタム変換、アセスメント機能はこの GovCloud リージョンには含まれておらず、これらの機能は引き続き商用のサポート対象リージョンで提供されます。GovCloud の隔離された運用境界により、連邦機関や防衛関連、その他の規制産業が敏感データや規制対象ワークロードを移行する際のコンプライアンス要件に対応しやすくなります。

影響範囲・利用シーン ​

  • 対象ユーザー: 連邦機関、政府系組織、国防関連企業、HIPAA/FISMA/ITAR 等の規制対象業務を扱う組織
  • 利用シーンまたは効果: GovCloud 内でのサーバー移行自動化（VMware/ベアメタル/Hyper‑V/DB）により、大規模移行プロジェクトの複雑さと手作業を低減
  • 運用効果: レプリケーションとカットオーバーの自動化でダウンタイムと人的ミスを減らし、移行リスクの低減とスピードアップを実現
  • 制約: モダナイゼーションやカスタム変換、評価機能は GovCloud では未提供のため、移行後のアプリケーション近代化や詳細な評価は商用リージョンで行う必要がある

技術的な注意点 ​

  • IAM権限: AWS Transform を使用するために必要な IAM ロール/ポリシー（レプリケーション/EC2作成/ネットワーク設定等）を事前に設定してください
  • リージョン制限: AWS Transform の GovCloud 展開は GovCloud (US‑West) に限定され、モダナイゼーションやアセスメント機能は商用リージョンのみで提供されます。移行先は GovCloud (US‑East) と GovCloud (US‑West) のみサポート
  • エージェント/アクセス要件: ソースサーバ（VMware ホストや物理サーバ、Hyper‑V、DB）への管理アクセスや、必要に応じてレプリケーション用エージェントの導入が必要です。ネットワーク経路とファイアウォール設定を確認してください
  • ネットワーク/セキュリティ: GovCloud の隔離ポリシーに従い、VPC、サブネット、NACL、セキュリティグループの設定と KMS キー管理など暗号化要件を整備する必要があります
  • コスト: レプリケーション用のインスタンス、データ転送、ストレージ（スナップショット/複製ストレージ）などの追加コストが発生します。見積もりとコスト管理を事前に検討してください
  • 互換性: 一部の移行パスやデータベースの特殊構成は追加作業が必要になる場合があります。商用リージョンでのみ提供される変換ツールや評価ツールに依存するシナリオは別途計画が必要です

参考情報 ​

[API Gateway] Amazon API Gateway now supports mutual TLS for backend integrations ​

概要 ​

Amazon API Gateway（REST API）は、バックエンドとのTLSハンドシェイクでクライアント証明書（ACMで管理された証明書）を提示できるようになり、API Gateway→バックエンド間での相互TLS（mTLS）をサポートします。これにより、クライアント→APIおよびAPI→バックエンドの双方で相互認証を適用できます。

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

従来、API Gatewayは統合先（バックエンド）に対して自身で生成した自己署名証明書のみを提示していました。本リリースにより、AWS Certificate Manager（ACM）で管理される証明書（外部PKIからインポートした証明書、またはAWS Private Certificate Authorityで発行された証明書）をAPI Gatewayのバックエンド統合に使用できるようになりました。

  • 動作: API GatewayはTLSハンドシェイク時にACMの証明書を提示し、バックエンドはその証明書を検証して接続元が期待するAPIであることを確認できます。
  • 証明書管理: 証明書をACMにインポートするか、ACM PCAで発行可能。ACM内で証明書が再インポート／更新（更新や自動更新）されると、API Gatewayは再デプロイ不要で自動的に更新を伝播します（ダウンタイムなし）。
  • 適用範囲: REST APIのバックエンド統合に対する機能で、API Gatewayのコンソール、AWS CLI、CloudFormationから設定可能です。
  • セキュリティ領域: 金融、医療、ゼロトラスト／規制対応が必要な環境で、クライアント→API、API→バックエンドの両方における相互TLSを実現できます。

影響範囲・利用シーン ​

  • 対象ユーザー: API設計者、セキュリティエンジニア、SRE、金融/医療など規制環境で運用するシステム担当者
  • 利用シーン: クライアント→APIとAPI→バックエンドの両方向で相互TLSを適用してエンドツーエンドの相互認証を実現するケース（例: バンキングAPI、医療データ連携、ゼロトラストアーキテクチャ）
  • 運用効果: バックエンドが接続元APIの真正性をTLSレイヤで検証できるため、中間者攻撃や不正なサービスからの接続を低減し、セキュリティポスチャ向上およびコンプライアンス対応が容易になる
  • 導入障壁: ACMへの証明書導入（またはPCAの導入）とバックエンド側でのクライアント証明書検証設定が必要になるため、証明書ライフサイクル管理の運用が必要
  • 可用性影響: 証明書更新はAPI Gatewayが自動伝播するため、証明書更新によるダウンタイムは基本的に発生しない

技術的な注意点 ​

  • 対応APIタイプ: 現時点ではREST APIのバックエンド統合に対する機能です。HTTP APIやWebSocket APIでのサポート状況は個別確認が必要です
  • ACM所在リージョン: ACMで管理する証明書はAPI Gatewayが配置されたリージョンのACMで扱う必要があります（リージョン特有の証明書スコープに注意）
  • バックエンド設定: バックエンド（統合先）はクライアント証明書の検証を行うよう設定する必要があります。CAチェーンをバックエンドの信頼ストアに登録する等の設定が前提です
  • 証明書形式: 証明書はACMでサポートされる形式である必要があります（一般的にはPEM等）。外部PKIからのインポートはACMの手順に従ってください
  • 権限/IAM: API GatewayとACM操作のために適切なIAM権限（apigateway:PATCHなどAPI Gatewayの設定権限、acm:ImportCertificate/DescribeCertificate/GetCertificate/RequestCertificateなど）が必要です
  • CloudFormation/CLI: コンソールのほかAWS CLIおよびCloudFormationから設定可能です。CloudFormationテンプレートでの設定フィールドはドキュメントで確認してください
  • コスト: ACMへの証明書インポート自体は追加料金が発生しませんが、AWS Private CAを利用して証明書を発行する場合はPrivate CAの月次/発行コストが発生します。運用コスト（証明書ライフサイクル管理）も考慮してください
  • リージョン制限: REST APIが利用可能なすべての商用リージョンとAWS GovCloud（US）リージョンで利用可能とアナウンスされていますが、利用前に対象リージョンでのサポート状況を確認してください
  • 互換性/暗号套件: バックエンドとAPI Gateway間のTLSバージョンや暗号スイートの互換性を確認してください。必要に応じてバックエンドのTLS設定を調整する必要があります

参考情報 ​

[RDS] Amazon RDS for MariaDB now supports community MariaDB minor versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, and 12.3.3 ​

概要 ​

Amazon RDS for MariaDB がコミュニティで公開された最新のマイナーバージョン（10.6.28、10.11.19、11.4.13、11.8.9、12.3.3）をサポートしました。これらには運用改善や CVE 修正に加え、トラフィック暗号化のためのポスト量子（PQ）TLS 鍵交換のサポートが含まれます。

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

サポート対象の MariaDB マイナーバージョンは 10.6.28、10.11.19、11.4.13、11.8.9、12.3.3 です。これらのマイナーリリースにはセキュリティ修正（既知の CVE の修正）、バグ修正、パフォーマンス改善およびコミュニティが追加した機能拡張が含まれます。注目点として、トランジット暗号化に対するポスト量子 TLS（PQ-TLS）鍵交換のサポートが追加されており、将来の量子耐性を考慮した鍵交換アルゴリズムを利用できるオプションが提供されます。アップグレードは既存インスタンスに対するインプレースアップグレード、Blue/Green Deployments を用いたダウンタイム最小化の切替、スナップショットからの復元のいずれかで実施可能です。大規模環境では自動マイナーバージョンアップと AWS Organizations の Upgrade Rollout Policy を組み合わせ、フェーズごとにローリングアップグレードを行う運用が推奨されます。既存の外部 MariaDB からの移行は AWS Database Migration Service (DMS) を利用できます。導入前に必ずリリースノートと互換性情報を確認し、テスト環境での検証を行ってください。

影響範囲・利用シーン ​

  • 対象ユーザー: MariaDB を RDS 上で運用するデータベース管理者、SRE、クラウド/セキュリティエンジニア
  • 利用シーン: セキュリティパッチ適用・性能改善のためのマイナーバージョン更新、ポスト量子耐性を考慮した通信暗号化の導入検討
  • 運用効果: CVE 修正とバグフィックスにより安全性と安定性が向上。Blue/Green を用いればダウンタイムを最小化して段階的にアップグレード可能

技術的な注意点 ​

  • IAM権限: アップグレード実行やスナップショット操作には rds:ModifyDBInstance、rds:CreateDBSnapshot、rds:RestoreDBInstanceFromDBSnapshot 等の権限が必要です。Automation の場合は追加の権限を確認してください。
  • ダウンタイム: インプレースアップグレードは接続中断が発生する可能性があります。Blue/Green Deployments を使うとダウンタイムを最小化できますが、追加のリソースが必要です。
  • PQ-TLS クライアント互換性: サーバ側が PQ-TLS をサポートしていても、クライアント（アプリケーションの TLS ライブラリ）が対応している必要があります。クライアント互換性を事前に検証してください。
  • 自動マイナーバージョンアップ: 自動適用を有効にするとメンテナンスウィンドウ内で更新が実行されます。運用ポリシーとテスト計画を整備した上で有効化してください。
  • バックアップ／ロールバック: アップグレード前にスナップショットを取得し、復元手順を確認してロールバック戦略を用意してください。
  • 互換性テスト: ストアドプロシージャ、ユーザ定義関数、プラグイン、レプリケーション（バイナリログ形式など）について互換性テストを必ず行ってください。
  • コスト: Blue/Green や追加テスト環境の利用は一時的にインスタンス・ストレージコストが増加します。スナップショットやデータ転送にも料金が発生する場合があります。
  • リージョン制限: 新バージョンの展開はリージョン毎に段階的です。利用予定のリージョンで提供済みか事前に確認してください。

参考情報 ​

[General] Amazon Bedrock AgentCore Memory now supports direct ingestion to long-term memory ​

概要 ​

Amazon Bedrock AgentCore Memoryは、短期メモリイベントを作成せずに直接長期メモリ向けにコンテンツを投入できるIngestData APIを公開しました。これにより長期メモリの抽出パイプラインを短期メモリに依存せずに利用できます。

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

IngestData APIは会話型ペイロード（USER/ASSISTANTロールを持つメッセージ）およびJSONペイロード（振る舞いイベント、アクティビティログ、システムイベントなど）を受け取り、AgentCoreに設定された長期メモリ抽出戦略へファンアウトして長期メモリレコードを生成します。従来はコンテンツを一旦短期メモリイベントとして保存してから抽出処理を行う必要がありましたが、IngestDataはその中間イベント作成を不要にします。オプションのメタデータもCreateEventと同じ抽出パイプラインに流され、処理後はListMemoryRecordsやRetrieveMemoryRecordsで結果確認が可能です。リアルタイム通知はKinesisでストリーミングでき、抽出失敗はListMemoryExtractionJobs経由でリドライブ（再処理）できます。IngestDataはAgentCore MemoryがサポートされるすべてのAWSリージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: LLMアプリ開発者、データエンジニア、SRE/運用チーム
  • 利用シーン: 会話履歴やアクティビティログを短期イベントに残さず直接長期知識ベースへ取り込みたいケース（カスタム長期記憶、パーソナライズ、検索強化など）
  • 運用効果: 短期メモリの管理不要によりパイプラインが簡素化され、長期メモリ抽出の導入を短期メモリ実装から切り離して進められる
  • 導入効果: 不要な短期イベントの保存を省略でき、短期ストレージやイベント管理の負荷が低減される一方で長期レコードのストレージと抽出処理コストは発生する

技術的な注意点 ​

  • IAM権限: IngestDataおよび関連の読み取り（ListMemoryRecords、RetrieveMemoryRecords、ListMemoryExtractionJobs）とKinesis書き込みの権限が必要です。詳細なAPI権限はドキュメントを確認してください。
  • リージョン制限: AgentCore Memoryがサポートされるすべてのリージョンで利用可能と明記されていますが、利用前に対象リージョンでAgentCore Memoryが有効か確認してください。
  • コスト: 長期メモリレコードのストレージ、抽出処理（抽出ジョブ）およびKinesisストリーミングの利用に対する課金が発生します。短期イベント未作成により短期ストレージ費用は削減されますが、トータルコストはワークロードに依存します。
  • ペイロード/データ管理: 会話型（USER/ASSISTANT）および汎用JSONを受け入れますが、ペイロードサイズ制限やフォーマット要件はドキュメントで確認してください。個人情報や機密データを送信する場合はデータ保護と暗号化方針を遵守してください。
  • 可観測性とエラーハンドリング: 抽出結果はListMemoryRecords/RetrieveMemoryRecordsで確認可能。抽出失敗はListMemoryExtractionJobsで検出・リドライブできます。リアルタイム通知はKinesisを利用するため、ストリームの可用性や遅延も考慮してください。
  • 移行/互換性: 既存のCreateEventベースのフローと並行運用が可能で、必要に応じて短期イベントベースの処理から段階的に切り替えられます。
  • 運用上の制限: APIレート制限やジョブキューの挙動、処理遅延の特性は環境に依存するため、スケールテストを推奨します。

参考情報 ​

[General] AWS HealthOmics introduces resource fallback order for WDL workflows ​

概要 ​

AWS HealthOmicsがWDLワークフロー向けに「resource fallback」ディレクティブを導入しました。優先するアクセラレータ（GPU/その他）を順序付けし、最終的にCPUにフォールバックする設定が可能になり、アクセラレータ不足での再実行を減らせます。

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

resource fallbackディレクティブは、WDLタスクごとに優先するアクセラレータの順序付きリストを定義できる機能です。各アクセラレータ（プロファイル）には検索のためのタイムアウトを個別に設定でき、HealthOmicsは指定順にアクセラレータを探索します。指定したアクセラレータが利用できない場合でも、ユーザーがジョブを再提出することなく自動的に次の候補へ移行します。最後の候補としてCPUプロファイルを含めることで、アクセラレータが全て確保できない状況でもインスタンス確保の可能性を高められます。タイムアウトを短く設定すればフォールバックを素早く進められ、長く設定すれば優先アクセラレータを確保できる確率が上がります。機能は以下のリージョンで利用可能です：US East (N. Virginia, Ohio)、US West (Oregon)、Europe (Frankfurt, Ireland, London)、Israel (Tel Aviv)、Asia Pacific (Seoul, Singapore, Tokyo)。詳細はAdvanced Resource Configurationのドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: 研究者、バイオインフォマティクスエンジニア、パイプライン運用者、SRE
  • 利用シーンまたは効果: GPUや専用アクセラレータに依存する解析ジョブで、アクセラレータ不足によるジョブ再提出や長時間待機を減らし、プロダクションワークフローの継続稼働を実現
  • 運用効果: 自動フォールバックにより手動介入とデバッグ時間が削減され、スループットの向上と安定稼働が期待できる

技術的な注意点 ​

  • IAM権限: ワークフロー定義やリソースプロファイルの変更に必要なHealthOmics関連の権限を事前に確認してください（編集/更新権限が必要）
  • リージョン制限: 本機能は記事で列挙されたリージョンで利用可能です。その他のリージョンでは未対応の可能性があります。各アクセラレータの可用性はリージョン/インスタンスタイプ依存です
  • コスト: フォールバック先（特にCPU）での実行は処理時間が延びる可能性があり、その分コストが増加します。長いタイムアウトは待機時間を増やし完了までの遅延要因になります
  • ランタイム影響: 優先アクセラレータを待つ時間はワークフローの総所要時間に影響します。タイムアウトの調整でトレードオフを設計してください
  • 互換性: WDLワークフローで指定して使用する形式となるため、使用中のWDLバージョンとHealthOmicsのリソース設定仕様を確認してください
  • その他運用上の注意: アクセラレータの在庫やService Quotas、組織の制限（アカウントレベルのインスタンス上限）を考慮し、事前に検証環境で挙動を確認してください
  • HIPAA: HealthOmicsはHIPAA適格サービスですが、ワークフローの運用にあたっては組織側のコンプライアンス設定を継続して確認してください

参考情報 ​

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

Copyright © 2026