2026/7/14 9:00:00 ~ 2026/7/15 9:00:00 (JST)
最近の発表
AWS Elastic Disaster Recovery now supports Amazon EBS volume initialization rate
AWS Elastic Disaster Recovery (AWS DRS) は Amazon EBS ボリューム初期化レートをサポートするようになりました。これにより、ドリルやリカバリの実行中に、復元されたボリュームがより早くフルパフォーマンスに達するようになりました。DRS がスナップショットから EBS ボリュームを復元する場合、Amazon S3 からのデータロードはバックグラウンドで行われ、まだロードされていないブロックへの I/O は初期化が完了するまで遅くなる可能性があります。この起動により、DRS が管理する EC2 起動テンプレートにボリュームの初期化レートを設定でき、DRS はリカバリ中にボリュームを作成するときに自動的にそれを適用し、予測可能なタイムラインでアプリケーションをフルストレージパフォーマンスに引き上げます。\n これは、リカバリ時間目標を達成するためには高速で一貫したストレージパフォーマンスが極めて重要な、データベースなどの I/O が多いワークロードに特に役立ちます。起動テンプレートで一度レートを設定すると、DRS はサイズ変更やディスク変更のために更新を行ってもそのレートを保存します。特定のリカバリにレートを適用できない場合、DRS はそのレートなしでリカバリを完了するため、リカバリがブロックされることはありません。
EBS ボリューム初期化レートに関する AWS DRS サポートは、EBS ボリューム初期化レートが提供されているすべての AWS リージョンと環境で利用できます。フルスナップショットサイズと指定したレートに基づいて GB 単位で課金されます。詳細については、Amazon EBS 料金表を参照してください。詳細については、AWS Elastic ディザスターリカバリーユーザーガイドを参照してください。
AWS Elastic Disaster Recovery reduces recovery time for AWS-to-AWS workloads
AWS Elastic ディザスターリカバリー (AWS DRS) は、AWS ベースのワークロードをより迅速に復旧できるようになりました。Amazon EC2 上で稼働しているソースサーバーの場合、DRS はこれらのワークロードで不要になった準備ステップをスキップできるようになり、復旧時間をWindowsで最大 65%、Linux で最大 40% 短縮できるようになりました。\n 災害時や訓練時には、1 分一秒が重要です。既に AWS で実行されているワークロードには AWS 互換のドライバと設定が付属しているため、DRS はより少ない手順で起動できるため、アプリケーションをより早く、より自信を持ってオンラインに戻すことができます。ネットワーク、ドライバ、ライセンスは引き続き自動的に適用されるため、復旧は簡単で手間がかかりません。管理は自分で行えます。アカウント全体または個々のサーバーで高速リカバリーを有効にし、ニーズが変わるたびに設定を変更できます。
この機能は、AWS DRS が提供されているすべての AWS リージョンで、追加料金なしで利用できます。詳細については、AWS Elastic ディザスターリカバリーユーザーガイドをご覧ください。
AWS Lambda console provides a one-click setup prompt for coding agents
AWS Lambdaコンソールでは、コーディングエージェント用のワンクリックセットアッププロンプトが提供され、エージェントにAWSサーバーレススキルとサーバーレスモデルコンテキストプロトコル（MCP）サーバーを設定し、最初からサーバーレスのベストプラクティスを組み込んでいます。この設定は、開発者がLambdaの旅を始める場所ならどこでも、Lambdaコンソールで利用できます。Lambdaを使い始めようとしている人、その機能を調べている人、初めての関数を作成した人など。\n 開発者はコーディングエージェントを使用して Lambda 関数を構築、テスト、デプロイしますが、サーバーレス開発用のエージェントをセットアップするには、以前は複数のドキュメントページに移動して適切な設定を見つける必要がありました。ワンクリックのセットアッププロンプトでは、開発者が希望するコーディングエージェントに AWS Serverless スキル (Agent Toolkit for AWS でホストされている) と Serverless MCP サーバーを直接インストールするようにエージェントに指示するプロンプトが表示されるため、このような問題が解消されます。プロンプトは、Claude Code、Kiro、Cursor、GitHub Copilot、Codex、Devin Desktop、OpenCodeのインストールコマンド、AWSサーバーレススキル、3つの特殊なLambdaスキル（MicroVM、マネージドインスタンス、耐久機能）、およびサーバーレスMCPサーバー構成用のインストールコマンドを含むLambdaエージェントセットアップガイドを参照しています。開発者がローカル AWS 認証を設定していない場合、プロンプトには、Signing-in-to-aws スキルを使用して接続するように指示されます。
この機能は、Lambda が利用可能なすべての商用 AWS リージョン (中東 (バーレーン) と中東 (UAE) を除く) と AWS GovCloud (米国) リージョンで利用できます。AWS Lambda コンソールにアクセスして開始するか、Lambda エージェント設定ガイドで詳細を確認してください。
AWS IAM Identity Center achieves FedRAMP Class C Certification
AWS IAM Identity Center は現在、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (北カリフォルニア)、および米国西部 (オレゴン) リージョンの FedRAMP クラス C の対象となっています。IAM Identity Center を使用して、従業員が FedRAMP クラス C コンプライアンスの対象となる AWS アカウントやアプリケーションにアクセスできるようにできるようになりました。\n 連邦リスク承認管理プログラム (FedRAMP) は、クラウド製品とサービスのセキュリティ評価、認証、および継続的な監視に標準的なアプローチを提供する米国政府全体のプログラムです。AWS IAM Identity Center は、AWS アカウントやアプリケーションへの従業員のアクセスを管理するための推奨サービスです。
FedRAMP の詳細については、AWS サービスのコンプライアンスページと AWS コンプライアンスリソースページをご覧ください。IAM Identity Center の詳細については、ユーザーガイドをご覧ください。
Introducing Amazon GuardDuty AI Protection for AWS AI workloads
Amazon GuardDuty が AI プロテクションを提供するようになり、脅威検出が Amazon Bedrock や Amazon SageMaker などの AWS AI サービスにまで拡大されました。組織が AI を急速に採用するにつれて、セキュリティチームは、異常なモデル呼び出し、コストハーベスティング攻撃、即時注入の試みなど、特に AI ワークロードを標的とする脅威を把握できなくなる可能性があります。GuardDuty AI Protection はこれらのワークロードを継続的に監視しているため、セキュリティチームは手動での設定やカスタムツールを使用せずに AI 固有の脅威を検出して対応できます。\n GuardDuty AI Protection は CloudTrail の管理イベントと AWS AI サービスからのデータイベントの両方を分析して、Amazon Bedrock Guardrails との統合による異常な呼び出しパターン、脅威アクターが AI リソースに AI リソースに過剰な GPU 時間とトークンを消費させるコストハーベスティング攻撃、迅速なインジェクションの試みなど、疑わしいアクティビティを特定します。脅威の検出結果は直接 AWS Security Hub に送られるため、チームは AI 資産と脅威を一元的に把握して、優先順位を付けて対応できるようになります。GuardDuty AI Protection は GuardDuty コンソールまたはセキュリティ Hub コンソールでいくつかの手順を実行するだけで有効化でき、AWS Organizations を使用すると組織内のすべてのアカウントで一元的に有効化できます。
GuardDuty AI プロテクションは、GuardDuty のお客様が 30 日間の無料トライアルでご利用いただけます。価格の詳細については、Amazon GuardDuty の料金表ページをご覧ください。詳細については、Amazon GuardDuty ユーザーガイドと Amazon GuardDuty 製品ページを参照してください。サポートされているリージョンの全リストについては、AWS リージョナルサービスリストを参照してください。
Apache Flink 向け Amazon マネージドサービスでは、AI コーディングアシスタントに Flink アプリケーションの構築と運用に関する最新のガイダンスを専門家に提供する AI エージェントスキルが提供されるようになりました。このスキルは、アプリケーションの作成、トラブルシューティング、スケーリング、モニタリング、ネットワーク設定、コスト最適化などの一般的なタスクについて専門家によるガイダンスを提供します。\n 顧客はこれらのスキルを活用して、Flink アプリケーションの正常性とパフォーマンスを維持し、新しいストリーミングアプリケーションの開発を加速し、Flink 2.2 などの Apache Flink の最新バージョンに簡単にアップグレードできます。このスキルは、かつては Apache Flink の専門知識が必要だったタスクを、開発者が自分で完了できるガイド付きの経験に変えます。
Apache Flink 向けマネージドサービスのスキルは、Kiro、Claude Code、Cursor などの既存の AI コーディングエージェントで使用できます。開始するには、AWS CLI を使用して Agent Toolkit for AWS を設定してから、コーディングエージェントに「MSF で新しい Flink アプリケーションを作成する方法を教えてください」などの質問をします。または「使用している Flink アプリケーションが異常です。何が問題なの?」
AWS Security Hub now provides AI inventory for organization-wide visibility of AI assets
本日、AWS は、AWS Security Hub が AI インベントリを提供するようになったことを発表しました。これにより、中央セキュリティチームが AI 資産とそのセキュリティ体制について組織全体で継続的に最新情報を把握できるようになります。組織が AI エージェント、モデル、パイプラインを急速にデプロイするにつれて、セキュリティチームは組織全体にどの AI 資産が存在するかを把握できなくなる可能性があります。AI 資産をアクティブな脅威や構成ミスに結び付ける一元的な可視性がなければ、組織は存在を知らないものを保護することができません。\n Security Hub AI インベントリは、3 つの検出方法により、AWS 環境全体の AI ワークロードを自動的に検出してカタログ化します。マネージド AI サービスの場合、セキュリティハブは Amazon Bedrock、Bedrock AgentCore、Amazon SageMaker の AWS Config リソースをインベントリします。追加の設定は不要です。セルフホスト AI ワークロードの場合、Security Hub は Amazon Inspector のソフトウェア部品表（SBOM）分析を活用します。この分析は、Amazon EC2 インスタンスと Amazon ECR コンテナイメージ（Ollama、vLLM、Hugging Face TGI などのフレームワークを含む）にインストールされている推論エンドポイント、モデル、AI エージェントを識別するように強化されています。また、Security Hub は Amazon GuardDuty DNS テレメトリを利用して、EC2 インスタンスからアクセスされている外部 AI API エンドポイント (サードパーティモデルプロバイダーへの呼び出しなど) を検出し、これまで特定されていなかったサードパーティの AI 依存関係を明らかにします。
発見された AI アセットはそれぞれ基盤となるインフラストラクチャにマッピングされ、Amazon GuardDuty の脅威結果を含む AWS セキュリティスタック全体から得られたセキュリティ調査結果と関連付けられます。チームは、アカウント、リソースタイプ、発見方法、特定のモデル ID ごとに AI インベントリをフィルタリング、グループ化、クエリできるため、どの AI ワークロードが活発に脅威にさらされていて組織的リスクが最も高いかに基づいて修復の優先順位を付けることができます。
AI インベントリは Security Hub Essentials に追加費用なしで含まれており、新たに有効にする必要もありません。セキュリティハブが提供されているすべての AWS 商用リージョンで利用できます。詳細については、AWS セキュリティ Hub ユーザーガイドと AWS セキュリティハブの製品ページを参照してください。
Amazon WorkSpaces Personal simplifies bulk PCoIP to DCV protocol migration
Amazon WorkSpaces Personal では、最近開始されたコンソールベースの移行ワークフローとチェックポイントスナップショットのサポートに基づいて、停止した WorkSpaces の PCoIP から DCV プロトコルへの自動ロールバックとサポートが提供されるようになりました。これらの新機能により、管理者は最小限の手動操作で WorkSpaces を大規模に移行できます。\n Amazon DCV は AWS によって構築された高性能ストリーミングプロトコルで、Amazon WorkSpaces サービスを強化しています。DCV に移行することで、お客様は Windows 11 や Windows Server 2025 などの幅広いオペレーティングシステムサポート、証明書ベースの認証や WebAuthN リダイレクトなどの強化されたセキュリティ機能、およびストリーミングパフォーマンスの向上を利用できるようになります。今回のリリースにより、プロトコルの変更に失敗した場合、WorkSpace は移行前のスナップショットに自動的にロールバックし、手動操作なしで既知の正常な状態に戻ることが保証されます。さらに、管理者は停止した状態で WorkSpace の移行を開始できるようになったため、プロトコルを変更する前に、停止した各 WorkSpace を手動で起動する必要がなくなりました。これにより、お客様は大規模な移行を大幅にスピードアップできます。 これらの機能強化は、Amazon WorkSpaces Personal がサポートされているすべての AWS 商用リージョンと AWS GovCloud (米国) リージョンで利用できます。 開始するには、Amazon WorkSpaces コンソールにサインインしてください。詳細については、Amazon WorkSpaces 管理ガイドの「プロトコルの変更」セクションを参照してください。Amazon WorkSpaces の詳細については、Amazon WorkSpaces 製品ページをご覧ください。
Amazon Aurora DSQL is now available in Europe (Spain)
本日より、Amazon Aurora DSQL はヨーロッパ (スペイン) リージョンの単一リージョンクラスターで利用できるようになりました。Aurora DSQL は最速のサーバーレス分散型 SQL データベースで、アクティブ-アクティブ間の高可用性とマルチリージョンの強固な一貫性を備えています。これにより、事実上無制限のスケーラビリティ、最高の可用性、インフラストラクチャー管理なしで常に利用可能なアプリケーションを構築できるため、アプリケーションのスケーリングとレジリエンスを簡単に実現できます。\n 今回の発表により、Aurora DSQL は米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、カナダ (中部)、カナダ西部 (カルガリー)、南米 (サンパウロ)、ヨーロッパ (フランクフルト)、ヨーロッパ (アイルランド)、ヨーロッパ (ロンドン)、ヨーロッパ (パリ)、ヨーロッパ (スペイン)、ヨーロッパ (ストックホルム)、アジア太平洋 (香港) の AWS リージョンで利用できるようになりました。アジアパシフィック (メルボルン)、アジアパシフィック (ムンバイ)、アジアパシフィック (大阪)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、およびアジアパシフィック (東京)。 AWS 無料利用枠を利用すると、Aurora DSQL を無料で使い始めることができます。詳細については、Aurora DSQL ウェブページとドキュメントをご覧ください。
AWS Storage Gateway adds console support for copying file shares across gateways
AWS Storage Gateway では、ストレージゲートウェイコンソールからゲートウェイ間でファイル共有を直接コピーできるようになりました。コピーを開始すると、コンソールはソース共有の設定を読み取り、互換性のある設定を保存したままターゲットゲートウェイに新しいファイル共有を作成します。\n 以前は、宛先ゲートウェイで各ファイル共有を手動で再作成し、設定の詳細を 1 つずつ再入力する必要がありました。ファイル共有をコピーして、その構成を宛先ゲートウェイに自動的に適用できるようになったため、AL2023 へのアップグレードなどの移行に必要な時間と労力を大幅に削減できます。ガイド付きのエクスペリエンスでは、新しい共有が作成される前に注意が必要な設定がすべて表示されるため、重要な設定を見逃すことなくスムーズに移行できます。
まず、Storage Gateway コンソールでファイル共有に移動し、共有を選択して [Copy to gateway] を選択します。この機能は商用 AWS リージョンで利用できます。リージョンの可用性を確認するには、「AWS 機能」を参照してください。詳細については、AWS Storage Gateway ユーザーガイドをご覧ください。
Amazon CloudFront Functions now supports logging to CloudFront access logs
CloudFront Functions 内から利用できる新しいヘルパーメソッドを使用して、カスタムデータを CloudFront アクセスログに直接書き込めるようになりました。CloudFront Functions は、URL の書き換え、ヘッダーの操作、リクエストのルーティングなどのタスクに対して、軽量な JavaScript をエッジで実行します。以前は、ログデータを CloudFront アクセスログとは別のログファイルとして Amazon CloudWatch Logs に送信することしかできませんでした。今回のローンチにより、機能の決定を別々のロギングシステムの CloudFront アクセスログデータと関連付ける必要がなくなりました。\n ビューワーリクエストまたはビューワーレスポンス関数から cf.logCustomData () を呼び出して、A/B テストバリアントの割り当て、認証結果、ルーティング決定などの値をそのリクエストの CloudFront アクセスログレコードに直接記録できます。これは CloudFront リアルタイムログ設定と標準ロギング (v2) の両方に対応しているため、関数の動作とリクエストの結果を 1 つのクエリで分析できます。既存の console.log () 機能は引き続き使用可能で、2 つの方法を同じ関数で一緒に使用できます。
Amazon CloudFront Functions のカスタムログデータは、現在、すべての CloudFront エッジロケーションで利用可能です。cf.logCustomData () を使用しても追加料金はありません。標準の CloudFront 関数呼び出し料金とアクセスログ配信料金が適用されます。開始するには、CloudFront Functions ヘルパーメソッドをご覧ください。
AWS Blogs
Amazon Web Services ブログ (日本語)
- AWS SimuLearn に学習プランとデジタルバッジが追加されました
- ハイテクインターが Amazon Rekognition と Graviton プロセッサで実現した富山市の人流観測プラットフォーム
- 株式会社村田製作所様の AWS 生成 AI 活用事例 : 3 万人利用の「Murata Coworker」を AI エージェント活用基盤へ進化させるまで
- Kiro のバースデーウィークへようこそ
AWS Startup ブログ (日本語)
AWS Architecture Blog
AWS Cloud Operations Blog
AWS Big Data Blog
AWS Compute Blog
AWS Database Blog
AWS DevOps & Developer Productivity Blog
Artificial Intelligence
- ストランド・エージェントと Amazon Bedrock によるマルチエージェント・ソーシャル・インテリジェンス
- Amazon Nova Act を使用したエージェント QA 自動化によるソフトウェア配信の促進 — パート 2
- Amazon Nova Act による UX テストのスケーリング:ユーザーフロー分析への新しいアプローチ
- Amazon Bedrockによるフローヘルスの医療コンテンツレビューのスケーリング—パート2
- AWS 上に構築された ScienceSoft の HIPAA 準拠の AI 音声スケジューラー