2026/11/2 9:00:00 ~ 2026/11/3 9:00:00 (JST)

最近の発表

Haiku 5.5 now available on Kiro in AWS GovCloud (US)

新しい Anthropic モデルが AWS GovCloud (米国) リージョンの Kiro IDE と CLI で利用できるようになりました。Haiku 5.5 では、クロード 5.5 の 3 つのモデルすべてが AWS GovCloud (米国) の Kiro で利用できるようになりました。\n クロード・ハイク 5.5 はクロード 5.5 ファミリーの中で最速のモデルです。これはClaude Haiku 4.5から明らかにステップアップしたもので、大量に実行され、迅速な対応が必要な作業向けに構築されています。開発者はこれを使用して、長いコンテキストの要約と圧縮、リクエストの分類と転送、テキストの一括処理、多数のファイルにわたる小規模で的を絞った編集を行うことができます。Opus 5.5 と Sonnet 5.5 が面倒な計画やコーディング作業を引き受けるのに対し、並行して動作するレビューサブエージェントとしてもうまく機能します。Haiku 5.5 では、デフォルトは「中」で、「低」から「最大」まで 5 つのレベルにわたって適応的思考を採用しています。1 M のコンテキストウィンドウと 0.06 倍のクレジットマルチプライヤーが用意されています。10万トークンを超えるリクエストには、0.3倍の倍率で請求されます。

IDE または CLI が最新バージョンに更新されていることを確認してから再起動し、モデルセレクターから新しいモデルにアクセスします。詳細については、GovCloud ドキュメント、モニタリングおよび追跡ガイドを参照するか、AWS アカウントチームにお問い合わせください。Kiro の詳細については、Kiro 製品ページをご覧ください。

Amazon RDS now supports per snapshot billing

本日より、Amazon RDS は Amazon RDS スナップショットのスナップショット単位の請求をサポートします。スナップショット単位の請求では、個々のスナップショットのコストを把握できます。\n 以前は、RDS スナップショットの料金は Cost and Usage レポートと Cost Explorer でデータベースインスタンスレベルで集計されていました。つまり、スナップショットの料金を理解している間は、個々のスナップショットまでドリルダウンする代わりに、データベースインスタンスの集計ビューしか表示できませんでした。これで、スナップショットにコスト配分タグを使用して各スナップショットのコストを正確に把握できるようになり、バックアップの費用と予算をよりよく把握できるようになりました。スナップショット単位の課金はすべての RDS スナップショットでデフォルトで有効になっており、追加料金はありません。

スナップショット単位の請求は、すべての商用 AWS リージョンと AWS GovCloud (米国) リージョンのすべての Amazon RDS エンジンで利用できます。詳細については、当社のドキュメントをご覧ください。

Amazon Quick on desktop now uses your organization’s existing Amazon Quick sign-in

Amazon Quick を使用する組織では、デスクトップアプリケーションが、組織がウェブ上の Quick で既に使用しているのと同じサインイン方法でユーザーをログインさせるようになりました。ユーザーが作業を開始する前に、管理者は ID プロバイダーに OIDC アプリケーションを登録したり、別のデスクトップサインインを設定したりする必要がなくなりました。Web 上の Quick にサインインできるユーザーは、デスクトップアプリケーションにサインインできます。\n デスクトップアクセスを有効にするには、管理者が Amazon Quick コンソールにデスクトップコネクタを一度追加します。次に、ユーザーはクイックアカウント名を入力して [サインイン] を選択し、ブラウザからサインインを完了します。これは IAM アイデンティティセンター、IAM フェデレーション、またはネイティブの Amazon Quick ユーザーを使用するアカウントで機能します。組織がデスクトップサインインを個別に管理したい場合でも、Microsoft Entra ID、Google Workspace、Okta、Ping Identity などのプロバイダーを使用して専用の ID プロバイダー構成を設定できます。

デスクトップ版 Amazon Quick は、Amazon Quick の全機能セットをサポートする AWS リージョンでご利用いただけます。

開始するには、Amazon クイックユーザーガイドの「デスクトップ版 Amazon Quick」を参照してください。

Amazon Aurora MySQL 3.14 (compatible with MySQL 8.0.46) is generally available

本日より、Amazon Aurora MySQL 互換エディション 3 (MySQL 8.0 に対応) は MySQL 8.0.46 をサポートします。これには MySQL コミュニティの修正と Aurora 固有の改善が含まれています。Aurora MySQL 3.14 では、運用上の改善に加えて、ポスト量子型 TLS (PQ-TLS) キー交換のサポートが導入され、転送中のデータを暗号化するためのポスト量子暗号オプションが提供されています。このリリースの詳細については、Aurora MySQL 3 と MySQL 8.0.46 のリリースノートを参照してください。\n マイナーバージョン自動アップグレードを使用して、定期メンテナンス期間中にデータベースをアップグレードできます。大規模な運用を簡素化するには、マイナーバージョンの自動アップグレードを有効にし、AWS Organizations Upgrade Rollout Policy を使用してクラスター全体のアップグレードを段階的に調整してください。マイナーバージョンアップグレードは、インプレースで実行することも、スナップショット復元を使用して実行することもできます。このリリースは、Aurora MySQL が利用可能なすべての AWS リージョンでサポートされています。

Amazon Aurora は MySQL との完全な互換性を保ちながら、世界規模で高いパフォーマンスと可用性を実現するように設計されています。ゼロまでスケールできるサーバーレスコンピューティング、マルチリージョンの耐障害性を実現する Aurora Global Database、I/O を多用するワークロードでコストパフォーマンスを向上させるための Aurora I/O 最適化機能、組み込みセキュリティと継続的バックアップを提供します。始めるには、Aurora の入門ページをご覧ください。

Amazon Aurora MySQL 8.4.10 is now generally available

本日より、Amazon Aurora MySQL 互換エディション 8.4 は MySQL 8.4.10 をサポートします。MySQL の以前のバージョンにあった一般的な脆弱性と暴露 (CVE) の修正を受け入れ、MySQL コミュニティによって追加されたバグ修正、パフォーマンスの向上、新機能の恩恵を受けるには、新しいマイナーバージョンにアップグレードすることをお勧めします。詳細については、Aurora MySQL 8.4 と MySQL 8.4.10 のリリースノートを参照してください。\n Aurora MySQL 8.4.10 では、グローバルトランザクション識別子 (GTID) タグのサポートが追加されました。これにより、ユーザー定義のタグを GTID に割り当てて、バイナリログレプリケーションで関連するトランザクションを識別してグループ化しやすくなります。また、このリリースでは、DB インスタンスあたり最大 50,000 の同時接続がサポートされるようになりました。これにより、接続プールレイヤーを追加しなくても接続量の多いアプリケーションを拡張できます。最大接続数のベストプラクティスについて詳しくは、Amazon Aurora MySQL ユーザーガイドをご覧ください。

マイナーバージョン自動アップグレードを使用して、スケジュールされたメンテナンス期間中にデータベースをアップグレードできます。大規模な運用を簡素化するには、マイナーバージョンの自動アップグレードを有効にし、AWS Organizations Upgrade Rollout Policy を使用してクラスター全体のアップグレードを段階的に調整し、最も重要な環境をアップグレードする前に優先度の低い環境で検証します。マイナーバージョンアップグレードは、インプレースで実行することも、スナップショット復元を使用して実行することもできます。バージョンアップグレードの実行について詳しくは、Amazon Aurora ユーザーガイドをご覧ください。このリリースは、Aurora MySQL が利用可能なすべての AWS リージョンでサポートされています。

Amazon Aurora は MySQL との完全な互換性を保ちながら、世界規模で高いパフォーマンスと可用性を実現するように設計されています。ゼロまでスケールできるサーバーレスコンピューティング、マルチリージョンの耐障害性を実現する Aurora Global Database、I/O を多用するワークロードでコストパフォーマンスを向上させるための Aurora I/O 最適化機能、組み込みセキュリティと継続的バックアップを提供します。始めるには、Aurora の入門ページをご覧ください。

AWS Lambda now supports queues for Apache Kafka in self-managed Kafka event sources

AWS Lambda は、セルフマネージド Kafka イベントソースマッピング (ESM) の Apache Kafka のキュー、顧客が自分で実行する Kafka クラスター、および Confluent Cloud などのマネージドサービスのキューをサポートするようになりました。お客様は Kafka ワークロードの処理をトピックのパーティション数を超えてスケーリングできるようになりました。これにより、トラフィックが急増したときのスループットが向上し、処理の回復力が向上します。\n 画像や動画のエンコーディング、不正検知、通知配信、テレメトリの取り込みなどのユースケース向けにイベント駆動型の Kafka ワークロードを構築しているお客様は、各イベントを独立した作業単位として扱います。この場合、厳密な順序付けよりも処理速度が重要になります。以前は、Kafka ESM は Kafka コンシューマー・グループ・プロトコルを使用しており、各パーティションはコンシューマー・グループ内の 1 人のコンシューマーにのみ割り当てられていました。より高度な並列処理を必要とするお客様は、トピックを過剰に分割するか、トラフィックを別のキューシステムに移動して、運用するインフラストラクチャと保守するプロデューサーコードを追加する必要がありました。セルフマネージド Kafka ESM のキューサポートは、Apache Kafka 4.2 で一般的に利用可能な Kafka 共有グループに基づいて構築されています。今回のローンチにより、複数のイベントポーラーが同じパーティションから同時に使用できるようになり、各イベントポーラーは最大 10 件の同時呼び出しをサポートするようになりました。これにより、プロデューサー、トピック構成、または関数コードを変更しなくても、並列処理をパーティション数から切り離すことができます。その結果、遅いイベントや失敗したイベントが同じパーティション内の他のイベントを妨げることがなくなるため、トラフィックが急増したときのスループットが向上し、処理の回復力が高まります。キューモードはパーティションの順序を維持せず、順序を必要としないワークロードを対象としています。

この機能には、Apache Kafka 4.2 以降などの共有グループが有効になっている Kafka クラスターが必要で、セルフマネージド Kafka ESM が利用できるすべての AWS 商用リージョンで利用できます。まず、コンシューミングモードを AWS マネジメントコンソール、Lambda API、AWS CLI、AWS CloudFormation、AWS SAM、または AWS CDK を介してキューに設定したセルフマネージド型 Kafka ESM を作成します。標準の Lambda 料金が適用されます。セルフマネージド型 Kafka ESM にプロビジョニングモードを設定したお客様には、イベントポーラーユニット (EPU) の使用料も支払われます。詳細については、AWS Lambda 開発者ガイドと AWS Lambda の料金表を参照してください。

Amazon Connect Customer now supports Model Context Protocol (MCP) tools in flows

Amazon Connect Customer では、新しい「外部ツール」ブロックを使用して、カスタマーエクスペリエンスフローでモデルコンテキストプロトコル (MCP) ツールを呼び出すことができるようになりました。今回のリリースにより、Amazon Bedrock AgentCore Gateway を介してフローをサードパーティアプリケーションに接続し、カスタム Lambda 関数を記述しなくても、エージェントエクスペリエンスで使用していたのと同じツールを再利用してデータを取得したりアクションをトリガーしたりできます。たとえば、顧客が最近の取引について金融機関に問い合わせた場合、フローは外部ツールブロックを使用して、CRMシステムからのケース履歴や銀行プラットフォームからの取引詳細など、サードパーティアプリケーションから関連するコンテキストを取得できます。\n この機能は、米国東部 (バージニア北部)、米国西部 (オレゴン)、カナダ (中部)、ヨーロッパ (フランクフルト)、ヨーロッパ (ロンドン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京) の AWS リージョンで利用できます。この機能の詳細については、管理者ガイドを参照してください。企業が優れたカスタマーエクスペリエンスを提供するのに役立つエージェント AI ソリューションである Amazon Connect Customer の詳細については、Amazon Connect カスタマーウェブサイトをご覧ください。

Amazon Connect Customer now supports Cases and External Tool events in the Wait block

Amazon Connect Customer では、待機ブロックでケースイベントと外部ツールイベントがサポートされるようになり、カスタマーエクスペリエンスフローがリアルタイムのデータ変更にどのように反応するかをより細かく制御できるようになりました。Lambda 関数が完了するのを待つだけでなく、Connect Case フィールドが指定された条件を満たすか、外部ツールの呼び出しが完了するまで待つこともできるようになりました。これにより、重要な情報が出るまで待ってからインタラクションを進めることができるため、不要な転送が減り、エンドカスタマーとエージェントの両方の時間を節約できます。たとえば、ケースの返金状況フィールドが更新されるまでフローを保留し、その結果に基づいてインタラクションを自動的に再開してルーティングすることができます。 \n この機能の詳細については、管理者ガイドおよび Connect Customer 機能の地域別の利用可否を参照してください。企業が優れたカスタマーエクスペリエンスを提供するのに役立つエージェント AI ソリューションである Amazon Connect Customer の詳細については、Amazon Connect カスタマーウェブサイトをご覧ください。

EC2 Amazon Machine Images can now be scanned for vulnerabilities through Amazon Inspector

Amazon Inspector の脆弱性スキャンが EC2 Amazon マシンイメージ (AMI) にまで拡張され、インスタンスを起動したり、追加のソフトウェアをインストールしたりしなくても、AMI のソフトウェアの脆弱性を特定できるようになりました。これにより、AMI を使用して複数のインスタンスを起動する前に、問題を発生源で修正できます。\n この機能により、継続的に評価を行って AMI カタログに新たに発見された脆弱性がないか監視したり、特定の AMI を対象とした 1 回限りのスキャンを EC2 コンソールから直接実行したりできます。Amazon Inspector では、1 つのアカウントまたは組織全体で AMI スキャンを有効にできます。AWS Security Hub のお客様は、AMI スキャンをアドオンとして組織全体で有効にすることができ、結果はセキュリティハブにも配信されます。スキャン結果に基づいて、Allowed AMIs 設定を有効にし、AMI がアカウント内で利用できるようにするために満たす必要があるセキュリティ基準を指定し、宣言型ポリシーを使用してこの設定を組織全体に適用できます。EC2 Image Builder で AMI を構築しているお客様は、スキャンをパイプラインに直接統合し、自社のセキュリティ基準を満たしていない AMI の配布を制限できます。

AMI Scanning は、デプロイパイプラインの早い段階で脆弱性を検出して修正するのに役立ち、侵害されたコンピューティングリソースをデプロイするリスクを軽減します。セキュリティチームは、インスタンスを起動する前に、すべての AMI で一貫した脆弱性スキャンプロセスを確立して、セキュリティ体制を改善できるようになりました。

この機能は、Amazon Inspector が利用できるすべての商用 AWS リージョンで利用できます。詳細については、Amazon Inspector ユーザーガイド、Amazon Inspector 料金ページ、および Amazon Inspector 製品ページを参照してください。

Amazon CloudFront now supports self-service increases in AWS Service Quotas

Amazon CloudFront が AWS サービスクォータをサポートするようになったため、サービスクォータコンソールまたは API から 28 個の CloudFront クォータを表示、監視、および増加をリクエストできます。\n これまで、ディストリビューション、キャッシュポリシー、オリジン、代替ドメイン名などのリソースのクォータを増やすには、サポートケースを開いて手動による確認を待つ必要がありました。AWS ビジネスサポート以上の契約を結んでいる場合は、公開されているしきい値内での制限引き上げのリクエストが自動的に承認されるようになりました。たとえば、サポートケースを開かなくても、ディストリビューションクォータを 500 から 1,000 に、ディストリビューションあたりの代替ドメイン名の数を 100 から 500 に増やすことができます。クォータの中には、5 分ごとに使用状況メトリクスを公開するものもあるため、制限に達する前にアラームを設定して増加をリクエストできます。

この機能は、Amazon CloudFront がサポートされているすべての AWS リージョンで利用できます。

開始するには、サービスクォータコンソールにアクセスして CloudFront クォータを確認して増加をリクエストしてください。詳細については、『Amazon CloudFront 開発者ガイド』の「Amazon CloudFront クォータ」を参照してください。

AWS Blogs

Amazon Web Services ブログ (日本語)

AWS News Blog

AWS Architecture Blog

AWS Cloud Operations Blog

AWS Big Data Blog

AWS Compute Blog

AWS Database Blog

Artificial Intelligence

AWS Security Blog

Open Source Project

Bottlerocket OS