2026/9/30 9:00:00 ~ 2026/10/1 9:00:00 (JST)

最近の発表

AWS CLI now supports bulk skill updates and version checks for the Agent Toolkit for AWS

本日、AWS は Agent Toolkit for AWS の AWS コマンドラインインターフェイス (CLI) コマンドを拡張し、エージェントのスキルを最新に保つのをより簡単に 2 つの新機能を追加しました。お客様は aws agent-toolkit check-skill-updates を実行して、インストールされているすべてのスキルをレジストリで入手可能な最新バージョンと比較したり、aws agent-toolkit update-skill–all を使用して古いスキルをすべて 1 つのコマンドで更新したりできるようになりました。\nAgent Toolkit for AWSは、AWS MCPサーバー（15,000以上のAWS APIに安全で監査可能なエージェントインターフェイスを提供）、エージェントスキル（ストレージ、ネットワーク、分析などに関する専門的なガイダンスをエージェントに提供する）、プラグイン（MCPサーバーをバンドルし、スキルセットを1つのインストールにまとめる）で構成されています。以前は、お客様は各スキルを個別に確認して更新する必要がありました。AWS CLI にこのような機能を追加することで、開発者はどのスキルに新しいバージョンがあるかをすばやく特定し、更新を 1 つずつ管理しなくても自分のスキルセット全体を最新の状態にすることができます。これは、サーバーレス、ストレージ、ネットワーキング、分析、その他の分野にわたって多くのスキルを身につけていて、コーディングエージェントが常に最新のガイダンスに従って動作するようにしたいチームにとって特に便利です。これらの新しいコマンドは、エージェントツールキットの既存の AWS CLI 機能セットに追加されました。これにより、お客様はすでに Kiro、Claude Code、Codex、Cursor、その他の一般的なコーディングエージェントにわたって AWS MCP サーバーとエージェントスキルをインストール、検索、設定できるようになりました。 開始するには、『Agent Toolkit for AWS ユーザーガイド』の「AWS CLI」を参照してください。AWS CLI バージョン 2.37.0 以降がインストールされていることを確認してください。AWS MCP Server は、米国東部 (バージニア北部) およびヨーロッパ (フランクフルト) リージョンでご利用いただけます。

Amazon S3 Vectors introduces metadata pre-filtering for up to 5x higher recall on filtered search

Amazon S3 Vectors では、類似検索を実行する前にメタデータフィルターを評価する事前フィルタリングがサポートされるようになりました。フィルターが選択的であると、一致するベクターが最大 5 倍多く返されます。S3 Vectors には、パスや URL などの値をフィルタリングするためのプレフィックス一致演算子 ($startsWith) も追加されています。これらの改善により、検索拡張生成 (RAG) アプリケーション、エージェントアプリケーション、およびセマンティック検索アプリケーションでは、フィルタリングしたときにより完全な結果が得られるため、アプリケーションからより関連性の高い回答が返されるようになります。\nS3 Vectors は Amazon S3 でのベクターの保存とクエリをネイティブでサポートし、目的に合わせて最適化されたコスト最適化型のベクターストレージとクエリを 10 億ベクター規模で提供します。今回の発表により、新しいベクターバケットのインデックスでは、デフォルトでメタデータの事前フィルタリングが使用されるようになり、PutVectors でベクターを記述する方法や QueryVectors でフィルターされたクエリを実行する方法に変更はありません。既存のインデックスで事前フィルタリングを使用するには、UpdateIndexMode API を使用してその場で更新してください。また、更新する前に QueryVectors のクエリごとのパラメーターを使用して、事前フィルタリングを同じインデックスでの現在のフィルタリングと比較することもできます。 メタデータの事前フィルタリングは、Amazon S3 Vectors が利用できるすべての商用 AWS リージョンと AWS 中国リージョンで、追加料金なしで利用できます。現在、この変更をデプロイ中であり、近日中にデプロイを完了する予定です。開始するには、AWS CLI、AWS SDK、または Amazon S3 コンソールを使用してください。詳細については、Amazon S3 ベクターのドキュメントと AWS ニュースブログをご覧ください。

Amazon Managed Grafana now supports creating Grafana 13.2 workspaces

Amazon マネージド Grafana は、Grafana バージョン 13.2 での新しいワークスペースの作成をサポートするようになりました。このリリースでは、ダッシュボード用の Git Sync、ダイナミックダッシュボード、Amazon CloudWatch データソースプラグインの PromQL クエリサポートなど、オープンソースの Grafana バージョン 13.0 から 13.2 までの機能が導入されています。\nGit Sync では、ワークスペースを Git リポジトリにリンクすることでダッシュボードをコードとして扱うことができます。これにより、ダッシュボードの変更を追跡、レビュー、元に戻すためのバージョン管理が可能になります。動的ダッシュボードでは、データや変数に反応する条件に基づいてレスポンシブなビューを構築できるため、レイアウトやパネル作成への適応性が高まります。Amazon CloudWatch データソースプラグインが PromQL クエリをサポートするようになったため、Prometheus クエリ言語を使用して CloudWatch が OpenTelemetry (OTLP) エンドポイント経由で取り込んだメトリクスをクエリできるようになりました。これにより、既存のメトリックス検索とメトリクスインサイトのクエリタイプを補完できます。 Grafana 13.2 は、Amazon マネージド Grafana が一般的に利用できるすべての AWS リージョンで利用できます。 バージョン 13.2 で Amazon マネージド Grafana ワークスペースを作成する方法の詳細については、ユーザードキュメントをご覧ください。Amazon Managed Grafana の機能と料金の詳細については、製品ページと価格ページをご覧ください。

OpenAI GPT-6 Astra now supports UltraFast mode on Amazon Bedrock

本日、AWSは、Amazon BedrockのOpenAIからGPT-6 Astraの超高速モードが利用可能になったことを発表しました。Ultrafast は GPT-6 Astra のプレミアム速度階層で、速度が最も重要なワークロード向けに構築されています。OpenAI によると、Ultrafast は 1 秒あたり最大 300 トークンで、API での推論を最大 6 倍高速化します。Amazon Bedrock 推論エンジンは、本番環境のワークロードに必要なパフォーマンス、セキュリティ、信頼性を提供します。\nGPT-6 Astra Ultrafast は、リアルタイムのコーディングアシスタント、インタラクティブエージェント、迅速で高品質な応答を必要とする顧客対応エクスペリエンスなど、遅延の影響を受けやすいアプリケーションに使用してください。確立された AWS 統制は、ワークロードの保護、アクセスの管理、モデル呼び出しアクティビティの監査に役立ちます。 Amazon Bedrock コンソールから始めることも、サポートされている Amazon Bedrock API を使用してプログラム的に開始することもできます。サポートされている AWS リージョン、エンドポイント、API、機能、推論プロファイル、料金については、Amazon Bedrock のドキュメントを参照してください。

AWS Parallel Computing Service now supports scaling logs

AWS パラレルコンピューティングサービス (AWS PCS) は、AWS PCS がクラスター内のコンピューティングノードグループをどのようにスケーリングするかを記録するスケーリングログをサポートするようになりました。各ログエントリには、インスタンスの起動、ノードの登録、スケールダウン、起動の失敗とその理由など、1 つのコンピューティングノードの 1 つの状態遷移が記録されます。スケーリングログを使用すると、スケーリングに関する問題をより簡単にトラブルシューティングできます。たとえば、コンピュートノードグループが目標サイズに達しなかった理由、容量の理由で起動に失敗した理由、特定のノードがいつ起動または停止したかを特定できます。スケーリングログの配信はオプトインになっており、Amazon CloudWatch Logs、Amazon S3、Amazon Data Firehose にスケーリングログを送信するように AWS PCS を設定できます。\nAWS PCS は、Slurm を使用して AWS での HPC ワークロードの実行とスケーリングを簡素化するマネージド型サービスです。コンピューティング、ストレージ、ネットワーキング、可視化ツールを統合した完全で伸縮自在な環境を構築できる一方で、このサービスは更新管理と組み込みのオブザーバビリティ機能でクラスター操作を処理します。 この機能は、AWS PCS が利用できるすべての AWS リージョンで利用できます。開始するには、AWS PCS ユーザーガイドを参照してください。

Amazon Aurora serverless now scales faster to support agentic AI and other bursty workloads

Amazon Aurora サーバーレスは、さらに大きなステップでスケーリングできるようになりました。1 秒以内に現在の容量に最大 16 個の ACU を追加し、ワークロードの増大に合わせて最大 256 ACU まで拡張し続けます。今回のローンチにより、ワークロードはより速くスケーリングされ、必要な容量に達するようになります。ワークロードが終了すると、Aurora サーバーレスは自動的にゼロまでスケールダウンするので、支払いは使用した分だけになります。そのため、アクティビティが急増し、アイドル時間が長く、トラフィックパターンが予測できないことが多いエージェント AI アプリケーションに特に適しています。\nこの拡張は、プラットフォームバージョン 3 または 4 で実行されているすべての Aurora サーバーレスクラスターでデフォルトで有効になっており、設定を変更する必要はありません。プラットフォームバージョン 1 と 2 の既存のクラスターは、最新のプラットフォームバージョン 4 に直接アップグレードしてこれらの改善の恩恵を受けることができます。クラスターのプラットフォームバージョンは、AWS マネジメントコンソールのインスタンス設定セクションで確認するか、RDS API の ServerlessV2PlatformVersion パラメータで確認できます。 価格の詳細とリージョンの提供状況については、Amazon Aurora 料金表をご覧ください。詳細については、Aurora サーバーレススケーリングのドキュメントを読み、AWS マネジメントコンソールのわずか数ステップで Aurora サーバーレスデータベースを作成することから始めましょう。

Amazon Aurora and RDS now support AMD-based R8a instances

Amazon Aurora と Amazon RDS は、第 5 世代 AMD EPYC プロセッサを搭載した R8a データベースインスタンスをサポートするようになり、データベースワークロードの選択肢が広がりました。R8a データベースインスタンスの各 vCPU は物理的な CPU コアに対応しているため、コアごとに一貫したパフォーマンスが得られます。I/O 要件が高いワークロード向けに、R8a インスタンスは最大 75 Gbps のネットワーク帯域幅と 60 Gbps の Amazon EBS 帯域幅を提供します。すべての R8a インスタンスは、第 6 世代の Nitro カードを使用して AWS Nitro システム上に構築されています。\nR8a データベースインスタンスは Amazon Aurora PostgreSQL 互換エディション、Amazon Aurora MySQL 互換エディション、PostgreSQL、MySQL、MariaDB 用の RDS でサポートされています。R8a データベースインスタンスは、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、カナダ (中部)、アジアパシフィック (東京、台北)、およびヨーロッパ (アイルランド、フランクフルト、スペイン) の各リージョンでご利用いただけます。 R8a データベースインスタンスは Amazon RDS マネジメントコンソールまたは AWS コマンドラインインターフェイス (CLI) を使用して開始できます。これらのインスタンスクラスをサポートする特定のエンジンバージョンについては、Aurora と RDS のドキュメントを参照してください。料金については、Amazon Aurora の料金表ページと Amazon RDS の料金表ページを参照してください。

Amazon RDS now supports AMD-based M8a instances

PostgreSQL、MySQL、MariaDB 用の Amazon RDS は、第 5 世代 AMD EPYC プロセッサを搭載した M8a データベースインスタンスをサポートするようになりました。これにより、データベースワークロードの選択肢が広がりました。M8a データベースインスタンスの各 vCPU は物理的な CPU コアに対応しているため、コアごとに一貫したパフォーマンスが得られます。I/O 要件が高いワークロードの場合、M8a インスタンスは最大 75 Gbps のネットワーク帯域幅と 60 Gbps の Amazon EBS 帯域幅を提供します。すべてのインスタンスは、第 6 世代の Nitro カードを使用して AWS Nitro システム上に構築されています。\nM8a データベースインスタンスは、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ、東京、ハイデラバード)、およびヨーロッパ (アイルランド、フランクフルト、スペイン) の各リージョンでご利用いただけます。M8a データベースインスタンスは Amazon RDS マネジメントコンソールまたは AWS コマンドラインインターフェイス (CLI) を使用して開始できます。これらのインスタンスクラスをサポートする特定のエンジンバージョンについては、RDS ドキュメントを参照してください。料金については、Amazon RDS 料金表ページを参照してください。

Aurora PostgreSQL now supports querying of Apache Iceberg and Parquet data

今日から、既存のPostgreSQLアプリケーションとツールを使用して、抽出、変換、読み込み（ETL）パイプラインやデータの重複なしに、Apache IcebergおよびParquet形式のデータレイクに保存されているデータとともに運用データを直接クエリできます。\nより多くの情報に基づいた意思決定を行い、ビジネスプロセスを自動化するために、アプリケーションが Apache Iceberg や Parquet の形式で保存されていることが多いデータレイクのデータにアクセスする必要性が高まっています。データにアクセスするには通常、データレイクから Aurora にデータをコピーするパイプラインが必要であり、スキーマの進化に伴ってコストとエンジニアリング作業が増加していました。今回のリリースにより、Amazon S3、Amazon S3 テーブル、または AWS Glue データカタログ内のアイスバーグまたはパーケットデータを参照する PostgreSQL 外部テーブルを作成できます。顧客がこれらの外部テーブルをクエリすると、Aurora は PostgreSQL に組み込まれた DuckDB の高性能クエリエンジンを使用して、基になるアイスバーグデータと Parquet データに対してクエリを実行します。既存のアプリケーションと BI ツールは同じ PostgreSQL インターフェースを引き続き使用します。 また、データを移動したり複製したりせずに、AWS Glue Data Catalog を介してフェデレートされた外部の Iceberg REST Catalog (IRC) 互換カタログのテーブルをクエリすることもできます。レイテンシーの影響を受けやすいワークロードでは、ETL パイプラインを使用せずに、標準の SQL ステートメントを使用して Iceberg または Parquet のデータをネイティブ Aurora PostgreSQL テーブルにマテリアライズできます。 この機能は、Aurora PostgreSQL の 17.11 から 18.6 以降、すべての AWS 商用リージョンと GovCloud (米国) リージョンで一般的に追加料金なしで利用できます。開始するには、Amazon RDS コンソールまたは任意の PostgreSQL クライアントを使用してください。詳細については、ブログ投稿またはドキュメントを参照してください。

Amazon RDS for MySQL supports MySQL 26.7 in Amazon RDS Database Preview Environment

本日より、Amazon RDS for MySQL 26.7 が Amazon RDS データベースプレビュー環境で利用可能になり、Amazon RDS for MySQL で MySQL 26.7 のプレリリースを評価できるようになりました。\nMySQL 26.7 は、新しい YY.M (Year.Month) カレンダーバージョニングモデルを採用した最初のイノベーションリリースです。バグ修正、セキュリティパッチ、およびテストワークロードの適用スループットとバックログリカバリを向上させるモジュール式レプリケーションアプライヤーであるChange Stream Applierなどの新機能が含まれています。詳細については、MySQL 26.7 リリースノートを参照してください。 Amazon RDS データベースプレビュー環境のデータベースインスタンスは最大 60 日間保持され、保持期間が過ぎると自動的に削除されます。プレビュー環境で作成されたデータベーススナップショットは、プレビュー環境内でのみ使用できます。プレビュー環境のデータベースインスタンスは、米国東部 (オハイオ) リージョンの価格に基づいて価格設定されます。 詳細については、Amazon RDS データベースプレビュー環境のドキュメントをご覧ください。

Uncover blind spots in AWS data plane operations with CloudTrail Event Coverage

AWS CloudTrail では、新しいコンソールエクスペリエンスである Event Coverage が導入されました。これにより、お客様はアカウントおよび組織レベルでデータプレーンの運用範囲を把握できます。環境内のどの AWS サービスとリソースタイプでデータイベントログが有効になっていて、どれが有効になっていないかを確認できるようになりました。これにより、組織内のアカウントを手作業でスキャンしなくても、ロギング状況のギャップをすばやく特定できます。\nデータイベントにより、AWS サービスのデータプレーンの操作を追跡できます。たとえば、GetObject や PutObject などの Amazon S3 オブジェクトレベルのオペレーションをログに記録して、不正なデータアクセスやデータ漏洩の試みを検出できます。データイベントを包括的にカバーしなければ、これらのアクティビティは見過ごされてしまい、セキュリティモニタリングに盲点が残る可能性があります。Event Coverage では、サポートされているすべてのデータイベントソースのカバレッジを 1 か所で確認し、ダッシュボードから直接データイベントを登録できます。これにより、特に複数のアカウントを管理している組織で、サービス全体のカバレッジの追跡に時間がかかる場合がある場合に、数回クリックするだけでカバレッジのギャップを簡単に埋めることができます。 イベントカバレッジには AWS CloudTrail コンソールからアクセスできます。この機能は、AWS CloudTrail がサポートされているすべての商用 AWS リージョンで利用できます。データイベントのログ記録の詳細については、AWS CloudTrail のドキュメントをご覧ください。

Partner Revenue Measurement adds Multi-Partner support to Resource Tagging

パートナー収益測定 (PRM) では、パートナーソリューションによる AWS の消費量を測定できます。現在、PRM はリソースタギングにマルチパートナーサポートを追加し、複数の AWS パートナーが同じ AWS リソースの収益アトリビューションを受けられるようにしました。以前は、1 つのリソースに aws-apn-id という 1 つのパートナータグしか割り当てられていなかったため、複数のパートナーが同じワークロードに貢献した場合、アトリビューションを受け取れるのは 1 つのパートナーだけでした。 \n今回の更新では、各パートナーが aws-apn-id-という形式の新しいキーを使用して、貢献したリソースにタグを付けるようになりました。複数のパートナーが同じリソースにタグを付けると、タグ付けされた各パートナーは収益アトリビューションを受け取ります。これは、ソフトウェアパートナーの製品を AWS アカウントにデプロイして運用するコンサルティングパートナーなど、ソリューションを共同で提供するパートナーに役立ちます。既存の aws-apn-id キーは引き続き機能し、タグ付けされたリソースに追加の変更は必要ありません。 リソースタグ付けのマルチパートナーサポートは、現在、すべての商用 AWS リージョンでご利用いただけます。既存の aws-apn-id キーによる収益と新しいキーによる収益は、いずれも属性収益ダッシュボードの「リソースタグ付け」メソッドに表示されます。ダッシュボードは変更されません。 詳細については、「パートナー収益測定」製品ページと「リソースタグ付けオンボーディングガイド」を参照してください。

AWS Transfer Family now automatically approves SFTP connector quota increases up to 1,000

AWS Transfer Familyは、SFTPコネクタクォータを各AWSリージョンでAWSアカウントあたり最大1,000コネクタまで増やすリクエストを自動的に承認するようになりました。手動による承認を待たずに、ファイル転送のニーズが増えたときにコネクタをさらに追加できます。\nデフォルトクォータは、各 AWS リージョンの AWS アカウントあたり 100 SFTP コネクタのままであり、引き続き AWS サービスクォータコンソールで増加をリクエストしてください。以前は、クォータを増やすにはすべて手動による承認が必要でした。自動承認は、サービスマネージド型または Amazon VPC Lattice Egress を使用するコネクタに適用されます。1,000 個を超えるコネクタが必要な場合は、サービスクォータコンソールでより高いクォータリクエストを送信してください。 この機能は、Transfer Family SFTP コネクタが提供されているすべての AWS リージョンで利用できます。詳細については、AWS Transfer Family SFTP コネクタのドキュメントをご覧ください。

AWS accounts now support phone number verification

AWS アカウントでは、主要連絡先電話番号の電話番号検証がサポートされるようになりました。以前は、AWS アカウントの連絡先情報に含まれる電話番号の形式は検証されていましたが、帯域外メカニズムによる検証は行われていませんでした。これで、お客様は SMS ワンタイムパスコード (OTP) を使用して電話番号を確認できるようになりました。\n電話番号を検証するには、お客様は AWS マネジメントコンソールを使用するか、6 桁の OTP を送信する新しい SendPhoneNumberVerification API を使用してプログラムで認証を開始します。コードを入力すると、VerifyPhoneNumber API によって検証され、確認済みのステータスが維持されます。PutContactInformation API を使用して電話番号を変更すると、お客様は確認を再度完了するように求められます。GetContactInformation API が確認ステータスを公開するようになり、どの電話番号が確認されたかを顧客が確認できるようになりました。 AWS Organizations のお客様の場合、電話番号の検証は管理アカウントからの継承をサポートします。認証済みの電話番号を管理アカウントからメンバーアカウントに適用した場合、番号が管理アカウントと一致すれば、そのメンバーアカウントは確認済みステータスを継承するため、何千ものアカウントで同じ番号を確認する必要がなくなります。メンバーアカウントが独自に電話番号を変更した場合は、別途認証を行う必要があります。 この機能はすべての AWS 商業地域で使用できます。電話番号認証の詳細については、AWS アカウント管理のドキュメントをご覧ください。

AWS IAM Identity Center Identity Store APIs now accept resource ARNs in addition to resource IDs

AWS IAM アイデンティティセンターのアイデンティティストア API は、API が以前にリソース ID を受け入れた場所ならどこでも、ユーザー、グループ、グループメンバーシップ、または ID ストアの Amazon リソースネーム (ARN) を受け入れるようになりました。ARN サポートは追加的であり、既存の統合は変更されずに引き続き機能します。\nアイデンティティストア API に基づいて構築する場合、IAM ポリシー評価、CloudTrail イベント、クロスサービス統合などのリソース ARN をすでに保持している場合があります。以前は、アイデンティティストア API を呼び出す前に ARN をリソース ID まで絞り込む必要がありました。この変更により、どちらのフォームも直接渡せるようになったため、アプリケーションコードが簡略化され、潜在的な解析エラーがなくなります。 この変更は Identity Store API サーフェスのすべてのリクエスト識別子フィールドに適用されます。レスポンスは以前と同様にリソース ID を返し続けます。ARN の形式が正しくない場合やリソースタイプが間違っていると、ValidationException が返されます。 この機能は、AWS IAM Identity Center が提供されているすべての AWS リージョンで、追加料金なしで利用できます。詳細については、「アイデンティティストア API リファレンス」を参照してください。

AWS Marketplace launches an AI agent skill for usage-based metering integration

AWS は、AWS Marketplace メータリングエージェントスキルの一般提供を発表しました。このスキルは、販売者が AI コーディングアシスタント内から使用量ベースの (従量課金制の) SaaS メータリング統合を構築、デプロイ、検証するのに役立つ AI ガイド付きエクスペリエンスです。このスキルは、製品タイプ、価格モデル、使用ディメンションの収集、適切なメータリング API の推奨、設定に合わせた統合コードとカスタマイズされた AWS CloudFormation スタックの生成、製品コードが出荷される前に AWS Marketplace に対してエンドツーエンドのテストを実施するなど、完全な統合プロセスを販売者に案内します。\nこれまで、メータリングを統合している販売者は、ドキュメンテーションやワークショップ、試行錯誤を繰り返すAPIコールをナビゲートしていましたが、ディメンション名の不一致やタイムスタンプの無効などのよくある間違いにより、数日後に請求ギャップが発生していました。メータリングエージェントスキルは、ディメンションを販売者の実際の製品構成と照合し、組み込みのガードレールを適用し、サーバーレスメータリングパイプラインをデプロイし (サブスクリプションイベントにはResolveCustomer API、BatchMeterUsage API、Amazon EventBridgeを使用)、ライブテストで統合を検証します。また、同時契約もサポートしており、既存の出品者がメータリング記録を検査、デバッグ、分析するのに役立ちます。 このスキルは、Amazon Q Developer、Kiro、その他の MCP 互換クライアントなど、MCP をサポートするすべての AI コーディングアシスタントで AWS MCP サーバーから利用でき、プラグインをインストールする必要はありません。 開始するには、「SaaS サブスクリプションで使用するためのメータリングの設定」を参照してください。

Amazon S3 Tables now support all Apache Iceberg V3 data types

Amazon S3 テーブルでは、Apache Iceberg バージョン 3 (V3) 仕様で定義されている列のデフォルト値とともに、ジオメトリ、地理、不明、ナノ秒のタイムスタンプデータタイプのサポートが追加されています。地理空間座標とナノ秒精度のイベント時間を、文字列や整数でエンコードする代わりにネイティブに保存できるようになりました。これにより、ストレージの効率とパフォーマンスを向上させながら、データアーキテクチャを簡素化できます。今回の発表により、S3 テーブルは V3 で導入されたすべてのデータ型をサポートするようになり、バリアントデータ型、削除ベクトル、行系統に対する既存のサポートに加えて、V3 で導入されたすべてのデータ型をサポートするようになりました。\nジオメトリ列と地理列にはポイント、ライン、ポリゴンがネイティブに保存されるため、フリートトラッキングやアセットマッピングのワークロードでは、クエリ時に位置に基づいてフィルタリングできます。ナノ秒のタイムスタンプにより、テレメトリや金融ワークロードはイベント時間をソースの精度で記録できます。列のデフォルト値により、既存の行に新しく追加された列にデータが入力され、バックフィルは不要です。S3 テーブルでは、Apache Iceberg テーブルのテーブルメンテナンスと圧縮が自動的に行われるため、V3 データ型を使用するテーブルは、データの規模が拡大してもパフォーマンスとコスト効率が維持されます。 S3 テーブルにおけるこれらのデータ型のサポートは、S3 テーブルが利用できるすべての AWS リージョンで利用できます。詳細については、「Amazon S3 テーブル」、「AWS 上の Apache Iceberg V3」、および「Iceberg テーブルフォーマット仕様バージョン 3 の使用に関する AWS 規範ガイダンス」を参照してください。

AWS Blogs

Amazon Web Services ブログ (日本語)

AWS News Blog

AWS Open Source Blog

AWS Architecture Blog

AWS Contact Center

Containers

AWS Database Blog

AWS DevOps & Developer Productivity Blog

AWS HPC Blog

AWS for Industries

Artificial Intelligence

Networking & Content Delivery

Open Source Project

AWS CLI

AWS CDK