メインコンテンツへスキップ

【AWSデイリーアップデート】CDKリファクタリングでインフラ安全に進化!Bedrock PrivateLink対応も

· loading · loading ·
kiitosu
著者
kiitosu
画像処理やデバイスドライバ、データ基盤構築からWebバックエンドまで、多様な領域に携わってきました。地図解析や地図アプリケーションの仕組みにも経験があり、幅広い技術を活かした開発に取り組んでいます。休日は草野球とランニングを楽しんでいます。
目次

はじめに
#

AWSの基礎力をつけるためにAWS What’s Newを毎日目を通す事を始めました。 最初は日本語訳されたものを見ていたのですが、1週間ほど遅れて訳されるようなので、英語の情報を訳して整理することにしました。

本情報が役立つ人もいるかなと思い公開します。 個人的な理解なので、実際の情報は原典をあたってください。

まとめと気づき
#

AWS CDK Refactor がプレビュー公開されました。今年の2月頃に Cloud Formation Stack Refactoring が発表されていましたが、それのCDK版でしょうか。インフラのメンテナンスは緊張感を伴う作業なので、仕組みとしてサポートされて作業が簡単になるのはありがたいです。

最近IPv6とIPv4のデュアルスタックに対応したというニュースを良く見る気がします。ここらへんを意識することなくAWS側で管理してくれるようになるとありがたいですね。


Amazon Managed Service for Prometheus が AWS GovCloud (米国) リージョンで利用可能に
#

投稿日: 2025年09月10日

何ができるようになったのか
#

AWS GovCloud (米国) リージョンで Amazon Managed Service for Prometheus が利用可能になりました。これは、運用メトリクスを大規模に監視およびアラーム設定できる、フルマネージドな Prometheus 互換のモニタリングサービスです。顧客は1つのワークスペースに最大10億のアクティブメトリクスを送信でき、アカウントごとに複数のワークスペースを作成できます。

何が嬉しいのか
#

AWS GovCloud (米国) リージョンを利用する顧客が、Prometheus 互換のモニタリングサービスをフルマネージドで利用できるようになり、大規模な運用メトリクスの監視とアラーム設定が容易になります。これにより、コンプライアンス要件を満たしながら、Prometheus の強力な機能を活用して、機密性の高いワークロードの可視性を高めることができます。

これまでとどう変わるのか
#

  • これまで
    • AWS GovCloud (米国) リージョンでは、Amazon Managed Service for Prometheus が利用できなかったため、Prometheus を利用するには手動で環境を構築・管理する必要がありました。
  • これから
    • AWS GovCloud (米国) リージョンで、フルマネージドな Amazon Managed Service for Prometheus を利用して、大規模な運用メトリクスを簡単に監視・アラーム設定できるようになりました。これにより、運用負担が軽減され、より迅速な洞察が得られます。

具体的なユースケース
#

  • GovCloud 環境で、Prometheus を利用してアプリケーションやインフラストラクチャのメトリクスを収集・監視したい政府機関や規制対象の顧客。
  • 機密性の高いワークロードの運用メトリクスを、コンプライアンス要件を満たしながら大規模に管理したい場合。
  • 既存の Prometheus ワークロードを GovCloud 環境に移行し、運用負担を軽減したい場合。

AWS CDK Refactor (プレビュー) のご紹介
#

投稿日: 2025年09月10日

何ができるようになったのか
#

AWS Cloud Development Kit (CDK) CLIで新しいcdk refactorコマンド(プレビュー版)を通じて、安全なインフラストラクチャのリファクタリングが可能になりました。この機能により、デプロイ済みのリソースの状態を維持したまま、コンストラクトの名前変更、スタック間のリソース移動、CDKアプリケーションの再編成ができます。AWS CloudFormationのリファクタリング機能と自動マッピング計算を活用することで、コードの再構築中に意図しないリソースの置き換えが発生するリスクがなくなります。

何が嬉しいのか
#

コードの再構築中に意図しないリソースの置き換えのリスクがなくなるため、複雑な移行手順やステートフルなリソースのダウンタイムのリスクなしに、アーキテクチャの改善を自信を持って実施できます。これにより、チームは本番環境の安定性を維持しながら、インフラストラクチャコードを継続的に進化させることができます。

これまでとどう変わるのか
#

  • これまで
    • インフラストラクチャコードのメンテナンスでは、リソースの再編成やコード構造の改善が必要となることが多かったですが、これらの変更は論理IDの変更により既存のリソースを置き換えるリスクがありました。
  • これから
    • CDK Refactor機能により、開発者は複雑な移行手順やステートフルなリソースのダウンタイムのリスクなしに、モノリシックなスタックの分割、継承パターンの導入、高レベルのコンストラクトへのアップグレードといったアーキテクチャの改善を自信を持って実施できます。

具体的なユースケース
#

  • モノリシックなスタックを分割する
  • 継承パターンを導入する
  • 高レベルのコンストラクトにアップグレードする

Amazon Bedrock AgentCore Gateway が AWS PrivateLink を介した呼び出しと呼び出しログ記録をサポート #

投稿日: 2025年09月10日

何ができるようになったのか
#

Amazon Bedrock AgentCore Gateway が AWS PrivateLink を介した呼び出しと、Amazon CloudWatch、Amazon S3、Amazon Data Firehose を利用した呼び出しログ記録をサポートするようになりました。これにより、VPC (Virtual Private Cloud) ネットワーク内のユーザーやエージェントが、パブリックインターネットを経由せずに AgentCore Gateway にアクセスできるようになり、各呼び出しログの可視性を得て、問題の深掘りやアクティビティの監査ができるようになりました。

何が嬉しいのか
#

AgentCore Gateway を通じて、エージェントやツールにネットワークおよびガバナンス要件を適用できるようになります。パブリックインターネットに公開することなく、VPC内から安全にAgentCore Gatewayにアクセスできるため、セキュリティが強化されます。また、呼び出しログにより、エージェントの動作を詳細に監視し、問題発生時の原因究明やセキュリティ監査が容易になります。

これまでとどう変わるのか
#

  • これまで
    • AgentCore Gatewayへのアクセスにパブリックインターネットを経由する必要がある場合があり、ネットワークセキュリティやガバナンスの適用が複雑でした。
    • エージェントの呼び出しログが統合されておらず、詳細な監視や監査が困難でした。
  • これから
    • AWS PrivateLink を利用して、VPC内からプライベートに AgentCore Gateway にアクセスできるようになり、セキュリティとネットワーク分離が強化されます。
    • Amazon CloudWatch、Amazon S3、Amazon Data Firehose と連携した呼び出しログ記録により、エージェントの利用状況の可視性が向上し、監査やトラブルシューティングが容易になります。

具体的なユースケース
#

  • 厳格なネットワークセキュリティポリシーを持つ企業が、エージェントツールを安全に利用する。
  • エージェントの利用状況を詳細に監査し、コンプライアンス要件を満たす。
  • エージェントの呼び出しに関する問題を迅速に特定し、トラブルシューティングを行う。

AWS Elastic Beanstalk がアプリケーションおよびネットワークロードバランサーのデュアルスタック設定で IPv6 をサポート
#

投稿日: 2025年09月10日

何ができるようになったのか
#

  • AWS Elastic Beanstalk が、Application Load Balancer (ALB) および Network Load Balancer (NLB) の両方でデュアルスタック設定をサポートするようになりました。
  • これにより、Elastic Beanstalk 環境が IPv4 と IPv6 の両方のプロトコルに対応できるようになります。
  • IpAddressType オプションを “dualstack” に設定するだけで、ロードバランサーが自動的にデュアルスタックを構成し、A レコードと AAAA レコードの両方が作成されます。
  • 既存の IPv4 環境をデュアルスタックにシームレスに更新したり、必要に応じて元に戻したりすることも可能です。

何が嬉しいのか
#

  • IPv4 との完全な互換性を維持しながら、IPv6 のみのネットワーク上のユーザーにもアプリケーションを提供できるようになります。
  • グローバルなアクセシビリティ要件や IPv6 導入義務に対応できます。
  • DNS レコード管理が自動的に処理されるため、アプリケーションの IPv6 デプロイが簡素化され、すべてのユーザーに最適なパフォーマンスが保証されます。

これまでとどう変わるのか
#

  • これまで
    • Elastic Beanstalk 環境のロードバランサーは主に IPv4 に対応しており、IPv6 とのデュアルスタック設定は容易ではありませんでした。
  • これから
    • ロードバランサーが IPv4 と IPv6 の両方に対応するデュアルスタック設定をサポートし、自動的な DNS レコード管理により簡単に導入できるようになります。
    • 既存の IPv4 環境も容易に IPv6 対応に移行できます。

具体的なユースケース
#

  • IPv6 のみのネットワークを使用しているユーザーにアプリケーションを提供したい場合。
  • グローバルなアクセシビリティ要件を満たす必要がある場合。
  • IPv6 への移行や導入が義務付けられている環境に対応する場合。

AWS Backup が Amazon S3 バックアップで ACL とオブジェクトタグの選択的バックアップをサポート
#

投稿日: 2025年09月10日

何ができるようになったのか
#

AWS Backup で Amazon S3 バケットをバックアップする際に、Access Control Lists (ACL) と ObjectTags を含めるかどうかを選択できるようになりました。

何が嬉しいのか
#

回復のニーズに基づいてバックアップアプローチをカスタマイズできるようになり、必要なメタデータのみを含めることで、より効率的で目的に合ったバックアップが可能になります。これにより、不要なメタデータをバックアップから除外し、ストレージ容量とコストを最適化できます。

これまでとどう変わるのか
#

  • これまで
    • AWS Backup は、Amazon S3 オブジェクトのバックアップ時に、ACL と ObjectTags のメタデータコンポーネントをすべてのオブジェクトに対してデフォルトで含んでいました。
  • これから
    • Amazon S3 バケットのバックアップ時に、ACL と ObjectTags を含めるかどうかを選択できるようになりました。

具体的なユースケース
#

  • S3オブジェクトの回復時にACLやObjectTagsが不要な場合、バックアップから除外することでストレージ容量とコストを節約できます。
  • 特定のコンプライアンス要件に基づき、S3オブジェクトのメタデータのうち、必要なものだけをバックアップに含める必要がある場合。
  • バックアップとリストアのプロセスを高速化するため、不要なメタデータの処理をスキップしたい場合。

Amazon EC2 I8g インスタンスが米国東部 (オハイオ) リージョンで利用可能に
#

投稿日: 2025年09月10日

何ができるようになったのか
#

AWS米国東部 (オハイオ) リージョンで、Amazon EC2 ストレージ最適化 I8g インスタンスが一般提供開始されました。I8g インスタンスは、ストレージ集約型ワークロード向けにAmazon EC2で最高のパフォーマンスを提供します。

何が嬉しいのか
#

  • AWS Graviton4 プロセッサにより、前世代の I4g インスタンスと比較して最大60%優れたコンピューティングパフォーマンスを実現します。
  • 最新の第3世代 AWS Nitro SSD を使用し、TBあたり最大65%優れたリアルタイムストレージパフォーマンスを提供し、ストレージI/Oレイテンシーを最大50%削減、ストレージI/Oレイテンシーの変動を最大60%削減します。
  • AWS Nitro System 上に構築されており、ワークロードのパフォーマンスとセキュリティを向上させます。
  • 最大100 Gbpsのネットワークパフォーマンス帯域幅と、Amazon Elastic Block Store (EBS) 用に60 Gbpsの専用帯域幅を提供します。

これまでとどう変わるのか
#

  • これまで
    • ストレージ集約型ワークロードにおいて、I8gインスタンスほどの高性能なコンピューティング、ストレージI/Oパフォーマンス、低レイテンシーは利用できませんでした。
  • これから
    • I8gインスタンスの登場により、トランザクション、リアルタイム、分散データベース、リアルタイム分析プラットフォーム、AI LLM前処理など、高速なデータアクセスとリアルタイムのストレージレイテンシーを必要とするI/O集約型ワークロードで、大幅に向上したパフォーマンスと効率性を享受できるようになります。

具体的なユースケース
#

  • MySQL、PostgreSQL、Hbaseなどのトランザクションデータベース
  • Aerospike、MongoDB、ClickHouse、Apache DruidなどのNoSQLソリューション
  • Apache Sparkなどのリアルタイム分析プラットフォーム
  • データレイクハウス
  • AI LLM (大規模言語モデル) のトレーニングのための前処理

Amazon CloudWatch Network Monitoring がリージョン間のフロー可視性を追加
#

投稿日: 2025年09月10日

何ができるようになったのか
#

Amazon CloudWatch Network Monitoringのフローモニターを使用して、AWSグローバルネットワークを介したAWSリージョン間のトラフィックのネットワークパフォーマンスを監視できるようになりました。これにより、Amazon EC2やAmazon EKSなどのコンピューティングインスタンス、Amazon S3やAmazon DynamoDBなどのAWSサービス間のワークロードのネットワークパフォーマンスをほぼリアルタイムで可視化できます。また、リモートリージョンのパブリックIPアドレスへのフロー、およびAmazon VPCピアリングまたはAWS Transit Gatewayピアリングを介したリモートリージョンへのプライベートトラフィックのネットワーク可視性が拡張されました。

何が嬉しいのか
#

ワークロードのネットワーク起因の障害を迅速に検出し、その原因を特定するのに役立つメトリクスが提供されます。ローカルリージョンとリモートリージョン間のAWSグローバルネットワークにおけるネットワークパフォーマンスの問題がワークロードに影響を与えているかどうかを評価できるようになります。フローモニターのネットワークヘルスインジケーター (NHI) がリージョン間のワークロードのネットワークパスにおけるAWSグローバルネットワークの健全性も捕捉するため、障害がローカルリージョン、AWSグローバルネットワーク、またはリモートリージョンのどこで発生しているかを迅速に特定できます。

これまでとどう変わるのか
#

  • これまで
    • AWSグローバルネットワークを介したリージョン間のトラフィックのネットワークパフォーマンスを詳細に監視し、問題の原因を特定することが困難でした。特に、リージョン間のネットワークパスにおけるAWSグローバルネットワーク自体の健全性を把握する手段が限られていました。
  • これから
    • AWSグローバルネットワークを介したリージョン間のトラフィックのネットワークパフォーマンスを詳細に監視できるようになります。ワークロードに影響を与える障害が、ローカルリージョン、AWSグローバルネットワーク、またはリモートリージョンのどこで発生しているかを迅速に特定できます。リモートリージョンのパブリックIPアドレスへのフローや、VPCピアリング/Transit Gatewayピアリングを介したプライベートトラフィックの可視性も向上します。

具体的なユースケース
#

  • 複数のリージョンにまたがる分散アプリケーションのネットワークパフォーマンスを監視し、遅延や障害の原因を特定する。
  • リージョン間のデータ転送(例: S3バケット間のレプリケーション、DynamoDBグローバルテーブル)の健全性を確認する。
  • VPCピアリングやTransit Gatewayピアリングを介して接続されたリージョン間のプライベートネットワーク通信のトラブルシューティングを行う。
  • ユーザーからのアプリケーションの遅延報告があった際に、それがネットワーク起因なのか、特定のリージョンでの問題なのか、AWSグローバルネットワークの問題なのかを切り分ける。

AWS HealthImaging が DICOMweb API の OpenID Connect (OIDC) 認証をサポート
#

投稿日: 2025年09月10日

何ができるようになったのか
#

AWS HealthImaging の DICOMweb API で、OpenID Connect (OIDC) を使用した認証がサポートされました。これにより、OAuth 2.0 互換の既存の ID プロバイダー(Amazon Cognito、Okta、Auth0 など)を利用して DICOMweb リクエストの認証ができるようになりました。

何が嬉しいのか
#

  • 組織の標準的なユーザー管理手順(アカウントの作成、有効化、無効化)を用いて、DICOM リソースへのセキュアなアクセスを管理できます。
  • 既存の医療画像アプリケーションへの AWS HealthImaging の統合が簡素化されます。
  • DICOMweb 標準インターフェースの OAuth 2.0 互換認証への対応が強化され、より柔軟な認証オプションが提供されます。

これまでとどう変わるのか
#

  • これまで
    • DICOMweb API の認証は、主に AWS Identity and Access Management (IAM) ユーザーとロールに限定されていました。
  • これから
    • 既存の OpenID Connect (OIDC) 互換の ID プロバイダーを通じて DICOMweb API の認証が可能になり、組織の既存の ID 管理システムと連携しやすくなりました。

具体的なユースケース
#

  • 既存の医療画像アプリケーションから AWS HealthImaging の DICOMweb API に、組織で利用している ID プロバイダー(Okta、Auth0 など)を通じてセキュアにアクセスする。
  • 医療機関が既存のユーザー管理システム(Active Directory などと連携した IdP)を利用して、DICOM データのアクセス権限を一元的に管理し、セキュリティと運用効率を向上させる。

Amazon IVS がインターフェース VPC エンドポイントを介したプライベートインジェストをサポート
#

投稿日: 2025年09月10日

何ができるようになったのか
#

Amazon Interactive Video Service (Amazon IVS) が、AWS PrivateLink を利用したインターフェース VPC エンドポイントを介したメディアインジェストをサポートしました。これにより、パブリックインターネットを介さずに、RTMP(S) ストリームを IVS 低遅延チャネルまたは IVS リアルタイムステージに安全にブロードキャストできるようになりました。

何が嬉しいのか
#

ライブビデオワークフローに対して、プライベートで信頼性の高い接続を提供します。トラフィックをパブリックインターネットに送信しないため、セキュリティが強化されます。

これまでとどう変わるのか
#

  • これまで
    • Amazon IVS へのメディアインジェストは、通常パブリックインターネットを介して行われる可能性がありました。
  • これから
    • インターフェース VPC エンドポイントを使用することで、VPC 内から、または AWS Direct Connect を介してオンプレミス環境から、メディアインジェストをプライベートに行うことができるようになります。

具体的なユースケース
#

  • パブリックインターネットにトラフィックを公開することなく、VPC 内またはオンプレミス環境から RTMP(S) ストリームを IVS 低遅延チャネルや IVS リアルタイムステージに安全にブロードキャストする。

AWS IoT SiteWise が異常検出モデルの再トレーニングをサポート
#

投稿日: 2025年09月10日

何ができるようになったのか
#

AWS IoT SiteWise のネイティブ異常検出機能において、以下の新機能が追加されました。

  • 自動モデル再トレーニング: 30日から1年までの範囲でスケジュールを設定し、モデルを自動的に再トレーニングできるようになりました。
  • 柔軟なプロモーションモード: サービス管理型と顧客管理型の2つのモデルプロモーションモードを選択できるようになりました。
    • 自動プロモーション: AWS IoT SiteWise が最適なモデルを評価し、自動的にプロモーションします。
    • 手動プロモーション: 顧客が精度、再現率、AUCなどの包括的なモデルメトリクスを確認し、どのモデルバージョンをアクティブにするか決定できます。
  • モデルメトリクスの公開: 精度、再現率、ROC曲線下面積 (AUC) などのモデルメトリクスが公開されるようになりました。

何が嬉しいのか
#

  • モデルの精度維持: 機器の状態や構成の変化に合わせてモデルが常に最新の状態に保たれるため、異常検出の最適なパフォーマンスを維持できます。
  • 運用負荷の軽減: モデルの手動再トレーニングが不要になり、運用上の手間が削減されます。
  • 柔軟な運用: 自動化されたハンズオフアプローチと、人間による監視を伴うアプローチを選択できるため、運用のニーズやコンプライアンス要件に合わせて柔軟に対応できます。
  • 意思決定の改善: 公開されたモデルメトリクスにより、モデルのパフォーマンスを詳細に把握し、より情報に基づいた意思決定を行うことができます。

これまでとどう変わるのか
#

  • これまで
    • 異常検出モデルの再トレーニングは手動で行う必要があった可能性があります。
    • モデルのプロモーションは自動化されておらず、柔軟性に欠けていた可能性があります。
    • モデルのパフォーマンスに関する詳細なメトリクスが公開されていなかった可能性があります。
  • これから
    • モデルの自動再トレーニングが可能になり、常に最新のモデルで異常検出を行えます。
    • サービス管理型と顧客管理型の柔軟なプロモーションモードを選択でき、運用ポリシーに合わせたモデルのデプロイが可能です。
    • 精度、再現率、AUCなどの詳細なモデルメトリクスを確認できるため、モデルの健全性をより深く理解し、適切な判断を下せます。

具体的なユースケース
#

  • 製造ラインの機器が経年劣化や設定変更により挙動が変化する際に、異常検出モデルを自動的に適応させ、誤検知や見逃しを減らす。
  • 季節変動や生産量の変化など、環境要因によって機器の正常な動作パターンが変わる場合でも、モデルを最新の状態に保ち、正確な異常検出を継続する。
  • 厳格な品質管理や規制要件がある環境で、モデルのデプロイ前にそのパフォーマンスメトリクスを詳細にレビューし、承認プロセスを経てから本番環境に適用する。
Reply by Email

関連記事

AWS What's New 2025年8月02日 公平キューイング地味に便利そう
· loading · loading
AWS What's New 2025年8月01日 Lambdaのレスポンスストリーミング知らなかった
· loading · loading
AWS What's New 2025年7月17日 クラウドで実行されているlambda関数のデバッグが可能に
· loading · loading