2025/7/17 9:00:00 ~ 2025/7/18 9:00:00 (JST)

最近の発表

Amazon RDS for SQL Server now supports linked servers with Oracle OLEDB Driver version 21.16

SQL Server 用 Amazon RDS が Oracle OLEDB ドライババージョン 21.16 のリンクサーバーをサポートするようになりました。\n リンクされたサーバーにより、お客様は自分の Amazon RDS for SQL Server データベース内から外部データソースにアクセスできます。Oracle OLEDB を含むリンクサーバーは、SQL Server スタンダードエディションまたはエンタープライズエディションで使用できます。SQL Server 2017、2019、または 2022 では、Oracle データベースバージョン 18c、19c、または 21c を使用するリモートの Oracle データベースサーバーからデータを読み取ったり、コマンドを実行したりできます。Oracle OLEDB ドライバーバージョン 21.16 では、パフォーマンスが向上し、Oracle データベースへの信頼性の高いアクセスが可能になります。リンクサーバー統合の詳細については、Amazon RDS ユーザーガイドを参照してください。 Amazon RDS for SQL Server のリンクサーバーサポートは、SQL Server 用 Amazon RDS が利用できるすべての AWS リージョンでご利用いただけます。

Announcing Amazon DynamoDB local major version release version 3.0.0

本日、Amazon DynamoDB のダウンロード可能なバージョンである DynamoDB ローカルが AWS SDK for Java 2.x に移行されました。SDK とツールのメンテナンスポリシーに沿って、この移行により、開発者がローカルで DynamoDB アプリケーションを開発およびテストする際に、DynamoDB local のセキュリティ、互換性、安定性が常に最新の状態に保たれます。新しい DynamoDB ローカルバージョン 3.0.0 では、AWS SDK for Java 1.x への依存を完全に取り除くことができるようになりました。コードベースを次のように更新することで、以前の DynamoDB ローカルバージョンを使用するアプリケーションを DynamoDB ローカル 3.0.0 にアップグレードできます。\n

現在の com.amazonaws 名前空間を参照しているすべてのインポートステートメントは、新しい software.amazon.dynamodb 名前空間に更新する必要があります。

DynamoDB を Apache Maven 依存関係としてローカルで実行している場合は、アプリケーションのプロジェクトオブジェクトモデル (POM) ファイルにある新しい DynamoDB Maven リポジトリを参照してください。DynamoDB ローカルサンプル Java プロジェクトを参照してください。

クライアントクラス名 AmazonDynamoDB を使用して埋め込みモードで DynamoDB をローカルで実行している場合は、AWS SDK バージョン 1 から AWS SDK バージョン 2 への移行方法に関するクライアントの変更点を参照してください。

Java 2.x 用 AWS SDK の詳細については、「Java 2.x 用 AWS SDK」を参照してください。DynamoDB ローカルの詳細については、「DynamoDB ローカル (ダウンロード版) のセットアップ」を参照してください。

AWS Clean Rooms ML now supports Parquet file format

本日より、AWS Clean Rooms は Parquet ファイル形式のデータでのカスタム ML モデルのトレーニングをサポートするようになりました。Parquet は無料のオープンソースの列指向データストレージ形式で、効率的なデータ圧縮とエンコードスキームを提供し、パフォーマンスを向上させます。\n AWS Clean Rooms ML カスタムモデリングでは、機密性の高い知的財産を共有しなくても、あなたとパートナーは大規模なデータセットを集めてカスタム ML モデルをトレーニングできます。Parquet ファイル形式で ML 入力チャネルを作成すると、大量のデータをより効率的に処理し、非テキストベースのデータをエンコードできるため、画像やその他のバイナリでエンコードされたデータタイプでトレーニングできます。 AWS Clean Rooms ML は、お客様とパートナーがプライバシーを強化するコントロールを適用してお客様独自のデータと ML モデルを保護すると同時に、予測的な洞察を得られるようにします。しかも、お互いに生データやモデルを共有したりコピーしたりする必要はありません。AWS Clean Rooms ML が利用できる AWS リージョンの詳細については、AWS リージョンの表を参照してください。詳細については、AWS クリーンルーム ML をご覧ください。

Amazon ECS enables built-in blue/green deployments

Amazon Elastic Container Service (Amazon ECS) は、コンテナ化されたアプリケーションのソフトウェア更新をより安全にする新機能を発表しました。これにより、カスタムのデプロイツールを構築しなくても、より迅速かつ自信を持ってソフトウェアを出荷できるようになります。Amazon ECS では、Blue/Green デプロイ戦略とデプロイライフサイクルフックが組み込まれています。これにより、新しいアプリケーションバージョンを本番環境でテストし、失敗したデプロイをすばやくロールバックできます。\n ブルー/グリーンデプロイ戦略を使用して、アプリケーションロードバランサー (ALB)、ネットワークロードバランサー (NLB)、または ECS Service Connect からのトラフィックを処理する Amazon ECS サービスにソフトウェア更新をデプロイできるようになりました。Blue/Green デプロイ戦略を使用する場合、Amazon ECS は新しいアプリケーションバージョンを古いバージョンと一緒にプロビジョニングし、本番トラフィックをルーティングする前に新しいアプリケーションバージョンを検証できます。デプロイライフサイクルフックを使用してカスタム検証ステップを実行し、検証が成功するまでデプロイをブロックできます。さらに、本番環境のトラフィックが移行されたら、新しいアプリケーションを事前に指定した期間ベイクし、リグレッションが検出された場合でもダウンタイムを発生させずに古いバージョンにロールバックできます。障害を自動的に検出するには、デプロイを監視するように Amazon CloudWatch アラームと ECS デプロイサーキットブレーカーを設定できます。これらの機能を組み合わせることで、ソフトウェアの更新がより安全になり、新機能をより早くリリースできるようになります。

ブログの手順に従うことで、AWS マネジメントコンソール、SDK、CLI、CloudFormation、CDK、Terraform を使用して、すべての商用 AWS リージョンの新規および既存の Amazon ECS サービスにブルー/グリーンデプロイとデプロイライフサイクルフックを使用できます。詳細については、当社のドキュメントを参照してください。

Amazon SNS enhances cross-Region delivery capabilities

Amazon Simple Notification Service (Amazon SNS) がクロスリージョン配信機能を拡張し、オプトインリージョンを使用するお客様により柔軟に対応できるようになったことをお知らせできることを嬉しく思います。この更新により、3 つの改善が加えられました。\n

オプトインリージョン間の Amazon SNS から Amazon SQS への配信:あるオプトインリージョンの Amazon SNS トピックから、別のオプトインリージョンの Amazon SQS キューにメッセージを配信できるようになりました。

オプトインリージョン間の Amazon SNS から AWS Lambda への配信:あるオプトインリージョンの Amazon SNS トピックから別のオプトインリージョンの AWS Lambda 関数へのメッセージ配信がサポートされるようになりました。

Amazon SNS から AWS Lambda へのデフォルトリージョンからオプトインリージョンへの配信:デフォルトが有効になっているリージョンの Amazon SNS トピックから、オプトインリージョンの AWS Lambda 関数にメッセージを配信できるようになりました。

これらの機能強化により、AWS リージョン全体にわたる分散システムをより柔軟に設計できるようになり、アーキテクチャでオプトインリージョンを活用しやすくなりました。 これらの新機能を使用するには、アカウントで必要なオプトインリージョンを有効にしていることを確認してください。オプトインリージョンを含むクロスリージョンサブスクリプションを設定する場合は、必ずリージョン固有のサービスプリンシパル (sns) を使用してください。リソースポリシーで.amazonaws.com)。 オプトインリージョンの使用方法の詳細については、AWS アカウント管理のドキュメントを参照してください。Amazon SNS のクロスリージョン配信の詳細については、Amazon SNS のドキュメントを参照してください。

AWS Lambda enables developers to debug functions running in the cloud from VS Code IDE

AWS Lambda は Visual Studio Code (VS Code) でのリモートデバッグをサポートするようになりました。これにより、開発者はクラウドで実行されている Lambda 関数をローカル IDE から直接デバッグできるようになりました。この新機能により、開発者は既存の開発ワークフローを変更することなく、ブレークポイント、変数インスペクション、クラウドにデプロイされた関数のステップスルーデバッグなどの使い慣れたデバッグツールを使用できるため、サーバーレス開発プロセスを加速できます。\n Lambda を使用してサーバーレスアプリケーションを構築する開発者は、Amazon Virtual Private Cloud (VPC) にアタッチされている場合や、特定の AWS ID およびアクセス管理 (IAM) 権限を必要とする複数の AWS サービスが関与するクロスサービス統合のテストとデバッグが必要になることがよくあります。以前は、Lambda ランタイム環境とその他の AWS サービスとのやりとりをローカルで完全に複製するツールがなかったため、開発者は印刷ステートメント、ログ、および複数の反復デプロイに頼って問題の診断と解決を行う必要がありました。VS Code のリモートデバッグにより、開発者は VPC リソースや IAM ロールに完全にアクセスして、クラウドで実行されている関数の実行環境をデバッグし、クラウド内のサービスフロー全体を通じて実行を追跡できるようになりました。また、開発者は関数をすばやく更新して変更をテストすることもできます。このリリースにより、ローカルでの複雑なデバッグ設定や繰り返しのデプロイが不要になり、問題の特定と修正にかかる時間が数時間から数分に短縮されます。 この機能は、AWS Toolkit (v3.69.0 以降) を VS Code にインストールしているすべての開発者が、追加料金なしで利用できるようになりました。開始するには、VS Code IDE で Lambda 関数を選択し、[リモートで起動] をクリックします。これで、1 回のクリックでリモートデバッグセッションを開始できます。AWS Toolkit は関数コードを自動的にダウンロードし、安全なデバッグ接続を確立し、ブレークポイントの設定を有効にします。詳細については、AWS ニュースブログ記事、AWS Toolkit ドキュメント、Lambda 開発者ガイドをご覧ください。

AWS Lambda announces low latency processing for Kafka events

AWS Lambda では、Apache Kafka (Amazon MSK) 向けの Amazon マネージドストリーミングの低レイテンシー (100 ミリ秒未満) イベント処理と、Kafka ESM のプロビジョニングモードでのセルフマネージド型の Apache Kafka イベントソースがサポートされるようになりました。Kafka ESM 構成でお客様が MaximumBatchingWindowInSeconds パラメータを 0 に設定できるようになり、Kafka イベントのリアルタイム処理が可能になりました。この強化により、時間に敏感なビジネスアプリケーションのエンドツーエンド処理レイテンシーが大幅に削減されます。\n 業界全体の厳しいビジネス要件を満たすために、エンドツーエンドの遅延が 100 ミリ秒未満で一貫して求められるミッションクリティカルなアプリケーションを構築するお客様が増えています。例としては、市場データフィードを処理してアルゴリズム取引を実行する金融サービス会社、パーソナライズされたレコメンデーションをリアルタイムで提供する電子商取引プラットフォーム、プレイヤーとのライブインタラクションを管理するゲーム会社などがあります。本日の発表により、Lambda は Kafka イベントのポーリングと呼び出しを効率的に最適化し、低レイテンシーのイベント処理をネイティブでサポートするようになりました。これにより、お客様はミッションクリティカルな、またはレイテンシーの影響を受けやすい Kafka アプリケーションを Lambda 上で構築できるようになります。MaximumBatchingWindowInSeconds を 0 に設定すると、Kafka ESM は前回の呼び出しが完了した直後に Kafka イベントを含む関数を呼び出します。この構成では、エンドツーエンドのレイテンシーは関数の実行時間のみに依存するため、重要なリアルタイムアプリケーションではエンドツーエンドで平均 50 ミリ秒のレイテンシーが発生する可能性があります。 この機能は通常、イスラエル (テルアビブ)、アジア太平洋 (マレーシア)、カナダ西部 (カルガリー) を除き、AWS Lambda Kafka ESM が利用可能なすべての AWS 商用リージョンで利用できます。 Kafka ESM で低レイテンシー処理を有効にするには、ESM API、AWS コンソール、AWS CLI、AWS SDK、AWS CloudFormation、AWS SAM で、新規または既存の Kafka ESM のプロビジョニングモードを 0 に設定し、新規または既存の Kafka ESM のプロビジョニングモードを有効にします。詳細については、Lambda ESM のドキュメントと AWS Lambda の料金表をご覧ください。

AWS Lambda bridges console to VS Code for unified serverless development experience

AWS Lambda では、コンソールから Visual Studio Code (VS Code) IDE へのシームレスな移行が可能になりました。この新しいコンソールと IDE の統合により、サーバーレスアプリケーションのクラウド開発環境とローカル開発環境間の摩擦が解消されます。 \n コンソールから開発を始める開発者は、アプリケーションが複雑になるにつれて、ローカル IDE のより高度な開発機能が必要になります。以前は、開発を始める前に IDE のインストール、機能コード、構成、統合設定のコピーなど、ローカル開発環境を手動で設定する必要がありました。これには時間がかかり、開発ワークフローが中断されました。新しいコンソールと IDE の統合により、開発者はコードと設定を維持したまま Lambda 関数を VS Code にワンクリックで移行できるようになりました。これにより、開発者はセットアップのオーバーヘッドなしに、外部依存関係管理 (npm や pip などのパッケージマネージャーを使用)、linter や Formatter などの開発ツールなどの高度な IDE 機能を使用できます。このリリースでは、開発者がアプリケーションを AWS サーバーレスアプリケーションモデル (AWS SAM) テンプレートに簡単に変換できる VS Code IDE の新機能も導入され、コードとしてのインフラストラクチャ (IaC) プラクティスと CI/CD パイプライン統合が簡素化されます。 開始するには、Lambda コンソールの [コード] タブにある [Visual Studio Code で開く] ボタンをクリックするか、新しい関数を作成するときに [はじめに] ポップアップをクリックします。これにより、ローカルデバイスに VS Code IDE が自動的に開かれるか、ガイド付きの手順に従って VS Code や AWS Toolkit などの必要なツールをインストールできます。このエクスペリエンスについて詳しくは、AWS ニュースのブログ記事、Lambda 開発者ガイド、および VS Code 用 AWS Toolkit のドキュメントをご覧ください。 この機能は、AWS GovCloud (米国) リージョンを除き、Lambda が利用可能なすべての商用 AWS リージョンで追加料金なしで利用できます。

Amazon DynamoDB Streams introduces a new API feature for faster and more efficient stream shard discovery

Amazon DynamoDB ストリームでは、ストリーミングデータの使用を簡素化および最適化するための新しい ShardFilter パラメータが DescribeStream API でサポートされるようになりました。ShardFilter パラメータを使用すると、親シャードを閉じた後に子シャードをすばやく見つけることができるため、DynamoDB ストリームからのデータを処理する際の効率と応答性が大幅に向上します。\n DynamoDB ストリームはサーバーレスのデータストリーミング機能で、DynamoDB テーブルの項目レベルの変更をほぼリアルタイムで簡単に追跡、処理、対応できます。DynamoDB Streams では、イベント駆動型アプリケーションの構築、データレプリケーション、監査、データ分析や機械学習機能の実装など、さまざまな変更データキャプチャのユースケースが可能です。DynamoDB ストリームからのデータを使用するアプリケーションでは、このオプションの ShardFilter パラメータを使用することで、クローズドシャードの読み取りから子シャードへの効率的な移行が可能になります。これにより、DescribeStream API を繰り返し呼び出して、すべてのクローズドシャードとオープンシャードのシャードマップを取得してトラバースする必要がなくなります。この API の強化により、シャード間の切り替え時のスムーズな移行とレイテンシーの短縮が可能になり、ストリーム処理アプリケーションの応答性とコスト効率が向上します。 新しい ShardFilter パラメータはすべての AWS リージョンで使用できます。この機能は、AWS API、Kinesis クライアントライブラリ (KCL) 3.0、または DynamoDB ストリーム用の Apache Flink コネクタを使用して開始できます。AWS Lambda を使用して DynamoDB ストリームを利用するお客様は、この拡張された API エクスペリエンスの恩恵を自動的に受けます。 詳細については、『DynamoDB 開発者ガイド』の「DynamoDB ストリームの使用」と「DescribeStream の API リファレンス」を参照してください。

Amazon Connect agent workspace now includes real-time agent performance metrics

Amazon Connect のエージェントワークスペースに、すぐに使える分析ダッシュボードが追加されました。これにより、エージェントは、処理された連絡先や平均処理時間など、個々のパフォーマンスに関する洞察を得ることができます。このダッシュボードには、キュー内の連絡先や最長待機時間など、エージェントに割り当てられたキューメトリックスも表示されます。これらのインサイトは、エージェントがパフォーマンスを向上させ、カスタマーエクスペリエンスを向上させる意思決定を行うのに役立ちます。たとえば、エージェントはキューの量が多い場合は休憩を遅らせることで、顧客の待ち時間を短縮できます。\n Amazon Connect エージェントワークスペース分析ダッシュボードは、米国東部 (バージニア北部)、米国西部 (オレゴン)、カナダ (中部)、アフリカ (ケープタウン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、ヨーロッパ (フランクフルト)、ヨーロッパ (ロンドン) の AWS リージョンで利用できます。詳細を確認して使用を開始するには、ウェブページとドキュメントをご覧ください。

AWS Outposts now supports booting Amazon EC2 instances from external storage arrays

本日より、お客様はネットアップ® オンプレミスエンタープライズストレージアレイとピュアストレージ® FlashArray™ にバックアップされたブートボリューム（認証済みボリュームと暗号化ボリュームを含む）を使用して、AWS Outposts上のAmazon Elastic Compute Cloud（Amazon EC2）インスタンスを起動できます。この拡張機能では iSCSI SAN ブートオプションとローカルブートオプションの両方がサポートされ、ローカルブートは iSCSI プロトコルと NVMe-over-TCP プロトコルの両方をサポートしています。フルマネージド型の Amazon EBS ボリュームとローカルインスタンスストアボリュームを補完するこの機能により、外部データボリュームに対する既存のサポートがサードパーティのストレージアレイのブートボリュームを含むように拡張され、お客様が Outposts でのストレージ投資をより柔軟に活用できるようになります。\n この新機能により、お客様は Outposts のクラウド運用モデルを活用しながら、オンプレミスのストレージへの投資から得られる価値を最大化できます。高度なデータ管理機能と高いパフォーマンスを活用して、ブートボリュームとデータボリュームの両方に互換性のあるエンタープライズストレージアレイを使用できるようになりました。外部ブート・ボリュームのサポートにより、お客様はブート・ボリュームを一元管理してオペレーティングシステム (OS) の管理を合理化できると同時に、オンプレミスのストレージ・アレイを通じてデータの保存要件を満たすのに役立ちます。このプロセスを簡素化するために、AWS では AWS Samples を通じて自動化スクリプトを提供しています。これにより、お客様が Outposts の EC2 インスタンスで外部ブートボリュームを簡単にセットアップして使用できるようになります。 この拡張は、AWS GovCloud リージョンを除き、Outposts が利用可能なすべての AWS リージョンで Outposts 2U サーバーと Outposts ラックで追加料金なしで利用できます。最新の可用性情報については、Outposts サーバーと Outposts ラックに関するよくある質問を参照してください。

AWS 提供の自動化スクリプトを使用して Outposts の外部ブートボリュームを使い始めることができます。実装の詳細とベストプラクティスについて詳しくは、このブログ投稿を確認するか、Outposts サーバー、第 2 世代 Outposts ラック、および第 1 世代の Outposts ラックに関する技術文書をご覧ください。

Amazon MemoryDB now supports an AWS FIS action to pause multi-Region cluster replication

Amazon MemoryDB は、マルチリージョンクラスターのレプリケーションを一時停止する AWS フォールトインジェクションサービスアクションをサポートするようになりました。FIS は、制御されたフォールトインジェクション実験を実行してアプリケーションのパフォーマンス、可観測性、耐障害性を向上させるための完全マネージド型サービスです。Amazon MemoryDB Multi-Region は、フルマネージド型のアクティブ-アクティブマルチリージョンデータベースで、最大 99.999% の可用性とマイクロ秒の読み取りレイテンシーと 1 桁ミリ秒の書き込みレイテンシーを備えたマルチリージョンアプリケーションを構築できます。お客様は新しい FIS アクションを使用して、リージョナルレプリケーションの中断にアプリケーションがどのように反応するかを観察し、モニタリングと復旧プロセスを調整して耐障害性とアプリケーションの可用性を向上させることができます。\n MemoryDB Multi-Regionを使用すると、高可用性、アプリケーションの耐障害性の向上、事業継続性の向上を必要とするマルチリージョンのアプリケーションを構築できます。この新しい FIS アクションは、マルチリージョンクラスターのレプリケーションが中断されて再開されたときの実際の動作を再現します。これにより、リージョン内のリソースにアクセスできない場合でも、アプリケーションが意図したとおりに応答することをテストし、確信できるようになります。FIS で実験テンプレートを作成して、実験を継続的インテグレーションやリリーステストと統合したり、他の FIS アクションと組み合わせたりすることができます。たとえば、「クロスリージョン:接続」シナリオでは、MemoryDB レプリケーションの一時停止を他のアクションと組み合わせて、リージョンを分離します。 MemoryDB マルチリージョン一時停止レプリケーションは、MemoryDB マルチリージョンが利用可能なすべての AWS リージョンで利用できるようになりました。詳細については、MemoryDB FIS アクションのドキュメントをご覧ください。

Amazon RDS for PostgreSQL 18 Beta 2 is now available in Amazon RDS Database Preview Environment

Amazon RDS for PostgreSQL 18 ベータ 2 が Amazon RDS データベースプレビュー環境で利用可能になり、Amazon RDS for PostgreSQL で PostgreSQL 18 のプレリリースを評価できるようになりました。PostgreSQL 18 ベータ 2 は、完全マネージド型のデータベースという利点がある Amazon RDS データベースプレビュー環境にデプロイできます。\n PostgreSQL 18 では、複数列の B ツリーインデックスの「スキップスキャン」がサポートされ、OR 条件と IN 条件の WHERE 句の処理が改善されています。GIN インデックスの並列ビルドとジョイン操作の更新が導入されました。オブザーバビリティの改善により、接続ごとの I/O 使用率指標とともに、クエリ実行中のバッファ使用量とインデックス検索が表示されるようになりました。詳細については、RDS PostgreSQL リリースドキュメントを参照してください。 Amazon RDS データベースプレビュー環境のデータベースインスタンスは最大 60 日間保持され、保持期間が過ぎると自動的に削除されます。プレビュー環境で作成された Amazon RDS データベーススナップショットは、プレビュー環境内のデータベースインスタンスの作成または復元にのみ使用できます。PostgreSQL のダンプおよびロード機能を使用して、プレビュー環境からデータベースをインポートまたはエクスポートできます。 Amazon RDS データベースプレビュー環境のデータベースインスタンスの価格は、米国東部 (オハイオ) リージョンの価格に基づいています。

Amazon AppStream 2.0 expands support for GPU based instances

本日、Amazon AppStream 2.0 は、グラフィックスを多用するアプリケーションに対応するように設計された EC2 G6 ファミリー上に構築されたグラフィックス G6 インスタンスのサポートを発表しました。Amazon EC2 G6 インスタンスには NVIDIA L4 テンソルコア GPU と第 3 世代 AMD EPYC プロセッサが搭載されています。\n 今回の発表により、AppStream 2.0 では、16 GB から 384 GB までのシステムメモリと 4 ～ 96 個の vCPU を搭載した 9 種類のグラフィックス G6 インスタンスサイズが導入されました。7 つの G6 インスタンスは vCPU とメモリの比率が 1:4 を維持し、GPU の全機能を備えています。ただし、それぞれ 4 つの GPU を搭載している g6.12xlarge インスタンスと g6.24xlarge インスタンスを除きます。2 つの Gr6 インスタンスは、サイズが 4 倍、サイズが 8 倍で、vCPU 対メモリ構成が 1:8 になっています。この種類の新しいグラフィックインスタンスにより、グラフィックを多用するアプリケーションに適した価格とパフォーマンスを選択できます。 Graphics G6 インスタンスファミリーのサポートは、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、カナダ (中部)、ヨーロッパ (パリ、フランクフルト、ロンドン)、アジアパシフィック (東京、ムンバイ、シドニー、ソウル)、南米 (サンパウロ)、および AWS GovCloud (米国西部) を含む 13 の AWS リージョンで利用できます。AppStream 2.0 は従量課金制です。詳細については、「Amazon AppStream 2.0 料金表」を参照してください。 開始するには、イメージビルダーの起動時または新規フリート作成時に AppStream 2.0 Graphics G6 インスタンスを選択してください。Graphics G6 インスタンスは AWS マネジメントコンソールまたは AWS SDK を使用して起動できます。詳細については、「AppStream 2.0 インスタンスファミリー」を参照してください。

Amazon OpenSearch Service now supports integration with Amazon Aurora MySQL and PostgreSQL

Amazon OpenSearch Service では、Amazon Aurora MySQL と PostgreSQL からシームレスにデータを取り込むことができるようになりました。これにより、お客様はリレーショナルデータベースのデータに対するフルテキスト検索、ハイブリッド検索、ベクター検索などの高度な検索機能を活用できるようになりました。お客様は、データを書き込んでから数秒以内に Amazon Aurora MySQL と PostgreSQL から Amazon OpenSearch Service にデータを同期できるようになりました。抽出、変換、ロード操作のための複雑なデータパイプラインを構築および保守するためのカスタムコードを記述する必要はありません。\n このインテグレーションでは、Amazon OpenSearch Ingestion を使用して Amazon Aurora MySQL データベースと PostgreSQL データベースのデータを OpenSearch Service に同期します。Amazon OpenSearch Ingestion は Amazon Aurora MySQL テーブルと PostgreSQL テーブルのデータ形式を自動的に認識し、そのデータを Amazon OpenSearch Service のインデックスマッピングテンプレートにマッピングすることで、最もパフォーマンスの高い検索結果を得ることができます。さらに、お客様は Amazon Aurora MySQL および PostgreSQL データベース内の複数のテーブルのデータを 1 つの Amazon OpenSearch マネージドクラスターまたはサーバーレスコレクションに同期して、複数のアプリケーションにわたる総合的な洞察を得ることができます。 Amazon OpenSearch Service と Amazon Aurora MySQL および PostgreSQL の統合は、Amazon OpenSearch Igestion が現在利用できる 16 のリージョンすべてで利用できます。米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、米国西部 (北カリフォルニア)、ヨーロッパ (アイルランド)、ヨーロッパ (ロンドン)、ヨーロッパ (フランクフルト)、アジアパシフィック (東京)、アジアパシフィック (シドニー)、アジアパシフィック (シンガポール)）、アジアパシフィック（ムンバイ）、アジアパシフィック（ソウル）、およびカナダ（セントラル）。 この機能の詳細については、Amazon OpenSearch サービス開発者ガイドとローンチブログを参照してください。

Amazon OpenSearch Service now supports integration with Amazon RDS for MySQL and PostgreSQL

Amazon OpenSearch Service では、Amazon RDS for MySQL と PostgreSQL からシームレスにデータを取り込むことができるようになりました。これにより、お客様はリレーショナルデータベースのデータに対するフルテキスト検索、ハイブリッド検索、ベクター検索などの高度な検索機能を活用できるようになりました。お客様は、データを書き込んでから数秒以内に Amazon RDS for MySQL と PostgreSQL から Amazon OpenSearch Service にデータを同期できるようになりました。抽出、変換、ロード操作のための複雑なデータパイプラインを構築および保守するためのカスタムコードを記述する必要はありません。\n このインテグレーションでは、Amazon OpenSearch Ingestion を使用して Amazon RDS for MySQL データベースと PostgreSQL データベースのデータを OpenSearch Service に同期します。Amazon OpenSearch Ingest は、Amazon RDS for MySQL テーブルと PostgreSQL テーブルのデータ形式を自動的に認識し、そのデータを Amazon OpenSearch Service のインデックスマッピングテンプレートにマッピングして、最もパフォーマンスの高い検索結果を得ることができます。さらに、お客様は Amazon RDS for MySQL および PostgreSQL データベース内の複数のテーブルのデータを 1 つの Amazon OpenSearch マネージドクラスターまたはサーバーレスコレクションに同期して、複数のアプリケーションにわたる総合的な洞察を得ることができます。 Amazon OpenSearch Service と Amazon RDS for MySQL および PostgreSQL の統合は、Amazon OpenSearch Igestion が現在利用できる 16 のリージョンのすべてで利用できます。米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、米国西部 (北カリフォルニア)、ヨーロッパ (北カリフォルニア)、ヨーロッパ (アイルランド)、ヨーロッパ (ロンドン)、ヨーロッパ (フランクフルト)、アジアパシフィック (東京)、アジアパシフィック (シドニー)、アジアパシフィック (シドニー)、アジアパシフィック (シドニー) (アジアパシフィック) (シドニー) シンガポール)、アジアパシフィック (ムンバイ)、アジアパシフィック (ソウル)、カナダ (セントラル)。 この機能の詳細については、Amazon OpenSearch サービス開発者ガイドとローンチブログを参照してください。

Amazon S3 Multi-Region Access Points are now available in 12 additional AWS Regions

Amazon S3 マルチリージョンアクセスポイントは、アジアパシフィック (ジャカルタ、香港、ハイデラバード、メルボルン)、ヨーロッパ (チューリッヒ、スペイン、ミラノ)、中東 (バーレーンとアラブ首長国連邦)、カナダ西部 (カルガリー)、アフリカ (ケープタウン)、イスラエル (テルアビブ) の 12 の AWS オプトインリージョンで利用できるようになりました。\n 開始するには、まずここに記載されている手順を使用して、アカウントの AWS オプトインリージョンを有効にする必要があります。次に、AWS CLI または AWS SDK を使用して AWS オプトインリージョンに S3 マルチリージョンアクセスポイントを作成できます。料金情報については、Amazon S3 料金表ページをご覧ください。S3 マルチリージョンアクセスポイントの詳細については、機能ページ、S3 ユーザーガイド、または S3 FAQ をご覧ください。

AWS Glue now supports new workers for larger and memory intensive workloads

AWS Glue では、さまざまなデータ統合とデータ処理のニーズを満たす新しいワーカータイプが追加されました。新しいワーカーには、より大きな G.12X と G.16X の一般コンピューティングワーカー、およびメモリを大量に消費する AWS Glue ワークロード用の 4 つの新しいメモリ最適化ワーカー (R.1X、R.2X、R.4X、R.8X) が含まれます。Glue のお客様は、より複雑な変換、集約、結合、クエリを処理できるようになり、Apache Spark を使用して大量のデータを迅速に処理できるようになりました。\n 新しい G.12X および G.16X ワーカーは既存の G ワーカーサイズを拡張し、より多くのコンピューティング、メモリ、ストレージを提供します。これらのワーカーは、大規模でリソースを大量に消費するワークロードを抱えるお客様に最適です。新しい R.1X、R.2X、R.4X、および R.8X ワーカーは G ワーカーと比較して 2 倍のメモリを提供するため、キャッシュ、シャッフル、集計などのメモリを大量に消費する Spark 操作を行うワークロードに適しています。お客様は、AWS Glue Studio でノートブックや Visual ETL を使用するか、Glue Job API を使用して、これらの新しいワーカータイプを選択できます。 これらの新しいワーカータイプと、新しいワーカーが利用できる AWS リージョンの詳細については、AWS Glue のドキュメントをご覧ください。

AWS Blogs

Amazon Web Services ブログ (日本語)

AWS News Blog

AWS Cloud Operations Blog

AWS Big Data Blog

AWS Compute Blog

Desktop and Application Streaming

AWS DevOps & Developer Productivity Blog

AWS for Industries

Artificial Intelligence

AWS for M&E Blog

AWS Storage Blog

Open Source Project

AWS CLI

Amplify for iOS

Amazon EKS Anywhere