2025/5/19 9:00:00 ~ 2025/5/20 9:00:00 (JST)

最近の発表

Announcing Amazon Bedrock Agents Metrics in CloudWatch

Amazon Bedrock では、エージェント向けの包括的な CloudWatch メトリクスのサポートが提供されるようになりました。これにより、開発者はエージェントベースのアプリケーションのモニタリング、トラブルシューティング、最適化をより可視化して行えるようになりました。この新機能により、呼び出し回数、レイテンシー測定、トークンの使用量、エラー率など、InvokeAgent と InvokeInlineAgent の両方のオペレーションに関する詳細なランタイムメトリクスが得られるため、お客様は実稼働環境におけるエージェントのパフォーマンスをよりよく理解できます。\n CloudWatch メトリクスの統合により、開発者はオペレーションタイプ、モデル ID、エージェントエイリアス ARN などのさまざまなディメンションにわたって、合計処理時間、最初のトークンまでの時間 (TTFT)、モデルレイテンシー、トークン数などの重要なパフォーマンス指標を追跡できます。これらのメトリクスにより、お客様はボトルネックを特定し、異常を検出し、データ主導の意思決定を行って、エージェントの効率と信頼性を向上させることができます。また、お客様は CloudWatch アラームを設定して、メトリックスが指定されたしきい値を超えたときに通知を受け取るように設定できるため、エージェントのデプロイをプロアクティブに管理できます。

Amazon Bedrock エージェントの CloudWatch メトリクスは、Amazon Bedrock がサポートされているすべての AWS リージョンで利用できるようになりました。エージェントのモニタリングを開始するには、IAM サービスロールに適切な CloudWatch 権限があることを確認してください。この機能と実装の詳細については、Amazon Bedrock のドキュメントを参照するか、包括的なモニタリングのベストプラクティスについては CloudWatch ユーザーガイドを参照してください。

AWS CodeBuild adds support for new IAM condition keys

AWS CodeBuild が新しい IAM 条件キーをサポートするようになりました。これにより、CodeBuild のリソース変更 API に対するきめ細かなアクセスコントロールが可能になります。新しい条件キーは、ネットワーク設定、認証情報の設定、コンピューティング制限など、CodeBuild の API リクエストコンテキストのほとんどに対応します。AWS CodeBuild は、ソースコードのコンパイル、テストの実行、デプロイ準備が整ったソフトウェアパッケージの作成を行う、完全マネージド型の継続的インテグレーションサービスです。\n 新しい条件キーを使用すると、プロジェクトやフリートなどの CodeBuild リソースに組織のポリシーをより効果的に適用できる IAM ポリシーを作成できます。たとえば、CodeBuild: VPCConfig.vpcid 条件キーを使用してプロジェクトまたはフリートに VPC 接続設定を強制したり、codebuild: source.buildspec 条件キーを使用してプロジェクトの buildspec コマンドが不正に変更されないようにしたり、CodeBuild: computeConfiguration.InstanceType 条件キーを使用してビルドで使用できるコンピューティングタイプを制限したりできます。 新しい IAM 条件キーは、CodeBuild が提供されているすべてのリージョンで使用できます。CodeBuild が利用可能な AWS リージョンの詳細については、AWS リージョンのページを参照してください。 新しい CodeBuild IAM 条件キーの一覧については、当社のドキュメントをご覧ください。CodeBuild の使用を開始する方法の詳細については、AWS CodeBuild 製品ページを参照してください。

DynamoDB local is now accessible on AWS CloudShell

本日、Amazon DynamoDB は AWS CloudShell での DynamoDB ローカルの一般提供を発表しました。これは、AWS マネジメントコンソールから直接起動できるブラウザベースの事前認証済みシェルです。DynamoDB ローカルでは、コストをかけずにローカルの開発環境で DynamoDB を実行してアプリケーションを開発およびテストできます。\n DynamoDB ローカルは、本番環境に影響を与えることなく既存の DynamoDB API 呼び出しと連携します。CloudShell の dynamodb ローカルエイリアスを使用するだけで DynamoDB をローカルで起動し、AWS CLI や DynamoDB ローカルをダウンロードまたはインストールしなくても、コンソールのどこでも DynamoDB テーブルを開発およびテストできるようになりました。CLI コマンドを使用して CloudShell で実行されている DynamoDB ローカルを操作するには、–endpoint-url パラメーターを使用して localhost: 8000 を指定してください。 AWS マネジメントコンソールから CloudShell に移動する方法はいくつかあります。詳細については、「AWS CloudShell の使用を開始する」を参照してください。DynamoDB ローカルコマンドラインオプションの使用方法の詳細については、「DynamoDB ローカル使用上の注意」を参照してください。

AWS CloudWatch Synthetics adds safe canary updates and automatic retries

CloudWatch Syntheticsは本日、カスタムコードスクリプトを定期的に実行することでウェブサイト上の顧客のワークフローを監視できるようになり、カナリアセーフアップデートと障害が発生したカナリアの自動再試行という2つの新機能を発表しました。前者では変更を適用する前に既存のカナリアの更新をテストでき、後者ではスケジュールされた実行が失敗した場合に Canary が自動的に追加の再試行を試みることができるため、本物の障害と断続的な障害を区別しやすくなります。\n Canary Safe Updatesは、誤った更新による監視の中断を最小限に抑えるのに役立ちます。ドライランを行うことで、新しくリリースされたランタイムや、設定やコードの変更との Canary の互換性を検証できます。更新プロセス中も継続的に監視を行うことで、潜在的な監視ギャップを最小限に抑え、Canary を最新の状態に保つプロセスにおけるエンドユーザーエクスペリエンスへのリスクを軽減します。自動再試行機能は誤報を減らすのに役立ちます。有効にすると、持続的な問題と断続的な障害を区別して不必要な中断を防ぐことができるため、より信頼性の高い監視結果が得られます。ユーザーは、カナリアランニンググラフを使用して一時的な障害を分析できます。このグラフでは、予定されているランニングとその再試行回数が色分けされて示されます。これらの機能の使用を開始するには、AWS マネジメントコンソール、AWS CLI、または CloudFormation から CloudWatch Synthetics にアクセスしてください。 安全なカナリア更新と自動再試行のドライランは、通常のカナリアランと同じ価格で、すべての商用 AWS リージョンで利用できます。 安全なカナリアアップデートと自動再試行の詳細については、リンク先の Amazon CloudWatch Synthetics ドキュメントを参照してください。または、ユーザーガイドにアクセスして Synthetics モニタリングを開始してください。

Amazon MSK adds support for Apache Kafka version 4.0

Apache Kafka 向け Amazon マネージドストリーミング (Amazon MSK) は Apache Kafka バージョン 4.0 をサポートするようになり、クラスター管理とパフォーマンスにおける最新の進歩が MSK Provisioned にもたらされました。Kafka 4.0 では、グループリバランスをよりスムーズかつ迅速に行えるようにする、新しいコンシューマーリバランスプロトコルが導入され、一般公開されました。さらに、Kafka 4.0 ではブローカーとツールに Java 17 の使用が義務付けられているため、セキュリティとパフォーマンスが向上し、さまざまなバグの修正と改善が行われ、Apache ZooKeeper によるメタデータ管理が廃止されました。\n Amazon MSK で Apache Kafka 4.0 を使い始めるには、AWS マネジメントコンソール、AWS CLI、または AWS SDK を使用して新しいクラスターを作成するときに、バージョン 4.0.x を選択するだけです。インプレースローリングアップデートを使用して、既存の MSK プロビジョニングクラスターをアップグレードすることもできます。Amazon MSK はブローカーの再起動を調整して可用性を維持し、アップグレード中もデータを保護します。Kafka バージョン 4.0 のサポートは、現在 Amazon MSK が提供されているすべての AWS リージョンでご利用いただけます。詳細については、Amazon MSK 開発者ガイドとバージョン 4.0 の Apache Kafka リリースノートを参照してください。

Amazon MSK is now available in Asia Pacific (Thailand) and Mexico (Central) Regions

Apache Kafka (Amazon MSK) 向け Amazon マネージドストリーミングが、アジアパシフィック (タイ) およびメキシコ (中部) リージョンで利用できるようになりました。お客様は、本日より、これらのリージョンで Amazon MSK プロビジョニングクラスターを作成できます。\n Amazon MSK は Apache Kafka と Kafka Connect 向けのフルマネージド型サービスです。これにより、Apache Kafka をデータストアとして使用するアプリケーションの構築と実行が容易になります。Amazon MSK は Apache Kafka と完全な互換性があるため、既存の Apache Kafka ワークロードをより迅速に Amazon MSK に移行したり、新しいワークロードをゼロから構築したりすることができます。Amazon MSK を使用すると、Kafka クラスターの管理にかかる時間を減らして、革新的なストリーミングアプリケーションの構築により多くの時間を費やすことができます。 Amazon MSK が利用できるすべてのリージョンについては、AWS リージョンのページをご覧ください。開始するには、Amazon MSK 開発者ガイドを参照してください。

Amazon Bedrock Data Automation now supports generating custom insights from videos

Amazon Bedrock Data Automation (BDA) がビデオ設計図をサポートするようになったため、マルチメディア分析アプリケーションに合わせた正確なインサイトを一貫した形式で生成できます。BDA は、Genai を利用したアプリケーション向けに、ドキュメント、画像、音声、動画などの非構造化マルチモーダルコンテンツからのインサイトの生成を自動化します。ビデオブループリントでは、生成する内容、出力データタイプ、生成の指針となる自然言語命令を指定することで、シーンの要約、コンテンツタグ、オブジェクト検出などのインサイトをカスタマイズできます。\n 新しいビデオブループリントを数分で作成することも、メディア検索やハイライト生成などのユースケース向けに設計された構築済みのブループリントのカタログから選択することもできます。ブループリントを使用すると、映画、テレビ番組、広告、会議の録画、ユーザー生成ビデオなど、さまざまなビデオメディアから洞察を得ることができます。たとえば、リアリティ番組のエピソードを分析してコンテキスト広告の配置を検討している顧客は、設計図を使用して、競技者が料理をしているシーンをまとめたり、「トマト」や「スパゲッティ」などのオブジェクトを検出したり、料理に使われる調味料のロゴを特定したりできます。リリースの一環として、BDAは標準出力におけるロゴ検出とインタラクティブ広告局（IAB）の分類法も強化しました。 ビデオ設計図は、Amazon Bedrock データオートメーションがサポートされているすべての AWS リージョンで利用できます。 詳細については、Bedrock データオートメーションユーザーガイドと Amazon Bedrock 料金表ページを参照してください。ビデオブループリントの使用を開始するには、Amazon Bedrock コンソールにアクセスしてください。

Amazon Inspector enhances container security by mapping ECR images to running containers

Amazon Inspector は、Amazon Elastic Container Registry (Amazon ECR) イメージを Amazon Elastic Container Service (Amazon ECS) で実行されている特定のタスクまたは Amazon Elastic Kubernetes サービス (Amazon EKS) で実行されているポッドに自動的にマッピングするようになりました。これにより、イメージがアクティブに使用されている場所を特定しやすくなります。これにより、限られたリソースを、実行中のワークロードに関連する最も重要で脆弱なイメージへのパッチの適用、セキュリティの向上、および平均修復時間の向上に集中させることができます。\n 今回の発表により、Amazon Inspector コンソールまたは API を使用して、アクティブに使用されているコンテナイメージ、最後にイメージを使用した日時、そのイメージを実行しているクラスターを特定できます。この情報は調査結果とリソースカバレッジの詳細に含まれ、EventBridge に転送されます。また、コンソールまたは API を使用して ECR 再スキャン時間を更新することで、「最終使用」日以降の Inspector による画像の監視期間を制御することもできます。これは、既存のプッシュ日とプル日の設定に加えてのものです。Amazon Inspector で連続スキャンが有効になっている Amazon ECR イメージでは、この更新されたデータが Amazon Inspector の結果に自動的に含まれます。

Amazon Inspector は、Amazon EC2 インスタンス、コンテナイメージ、AWS Lambda 関数などの AWS ワークロードを継続的にスキャンして、AWS 組織全体でソフトウェアの脆弱性、コードの脆弱性、意図しないネットワークへの露出がないかを調べる脆弱性管理サービスです。 この機能は、Amazon Elastic Container レジストリ (ECR) でコンテナイメージをスキャンする Amazon Inspector のお客様には追加費用なしでご利用いただけます。この機能は、Amazon Inspector が利用できるすべての商用リージョンと AWS GovCloud (米国) リージョンで利用できます。

Amazon インスペクターを使い始めましょう

Amazon インスペクター無料トライアル

AWS Blogs

Amazon Web Services ブログ (日本語)

AWS News Blog

AWS Architecture Blog

AWS Database Blog

AWS DevOps & Developer Productivity Blog

AWS for Industries

AWS Machine Learning Blog

AWS Messaging & Targeting Blog

AWS Storage Blog

Open Source Project

AWS CLI

AWS CDK