2025/4/2 9:00:00 ~ 2025/4/3 9:00:00 (JST)
最近の発表
Monitor service dependencies with Amazon CloudWatch Application Signals SLOs
Amazon CloudWatch アプリケーションシグナルは、サービス依存関係のメトリックスを使用したサービスレベル目標 (SLO) の作成をサポートするようになりました。この新しい機能により、サービスの依存関係のパフォーマンスをモニタリングし、SLO の目標設定を通じて問題をプロアクティブに解決できるようになりました。\n Application Signals を使用すると、サービスから送信されるリクエストとその依存関係におけるレイテンシーや障害などの主要なメトリクスを追跡する、期間ベースまたはリクエストベースの SLO を作成できます。依存関係がどのように機能し、これがサービス全体の信頼性にどのように影響するかを確認できます。たとえば、電子商取引サービスが支払い処理業者に依存している場合、CreateOrder オペレーションから支払い処理業者へのリクエストの待ち時間を監視するように SLO を設定できます。この SLO が低下した場合は、顧客対応サービスに影響が出る前に、その依存関係を潜在的な根本原因として迅速に調査できます。 依存関係に関する SLO は、CloudWatch アプリケーションシグナルが利用可能なすべての商用 AWS リージョンで利用できます。お客様は、アプリケーションシグナルの新しいバンドル料金プランにサインアップできるようになりました。詳細については、「Amazon CloudWatch 料金表」を参照してください。
Amazon Security Lake achieves FedRamp High and Moderate authorization
アマゾンセキュリティレイクは、AWS GovCloud (米国) リージョンでは FedRAMP 高認証を取得し、米国東部および米国西部リージョンでは FedRAMP モデレート認証を取得しています。FedRAMP コンプライアンス要件を満たす連邦政府機関、公共部門の組織、または企業であれば、Amazon Security Lake を使用してセキュリティデータを一元化できるようになりました。\n Amazon Security Lake は、AWS 環境、SaaS プロバイダー、オンプレミス、クラウドソースからのセキュリティデータを、お客様のアカウントに保存された専用のデータレイクに自動的に一元化します。Security Lake を使用すると、組織全体のセキュリティデータをより完全に把握できます。また、ワークロード、アプリケーション、およびデータの保護を強化することもできます。Security Lake は Linux Foundation の一部であるオープンスタンダードであるオープンサイバーセキュリティスキーマフレームワーク (OCSF) を採用しています。OCSF のサポートにより、このサービスは AWS のセキュリティデータと幅広いエンタープライズセキュリティデータソースからのセキュリティデータを標準化し、組み合わせています。 AWS マネジメントコンソールで 1 回クリックするだけで、Amazon Security Lake の 15 日間の無料トライアルを開始できます。詳細を確認して使用を開始するには、以下のリソースを参照してください。
Amazon セキュリティレイク POC を開発する方法
Amazon セキュリティレイクのコストを理解する
Amazon CloudWatch Logs increases maximum log event size to 1 MB
Amazon CloudWatch ログは、最大 1 MB のサイズのログイベントをサポートするようになりました。これは、以前の 256 KB の制限から 4 倍に増加しています。この拡張は CloudWatch Logs PutLogEvents API と OpenTelemetry Protocol (OTLP) エンドポイントに適用されます。\n お客様はデータの整合性を保ちながら、より豊富なログデータを取得できるようになったため、サイズの大きいイベントを切り捨てたり、複数のエントリに分割したりする必要がなくなりました。特に、スタックトレース、デバッグ出力、詳細なアプリケーションおよびセキュリティ監査ログなどのユースケースで役立つため、トラブルシューティングの簡素化、セキュリティ監査機能の強化、アプリケーションの動作の可視性の向上が可能になります。 制限の引き上げは、AWS GovCloud (米国) リージョンを含め、CloudWatch Logs が利用可能なすべての AWS リージョンで自動的に利用可能になります。詳細については、CloudWatch Logs のドキュメントをご覧ください。
AWS CDK L2 Construct for Amazon Cognito Identity Pools now generally available
アマゾンウェブサービス (AWS) は、Amazon Cognito ID プール用の AWS クラウド開発キット (AWS CDK) L2 コンストラクトの一般提供を発表しました。このライブラリにより、開発者は使い慣れたプログラミング言語を使用して Identity Pool リソースをプログラム的に定義してデプロイできるため、アプリケーション内の AWS サービスへの安全なアクセス権をユーザーに付与することが容易になります。\n このコンストラクトライブラリを使用すると、ID プールをインフラストラクチャとしてコードとして定義したり、Amazon Cognito ユーザープールなどの認証プロバイダー、ソーシャル ID プロバイダー (Facebook、Google、Apple、Amazon)、SAML 2.0 プロバイダーを設定したりできます。このライブラリは、セキュリティのベストプラクティスをデフォルトで実装するのに役立ち、ウェブおよびモバイルアプリケーションの認証と承認の管理の複雑さを軽減します。 Amazon Cognito ID プール用の AWS CDK コンストラクトライブラリは、Amazon Cognito が利用可能なすべての AWS リージョンで利用できます。 開始するには、以下のリソースを参照してください。
Amazon Cognito ID プールのドキュメント
AWS CDK API リファレンス
Amazon Connect now allows supervisors to take additional actions on in-progress chats
Amazon Connect では、スーパーバイザーが進行中のチャットに対して Amazon Connect UI から直接追加のアクションを実行できるようになり、問題解決が加速され、顧客満足度が向上しました。たとえば、スーパーバイザーは非アクティブな顧客とのチャットを終了したり、特定のエージェントやキューにチャットを再割り当てしたりできるようになりました。\n 詳細については、ヘルプドキュメントを参照するか、Amazon Connect ウェブサイトをご覧ください。この機能は、Amazon Connect が利用できるすべての商用 AWS リージョンで利用できます。
Amazon RDS Proxy announces TLS 1.3 support for PostgreSQL on Aurora and RDS
Amazon リレーショナルデータベースサービス (RDS) プロキシは、Amazon Aurora PostgreSQL へのプロキシ接続用のトランスポート層セキュリティ (TLS) プロトコルのバージョン 1.3 と PostgreSQL データベースインスタンス用の RDS をサポートするようになりました。TLS 1.3 は、古い TLS バージョンと比較して、より強力な暗号化アルゴリズムと簡素化されたハンドシェイクプロセスにより、セキュリティが向上しています。\n このリリースでは、RDS プロキシは TLS 1.3 を使用して Aurora PostgreSQL データベースに接続し、RDS for PostgreSQL データベースへの接続に使用できるようになりました。接続が確立されると、Proxy はデータベースでサポートされている最も安全な TLS バージョンを自動的にネゴシエートします。お客様は、パラメータグループに ssl_min_protocol_version パラメータを設定することで、TLS 1.3 を要求するように PostgreSQL データベースを設定することもできます。TLS 1.3 は RDS プロキシへの接続と MySQL エンジンへの RDS プロキシ接続ですでにサポートされています。 RDS プロキシは RDS および Amazon Aurora データベース用の完全マネージド型で可用性の高いデータベースプロキシです。RDS プロキシは、アプリケーションのスケーラビリティ、耐障害性、およびセキュリティを向上させるのに役立ちます。Aurora での TLS バージョンのサポートと関連設定については、Aurora のドキュメントをご覧ください。サポートされているデータベースエンジンのバージョンと RDS Proxy の提供地域については、RDS と Aurora のドキュメントを参照してください。
AWS CDK Construct Library for Amazon EventBridge Scheduler now generally available
アマゾンウェブサービス (AWS) は、Amazon EventBridge スケジューラー用の AWS クラウド開発キット (AWS CDK) L2 コンストラクトライブラリの一般提供を発表しました。このコンストラクトライブラリにより、開発者は好みのプログラミング言語で Infrastructure as Code を使用して、スケジュールされたタスクをプログラム的に作成、設定、管理できるため、イベント駆動型アプリケーションの構築プロセスが簡略化されます。\n EventBridge Scheduler コンストラクトライブラリを使用すると、cron 式や rate 式を使用してスケジュールを定義したり、AWS Lambda 関数、Amazon SQS キュー、その他の AWS サービスなどのターゲット送信先を設定したり、実行ウィンドウや再試行ポリシーを管理したりできます。開発者はタイプセーフなプログラミング言語を利用してスケジューリングインフラストラクチャを定義できるようになり、コードの保守性が向上し、設定エラーが減ります。 Amazon EventBridge スケジューラー用の AWS CDK コンストラクトライブラリは、Amazon EventBridge スケジューラーが利用できるすべての AWS リージョンで利用できます。 開始するには、以下のリソースを参照してください。
Amazon イベントブリッジスケジューラーのドキュメント
イベントブリッジスケジューラ用 AWS CDK API リファレンス
AWS CDK 開発者ガイド
AWS Clean Rooms Spark SQL now supports aggregation and list analysis rules
本日のリリースにより、AWS Clean Roomsには、Spark分析エンジンを使用した集計およびリスト分析ルールをサポートするためのプライバシー強化コントロールが追加されました。\n AWS Clean Rooms Spark SQL を使用することで、お客様とパートナーは、お客様のパフォーマンス、規模、コスト要件に基づいて設定可能なリソースで SQL クエリを実行しながら、集計、リスト、およびカスタム分析ルールを使用してデータの使用方法を管理できるようになりました。たとえば、広告主はリスト分析ルールを使用して、セグメントの作成に使用された未加工データを共有することなく、広告主とパブリッシャーの集合データセットからターゲットオーディエンスセグメントを作成できます。同様に、パブリッシャーとそのパートナーは、集計ルールを使用してデータセット全体でメディアプランニングとキャンペーン測定分析を行い、共同の統計結果をまとめることができます。これにより、すべての協力者の基礎となるデータを保護できます。さらに、新しいコラボレーションを作成する代わりに、既存の AWS Clean Rooms コラボレーションを Spark 分析エンジンを使用するように更新できるようになったため、AWS Clean Rooms Spark SQL を使い始めるのが簡単になりました。 AWS クリーンルーム Spark SQL は、一般的にこれらの AWS リージョンで利用できます。AWS Clean Roomsを使用すると、企業とそのパートナーは、互いの基礎データを公開したりコピーしたりすることなく、集合したデータセットをより簡単に分析して共同作業できます。詳細については、AWS クリーンルームをご覧ください。
Amazon RDS Proxy is now available in the AWS GovCloud (US) Regions
Amazon リレーショナルデータベースサービス (RDS) プロキシが AWS GovCloud (米国西部) と AWS GovCloud (米国東部) リージョンで利用できるようになりました。RDS プロキシは RDS および Amazon Aurora データベース用のフルマネージド型で可用性の高いデータベースプロキシです。RDS プロキシは、アプリケーションのスケーラビリティ、耐障害性、およびセキュリティを向上させるのに役立ちます。\n アクティブユーザーの増減に基づいて水平スケーリングが可能な最新のアーキテクチャで構築されたアプリケーションを含め、多くのアプリケーションでは、多数のデータベース接続を開いたり、接続を頻繁に開いたり閉じたりできます。これにより、データベースのメモリと計算処理に負荷がかかり、パフォーマンスが低下し、アプリケーションのスケーラビリティが制限されることがあります。Amazon RDS Proxy はアプリケーションとデータベースの間にあり、確立されたデータベース接続をプールして共有し、データベースの効率とアプリケーションのスケーラビリティを向上させます。障害が発生した場合、Amazon RDS Proxy はリージョン内のスタンバイデータベースインスタンスに自動的に接続します。Amazon RDS Proxy では、データベースの認証情報とアクセスを AWS Secrets Manager と AWS ID とアクセス管理 (IAM) で管理できるため、データベース認証情報をアプリケーションコードに埋め込む必要がなくなります。 サポートされているデータベースエンジンのバージョンと RDS プロキシの地域別可用性については、RDS プロキシ RDS と Aurora のドキュメントを参照してください。
IAM Identity Center extends sessions and TIP management capabilities for customers with Microsoft AD
AWS IAM アイデンティティセンターは、Microsoft Active Directory (AD) をアイデンティティソースとして接続するお客様向けに、セッション管理とトラステッドアイデンティティプロパゲーション (TIP) 機能を強化しました。強化された機能により、お客様によるユーザーセッションの管理、Amazon Q Developer Pro などの AWS アプリケーションの利用拡大、および信頼できる ID 伝播による分析などのユースケースの実装が可能になります。\n このリリースにより、Microsoft AD を IAM Identity Center に接続するお客様は、(a) AWS アプリケーションと AWS アクセスポータルのセッション期間を最低 15 分から最長 90 日に設定すること、(b) アクティブなユーザーセッションを一覧表示して削除すること、(c) 他の AWS アプリケーションのセッション期間を短くしたまま Amazon Q Developer Pro の 90 日間のセッション期間を延長すること、(d) ビジネスインテリジェンスアプリケーションから TIP を有効にすることができるようになります。サードパーティ ID プロバイダーを介して AWS サービスのユーザーを認証します。例:アマゾンレッドシフトとアマゾンQビジネス。 IAM Identity Center は、AWS アプリケーションおよび複数の AWS アカウントへの従業員のアクセスを管理するための推奨サービスです。既存のワークフォース ID ソースを AWS に一度接続するだけで、AWS 全体でユーザーにシングルサインオンエクスペリエンスを提供できます。これにより、Amazon Q などの AWS アプリケーションが提供するパーソナライズされたエクスペリエンスが強化され、Amazon Redshift などの AWS サービス内のデータへのユーザー認識型アクセスを定義および監査できるようになります。複数の AWS アカウントへのアクセスを一元的に管理するのに役立ちます。IAM アイデンティティセンターは、これらの AWS リージョンでは追加費用なしで利用できます。詳細については、こちらをご覧ください。
Amazon SageMaker now offers 9 additional visual ETL transforms
Amazon SageMakerのVisual ETLには、「派生列」、「フラット化」、「現在のタイムスタンプを追加」、「配列またはマップを行に分解」、「タイムスタンプへ」、「配列を列に」、「交差」、「制限」、「列を連結」の9つの新しい組み込み変換が用意されています。\n Amazon SageMaker のビジュアル ETL には、Amazon Q 開発者を使用して ETL フローを構築したり、フローを作成したりするためのドラッグアンドドロップインターフェイスが用意されています。これらの新しい変換により、ETL 開発者は一般的な変換タスク用のカスタムコードを記述しなくても、より高度なデータパイプラインをすばやく構築できます。これらの新しいトランスフォームはそれぞれ、固有のデータ処理ニーズに対応しています。たとえば、「派生列」を使用して数学式や SQL 式に基づいて新しい列を定義したり、「To timestamp」を使用して列をタイムスタンプ型に変換したり、「Concatenate columns」変換を使用してオプションのスペーサーを使用して他の列の値を使用して新しい文字列列を作成したりできます。 この新機能は、Amazon SageMaker が利用できるすべての AWS リージョンで利用できるようになりました。最新の可用性情報については、サポートされているリージョンのリストにアクセスしてください。 詳細については、Amazon SageMaker ドキュメントをご覧ください。
Announcing enhanced autoscaling for Amazon OpenSearch Ingestion pipelines
Amazon OpenSearch Ingestion が強化された自動スケーリング機能をサポートするようになったため、Amazon SQS キューサイズ、永続的なバッファラグ、受信 HTTP 接続数などの追加パラメータに基づいてパイプラインを動的にスケーリングできるようになりました。これらの機能強化により、以前はメモリと CPU の使用率のみに依存していた既存のスケーリングメカニズムが改善され、データ取り込みワークロードに対してより包括的で応答性の高いスケーリングメカニズムが提供されるようになりました。\n これらの改善により、お客様はさまざまなワークロードに自動的に適応する、よりレジリエントで効率的なデータ取り込みパイプラインを構築できます。新しい自動スケーリングパラメータは、リソース利用の最適化、取り込みのボトルネックの軽減、パイプライン全体のパフォーマンスの向上に役立ち、ログ分析、オブザーバビリティ、セキュリティ分析のユースケースにおける高スループットのデータストリームの処理が容易になります。
強化された自動スケーリング機能は、現在 Amazon OpenSearch インジェストが提供されているすべての AWS リージョンで利用できるようになりました。Amazon OpenSearch Service コンソールまたは API を使用して既存のパイプラインを更新したり、新しいパイプラインを作成したりすることで、追加費用なしでこれらの改善を活用できます。
詳細については、Amazon OpenSearch インジェストのウェブページと Amazon OpenSearch サービス開発者ガイドを参照してください。
Amazon CloudFront supports VPC Origin modification with CloudFront Functions
2024 年 11 月、CloudFront Functions ではオリジンの変更が導入され、リクエストごとにオリジンサーバーを条件付きで変更できるようになりました。本日より、この機能を VPC オリジンとオリジングループで使用できるようになり、CloudFront から配信されるアプリケーション向けにさらに高度なルーティングポリシーを作成できるようになりました。\n オリジンの ID を指定するだけで、VPC オリジンを含む任意のオリジン間で個々のリクエストを転送する動的ルーティングポリシーを作成できるようになりました。たとえば、ディストリビューション設定を更新しなくても、特定の割合のトラフィックを複数のバックエンドサービスに送信するようにウェイトを作成することで、各リクエストを異なるアプリケーションに自動的にルーティングできます。また、フェイルオーバー条件で複数のオリジンを設定できるので、新しいオリジングループを動的に作成することもできます。たとえば、視聴者のレイテンシーを最小限に抑えるために、視聴者の場所やリクエストヘッダーに基づいてプライマリアージンとフェイルオーバーオリジンを更新するカスタムフェイルオーバーロジックを作成できます。 これらの機能は CloudFront Functions 内で追加料金なしで利用できるようになりました。詳細については、CloudFront 開発者ガイドを参照してください。オリジン変更の使用方法の例については、GitHub サンプルリポジトリを参照してください。