はじめに #
AWSの基礎力をつけるためにAWS What’s Newを毎日目を通す事を始めました。 最初は日本語訳されたものを見ていたのですが、1週間ほど遅れて訳されるようなので、英語の情報を訳して整理することにしました。
本情報が役立つ人もいるかなと思い公開します。 個人的な理解なので、実際の情報は原典をあたってください。
まとめと気づき #
「Application Recovery Controller のリージョンスイッチがアジアパシフィック (ニュージーランド) リージョンで利用可能に」というニュースが有りました。 Application Recovery Controllerというのは初めて聞いたので今度使ってみようと思います。
他にも「Amazon Route 53 Resolver クエリログがアジアパシフィック (ニュージーランド) で利用可能に」と言う発表もあり、サービスの可用性を高めるような改善が進んでいることを感じました。
Amazon EC2 Auto Scaling がインスタンスリフレッシュの強制キャンセルをサポート #
投稿日: 2025年09月24日
何ができるようになったのか #
Amazon EC2 Auto Scaling のインスタンスリフレッシュにおいて、進行中のインスタンス起動や終了が完了するのを待つことなく、即座に強制キャンセルできるようになりました。これは、CancelInstanceRefresh
API を呼び出す際に WaitForTransitioningInstances
を false
に設定することで実現できます。
何が嬉しいのか #
この機能により、Auto Scaling グループ (ASG) の更新に対する制御が強化されます。特に、現在のデプロイがサービス障害を引き起こしている場合など、緊急時に新しいアプリケーションデプロイに迅速にロールフォワードする必要がある場合に、迅速な対応が可能になります。進行中のデプロイを素早く中止し、必要に応じてすぐに新しいインスタンスリフレッシュを開始できます。
これまでとどう変わるのか #
- これまで
- インスタンスリフレッシュのキャンセルは、進行中のインスタンスの起動や終了、またはライフサイクルイベントが完了するまで待機する必要がありました。これにより、緊急時の対応が遅れる可能性がありました。
- これから
WaitForTransitioningInstances
をfalse
に設定することで、進行中のインスタンスアクティビティ(インスタンスライフサイクルフックなど)をバイパスし、インスタンスリフレッシュを即座に強制キャンセルできるようになります。これにより、より迅速な対応と復旧が可能になります。
具体的なユースケース #
- 現在のアプリケーションデプロイがサービス障害を引き起こしている場合に、新しいデプロイに迅速にロールフォワードする。
- 問題のある進行中のデプロイを迅速に中止し、別のデプロイを開始する。
- 緊急事態発生時に、即座にインスタンスリフレッシュを中断し、新しい更新プロセスを開始する。
AWS、EC2 I8g および I7i インスタンスにおける無制限のネットワークバースト期間を発表 #
投稿日: 2025年09月24日
何ができるようになったのか #
AWSは、Amazon EC2 I7i および I8g インスタンスの4xlargeより大きいサイズにおいて、ネットワーク帯域幅のバースト期間制限を撤廃しました。これにより、これらのインスタンスサイズでは、常に利用可能なネットワーク帯域幅が実質的に2倍になり、最大パフォーマンスを無期限に維持できるようになりました。
何が嬉しいのか #
メモリおよびネットワーク集約型のワークロードを実行している顧客は、中断することなく常に最大ネットワーク帯域幅を維持できるようになり、持続的な高スループットのネットワーク接続を必要とするアプリケーションに対して、より予測可能なパフォーマンスを提供できるようになります。
これまでとどう変わるのか #
- これまで
- これらのインスタンスサイズにはベースライン帯域幅があり、ベースライン帯域幅を超えてバーストするためにネットワークI/Oクレジットメカニズムを使用していました。
- これから
- 4xlargeより大きいインスタンスサイズでは、最大パフォーマンスを無期限に維持できるようになり、常に利用可能なネットワーク帯域幅が実質的に2倍になります。
具体的なユースケース #
- 高速なデータアクセスとリアルタイムのレイテンシーを必要とするI/O集約型ワークロード
- MySQL、PostgreSQL、Hbaseなどのトランザクション、リアルタイム、分散型データベース
- Aerospike、MongoDB、ClickHouse、Apache DruidなどのNoSQLソリューション
- Apache Sparkなどのリアルタイム分析プラットフォーム、データレイクハウス
- AI LLMトレーニングのための前処理
Amazon GameLift Serversがテキサス州ダラスに新しいローカルゾーンを開設 #
投稿日: 2025年09月24日
何ができるようになったのか #
Amazon GameLift Serversが、テキサス州ダラス(us-east-1-dfw-2)に新しいAWSローカルゾーンをサポートするようになりました。これにより、EC2 C6gn, C6i, C6in, M6g, M6i, M6in, M8g, R6iインスタンスタイプを使用してGameLiftフリートをこのローカルゾーンにデプロイできるようになりました。
何が嬉しいのか #
主要なプレイヤー人口密集地やITセンターに近いローカルゾーンにゲームサーバーを配置することで、ダラス都市圏のプレイヤーに対して、リアルタイムマルチプレイヤーゲーム、応答性の高いAR/VR体験、競技トーナメントなどの低レイテンシーが要求されるワークロードを提供できるようになります。これにより、ネットワーク距離が短縮され、シングルミリ秒台のレイテンシーを実現し、プレイヤーはよりスムーズで応答性の高いゲーム体験を得られます。
これまでとどう変わるのか #
- これまで
- ダラス都市圏のプレイヤーは、より遠いAWSリージョンにデプロイされたGameLiftサーバーに接続する必要があり、レイテンシーが高くなる可能性がありました。
- これから
- ダラスのローカルゾーンにGameLiftフリートをデプロイすることで、ゲームサーバーをプレイヤーの近くに配置し、ネットワークレイテンシーを大幅に削減できるようになります。
具体的なユースケース #
- リアルタイムマルチプレイヤーゲームのサーバーをダラス都市圏のプレイヤーに近づけ、ラグを最小限に抑える。
- 応答性の高いAR/VR体験を提供し、没入感を高める。
- 競技性の高いeスポーツトーナメントにおいて、参加者全員に公平で低レイテンシーな環境を提供する。
AWS LambdaがGovCloudリージョンでのコード署名をサポート開始 #
投稿日: 2025年09月24日
何ができるようになったのか #
AWS Lambdaが、AWS GovCloud (US-West) および AWS GovCloud (US-East) リージョンでコード署名をサポートするようになりました。これにより、管理者は信頼され検証済みのコードのみがLambda関数にデプロイされるように徹底できます。この機能はマネージド型のコード署名サービスであるAWS Signerを利用し、デプロイ時にLambdaが署名をチェックしてコードが改ざんされておらず、信頼できる開発者によって署名されていることを確認します。
コード署名とは #
コード署名は、ソフトウェアやコードの作成者(出所)を証明し、配布中にコードが改ざんされていないこと(完全性)を保証するためのデジタル署名技術です。
開発者は、信頼された認証局(CA)から発行されたデジタル証明書を使用して、コードに署名します。ユーザーがそのソフトウェアを実行しようとすると、OSやプラットフォームが署名を検証します。
具体的な使い方(AWS Lambdaの場合)
-
署名プロファイルの作成:
- AWS Signerで「署名プロファイル」を作成します。これは、署名に使うデジタル証明書を管理するためのリソースです。
- IAMロールを指定し、信頼できる開発者やCI/CDパイプラインだけがこのプロファイルを使って署名できるようにアクセス権を管理します。
-
コードへの署名:
- 開発が完了したLambdaのデプロイパッケージ(ZIPファイルやコンテナイメージ)に対して、AWS Signerと作成した署名プロファイルを使って署名ジョブを実行します。
- これにより、署名済みのコードがS3バケットなどに出力されます。
-
Lambda関数の設定:
- Lambda関数の設定で「コード署名」を有効化し、先ほど作成した署名プロファイル(のARN)を関連付けます。
- これにより、この関数には指定されたプロファイルで署名されたコードしかデプロイできなくなります。署名がない、または検証に失敗したコードのデプロイは拒否(または警告)されます。
このプロセスにより、「信頼された開発者」が作成し、「改ざんされていない」コードだけが本番環境のLambda関数として実行されることを強制でき、セキュリティが大幅に向上します。
何が嬉しいのか #
この機能により、Lambda関数のセキュリティが大幅に向上します。不正なコードのデプロイを防ぎ、コードの完全性と信頼性を保証することで、セキュリティ要件の厳しいワークロードでも安心してLambdaを利用できるようになります。管理者は、署名プロファイルを細かく制御し、署名チェックが失敗した場合の動作(警告またはデプロイ拒否)を設定できるため、柔軟かつ厳格なセキュリティポリシーを適用できます。追加料金なしで利用可能です。
これまでとどう変わるのか #
- これまで
- GovCloudリージョンにおけるLambda関数へのコードデプロイにおいて、コードの完全性や信頼性を自動的に検証する組み込みのメカニズムがありませんでした。そのため、不正なコードがデプロイされるリスクが存在しました。
- これから
- 管理者はコード署名を強制できるようになり、承認された開発者によって署名され、改ざんされていないコードのみがLambda関数にデプロイされるようになります。これにより、より高いレベルのセキュリティとコンプライアンスを維持できます。
具体的なユースケース #
- 機密性の高い政府機関のアプリケーションをデプロイする際に、コードの完全性と出所を厳格に検証する必要がある場合。
- ソフトウェアサプライチェーンに対する厳格な管理を義務付けるコンプライアンス要件(例:FedRAMP、ITAR)を満たす必要がある場合。
- 重要なLambda関数への悪意のあるコードインジェクションや改ざんを防ぎ、システムのセキュリティ体制を強化する場合。
Application Recovery Controller のリージョンスイッチがアジアパシフィック (ニュージーランド) リージョンで利用可能に #
投稿日: 2025年09月24日
何ができるようになったのか #
Amazon Application Recovery Controller (ARC) のリージョンスイッチ機能が、アジアパシフィック (ニュージーランド) リージョンで利用可能になりました。これにより、複数のAWSアカウントにまたがるアプリケーションリソースを、別のAWSリージョンで運用するための特定の手順をオーケストレーションできるようになります。リアルタイムで復旧プロセスを可視化するダッシュボードが提供され、規制当局やコンプライアンスチームへの報告に必要なリソースやアカウントからのデータ収集も行えます。アクティブ/パッシブのマルチリージョンアプローチにおけるフェイルオーバーとフェイルバック、およびアクティブ/アクティブのマルチリージョンアプローチにおけるシフトアウェイとリターンをサポートします。リージョンスイッチプランを作成すると、アプリケーションが動作するすべてのリージョンに複製されるため、復旧時に元のリージョンへの依存関係がなくなります。
何が嬉しいのか #
- アジアパシフィック (ニュージーランド) リージョンで、より堅牢で自動化された災害復旧戦略を構築できるようになります。
- クロスアカウント、クロスリージョンでのアプリケーション復旧プロセスを、信頼性高く、オーケストレーションされた方法で実行できます。
- 復旧プロセスのリアルタイムな可視性により、状況を正確に把握し、迅速な意思決定が可能になります。
- コンプライアンスや規制要件に対応するための復旧データの収集と報告が容易になります。
- 復旧計画が複数のリージョンに複製されるため、障害が発生したリージョンへの依存が減り、復旧時間目標 (RTO) と復旧時点目標 (RPO) の改善に貢献します。
これまでとどう変わるのか #
- これまで
- アジアパシフィック (ニュージーランド) リージョンにおけるクロスリージョンでのアプリケーション復旧は、手動での作業が多く、複雑で、複数のAWSアカウントにまたがるリソースの調整が困難な場合がありました。
- 復旧プロセスの可視性が低く、コンプライアンス報告のためのデータ収集も手動で行う必要がありました。
- 復旧計画が単一リージョンに依存している場合、そのリージョンに障害が発生すると復旧自体が困難になるリスクがありました。
- これから
- ARCのリージョンスイッチ機能を利用することで、アジアパシフィック (ニュージーランド) リージョンを含むマルチリージョン環境でのアプリケーション復旧が、自動化され、オーケストレーションされたプロセスとして実行できるようになります。
- リアルタイムダッシュボードと自動データ収集により、復旧状況の把握とコンプライアンス報告が効率化されます。
- 復旧プランが複数のリージョンに複製されるため、特定のリージョンに障害が発生しても、他のリージョンから復旧プロセスを開始できるようになり、回復力が向上します。
具体的なユースケース #
- アジアパシフィック (ニュージーランド) リージョンでミッションクリティカルなアプリケーションを運用しており、リージョン障害発生時に、別のAWSリージョンへ迅速かつ確実にフェイルオーバーする必要がある場合。
- 金融サービスなど、厳格な規制要件を持つ業界の企業が、災害復旧計画の実行可能性とコンプライアンス遵守を規制当局に証明する必要がある場合。
- アクティブ/アクティブ構成で複数のリージョンに展開されたアプリケーションにおいて、特定のリージョンから別のリージョンへトラフィックを一時的にシフトさせ、メンテナンスやテストを行う場合。
Amazon Route 53 Resolver クエリログがアジアパシフィック (ニュージーランド) で利用可能に #
投稿日: 2025年09月24日
何ができるようになったのか #
アジアパシフィック (ニュージーランド) リージョンで、Amazon Route 53 Resolver クエリログが利用可能になりました。これにより、Amazon Virtual Private Cloud (Amazon VPC) 内で発生するDNSクエリをログに記録できるようになります。クエリログを有効にすると、どのドメイン名がクエリされたか、クエリがどのAWSリソース (送信元IPやインスタンスIDを含む) から発生したか、そして受信した応答を確認できます。VPC内で発生するDNSクエリと応答をログに記録でき、それらのクエリがRoute 53 Resolverによってローカルで応答されたか、パブリックインターネット経由で解決されたか、またはResolverエンドポイント経由でオンプレミスDNSサーバーに転送されたかに関わらず記録されます。AWS Resource Access Manager (RAM) を使用して、クエリログ設定を複数のアカウントで共有することも可能です。ログはAmazon S3、Amazon CloudWatch Logs、またはAmazon Data Firehoseに送信できます。
何が嬉しいのか #
VPC内のDNSクエリの可視性が向上し、セキュリティ分析、トラブルシューティング、およびコンプライアンス要件の達成に役立ちます。どのリソースがどのドメインにアクセスしようとしているかを詳細に把握できるため、異常なネットワークアクティビティの検出や、アプリケーションの依存関係の理解が容易になります。
これまでとどう変わるのか #
- これまで
- アジアパシフィック (ニュージーランド) リージョンでは、VPC内のDNSクエリの詳細なログを直接取得する機能が提供されていませんでした。
- DNSクエリの発生元や応答に関する詳細な情報を得るには、追加のツールや複雑な設定が必要でした。
- これから
- アジアパシフィック (ニュージーランド) リージョンでも、Route 53 Resolver クエリログを簡単に有効化し、VPC内のDNSクエリに関する詳細な情報を一元的に収集・分析できるようになります。
- ログデータをS3、CloudWatch Logs、Data Firehoseといった既存のAWSサービスと統合し、セキュリティ、運用、コンプライアンスのニーズに対応できます。
具体的なユースケース #
- セキュリティ分析: 不審なドメインへのアクセス試行や、マルウェア感染の兆候となる異常なDNSクエリパターンを特定し、セキュリティインシデントの早期発見と対応に役立てる。
- トラブルシューティング: アプリケーションが特定のサービスに接続できない場合など、DNS解決の問題の原因を特定するために、どのリソースがどのドメインをクエリし、どのような応答を受け取ったかを詳細に調査する。
- コンプライアンスと監査: 規制要件や内部ポリシーに基づき、すべてのDNSクエリをログに記録し、監査証跡として保持することで、コンプライアンス体制を強化する。
- ネットワークトラフィックの可視化: アプリケーションやサービスが外部リソースとどのように通信しているかを理解し、ネットワーク設計の最適化やコスト管理に役立てる。