はじめに #
AWSの基礎力をつけるためにAWS What’s Newを毎日目を通す事を始めました。 最初は日本語訳されたものを見ていたのですが、1週間ほど遅れて訳されるようなので、英語の情報を訳して整理することにしました。
本情報が役立つ人もいるかなと思い公開します。 個人的な理解なので、実際の情報は原典をあたってください。
まとめと気づき #
「Amazon CloudWatchがクロスアカウントおよびクロスリージョンでのログ一元化を開始」が気になりました。今までできなかったんですね。アカウントをまたいで作業するとめんどくさいことが多いのでログが一元化されるのは便利かもしれないですね。
「AWS Lambda が GovCloud リージョンでクロスアカウントコンテナイメージをサポート」という記事もありました。アカウント間連携を推し進めているようですね。アカウントごとに横串機能を分割してサービス毎のアカウントに展開するような使い方が求められているのでしょうか。
第2世代AWS Outpostsラックがさらに52カ国で利用可能に #
投稿日: 2025年09月17日
何ができるようになったのか #
第2世代AWS Outpostsラックが、オーストラリア、バーレーン、ブラジル、ブルネイ、チリ、コスタリカ、エジプト、EU諸国、アイスランド、インドネシア、イスラエル、日本、ヨルダン、ケニア、サウジアラビア、クウェート、マレーシア、ニュージーランド、ペルー、フィリピン、シンガポール、トリニダード・トバゴ、トルコ、アラブ首長国連邦(UAE)、英国、ベトナムを含む、さらに52カ国で利用可能になりました。これにより、これらの国々のデータセンターやオンプレミス環境に第2世代Outpostsラックを導入し、AWSインフラストラクチャ、サービス、API、ツールを拡張できるようになります。
第2世代Outpostsラックは、以下の機能を提供します。
- 最新世代のx86ベースのAmazon EC2インスタンス(C7i、M7i、R7i)をサポートし、第1世代OutpostsラックのC5、M5、R5インスタンスと比較して最大40%のパフォーマンス向上を実現します。
- ネットワークのスケーリングと設定が簡素化されます。
- 超低レイテンシーと高スループットに最適化された、新しいカテゴリの高速ネットワーキングAmazon EC2インスタンスをサポートします。
何が嬉しいのか #
- 一貫したハイブリッドエクスペリエンス: AWSインフラストラクチャ、サービス、API、ツールをオンプレミス環境に拡張することで、真に一貫したハイブリッドクラウドエクスペリエンスを実現できます。
- パフォーマンス向上: 最新世代のEC2インスタンスにより、オンプレミスワークロードのパフォーマンスが大幅に向上します。
- 運用効率の向上: ネットワークのスケーリングと設定が簡素化され、管理が容易になります。
- データレジデンシー要件への対応: より多くの国でデータレジデンシー要件を満たしながら、オンプレミスでAWSサービスを利用できます。
- 広範な地域での利用: これまで利用できなかった国々でも、AWSのハイブリッドクラウドソリューションを活用できるようになります。
これまでとどう変わるのか #
- これまで
- 第2世代Outpostsラックが利用できる国が限られており、特定の地域では最新のAWSハードウェアとサービスをオンプレミスで利用できませんでした。
- 第1世代Outpostsラックでは、C5、M5、R5インスタンスが提供され、現在の最新世代インスタンスと比較してパフォーマンスが低かったです。
- ネットワークのスケーリングや設定が、現在よりも複雑な場合がありました。
- これから
- 第2世代Outpostsラックがさらに52カ国で利用可能になり、より広範な地域でAWSのハイブリッドクラウド環境を構築できるようになります。
- 最新世代のx86ベースのAmazon EC2インスタンス(C7i、M7i、R7i)を利用でき、最大40%のパフォーマンス向上を実現します。
- ネットワークのスケーリングと設定が簡素化され、運用が容易になります。
- 超低レイテンシーと高スループットに最適化された新しいカテゴリの高速ネットワーキングEC2インスタンスをサポートし、より要求の厳しいワークロードに対応できます。
具体的なユースケース #
- オンプレミスシステムへの低レイテンシーアクセスを必要とするワークロード(例: 工場の自動化、医療機器のデータ処理)。
- ローカルでのデータ処理が必要なアプリケーション(例: 規制要件によりデータを国外に出せない場合)。
- ローカルシステムとの相互依存性を持つアプリケーションの移行。
- 新たにサポートされた国々で、データレジデンシー要件を満たしながらAWSサービスを利用するケース。
- 超低レイテンシーと高スループットが求められる、オンプレミスでの高性能コンピューティング(HPC)や機械学習ワークロードの実行。
AWS Network Firewall がコンソール、モニタリング、セキュリティ機能を強化 #
投稿日: 2025年09月17日
何ができるようになったのか #
AWS Network Firewall のコンソール、モニタリングダッシュボード、セキュリティコントロールが強化されました。具体的には以下の機能が追加されました。
- モニタリングダッシュボードが拡張され、Amazon S3、Amazon DynamoDB、AWS Backup などの AWS サービスへの PrivateLink エンドポイント経由のトラフィックに関する詳細なインサイトが提供されます。
- パケットと処理されたバイト数に基づいた上位の送信元および送信先 IP アドレスの可視化。
- IP アドレスとプロトコルに基づいたダッシュボードのフィルタリング機能。
- TLS インスペクションにセッション保持機能が導入され、Server Name Indication (SNI) に一致する TLS プロトコルルールが評価されるまで、TCP および TLS 確立パケットが宛先サーバーに到達するのを防ぎます。
何が嬉しいのか #
- ファイアウォールのパフォーマンスに対する可視性が向上し、より効果的な監視と管理が可能になります。
- アウトバウンド接続に対するセキュリティ対策が強化され、潜在的に悪意のあるターゲットへの接続から保護されます。
- ネットワークトラフィックパターンをより詳細に分析できるようになり、セキュリティインシデントの特定やトラブルシューティングが容易になります。
- TLS インスペクションのセッション保持により、ルールが適用される前に悪意のある接続が確立されるリスクが低減されます。
これまでとどう変わるのか #
- これまで
- AWS サービスへの PrivateLink 経由の trafficに関する詳細なモニタリングインサイトが不足していた可能性があります。
- 上位の送信元/送信先 IP アドレスの可視性や、IP アドレスとプロトコルによるフィルタリング機能が限定的でした。
- TLS インスペクションにおいて、ルール評価前に一部の TCP/TLS 確立パケットが宛先サーバーに到達する可能性がありました。
- これから
- AWS サービスへの PrivateLink 経由のトラフィックを含む、より包括的で詳細なネットワークトラフィックのモニタリングが可能になります。
- ネットワークトラフィックの分析がよりターゲットを絞ったものになり、異常なパターンやセキュリティ脅威の特定が容易になります。
- TLS インスペクションのセッション保持機能により、アウトバウンドトラフィックのセキュリティコントロールが大幅に強化され、悪意のある接続に対する保護が向上します。
具体的なユースケース #
- 企業が AWS サービスへのアウトバウンドトラフィックを厳密に監視し、セキュリティポリシーを適用する必要がある場合。
- セキュリティチームがネットワークトラフィックの異常を検出し、潜在的な脅威を特定するために詳細なインサイトを必要とする場合。
- 規制要件やコンプライアンス要件を満たすために、アウトバウンド TLS 接続に対する厳格な制御と可視性が求められる環境。
- ネットワーク管理者がトラフィックパターンを分析し、ネットワークの最適化やパフォーマンス問題のトラブルシューティングを行う場合。
補足: AWSのファイアウォール機能の比較 #
AWSにはVPCのトラフィックを制御するファイアウォールとして、主に4つのサービスがあります。それぞれ役割と機能が異なります。
簡単に言うと、保護するレイヤーと範囲、機能の高度さが違います。
- AWS WAF: ウェブアプリケーションの門番 (L7)
- Security Group: インスタンスのドアマン (L3/L4)
- Network ACL: サブネットの関所 (L3/L4)
- Network Firewall: VPC全体の高度なセキュリティゲートウェイ (L3-L7)
1. AWS WAF (Web Application Firewall) #
- 保護レイヤー: アプリケーション層 (L7)
- 適用範囲: CloudFront, Application Load Balancer, API Gatewayなどのエッジサービス。
- ステート: ステートフル
- ルール: 許可・拒否・カウント。SQLインジェクションやXSSなど、ウェブ攻撃のパターンをルール化します。
- 主な用途: ウェブサイトやAPIを、悪意のあるHTTP/HTTPSリクエストから保護します。
2. セキュリティグループ (Security Group) #
- 保護レイヤー: トランスポート層 (L4)
- 適用範囲: EC2インスタンスなどのインスタンス単位(正確にはENI単位)。
- ステート: ステートフル。許可されたインバウンド通信の戻り通信は自動的に許可されます。
- ルール: 許可ルールのみ設定可能です。
- 主な用途: インスタンスに対するアクセス制御。「このウェブサーバーには、このIPアドレスからのHTTPアクセスのみを許可する」など。
3. ネットワークACL (Network Access Control List) #
- 保護レイヤー: ネットワーク層 (L3)
- 適用範囲: サブネット単位。
- ステート: ステートレス。インバウンドとアウトバウンドの戻り通信をそれぞれ明示的に許可する必要があります。
- ルール: 許可ルールと拒否ルールの両方を設定できます。
- 主な用途: サブネットレベルでのアクセス制御。「このサブネット全体に対して、特定の悪意のあるIPアドレスからのアクセスをすべて拒否する」など。
4. AWS Network Firewall #
- 保護レイヤー: ネットワーク層からアプリケーション層 (L3-L7)
- 適用範囲: VPC全体。VPC間の通信、インターネットとの通信、オンプレミスとの通信などを一元的に保護します。
- ステート: ステートフル。
- ルール: 許可・拒否・アラート。ドメイン名でのフィルタリングや侵入防止システム(IPS)など高度なルールを設定できます。
- 主な用途: VPCの境界における高度な脅威防御と、複数VPCにまたがる一元的なポリシー管理。
まとめ表 #
特徴 | AWS WAF | セキュリティグループ | ネットワークACL | AWS Network Firewall |
---|---|---|---|---|
レイヤー | L7 | L4 | L3 | L3-L7 |
適用範囲 | エッジ (ALBなど) | インスタンス (ENI) | サブネット | VPC全体 |
ステート | ステートフル | ステートフル | ステートレス | ステートフル |
ルール | 許可/拒否/カウント | 許可のみ | 許可/拒否 | 許可/拒否/アラート |
機能 | ウェブ攻撃防御 | 基本的なアクセス制御 | 基本的なアクセス制御 | 高度なフィルタリング, IPS |
管理 | 集中管理 | 分散管理 | 分散管理 | 集中管理 |
使い分けのイメージ #
- AWS WAFで、ウェブサイトの入り口で不正なリクエスト(SQLインジェクションなど)をブロックします。
- ネットワークACLで、サブネットの入り口で不要なIPからの通信を大まかに拒否します。
- セキュリティグループで、各インスタンスのドアの前で、本当に必要なプロトコル・ポートの通信だけを許可します。
- Network Firewallで、VPC全体の出入り口に立ち、より高度な脅威(マルウェア通信など)がないかを包括的に監視・ブロックします。
これらを組み合わせて、多層的な防御を実現するのが一般的です。
AWS Parallel Computing Service (PCS) が ML 向け Amazon EC2 Capacity Blocks をサポート #
投稿日: 2025年09月17日
何ができるようになったのか #
AWS Parallel Computing Service (PCS) が Amazon EC2 Capacity Blocks for ML をサポートするようになりました。これにより、EC2 Capacity Blocks を使用して予約された Amazon EC2 インスタンスを PCS クラスター内でネイティブに利用できるようになります。
何が嬉しいのか #
Slurm クラスターにおける最先端の GPU ベースのワークロードのキャパシティプランニングが簡素化され、必要なときに必要な場所で GPU キャパシティが確実に利用できるようになります。これにより、研究やイノベーションに集中でき、インフラストラクチャの管理負担が軽減されます。
これまでとどう変わるのか #
- これまで
- Slurm クラスターで GPU ワークロードを実行する際、キャパシティの確保やプランニングが複雑で、必要なときに GPU が利用できるか不確実な場合がありました。
- これから
- EC2 Capacity Blocks を PCS と統合することで、GPU キャパシティの予約と利用が容易になり、キャパシティプランニングが大幅に簡素化され、必要なリソースが確実に利用できるようになります。
具体的なユースケース #
- Slurm を使用して AWS 上で高性能コンピューティング (HPC) ワークロードを実行およびスケーリングする。
- 科学および工学モデルを構築し、特に最先端の GPU キャパシティを必要とする機械学習ワークロードを実行する。
- GPU リソースの可用性を保証しつつ、弾力的なコンピューティング環境を構築する。
Amazon Connect がエージェント階層フィルターを使用したコンタクト検索機能を開始 #
投稿日: 2025年09月17日
何ができるようになったのか #
Amazon Connect のコンタクト検索ページで、エージェント階層フィルターを使用してコンタクトを検索できるようになりました。これにより、特定のコンタクトセンターのサイト、部門、またはチームが処理したコンタクトを絞り込んで確認できます。
何が嬉しいのか #
コンタクトセンターのリーダーは、特定のチームや部門が処理したコンタクトの品質やエージェントのパフォーマンスを詳細に評価できるようになります。また、品質管理や規制遵守などの中央チームは、特定のチームや部門が処理したコンタクトを効率的に見つけてレビューできるため、パフォーマンス評価やコンプライアンス監査のワークフローが効率化されます。
これまでとどう変わるのか #
- これまで
- エージェント階層に基づいてコンタクトを効率的に検索・フィルタリングする機能がなかったため、特定のチームや部門が処理したコンタクトの評価や監査に手間がかかっていた可能性があります。
- これから
- エージェント階層フィルターにより、特定のチームや部門が処理したコンタクトを迅速かつ効率的に検索・レビューできるようになり、評価や監査のプロセスが大幅に改善されます。
具体的なユースケース #
- コンタクトセンターのリーダーが、特定のチームや部門のエージェントが処理したコンタクトの品質を評価する。
- 品質管理チームが、特定の部門のコンタクトを監査し、改善点を見つける。
- 規制遵守チームが、特定のチームが処理したコンタクトが規制要件を満たしているかを確認する。
Amazon CloudWatchがクロスアカウントおよびクロスリージョンでのログ一元化を開始 #
投稿日: 2025年09月17日
何ができるようになったのか #
Amazon CloudWatchがクロスアカウントおよびクロスリージョンでのログ一元化機能を提供開始しました。これにより、複数のAWSアカウントおよびリージョンからのログデータを単一の宛先アカウントにコピーできるようになります。この機能はAWS Organizationsとシームレスに統合され、組織全体、特定の組織単位、または選択したアカウントからのログを効率的に集約できます。ログイベントには、元のソースアカウントとリージョンを識別する新しいシステムフィールド(@aws.accountおよび@aws.region)が付与され、ソースコンテキストとデータ系列が維持されます。
何が嬉しいのか #
複数のアカウントやリージョンにまたがるワークロードのログを、カスタムソリューションを管理することなく、単一のアカウントに効率的に集約できるようになります。これにより、ログ管理の複雑さが大幅に軽減され、運用コストと労力を削減できます。また、ログイベントにソース情報が付与されるため、トラブルシューティングやセキュリティ監査の際に、ログの出所を容易に特定でき、データ系列の追跡が容易になります。選択的なロググループのコピー、同名ロググループの自動マージ、オプションのバックアップリージョン設定など、集中型ログ管理を簡素化する追加機能も利用できます。
これまでとどう変わるのか #
- これまで
- 複数のAWSアカウントやリージョンに分散したログを中央集約するには、AWS Lambda、Kinesis Firehose、S3などのサービスを組み合わせてカスタムのログ転送ソリューションを構築する必要があり、設定と管理が複雑で、運用オーバーヘッドが大きかった。
- ログのソースアカウントやリージョン情報を維持するためには、追加の処理やメタデータ付与の仕組みを自前で実装する必要があった。
- これから
- CloudWatchのネイティブ機能としてクロスアカウント・クロスリージョンログ一元化が提供されるため、カスタムソリューションの構築や管理が不要になり、設定が大幅に簡素化される。
- AWS Organizationsとの統合により、組織全体や特定のOU単位でのログ集約ルールを容易に設定できる。
- ログイベントに自動的にソースアカウントとリージョン情報が付与されるため、データ系列の追跡が容易になり、運用上の可視性が向上する。
具体的なユースケース #
- セキュリティおよびコンプライアンス要件のために、組織内のすべてのAWSアカウントおよびリージョンからのログを中央のセキュリティアカウントに集約する。
- 大規模なエンタープライズ環境で、複数の開発チームや事業部門が利用するAWSアカウントの運用ログを、中央の運用チームが管理するアカウントに一元化し、監視と分析を効率化する。
- 災害復旧計画の一環として、重要なログデータをプライマリリージョンだけでなく、バックアップリージョンにも自動的にコピーして冗長性を確保する。
- 特定のアプリケーションやマイクロサービスが複数のアカウントやリージョンにデプロイされている場合、それらのログを単一のビューで確認し、エンドツーエンドのトラブルシューティングを容易にする。
AWS Lambda が GovCloud リージョンでクロスアカウントコンテナイメージをサポート #
投稿日: 2025年09月17日
何ができるようになったのか #
AWS Lambda 関数を、Lambda 関数とは異なる AWS アカウントに存在する Amazon Elastic Container Registry (ECR) リポジトリに保存されているコンテナイメージを使用して、すべての GovCloud リージョン (AWS GovCloud (US-West) および AWS GovCloud (US-East)) で作成または更新できるようになりました。
何が嬉しいのか #
異なるアカウント間でコンテナイメージにアクセスできるようになり、プロセスが効率化されます。これにより、集中管理されたアカウントにイメージが保存されている場合に、イメージをローカルの ECR リポジトリにコピーする必要がなくなります。
これまでとどう変わるのか #
- これまで
- ユーザーは、Lambda 関数と同じ AWS アカウント内のコンテナイメージにのみアクセスできました。集中管理されたアカウントにイメージが保存されている場合、それらのイメージをローカルの ECR リポジトリにコピーする必要がありました。
- これから
- GovCloud リージョンにおいて、Lambda 関数とは異なる AWS アカウントの ECR リポジトリに保存されているコンテナイメージを直接利用して、Lambda 関数を作成・更新できるようになります。
具体的なユースケース #
- GovCloud 環境において、複数の AWS アカウント間でコンテナイメージを一元的に管理し、各アカウントの Lambda 関数から共有のイメージを利用するケース。
- セキュリティ要件の高い環境で、コンテナイメージの管理と利用を分離し、アクセス権限を細かく制御しながら効率的にデプロイを行うケース。
Amazon Corretto 25 が一般提供開始 #
投稿日: 2025年09月17日
Amazon Correttoは、Amazonが提供する無料の、本番環境ですぐに使えるOpenJDK(Open Java Development Kit)のディストリビューションです。
Correttoは、パフォーマンスの向上やセキュリティ修正を含む長期サポート(LTS)がAmazonから提供されるのが大きな特徴です。
主な特徴は以下の通りです。
- 無償: 追加コストなしで本番環境で利用できます。
- 長期サポート (LTS): Amazon Corretto 25は2032年10月までの長期サポートが提供され、セキュリティアップデートやパフォーマンス改善を継続的に受けられます。
- パフォーマンス: 最新のJavaの機能改善(仮想スレッド、構造化された並行処理など)を取り込み、高いパフォーマンスを発揮します。
- 互換性: Java SE標準と互換性があります。
AWSの各種サービス(Lambda, EKS, EC2など)でJavaアプリケーションを実行する際の標準的なJDKとして利用されています。
何ができるようになったのか #
Amazon Corretto 25 (長期サポート版) が一般提供開始されました。このバージョンには、以下の新機能と改善が含まれています。
- Compact Object Headers: オブジェクトヘッダーを縮小し、ヒープメモリ使用量を削減。
- Generational Shenandoah GC: 持続可能なスループットと短い一時停止時間を実現し、より小さなヒープとCPU使用量で同等のパフォーマンスを提供。
- Ahead-of-Time (AOT) Caching: 事前解析・事前リンクされたクラスとコンパイルプロファイルを再利用することで、コールドスタートとウォームアップ時間を改善。
- Language improvements: パターン内のプリミティブ型、柔軟なコンストラクタ、モジュール全体のインポート、コンパクトなソースファイル、スレッドローカル変数用のスコープ付き値、不変データ用の安定した値など、定型コードを削減し、コードをより短く安全に保つための言語機能の強化。
- Observability: JDK Flight RecorderがCPU時間サンプリング、協調サンプリング、メソッドトレースイベントを獲得し、低オーバーヘッドでの本番プロファイリングを可能に。
- Structured Concurrency: 協調的なタスク管理を提供し、関連するタスクが一緒に失敗または完了できるように設計。
- Vector API: サポートされるCPUで最適なベクトル命令にコンパイルされる計算を提供。
- Virtual Thread pinning improvements: 同期ブロックでのスレッドピンニングを削減し、スケーラビリティを向上。
何が嬉しいのか #
- リソース効率の向上とコスト削減: メモリ使用量の削減により、より少ないリソースでアプリケーションを実行でき、クラウドコストの削減に繋がります。
- アプリケーションの応答性向上: GCの改善により、アプリケーションの一時停止時間が短縮され、ユーザーエクスペリエンスが向上します。
- 高速な起動とウォームアップ: AOTキャッシングにより、特にコンテナやサーバーレス環境でのアプリケーションの起動時間が大幅に短縮され、迅速なデプロイとスケーリングが可能になります。
- 開発効率とコード品質の向上: 言語機能の強化により、開発者はより簡潔で安全、かつ表現力豊かなコードを記述できるようになり、開発者の生産性が向上します。
- 本番環境でのパフォーマンス監視とデバッグの容易化: オブザーバビリティの強化により、低オーバーヘッドで詳細なプロファイリングが可能になり、パフォーマンスのボトルネックを迅速に特定できます。
- 堅牢な並行処理: 構造化された並行処理により、複雑な並行タスクの管理が容易になり、エラー処理が改善され、より堅牢なシステムを構築できます。
- 計算パフォーマンスの向上: Vector APIにより、数値計算やデータ処理が高速化され、データ集約型アプリケーションのパフォーマンスが向上します。
- 高並行性アプリケーションのスケーラビリティ向上: 仮想スレッドの改善により、多数の同時接続を効率的に処理できるようになります。
これまでとどう変わるのか #
- これまで
- オブジェクトヘッダーが大きく、ヒープメモリ使用量が高かったため、メモリ効率が課題となることがありました。
- GCの一時停止時間が長く、特に大規模なアプリケーションではスループットや応答性に影響を与える可能性がありました。
- アプリケーションのコールドスタートやウォームアップに時間がかかり、特に短命なコンテナやサーバーレス関数ではパフォーマンスのボトルネックとなっていました。
- 定型コードが多く、言語機能が限定的であったため、コードの記述が冗長になりがちで、開発効率が低下することがありました。
- 本番環境での詳細なプロファイリングはオーバーヘッドが高く、パフォーマンス問題の特定が困難な場合がありました。
- 並行タスクの管理が複雑で、エラー処理やタスクのライフサイクル管理が困難な場合がありました。
- ベクトル計算の最適化は手動または特定のライブラリに依存しており、CPUの性能を最大限に引き出すのが難しいことがありました。
- 同期ブロックでのスレッドピンニングが、高並行性アプリケーションのスケーラビリティを制限する要因となることがありました。
- これから
- Compact Object Headersにより、ヒープメモリ使用量が削減され、より多くのオブジェクトを効率的に扱えるようになり、メモリ効率が向上します。
- Generational Shenandoah GCにより、持続可能な高スループットと短い一時停止時間を実現し、応答性の高いアプリケーションを構築できるようになります。
- AOT Cachingにより、アプリケーションの起動とウォームアップが劇的に高速化され、ユーザーへの価値提供が早まります。
- 言語改善により、より簡潔で安全、かつ表現力豊かなコードを記述できるようになり、開発者の生産性とコード品質が向上します。
- JDK Flight Recorderの強化により、低オーバーヘッドで詳細な本番プロファイリングが可能になり、パフォーマンスのボトルネックを容易に特定できるようになります。
- Structured Concurrencyにより、並行タスクのライフサイクル管理が簡素化され、堅牢なシステムを構築できるようになります。
- Vector APIにより、CPUのベクトル命令を最大限に活用し、数値計算やデータ処理のパフォーマンスを大幅に向上できるようになります。
- Virtual Thread pinning improvementsにより、仮想スレッドの利用がさらに効率的になり、高並行性アプリケーションのスケーラビリティが向上します。
具体的なユースケース #
- マイクロサービスおよびサーバーレスアプリケーション: 高速な起動時間と低いメモリフットプリントは、コンテナ化されたマイクロサービスやAWS Lambdaのようなサーバーレス関数に最適で、リソース効率とコスト効率を向上させます。
- リアルタイムデータ処理システム: 改善されたGCとVector APIにより、金融取引システム、IoTデータ処理、ストリーミング分析など、低レイテンシと高スループットが求められるアプリケーションで優れたパフォーマンスを発揮します。
- 大規模エンタープライズアプリケーション: 仮想スレッドの改善と構造化された並行処理により、多数の同時接続を処理するエンタープライズアプリケーションのスケーラビリティと信頼性が向上します。
- AI/機械学習ワークロード: Vector APIを活用することで、数値計算が中心となる機械学習モデルのトレーニングや推論のパフォーマンスを大幅に向上させることができます。
- クラウドネイティブアプリケーション: リソース効率の向上と高速な起動は、クラウド環境での運用コスト削減と迅速なデプロイに貢献し、クラウドネイティブな開発を加速します。
- 高負荷なバックエンドサービス: データベース接続プール、メッセージキュー、APIゲートウェイなど、高並行性と低レイテンシが要求されるバックエンドサービスで、安定したパフォーマンスと高いスループットを実現します。
AWS End User Messaging が SMS の CloudFormation をサポート #
投稿日: 2025年09月17日
何ができるようになったのか #
AWS End User Messaging SMS が AWS CloudFormation をサポートするようになり、顧客は CloudFormation テンプレートを使用して SMS リソースをデプロイおよび管理できるようになりました。電話番号、送信者 ID、設定セット、保護設定、オプトアウトリスト、リソースポリシー、電話プールなどの SMS リソースが CloudFormation 経由でサポートされます。
何が嬉しいのか #
CloudFormation を使用することで、SMS リソースのセットアップと管理を標準化し、他の AWS リソースと並行して開発環境でのデプロイとデリバリーパイプラインを簡素化できます。これにより、安全性、セキュリティ、コミュニケーション結果を損なうことなく、スケーラブルで費用対効果の高いメッセージングインフラストラクチャを構築・運用できます。
これまでとどう変わるのか #
- これまで
- SMS リソースの管理は手動で行うか、カスタムスクリプトなどを用いて行う必要があり、他の AWS リソースとの一貫したインフラストラクチャ管理が困難な場合がありました。
- これから
- CloudFormation テンプレートを使って SMS リソースをコードとして定義し、自動的にプロビジョニングおよび管理できるようになります。これにより、インフラストラクチャのデプロイと管理の自動化、一貫性の確保、およびバージョン管理が可能になります。
具体的なユースケース #
- ワンタイムパスコード (OTP) のための電話番号や設定セットの自動デプロイと管理。
- アカウント更新や予約リマインダーなどの通知システムにおける SMS リソースのインフラストラクチャ・アズ・コード (IaC) による管理。
- 配送通知やプロモーションメッセージングのための、スケーラブルな SMS リソース群の環境間での一貫した展開。
Amazon EC2 I8ge インスタンスが欧州 (フランクフルト) リージョンで利用可能に #
投稿日: 2025年09月17日
何ができるようになったのか #
Amazon EC2 ストレージ最適化 I8ge インスタンスが AWS 欧州 (フランクフルト) リージョンで利用可能になりました。これらのインスタンスは AWS Graviton4 プロセッサを搭載し、前世代の Graviton2 ベースのインスタンスと比較して最大 60% 優れたコンピューティング性能を提供します。また、最新の第3世代 AWS Nitro SSD を使用し、TB あたりのリアルタイムストレージ性能を最大 55% 向上させ、ストレージ I/O レイテンシーを最大 60% 低減し、ストレージ I/O レイテンシーの変動を最大 75% 低減します。120 TB という AWS Graviton ベースのストレージ最適化 Amazon EC2 インスタンスの中で最高のストレージ密度と、300 Gbps というストレージ最適化 Amazon EC2 インスタンスの中で最高のネットワーク帯域幅を提供します。
何が嬉しいのか #
Graviton4 プロセッサによる大幅なコンピューティング性能向上と、Nitro SSD によるストレージ性能の劇的な改善により、リアルタイムアプリケーションの応答性と効率が向上します。高いストレージ密度とネットワーク帯域幅により、大規模なデータセットを扱うアプリケーションのパフォーマンスが最適化され、より要求の厳しいワークロードにも対応できるようになります。AWS Nitro System により、ワークロードのパフォーマンスとセキュリティが強化されます。
これまでとどう変わるのか #
- これまで
- 欧州 (フランクフルト) リージョンでは、Graviton4 プロセッサと第3世代 AWS Nitro SSD を搭載した I8ge インスタンスは利用できませんでした。そのため、ストレージ最適化インスタンスにおいて、コンピューティング性能、ストレージ性能、ストレージ密度、ネットワーク帯域幅に制限がありました。
- これから
- 欧州 (フランクフルト) リージョンで I8ge インスタンスが利用可能になったことで、前世代と比較して最大 60% 優れたコンピューティング性能、最大 55% 優れたリアルタイムストレージ性能、最大 120 TB のストレージ密度、最大 300 Gbps のネットワーク帯域幅を持つインスタンスを利用できるようになります。これにより、より高性能でセキュアなリアルタイムアプリケーションをデプロイできるようになります。
具体的なユースケース #
- リレーショナルデータベース、非リレーショナルデータベース、ストリーミングデータベースなど、大規模なストレージ密度を必要とするリアルタイムアプリケーション
- 検索クエリやデータ分析など、高速なストレージ I/O と低レイテンシーが求められるワークロード
- 高いネットワーク帯域幅を必要とするデータ集約型アプリケーション
Amazon EventBridge が、ルールフィルターパターンと入力トランスフォーマーに対するカスタマーマネージドキーのサポートを拡張 #
投稿日: 2025年09月17日
何ができるようになったのか #
Amazon EventBridge が、イベントバスのルールフィルターパターンと入力トランスフォーマーに対して、AWS Key Management Service (KMS) のカスタマーマネージドキー (CMK) のサポートを拡張しました。これにより、イベントのフィルタリングおよび変換ロジック内の機密情報を、独自の暗号化キーで保護できるようになります。
何が嬉しいのか #
厳格なセキュリティおよびコンプライアンス要件を満たしながら、暗号化キーを完全に制御し、イベントフィルタリングおよび変換ロジック内の機密情報を保護できるようになります。組織のコンプライアンスおよびガバナンス要件を満たし、AWS CloudTrail を使用して暗号化キーの使用状況を監査および追跡できます。
これまでとどう変わるのか #
- これまで
- EventBridge のイベントバスルールフィルターパターンと入力トランスフォーマーは、カスタマーマネージドキーによる暗号化を直接サポートしていませんでした。そのため、これらのコンポーネントに含まれる機密情報の保護には、追加の対策や考慮が必要でした。
- これから
- EventBridge のイベントバスルールフィルターパターンと入力トランスフォーマーで、KMS のカスタマーマネージドキーを使用して機密情報を暗号化できるようになります。これにより、セキュリティとコンプライアンスの要件をより容易に満たし、暗号化キーの管理と監査を強化できます。
具体的なユースケース #
- 機密性の高い個人情報や規制対象データを含むイベントを処理する際に、フィルタリングロジックや変換ロジック自体も暗号化して保護する必要がある場合。
- HIPAA、PCI DSS、GDPR などの特定のコンプライアンス規制に準拠するために、イベント処理パイプラインのあらゆる段階での暗号化が求められるワークロード。
- 組織のセキュリティポリシーにより、AWS マネージドキーではなく、独自の暗号化キー (CMK) を使用してデータを保護し、そのキーのライフサイクルとアクセスを完全に制御したい場合。
AWS Budgetsがカスタム期間をサポート #
投稿日: 2025年09月17日
何ができるようになったのか #
AWS Budgetsでカスタム期間がサポートされ、柔軟な開始日と終了日を持つ予算を作成できるようになりました。これにより、従来の暦ベースの期間(月次、四半期、年次)を超えて、組織の特定のニーズに合わせた予算期間を定義できます。
何が嬉しいのか #
特定の期間と資金制限を持つプロジェクトのコストを正確に監視できるようになります。これにより、プロジェクトの期間に合わせた予算設定が可能になり、コスト管理の精度と効率が向上します。
これまでとどう変わるのか #
- これまで
- 予算期間が月次、四半期、年次といった暦ベースの期間に限定されていました。
- 特定の期間を持つプロジェクトの予算を管理する場合、複数の暦月にわたって予算を計算・分割したり、個別のスプレッドシートで追跡したりする必要がありました。
- これから
- プロジェクトの正確な期間に合わせて単一の予算を作成し、支出がしきい値に近づいたときにアラートを受け取れるようになります。
- 従来の暦ベースの制約から解放され、より柔軟で実情に即したコスト監視が可能になります。
具体的なユースケース #
- 月の途中で開始し、特定の期間(例:3ヶ月間)で終了する開発プロジェクトがある場合、その正確な期間に対して単一の予算を設定し、支出がしきい値に近づいたときにアラートを受け取ることができます。
Amazon RDS for MySQL が Extended Support マイナーバージョン 5.7.44-RDS.20250818 を発表 #
投稿日: 2025年09月17日
何ができるようになったのか #
Amazon Relational Database Service (RDS) for MySQL が、新しいAmazon RDS Extended Support マイナーバージョン 5.7.44-RDS.20250818 をサポートするようになりました。これにより、コミュニティサポート終了後も最大3年間、主要バージョンをアップグレードするための猶予期間が提供され、その間も重要なセキュリティ修正とバグ修正が提供されます。
何が嬉しいのか #
主要バージョンのコミュニティサポートが終了した後も、最大3年間、新しい主要バージョンへのアップグレードに十分な時間を確保できます。これにより、ビジネス要件を満たしつつ、データベースのセキュリティと安定性を維持できます。
これまでとどう変わるのか #
- これまで
- MySQLの主要バージョンのコミュニティサポートが終了すると、ユーザーはセキュリティリスクやバグ修正の不足に直面する可能性があり、迅速なアップグレードが求められました。
- これから
- Extended Supportにより、コミュニティサポート終了後も最大3年間、重要なセキュリティおよびバグ修正を受けながら、新しい主要バージョンへのアップグレード計画と実行に余裕を持つことができます。
具体的なユースケース #
- 厳格なコンプライアンス要件があり、主要バージョンアップグレードに長い計画期間とテスト期間が必要な組織。
- 特定のMySQL主要バージョンに長期間依存するアプリケーションがあり、互換性の問題や広範なテストサイクルにより頻繁なアップグレードが困難な場合。
- 頻繁な主要バージョンアップグレードによる中断を最小限に抑えつつ、セキュリティと安定性を維持したいビジネス。

AWSクラウド設計完全ガイド 単行本(ソフトカバー) – 2025/3/21
¥3,520
Amazonで見る