Skip to content

2026年05月13日

[Rds For Oracle] Amazon RDS for Oracle now supports M8i and R8i instances with Oracle SE2 License Included

概要

Amazon RDS for Oracleが、License Included(LI)モデルで利用できる新しいインスタンスファミリーM8iおよびR8i(カスタムIntel Xeon 6搭載)をサポート開始しました。これにより、ソフトウェアライセンスとサポートを含むサブスクリプション型で高性能なOracle SE2の運用が可能になります。

変更内容・新機能の詳細

主な変更点は以下の通りです。

  • インスタンス: M8iおよびR8iインスタンスがRDS for OracleのOracle Database Standard Edition 2(SE2)License Includedで利用可能になりました。これらはAWS専用のカスタムIntel Xeon 6プロセッサを採用しています。
  • 性能とコスト: 同等の従来世代のIntelベースインスタンスと比べて最大で15%の価格性能改善(price-performance)を実現し、メモリ帯域幅は最大2.5倍に向上しています。メモリ集約型ワークロードやキャッシュ重視のデータベースに有利です。
  • ライセンスモデル: License Included(LI)を選択すると、Oracleの別途ライセンス購入やサポート契約は不要になり、ソフトウェアライセンス・サポート・コンピュート・マネージドDBサービスがサブスクリプション型の従量課金に含まれます。
  • 利用方法: AWS マネジメントコンソールまたはAWS CLIからデータベースインスタンス作成時にLIオプションを指定して利用します。詳細なインスタンスタイプ構成や価格・リージョンの対応状況は、公式のインスタンスタイプページおよび価格ページを参照してください。

影響範囲・利用シーン

  • 対象ユーザー: Oracleデータベースを運用するクラウド/DB管理者、SRE、アプリケーション開発チーム
  • 利用シーン: メモリ帯域幅や単一ノードのCPU性能が重要なトランザクショナル/キャッシュ重視ワークロードのRDS移行や新規構築
  • 運用効果: ライセンス管理の簡素化(別途Oracleライセンス購入不要)、サブスクリプション型でのコスト予測性向上、既存のIntel系インスタンスからの性能向上によるスループット改善

技術的な注意点

  • IAM権限: rds:CreateDBInstance等、RDS作成に必要なIAM権限を持つこと(LI選択に伴うAPI/CLIパラメータの指定が必要)
  • リージョン制限: M8i/R8iおよびLIオプションはリージョン毎の提供状況が異なります。導入前にリージョンの可用性を確認してください(価格ページ/インスタンスタイプページ参照)
  • コスト: LIはソフトウェアライセンスとサポートを含む従量課金です。BYOL(Bring Your Own License)と比べて総所有コストが変わるため、既存ライセンス契約と比較して検討してください
  • ライセンス/機能制限: SE2にはエディション固有の機能制限やデプロイ制約(例: 一部Oracleオプションや高可用性構成の制約)があります。ワークロードで必要なOracle機能がSE2でサポートされるか事前確認が必要です
  • 互換性とバージョン: 本アナウンスで対象となるOracleの具体的なバージョンは記載がないため、使用予定のOracleバージョンがLIでサポートされているか、及びRDSの機能(Multi-AZ、リードレプリカ、バックアップ等)との互換性を確認してください
  • 作成時の注意: コンソール/CLIでLIを明示的に指定する必要があります。既存インスタンスのライセンスモデルを切替える場合は影響範囲(ダウンタイムや再作成要否)を確認してください
  • ストレージ/I/O: M8i/R8iはメモリ帯域が向上していますが、DBパフォーマンスはEBSボリュームタイプ(gp3/io2)やI/Oプロビジョニングにも依存します。ストレージ設計とスループット要件を再評価してください

参考情報


[Lambda] AWS Lambda supports scheduled scaling for functions on Lambda Managed Instances

概要

AWS LambdaがLambda Managed Instances上で動作する関数に対して、Amazon EventBridge Schedulerを使った定期スケジュールによる容量(実行環境の最小/最大)調整をサポートしました。ピーク前に容量を引き上げたり、アイドル時にゼロにしてコストを抑えるなどの自動化が可能になります。

変更内容・新機能の詳細

Lambda Managed Instancesは、管理されたAmazon EC2インスタンス上でLambda関数を実行し、ルーティング・ロードバランシング・オートスケーリングを組み合わせて提供する仕組みです。本新機能では、Amazon EventBridge Schedulerで一度限りまたは繰り返しスケジュールを定義し、関数ごとの実行環境に対する最小/最大キャパシティ制限を事前に調整できます。これにより、トラフィック増加が予想される時間帯の前に実行環境数の上限を引き上げてパフォーマンス目標を確保したり、利用が無い時間帯に最小をゼロに設定してコストを削減したりできます。スケジュールはEventBridge Schedulerのコンソール、AWS CLI、AWS SDK、AWS CDK、AWS CloudFormationから作成可能で、Lambda Managed Instancesをサポートするすべてのリージョンで利用できます。実際の動作は、スケジュールで設定した最小/最大の範囲内で自動スケーリングが行われるため、スケジュールはあくまで上限・下限のプロアクティブな調整手段として機能します。モニタリングはCloudWatchメトリクスやログで実行環境数・スロットリング・レイテンシを確認し、必要に応じてスケジュールや閾値を微調整してください。

影響範囲・利用シーン

  • 対象ユーザー: Lambda Managed Instancesで関数を運用するアプリケーション開発者、SRE、クラウド運用チーム
  • 利用シーン: ビジネス営業時間にトラフィックが集中するアプリ、定期的なマーケティング/キャンペーン、夜間や週末にアイドルになるバッチ的ワークロード
  • 運用効果: ピーク前に実行環境を準備することで初期リクエストのレイテンシやエラーを低減し、アイドル時間にキャパシティを下げてコスト削減が可能
  • コスト影響: 実行環境をゼロにできる設定によりアイドル時の料金を削減できる一方、ピーク前にキャパシティを上げることでその期間のインスタンス費用が増加します(EventBridge Schedulerの呼び出し/スケジュール数に対する料金も発生する可能性あり)

技術的な注意点

  • IAM権限: EventBridge SchedulerからLambda Managed Instancesのキャパシティを変更するための適切なIAMロール/ポリシー(scheduler:CreateSchedule 等およびLambda/Managed Instancesの変更権限)が必要です
  • リージョン制限: Lambda Managed Instancesをサポートするリージョンで利用可能。対象リージョンは事前に確認してください(すべてのリージョンで無条件に利用できるわけではありません)
  • コスト: 実行環境(EC2相当)の稼働時間に対する料金や、EventBridge Schedulerの利用料金が発生します。スケジュールで頻繁に上下させると費用やAPIレート制限に影響する可能性があります
  • スケジュール粒度と伝播遅延: EventBridge Schedulerの式(cron/rate)に従いスケジュールされますが、実際のキャパシティ反映に数秒〜数分の遅延が発生する場合があります。ピーク到来前に十分なマージンを持ってスケジュールしてください
  • スケーリング挙動: スケジュールは最小/最大の制限値を調整するもので、実際の実行環境数はその範囲内でトラフィックに応じて自動スケーリングされます。最小をゼロにすると初回リクエスト時にウォームアップ遅延(いわゆるコールドスタート相当)が発生する可能性があります
  • モニタリング/アラート: CloudWatchメトリクス(実行環境数、関数レイテンシ、エラー率、スロットリング)と組み合わせて監視・アラートを設定し、スケジュールの有効性を検証してください

参考情報


[General] Amazon EventBridge Scheduler adds 619 new SDK API actions, including Lambda Managed Instances

概要

Amazon EventBridge SchedulerがAWS SDK連携を拡張し、13の追加サービスと合計619の新しいAPIアクションをサポートしました。これにより、カスタム統合コードを作成せずにより多くのAWS APIを直接スケジュール実行できるようになりました。

変更内容・新機能の詳細

今回の拡張では、EventBridge Schedulerが新たに13のAWSサービスをSDK統合に追加し、既存を含め合計619のAPIアクションを呼び出せるようになりました。Schedulerはサーバーレスなスケジューラであり、cron/レート式やカレンダー式スケジュールで数十億のジョブを管理可能です。今回の変更により、ターゲットサービスのAPIを直接呼び出して操作(例: Lambda Managed Instancesのスケールアップ/スケールダウン)できるため、Lambdaのキャパシティ管理など時間ベースの運用を精密に行えます。これらの機能はEventBridge Schedulerが利用可能な全リージョンで一般提供(GA)されますが、個々のAPIアクションやサービスの利用可否はターゲットサービス自体のリージョン提供状況に依存します。実装面では、SchedulerのSDK統合ターゲットを設定する際に呼び出し先のAPIアクション名やペイロードを指定し、呼び出しに必要なIAMロール/権限を付与することで動作します。詳細はDeveloper GuideのSDK integrationsセクションを参照してください。

影響範囲・利用シーン

  • 対象ユーザー: クラウドエンジニア、SRE、DevOps、プラットフォームチーム
  • 利用シーン: 時間ベースでのAPI操作の自動化(例: Lambda Managed Instancesの時間帯に応じたスケーリング、夜間のバッチ処理起動、定期的なリソース設定変更)
  • 運用効果: カスタム統合コード不要で運用負荷を低減し、スケジュールに基づく正確な容量管理・コスト最適化が可能になる
  • 導入上の効果: 既存のCronやワークフローサービスを置き換えやすく、より多くのAWSネイティブAPIを直接スケジュール可能にすることで運用の単純化と標準化が進む

技術的な注意点

  • IAM権限: SchedulerがターゲットAPIを呼び出すために、適切なIAMロール(およびiam:PassRole等)の付与が必要です。ターゲットごとに必要なAPI権限を確認してください。
  • リージョン制限: 変更はEventBridge Schedulerが利用可能なすべてのリージョンでGAですが、個々のサービス/APIアクションはターゲットサービスのリージョン対応に依存します。
  • サービス制限: すべてのAWS APIアクションが含まれるわけではありません。サポート対象の具体的なアクションはドキュメントで確認してください。
  • APIパラメータと互換性: 呼び出すAPIアクションごとに要求されるパラメータ構造や制約が異なります。Schedulerのターゲット設定で正しいペイロード・ヘッダーを指定する必要があります。
  • 監査/ログ: API呼び出しはCloudTrail等で記録されます。呼び出し結果やエラーはCloudWatch Logsやイベント履歴で確認してください。
  • 再試行とエラーハンドリング: Schedulerの再試行ポリシーやデッドレター設定を活用して、失敗時のハンドリングを設計してください。
  • コスト: Schedulerの利用量と対象サービス側の操作(例: インスタンス起動/停止やスケーリング)によりコストが発生します。料金体系を事前に確認してください。

参考情報


[SageMaker] Amazon SageMaker Feature Store now supports SageMaker Python SDK V3

概要

Amazon SageMaker Feature StoreがSageMaker Python SDK v3をサポートしました。Lake Formationによる列・行レベルのアクセス制御と、Apache Icebergテーブルプロパティ設定をSDKから直接操作できるようになり、オフラインストアのガバナンスと性能最適化が統合されます。

変更内容・新機能の詳細

主な変更点は以下の通りです。

  • SageMaker Python SDK v3サポート: モジュール化された最新のv3インターフェース(v3.8.0以上を使用)でFeature StoreのFeature Groupを作成・管理できるようになり、従来より冗長なボイラープレートを削減してワークフローを簡素化します。
  • Lake Formation連携(オプトイン): Feature Group作成時にオプトイン設定を行うことで、オフラインストア上のデータに対して列レベル/行レベルのアクセス制御を適用可能になります。これにより、機械学習用の特徴量データに対するきめ細かいデータガバナンスをSDK経由で実現します。
  • Apache Icebergテーブルプロパティ設定: Icebergのテーブルプロパティ(例: コンパクション設定、スナップショットの有効期限など)をSDKから直接指定できるようになり、オフラインストアのストレージ最適化やクエリ性能のチューニングが可能です。
  • 運用上の統合: これらの機能により、Feature Storeのアクセス制御とオフラインストア性能チューニングを別ツールで管理することなく、単一のSDKで完結して管理できるようになります。
  • 利用可能リージョン: Amazon SageMaker Feature Storeが提供されている全リージョンで利用可能です。

影響範囲・利用シーン

  • 対象ユーザー: 機械学習エンジニア、データサイエンティスト、MLOpsエンジニア
  • 利用シーンまたは効果: Feature Group作成時にLake Formationで列/行レベルのアクセス制御を適用して機密データを保護したり、Icebergプロパティを調整してオフラインストアのストレージコストとクエリ性能を最適化する場面で有効です。
  • 運用効果: SDK単体でガバナンスとストレージ最適化を行えるため、運用の手間が減り、データアクセス管理とパフォーマンス改善の反映が迅速になります。

技術的な注意点

  • SDKバージョン: SageMaker Python SDK v3.8.0以上が必要です(v2とはAPIが異なるため移行検討が必要)。
  • IAM/Lake Formation権限: SageMaker実行ロールに加え、Lake Formationの権限(列/行レベルアクセスの付与・管理)やGlueカタログ/メタデータ更新権限、S3アクセス権限が必要になる場合があります。事前に必要な権限を確認してください。
  • オプトイン設定: Lake Formationによる列/行レベル制御はFeature Group作成時のオプトイン設定です。既存のFeature Groupへ後付けで有効化するには再作成やデータ移行などの作業が発生する可能性があります。
  • Iceberg設定の影響: コンパクション間隔やスナップショット有効期限などのプロパティ設定はストレージ使用量やクエリ応答性に直接影響します。設定変更はテスト環境での検証を推奨します。
  • コスト: 追加の料金は発生しない場合が多いですが、Lake Formationのデータアクセス管理、Glueカタログ利用、S3ストレージ/リクエスト、及びデータ処理(コンパクション等)に伴うコスト増加の可能性があります。コスト見積もりを行ってください。
  • リージョン制限: SageMaker Feature Storeが利用可能な全リージョンで提供されていますが、利用するリージョンでLake FormationやGlueの設定状況を確認してください。
  • 互換性/移行: SDK v3はv2とAPI設計が異なるため、既存のスクリプトや自動化パイプラインは修正が必要になる場合があります。

参考情報


[Route 53] Karpenter now supports Amazon Application Recovery Controller zonal shift

概要

Amazon EKSでKarpenterを使うクラスタが、Amazon Application Recovery Controller (ARC) の zonal shift / zonal autoshift と連携できるようになりました。これにより、障害発生時に影響を受けたAZへ新規プロビジョニングや任意のノード再配置を自動的に抑止し、クラスタ内トラフィックの回避を支援します。

変更内容・新機能の詳細

ARCのzonal shiftは、障害や劣化が疑われる単一AZからアプリケーショントラフィックを一時的に迂回させる仕組みです。今回の対応で、オープンソースのKarpenterがEKSクラスタのARCリソースと直接統合され、手動のzonal shiftおよびARCによる自動zonal autoshift(練習実行を含む)いずれでも動作します。具体的なKarpenterの動作は以下の通りです。

  • 障害対象AZでzonal shiftが有効化されると、そのAZへの新規キャパシティ(ノード/インスタンス)プロビジョニングを停止します。
  • 当該AZ内のノードに対する任意の破壊的操作(例: consolidationやdriftによる再スケジューリング等のボランタリな破壊)は中断・抑止されます。
  • 正常なAZでのボランタリな破壊を行う際に、その操作が障害AZへのスケジューリングに依存する場合は、その破壊を防止します。
  • ボリュームアフィニティ等、特定AZへの厳密なスケジューリング制約を持つPodは、障害AZに依存する場合に起動試行を行わない(無駄な起動試行を防止)挙動になります。
  • zonal shiftが期限切れ・キャンセルされた場合はKarpenterは通常動作に復帰します。 実装上、カスタムなARCリソースを新たに作成する必要はなく、既存のEKSクラスタに紐づくARCリソースと連携します。機能を有効化するにはKarpenterの設定でENABLE_ZONAL_SHIFTを有効にします(詳細はKarpenterのドキュメント参照)。

影響範囲・利用シーン

  • 対象ユーザー: Amazon EKS上でKarpenterを使用しているクラウドエンジニア、SRE、プラットフォームチーム
  • 利用シーン: AZ単位の劣化や障害が発生した際に、クラスタ内トラフィックとノードプロビジョニングを自動で回避して可用性を維持する運用
  • 運用効果: 障害AZに対する不要なノード起動やボリューム関連の失敗を抑止し、影響範囲を限定して早期復旧を支援(手動対応やロールフォワードの頻度低減)
  • 制約・注意点: ボリュームアフィニティなどAZ依存のワークロードは自動回避されるため、AZ冗長性を持たないステートフルワークロードは別途設計が必要

技術的な注意点

  • IAM権限: KarpenterがARCリソースの読み取り/監視とノード(EC2)プロビジョニング権限を持つように、必要なIAMロール/ポリシーとKubernetes RBACを確認してください(詳細はドキュメント参照)。
  • リージョン制限: ARC(およびARCのzonal shift/autoshift)の提供状況はリージョンによって異なります。利用予定リージョンでARCがサポートされているかを事前に確認してください。
  • コスト: ARCの利用やautoshiftの実行に関連する追加課金が発生する可能性があります。さらに、zonal shiftによるプロビジョニング抑止は短期的にコスト削減に寄与しますが、フェイルオーバー先でのリソース増加はコスト増となり得ます。料金は各サービスの価格表を確認してください。
  • 設定方法: Karpenterの設定でENABLE_ZONAL_SHIFTを有効にする必要があります(正確な設定箇所・手順はKarpenterの公式ドキュメント参照)。
  • Karpenterバージョン: 本機能はKarpenterの該当リリース以降で利用可能です。導入前に動作するKarpenterのバージョンを確認し、アップグレード方針を検討してください。
  • ARC前提: EKSクラスタ側でARCのセットアップ(クラスタにARCを関連付ける設定)が完了している必要があります。zonal autoshiftを使う場合はautoshiftの練習実行や事前検証を推奨します。
  • 互換性: 他のノード管理・自動スケーリングツール(例: Cluster Autoscaler など)と併用している場合は、動作の重複や競合が発生するおそれがあるため組み合わせ動作を確認してください。

参考情報


[Redshift] Amazon Redshift launches RG instances powered by AWS Graviton

概要

Amazon RedshiftはAWS Gravitonプロセッサを採用した新世代のプロビジョンドノード「RGインスタンス」を一般提供開始しました。RA3世代比で最大2.4倍のクエリ性能(ワークロードにより異なる)と、vCPUあたり約30%低コストを実現します。

変更内容・新機能の詳細

RGインスタンスはGravitonベースのプロセッサを搭載し、Redshift組み込みのベクタ化データレイククエリエンジンを各クラスターのノード上で動作させます。これにより、データウェアハウス(Redshift Managed Storage上の構造化データ)とS3上のオープンフォーマット(Apache Iceberg, Parquet)に対して単一のエンジンでSQL分析を実行でき、従来のRedshift Spectrumの別個のスキャン・フリートやそのテラバイト単位の課金が不要になります。主な技術要素は以下の通りです。

  • 性能とコスト: RA3比でデータウェアハウスワークロード最大2.2x、Apache Icebergクエリ最大2.4x、Parquet最大1.5xの高速化。vCPUあたり約30%の価格低下。
  • ネイティブデータレイクエンジン: NVMeキャッシュを活用したスマートプリフェッチ、ファイル/パーティション単位のプルーニング、ベクタ化ParquetスキャンなどのI/O最適化を搭載。
  • JIT Analyze: 手動チューニング不要でテーブル統計を自動収集・更新し、クエリを一貫して高速化。
  • インテリジェントNVMeキャッシュ: 頻繁にアクセスされるデータを計算ノード近傍に保持し、S3往復を削減して反復クエリの応答性を向上。
  • インスタンスサイズと移行: リリース時点でrg.xlargeとrg.4xlargeを提供。既存RA3クラスタはSnapshot & Restore、Elastic Resize、Classic ResizeでRGに移行可能。
  • 料金体系: On-Demand、1年/3年のReserved Instances(No Upfront)など柔軟な購入オプションをサポート。
  • リージョン: 多数の主要リージョンで利用可能(記事参照)。

影響範囲・利用シーン

  • 対象ユーザー: データウェアハウス/データレイクをRedshiftで運用するデータエンジニア、アナリスト、SRE/運用チーム
  • 利用シーンまたは効果: 統合クエリエンジンによるS3上のIceberg/ParquetとRedshift内データの単一SQL分析(Spectrum不要)/クエリ性能改善とコスト効率化
  • 運用効果: NVMeキャッシュやJIT Analyzeにより反復クエリのレイテンシ低下と手動チューニング工数の削減が期待できる
  • コスト影響: vCPUあたりの単価低下(約30%)とSpectrumのテラバイト課金削減でトータルコスト削減が見込まれる
  • 導入制約: RG対応のインスタンスタイプ(rg.xlarge, rg.4xlarge)を選ぶ必要があり、既存クラスタは移行作業が必要

技術的な注意点

  • IAM権限: クラスタ作成・スナップショット操作・リサイズ等のために適切なRedshift/Migration権限が必要(Administrator権限か限定的な管理権限を確認してください)
  • リージョン制限: リリース時点で多数の主要リージョンで利用可能ですが、全リージョン対応ではありません。利用前に対象リージョンでの提供可否を確認してください
  • コスト: On‑Demandのほか1年/3年RI(No Upfront)を選択可。性能向上によりクエリコストが下がる一方、インスタンスサイズ選定やストレージ構成により総コストは変動します。料金詳細は料金ページで確認してください
  • 互換性: RGはRedshiftのネイティブエンジンを強化する設計ですが、特定の外部連携やサードパーティ製ツールとの動作確認は事前検証を推奨します
  • 移行手順: 既存RA3クラスタはSnapshot & Restore、Elastic Resize、Classic ResizeでRGへ移行可能。大規模環境ではテスト移行およびクエリ検証を行ってください
  • インスタンスサイズ: 現時点ではrg.xlargeとrg.4xlargeが提供。ワークロードに合わせたサイズ選定とベンチマークを実施してください
  • その他注意点: Redshift Spectrumの別フリートとTB課金が不要になる点はコスト構成に影響しますが、S3データレイアウト(パーティション、ファイルサイズ、Icebergメタデータの利用)により性能差が出るため、データ設計最適化は依然重要です

参考情報


[CloudFront] Amazon CloudFront Premium flat-rate plan now supports configurable usage allowances

概要

Amazon CloudFrontのPremiumフラットレートプランが、従来の単一許容値からセルフサービスで選べる複数の月次利用レベル(リクエスト数:5億〜60億、データ転送:50TB〜600TB)に対応しました。コンソールで即時に月額フラット料金を確認・変更でき、コミット不要でスケールできます。

変更内容・新機能の詳細

変更点の技術的説明:

  • Premiumフラットレートプランに、月間リクエスト数と月間転送量の複数の“利用レベル”が追加されました。選択可能なレンジはリクエストで500 million〜6 billion、データ転送量で50 TB〜600 TBです。
  • 利用レベルの選択はCloudFrontコンソール上でセルフサービスで行い、選択すると即時に新しい月額フラット料金が表示されます。利用レベルはいつでも変更可能で、特定の長期コミットメントは不要です。
  • 各利用レベルではPremiumの全機能が含まれます:コンテンツ配信(CloudFront本体)、AWS WAF、DDoS保護(AWS Shield)、ボット管理、Amazon Route 53 DNS、Amazon CloudWatch Logsの取り込み、サーバーレスエッジコンピューティング、Amazon S3ストレージクレジット等。
  • フラットレートはオーバーチャージ(超過課金)が発生しない形で設計されており、予測可能な単一月額料金で上記のサービス群をカバーします。
  • 目的は、従来はフラットレート対象外だった企業や中堅企業の基礎トラフィックをもつアプリケーションが、カスタム価格交渉なしにフラットレートを採用できるようにすることです。

影響範囲・利用シーン

  • 対象ユーザー: エンタープライズおよび中堅企業、CloudFrontを大量トラフィックで利用するウェブ/API/メディア配信のチーム
  • 利用シーンまたは効果: 月次トラフィックが高くコスト予測性が重要な配信ワークロード(動画配信、グローバルWebアプリ、ソフトウェア配信等)で固定費化により費用管理がしやすくなる
  • 運用効果: コンソールから利用レベルを切り替えてスケールできるため、トラフィック増減に応じた迅速なコスト最適化と請求の単純化が可能
  • コスト影響: 高トラフィック環境では従来の従量課金より総コストを抑えられる可能性があるが、選択した利用レベルに応じた固定月額が発生するため事前にトラフィック見積もりが必要

技術的な注意点

  • IAM権限: CloudFrontの設定変更と課金関連の操作を行うため、CloudFront管理権限(コンソール操作権限)および請求情報にアクセスするIAM権限が必要です
  • リージョン制限: CloudFrontはグローバルサービスのためリージョン依存の制限は基本的にありません(ただし管理コンソールはAWSアカウント単位で操作します)
  • コスト: 選択した利用レベルに応じた固定月額が発生します。オーバーチャージは発生しない設計ですが、超過時の扱いや課金実務は契約条件を確認してください
  • 反映タイミング: コンソールでの価格表示は即時ですが、実際の請求上の適用タイミングや履歴反映は月次請求サイクルに依存する可能性があります
  • 既存契約の移行: 既に旧来の単一許容値で運用している顧客は、コンソールで利用レベルを選ぶことで新プランに移行できます。大口カスタム契約を結んでいる場合は、既存条件との調整が必要な場合があります
  • 監視/アラート: 利用レベルに近づいた場合の検知は引き続きCloudWatchやログベースの監視で行い、必要に応じて利用レベルを上げる運用フローを整備してください

参考情報


[Connect] Amazon Connect Customer now supports embedding Cases and Customer Profiles in custom agent applications

概要

Amazon Connect Customerがカスタムのエージェントアプリケーション内にCases(ケース)とCustomer Profiles(顧客プロファイル)を埋め込めるようになりました。Amazon Connect SDKを使ってネイティブなConnect体験を既存のアプリに組み込めます。

変更内容・新機能の詳細

今回のアップデートにより、開発者はAmazon Connect SDKを利用して、ConnectのCases(問い合わせ管理)とCustomer Profiles(顧客情報)をカスタムエージェントUIに直接埋め込めます。これにより、エージェントは通話・チャット等の対応画面と同じインターフェイス上でケースの詳細や顧客コンテキストを参照・操作でき、外部で同等機能を一から実装・保守する負担を軽減します。Amazon Connect SDKは、Amazon Connect Customerが利用可能なすべてのAWSリージョンで提供されます。導入手順やAPI仕様、認証フロー、サンプルコードは管理者ガイドおよび開発者ガイドで確認できます。

影響範囲・利用シーン

  • 対象ユーザー: コンタクトセンターの開発者、プラットフォームエンジニア、CTI/CRM連携担当者
  • 利用シーン: カスタムのエージェントデスクトップやブラウザベースのコンソールにケース管理や顧客プロファイルを統合して、対応中に即座に参照・更新する場面
  • 運用効果: エージェントの画面遷移削減による応対時間短縮、コンテキストに基づく対応精度向上、既存ツールへの迅速な機能追加による開発コスト削減
  • 影響範囲: 既存のエージェントアプリケーションにSDKを組み込む作業が発生。認証/権限設定とUI実装の変更が必要
  • 導入条件: Amazon Connect Customer(Cases/Customer Profiles)を利用中、または利用可能なリージョンでの導入が前提

技術的な注意点

  • IAM権限: CasesやCustomer Profilesへアクセスするための適切なIAMポリシー(Connect関連のAPI呼び出し権限)を付与する必要があります。具体的な権限は開発者ガイドを参照してください。
  • リージョン制限: SDKは「Amazon Connect Customerが利用可能なすべてのリージョン」で提供されますが、ご利用のリージョンでCases/Customer Profilesが有効化されているかを事前に確認してください。
  • 認証/セッション管理: 埋め込み先アプリの認証フロー(SAML、OIDC、Amazon Cognito等)とAmazon Connectの認可を整合させる必要があります。トークン管理やセッション有効期限に注意してください。
  • セキュリティ/データ保護: 顧客プロファイルにはPIIを含む可能性があるため、画面表示制御やログ出力制御、暗号化・アクセスログの設定を検討してください。
  • 互換性/SDK言語: Amazon Connect SDKの対応言語やバージョン、ブラウザ互換性はドキュメントで確認してください(言語ごとの実装差に注意)。
  • コスト: SDK自体の導入で追加料金は発生しない場合が多いですが、CasesやCustomer Profilesの利用(ストレージ、API呼び出し等)や追加ログ保存などは別途課金対象になる可能性があります。料金ページを確認してください。
  • 運用: カスタムUIへ埋め込む場合はUI/UXテストとエージェント教育を実施し、運用監視(エラー、パフォーマンス)の仕組みを用意してください。

参考情報

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