はじめに #
AWSの基礎力をつけるためにAWS What’s Newを毎日目を通す事を始めました。 最初は日本語訳されたものを見ていたのですが、1週間ほど遅れて訳されるようなので、英語の情報を訳して整理することにしました。
本情報が役立つ人もいるかなと思い公開します。 個人的な理解なので、実際の情報は原典をあたってください。
まとめと気付き #
Amazon CloudWatch と OpenSearch Service が統合分析エクスペリエンスのリージョンサポートを拡大しました。Logs Insights QLは馴染みがなく苦手意識があったのでSQLで検索できるのは助かります。
AWS Step Functions が Service Quotas をサポートしました。多くのワークフローを実行している場合はクォータ確認・変更が簡単になりますね。
AWS Direct Connect、コロンビアのボゴタで100G拡張を発表 #
投稿日: 2025年09月30日
何ができるようになったのか #
コロンビアのボゴタ近郊にあるEquinix BG1データセンターの既存のAWS Direct Connectロケーションで、MACsec暗号化機能を備えた10 Gbpsおよび100 Gbpsの専用接続が拡張されました。このロケーションから、中国を除くすべてのパブリックAWSリージョン、AWS GovCloudリージョン、およびAWS Local Zonesへのプライベートで直接的なネットワークアクセスを確立できるようになりました。
何が嬉しいのか #
パブリックインターネット経由の接続と比較して、より一貫したネットワークエクスペリエンスを享受できるようになります。これにより、安定した高速接続が必要なワークロードのパフォーマンスと信頼性が向上します。
これまでとどう変わるのか #
- これまで
- ボゴタのDirect Connectロケーションでは、10 Gbpsおよび100 Gbpsの専用接続とMACsec暗号化機能が提供されていませんでした。また、アクセス可能なAWSリージョンが限定的でした。
- これから
- ボゴタのDirect Connectロケーションで、MACsec暗号化機能を備えた10 Gbpsおよび100 Gbpsの専用接続が利用可能になり、中国を除くすべてのパブリックAWSリージョン、AWS GovCloudリージョン、およびAWS Local Zonesへのアクセスが可能になります。
具体的なユースケース #
- データセンター、オフィス、またはコロケーション環境とAWS間のプライベートで直接的なネットワーク接続を確立し、安定した高帯域幅の通信を必要とする企業。
- 機密性の高いデータを扱うワークロードで、MACsec暗号化による追加のセキュリティ層を必要とする場合。
- ボゴタを拠点とし、AWSの様々なリージョンやLocal Zonesに展開されたアプリケーションやサービスへの低遅延かつ高スループットなアクセスが必要な場合。
AWS Direct Connectがスペインのマドリードに新しいロケーションを開設 #
投稿日: 2025年09月30日
何ができるようになったのか #
スペインのマドリード近郊にあるDigital Realty MAD3データセンター内に、新しいAWS Direct Connectロケーションが開設されました。これにより、中国を除くすべてのパブリックAWSリージョン、AWS GovCloudリージョン、およびAWS Local Zonesへのプライベートで直接的なネットワークアクセスを確立できるようになりました。このロケーションでは、MACsec暗号化が利用可能な専用の10 Gbpsおよび100 Gbps接続が提供されます。
何が嬉しいのか #
AWSとデータセンター、オフィス、またはコロケーション環境との間にプライベートで物理的なネットワーク接続を確立できるため、パブリックインターネット経経由よりも一貫したネットワークエクスペリエンスが得られます。また、MACsec暗号化により、データ転送のセキュリティが強化されます。マドリードにおける接続オプションが増えることで、より多くの企業が低レイテンシーでセキュアな接続を利用できるようになります。
これまでとどう変わるのか #
- これまで
- マドリードには2つのDirect Connectロケーションしかなく、スペイン全体でも3つのロケーションに限られていました。
- Digital Realty MAD3データセンターから直接、専用の高速かつセキュアな接続を確立する選択肢がありませんでした。
- これから
- マドリードに3番目のDirect Connectロケーションが追加され、スペイン全体で4番目のロケーションとなります。
- Digital Realty MAD3データセンターから、専用の10 Gbpsおよび100 Gbps接続（MACsec暗号化対応）を利用してAWSに直接接続できるようになります。これにより、より多くの企業がマドリードからAWSへのプライベート接続を確立しやすくなります。
具体的なユースケース #
- マドリード近郊のデータセンターやオフィスから、低レイテンシーかつ高帯域幅でAWSサービスにアクセスしたい企業。
- パブリックインターネットを介さずに、機密性の高いデータをAWSとやり取りする必要がある企業（MACsec暗号化を利用）。
- 既存のネットワークインフラストラクチャをAWSに拡張し、ハイブリッドクラウド環境を構築したい企業。
- ネットワークパフォーマンスの一貫性を重視するリアルタイムアプリケーションや大規模データ転送を行う企業。
Amazon FSx for Lustre が AWS 米国西部 (フェニックス) ローカルゾーンで利用可能に #
投稿日: 2025年09月30日
何ができるようになったのか #
AWS 米国西部 (フェニックス) ローカルゾーンで Amazon FSx for Lustre ファイルシステムを作成できるようになりました。
何が嬉しいのか #
クラウドで機能豊富で高性能なファイルシステムを、より簡単かつ費用対効果高く起動、実行、スケーリングできるようになります。信頼性、セキュリティ、スケーラビリティ、幅広い機能セットにより、多様なワークロードをサポートします。
これまでとどう変わるのか #
- これまで
- AWS 米国西部 (フェニックス) ローカルゾーンでは Amazon FSx for Lustre ファイルシステムを利用できませんでした。
- これから
- AWS 米国西部 (フェニックス) ローカルゾーンで Amazon FSx for Lustre ファイルシステムを直接作成し、利用できるようになります。
具体的なユースケース #
- 機械学習
- ハイパフォーマンスコンピューティング (HPC)
- ビデオ処理
- 金融モデリング
- 電子設計自動化 (EDA)
Amazon CloudWatch と OpenSearch Service が統合分析エクスペリエンスのリージョンサポートを拡大 #
投稿日: 2025年09月30日
何ができるようになったのか #
Amazon CloudWatch と OpenSearch Service の統合分析エクスペリエンスが、以下の5つの追加商用リージョンで利用可能になりました。
- アジアパシフィック (大阪)
- アジアパシフィック (ソウル)
- 欧州 (ミラノ)
- 欧州 (スペイン)
- 米国西部 (北カリフォルニア)
この統合により、CloudWatch Logs のお客様は、CloudWatch Logs Insights QL に加えて、SQL と OpenSearch PPL の2つのクエリ言語でログ分析を行えるようになりました。
何が嬉しいのか #
- CloudWatch Logs のお客様:
- SQL を使用して、JOIN、サブクエリ、JSON、数学、日時、文字列関数などのSQL関数を駆使した直感的なログ分析が可能になります。
- OpenSearch PPL を使用してデータをフィルタリング、集計、分析できます。
- 数クリックで VPC、WAF、CloudTrail のログ用 OpenSearch ダッシュボードを作成し、ログから導き出された可視化機能を使用して監視、分析、トラブルシューティングを行えます。
- OpenSearch のお客様:
- CloudWatch から分析のためにログをコピーしたり、ETL パイプラインを作成したりする必要がなくなります。
- OpenSearch Discover を使用して CloudWatch Logs をインプレースで分析し、CloudWatch Logs 上にインデックスとダッシュボードを構築できます。
これまでとどう変わるのか #
- これまで
- CloudWatch Logs のログ分析は CloudWatch Logs Insights QL に限定されていました。
- OpenSearch Service で CloudWatch Logs を分析するには、ログをコピーするか、ETL パイプラインを構築する必要がありました。
- これから
- CloudWatch Logs のお客様は、SQL や OpenSearch PPL を含む複数のクエリ言語で高度なログ分析を行えるようになります。
- OpenSearch のお客様は、CloudWatch Logs を直接、インプレースで分析し、ダッシュボードを構築できるようになり、データ移動の手間がなくなります。
具体的なユースケース #
- VPC、WAF、CloudTrail のログを、SQL の高度なクエリ機能や OpenSearch PPL を使用して詳細に分析し、セキュリティイベントやネットワークトラフィックの異常を特定する。
- CloudWatch Logs のデータから OpenSearch ダッシュボードを迅速に作成し、システムの健全性、パフォーマンス、セキュリティイベントをリアルタイムで可視化して監視する。
- CloudWatch Logs のデータを OpenSearch Discover で直接検索・分析し、トラブルシューティングの時間を短縮する。
- 複数の AWS リージョンにまたがるログデータを一元的に分析し、グローバルなアプリケーションの運用状況を把握する。
AWS Step Functions が Service Quotas をサポート #
投稿日: 2025年09月30日
何ができるようになったのか #
AWS Step Functions が AWS Service Quotas と統合され、Service Quotas コンソールから直接 Step Functions のクォータを監視および管理できるようになりました。これにより、アカウントレベルのクォータ値の確認、Amazon CloudWatch メトリクスを通じたクォータ使用状況の監視、そしてService Quotas コンソールからの直接的なクォータ増加リクエストが可能になります。
何が嬉しいのか #
- サービスクォータの可視性と管理が向上し、一元的な場所からクォータを管理できるようになります。
- 大規模なワークフロー運用を行う顧客は、リソース使用状況をプロアクティブに監視し、潜在的なサービス中断を回避できます。
- クォータ増加リクエストが効率化され、対象となるリクエストは手動介入なしで自動的に更新されるため、管理プロセスが合理化されます。
これまでとどう変わるのか #
- これまで
- AWS Step Functions のサービスクォータは、Service Quotas コンソールから直接監視・管理することができませんでした。クォータの確認や増加リクエストには、より手動のプロセスや個別の対応が必要でした。
- これから
- Service Quotas コンソールを通じて、AWS Step Functions のアカウントレベルのクォータ値を一元的に確認し、Amazon CloudWatch メトリクスで利用状況を監視できます。また、コンソールから直接クォータ増加をリクエストでき、自動更新により迅速な対応が可能になります。
具体的なユースケース #
- 大量のワークフローを実行しており、Step Functions のリソース使用状況をリアルタイムで監視し、クォータ超過によるサービス中断を未然に防ぎたい場合。
- ビジネス要件の変更に伴い、Step Functions のクォータを迅速かつ効率的に増加させたい場合。
- 複数の AWS サービスにわたるクォータを一元的に管理し、運用効率を向上させたい場合。
AWS Transfer Family が追加の IAM 条件キーのサポートを開始 #
投稿日: 2025年09月30日
何ができるようになったのか #
AWS Transfer Family が、Identity and Access Management (IAM) 向けに4つの新しいサービス固有の条件キーをサポートするようになりました。これにより、IAM ポリシーで API リクエストのコンテキストに基づいたアクセス制御を適用できるようになります。
何が嬉しいのか #
管理者は、よりきめ細やかな IAM ポリシーおよびサービスコントロールポリシー (SCP) を作成し、Transfer Family リソースの設定を制限できるようになります。これにより、セキュリティ管理とコンプライアンス管理が強化され、コンプライアンス要件を満たしやすくなります。
これまでとどう変わるのか #
- これまで
- IAM ポリシーで Transfer Family の設定（プロトコル、エンドポイントタイプ、ストレージドメインなど）を詳細に制限するためのサービス固有の条件キーが限られていました。
- これから
transfer:RequestServerEndpointTypeやtransfer:RequestServerProtocolsといった新しい条件キーを使用することで、Transfer Family リソースの設定をプロトコル、エンドポイントタイプ、ストレージドメインに基づいて、より詳細に制御できるようになります。
具体的なユースケース #
transfer:RequestServerEndpointTypeを使用して、公開サーバーの作成を防止する。transfer:RequestServerProtocolsを使用して、SFTP サーバーのみが作成されるように強制する。- Transfer Family のアクションに対して、組織のセキュリティポリシーに沿った追加の権限ガードレールを定義する。
AWS Transfer Familyは、Amazon S3またはAmazon EFSとの間でファイルを転送するための、フルマネージドなファイル転送サービスです。
SFTP (SSH File Transfer Protocol)、FTPS (FTP over SSL/TLS)、FTP (File Transfer Protocol) のプロトコルをサポートしており、既存のワークフローを変更することなく、これらのプロトコルを使用してファイルをAWSストレージに転送できます。
主な特徴は以下の通りです。
- フルマネージド: サーバーのプロビジョニング、パッチ適用、メンテナンスが不要です。
- プロトコルサポート: SFTP、FTPS、FTPに対応しており、様々なクライアントからの接続が可能です。
- 既存の認証システムとの統合: AWS Directory Service for Microsoft Active Directory、LDAP、カスタムIDプロバイダーと統合できます。
- スケーラビリティ: 転送量に応じて自動的にスケールし、高可用性を備えています。
- セキュリティ: VPCエンドポイント、AWS KMSによる暗号化、AWS CloudTrailによる監査ログなど、高いセキュリティ機能を提供します。
これにより、企業はレガシーなファイル転送ワークフローをクラウドに移行し、運用負担を軽減しながら、セキュアでスケーラブルなファイル転送環境を構築できます。
AWS B2B Data Interchange が新しい変換ステータスレポート機能を導入 #
投稿日: 2025年09月30日
何ができるようになったのか #
AWS B2B Data InterchangeがAWSコンソールで新しい変換ステータスレポート機能を導入し、単一のシンプルなユーザーインターフェースでEDIファイルの処理を監視およびトラブルシューティングできるようになりました。このリリースにより、AWSコンソールで直近に実行されたEDI変換のステータスを直接追跡および確認できるようになります。各パートナーシップについて、AWS B2B Data Interchangeは、最大10,000件の直近に処理された入出力ペアの変換ステータス、タイムライン、および検証結果に関する情報を自動的に表示します。
何が嬉しいのか #
この情報により、取引パートナーとのEDI交換のステータスを簡単に追跡し、問題をトラブルシューティングできるようになります。これらすべてを、手動でログエントリを確認することなく、単一のインターフェースで行えます。
これまでとどう変わるのか #
- これまで
- EDI変換のステータス追跡や問題のトラブルシューティングには、手動でログエントリを確認する必要がありました。
- これから
- AWSコンソールで直近のEDI変換ステータスを直接追跡・確認でき、変換ステータス、タイムライン、検証結果が自動的に表示され、単一のインターフェースで完結します。
具体的なユースケース #
- 取引パートナーとのEDI交換のステータスをリアルタイムで監視する。
- EDI変換中に発生した問題を迅速に特定し、トラブルシューティングを行う。
- EDI処理の履歴と検証結果を一元的に確認し、監査やコンプライアンス要件に対応する。
AWS B2B Data Interchangeは、企業間の電子データ交換（EDI）トランザクションを大規模に自動化し、変換するフルマネージドサービスです。ビジネスに不可欠なEDIドキュメントをJSONやXMLなどの一般的なデータ形式に変換できます。
主な特徴は以下の通りです。
- 生成AI支援マッピング: EDIマッピングコードの作成とテストを迅速化し、専門知識の必要性を低減します。
- 一元管理: 取引パートナーとの関係管理、トランザクションの監視、オンボーディングを一元的に行います。
- AWS Transfer Familyとの連携: SFTPやAS2などの標準プロトコルでのファイル転送を容易にします。
- 複雑さとコストの削減: EDI実装にかかる時間、複雑さ、コストを大幅に削減します。
- 従量課金制: 従量課金制の料金モデルでコストを最適化します。
Amazon ECS Managed Instances の発表 #
投稿日: 2025年09月30日
何ができるようになったのか #
Amazon Elastic Container Service (Amazon ECS) Managed Instances がリリースされました。これは、インフラストラクチャ管理のオーバーヘッドを排除しつつ、Amazon EC2 の全機能にアクセスできる、新しいフルマネージドなコンピューティングオプションです。タスクの要件（vCPU 数、メモリサイズ、CPU アーキテクチャなど）を定義するだけで、Amazon ECS が AWS が制御するアクセスを使用して、AWS アカウント内で最適な EC2 インスタンスを自動的にプロビジョニング、設定、運用します。また、GPU アクセラレーション、ネットワーク最適化、バースト可能なパフォーマンスなど、希望するインスタンスタイプを Managed Instances Capacity Provider の設定で指定することも可能です。
何が嬉しいのか #
AWS にインフラストラクチャ運用をオフロードすることで、ワークロードを迅速に起動およびスケーリングでき、パフォーマンスが向上し、総所有コスト (TCO) が削減されます。アプリケーションのパフォーマンスと必要なシンプルさを両立できます。EC2 インスタンスはワークロードの要件に合わせて動的にスケーリングされ、インフラストラクチャコストを削減するためにタスクの配置が継続的に最適化されます。また、14日ごとに開始される定期的なセキュリティパッチ適用により、セキュリティ体制が強化されます。EC2 イベントウィンドウを使用して、週次のメンテナンスウィンドウ内でパッチ適用をスケジュールし、重要な時間帯の中断リスクを最小限に抑えることができます。
これまでとどう変わるのか #
- これまで
- Amazon ECS でコンテナワークロードを実行する場合、ユーザーは基盤となる EC2 インスタンスのプロビジョニング、設定、スケーリング、パッチ適用、および管理を自身で行う必要がありました。これにより、インフラストラクチャ管理のオーバーヘッドが発生し、運用コストや複雑さが増大する可能性がありました。
- これから
- Amazon ECS Managed Instances を利用することで、EC2 インスタンスの管理が AWS に完全にオフロードされます。ユーザーはタスクの要件を定義するだけで、ECS が最適なインスタンスのプロビジョニング、設定、動的なスケーリング、タスク配置の最適化、定期的なセキュリティパッチ適用を自動的に行います。これにより、インフラストラクチャ管理の負担が大幅に軽減され、アプリケーション開発と運用に集中できるようになります。
具体的なユースケース #
- 基盤となる EC2 インスタンスの管理に時間をかけずに、Amazon ECS 上でコンテナ化されたアプリケーションを迅速にデプロイおよびスケーリングしたい場合。
- GPU アクセラレーション、ネットワーク最適化、バースト可能なパフォーマンスなど、特定の EC2 インスタンスタイプを必要とするワークロードを、自動管理された環境で実行したい場合。
- 需要に応じて EC2 インスタンスが自動的にスケーリングされ、コストが最適化されることを望む、変動の大きいワークロード。
- 定期的なセキュリティパッチ適用が自動的に行われ、EC2 イベントウィンドウを使用してメンテナンス時間を制御できる、セキュリティ要件の高いワークロード。
AWS Transform が VMware ネットワーク自動化のための Terraform を有効化 #
投稿日: 2025年09月30日
何ができるようになったのか #
AWS Transform が、VMware 環境からネットワークインフラストラクチャコードを自動生成する追加オプションとして、Terraform をサポートするようになりました。これにより、既存の AWS CloudFormation および AWS Cloud Development Kit (CDK) のサポートに加えて、ソースネットワーク定義を再利用可能な Terraform モジュールに変換できるようになります。
何が嬉しいのか #
組織は、既存のデプロイパイプラインを維持しながら、モジュール式でカスタマイズ可能なネットワーク構成のために、好みのツール（Terraform）を使用できるようになります。これにより、インフラストラクチャのモダナイゼーションが、より迅速かつ高い信頼性で加速されます。
これまでとどう変わるのか #
- これまで
- AWS Transform for VMware は、ネットワーク構成のために AWS CloudFormation および AWS Cloud Development Kit (CDK) テンプレートを生成していました。
- これから
- AWS Transform for VMware は、CloudFormation および CDK テンプレートに加えて、Terraform モジュールも生成できるようになります。
具体的なユースケース #
- VMware ワークロードの検出、計画、移行を自動化し、インフラストラクチャのモダナイゼーションを加速する際に、運用の一貫性を保ちながらネットワーク構成を再作成する。
- Terraform を好みのインフラストラクチャ・アズ・コード (IaC) ツールとして使用している組織が、既存のデプロイパイプラインを変更することなく、AWS Transform を利用して VMware ネットワークの自動化を進める。
AWS OutpostsがDellおよびHPEストレージアレイからの外部ブロックボリュームをサポート開始 #
投稿日: 2025年09月30日
何ができるようになったのか #
AWS Outposts上のAmazon EC2インスタンスで、Dell PowerStoreおよびHPE Alletra Storage MP B10000ストレージアレイによってバックアップされたブートボリュームとデータボリュームを使用できるようになりました。これには、認証済みおよび暗号化されたボリュームも含まれます。
何が嬉しいのか #
- 既存のオンプレミスストレージ投資を最大限に活用し、DellおよびHPEのエンタープライズストレージアレイをブートボリュームとデータボリュームの両方に利用できます。
- 集中管理されたブートボリュームによるOS管理の合理化や、高性能データボリュームによる高度なデータ管理機能など、運用上の大きなメリットが得られます。
- 独自のストレージを統合することで、データレジデンシー要件を満たし、ハイブリッド環境で一貫したクラウド運用モデルの恩恵を受けることができます。
これまでとどう変わるのか #
- これまで
- AWS Outpostsの外部ブロックボリュームは、NetApp®およびPure Storage® FlashArray™のオンプレミスエンタープライズストレージアレイのみをサポートしていました。
- これから
- 既存のサポートに加え、Dell PowerStoreおよびHPE Alletra Storage MP B10000ストレージアレイも外部ブロックボリュームとして利用できるようになりました。これにより、より多くの顧客が既存のストレージ投資を活用できるようになります。
具体的なユースケース #
- オンプレミスにDell PowerStoreまたはHPE Alletra Storage MP B10000ストレージアレイを既に導入している顧客が、それらをAWS OutpostsのEC2インスタンスのブートボリュームやデータボリュームとして活用する。
- データレジデンシー要件が厳しく、データを特定のオンプレミス環境に保持する必要があるワークロードをAWS Outpostsで実行する。
- ハイブリッドクラウド環境において、オンプレミスとAWSクラウド間で一貫した運用モデルを維持しつつ、既存の高性能ストレージを活用してOS管理やデータ管理を効率化する。
AWS Storage Gateway が VPC エンドポイントポリシーをサポート #
投稿日: 2025年09月30日
何ができるようになったのか #
AWS Storage Gateway が、VPC エンドポイントに対して VPC エンドポイントポリシーをサポートするようになりました。これにより、管理者は VPC エンドポイントにエンドポイントポリシーをアタッチし、Storage Gateway のダイレクト API に対してきめ細やかなアクセス制御を行うことができるようになります。
何が嬉しいのか #
Storage Gateway のダイレクト API へのアクセスをより詳細に制御できるようになるため、データ保護とセキュリティ体制が向上します。これにより、セキュリティ要件の厳しい環境でも安心して Storage Gateway を利用できます。
これまでとどう変わるのか #
- これまで
- VPC エンドポイントを介した Storage Gateway のダイレクト API へのアクセス制御は可能でしたが、エンドポイントポリシーによるきめ細やかな制御はできませんでした。
- これから
- VPC エンドポイントにエンドポイントポリシーをアタッチすることで、Storage Gateway のダイレクト API に対して、より詳細なアクセス許可や拒否のルールを設定できるようになります。
具体的なユースケース #
- 特定の VPC エンドポイントを介して、Storage Gateway の特定の API のみへのアクセスを許可する。
- オンプレミスアプリケーションが Storage Gateway と通信する際に、VPC エンドポイント経由でのアクセスを特定のユーザーやロールに限定し、最小権限の原則を適用する。
- 機密性の高いデータを扱うワークロードにおいて、Storage Gateway へのアクセス経路と操作を厳格に制御し、セキュリティコンプライアンス要件を満たす。
AWS Transfer Family が VPC エンドポイントポリシーと FIPS VPC エンドポイントをサポート #
投稿日: 2025年09月30日
何ができるようになったのか #
AWS Transfer Family が VPC エンドポイントの VPC エンドポイントポリシーをサポートするようになりました。この機能により、管理者はインターフェース VPC エンドポイントにエンドポイントポリシーをアタッチでき、Transfer Family API に対するきめ細やかなアクセス制御が可能になります。さらに、Transfer Family は Federal Information Processing Standards (FIPS) 140-3 に準拠した VPC エンドポイントもサポートするようになりました。
何が嬉しいのか #
Transfer Family API に対するきめ細やかなアクセス制御が可能になり、データ保護とセキュリティ体制が向上します。これにより、特定の API アクションを許可または拒否することで、セキュリティリスクを低減し、コンプライアンス要件を満たしやすくなります。FIPS 140-3 準拠の VPC エンドポイントにより、高いセキュリティ要件を持つワークロードにも対応できます。
これまでとどう変わるのか #
- これまで
- これまでは、AWS PrivateLink を利用したインターフェース VPC エンドポイントを通じて、お客様は Transfer Family API に完全にアクセスできました。API アクセス制御は主に IAM ユーザー/ロールポリシーに依存していました。
- これから
- 今回のリリースにより、どの Transfer Family API アクション (CreateServer、StartServer、DeleteServer など) を実行できるか、どのプリンシパルが実行できるか、どのリソースに対して実行できるかを VPC エンドポイントポリシーで管理できるようになりました。これらのポリシーは、既存の IAM ユーザーおよびロールポリシー、組織のサービスコントロールポリシーと連携して機能します。
具体的なユースケース #
- 企業が特定のユーザーやロールに対して、Transfer Family のサーバー作成や削除などの機密性の高い API アクションを制限したい場合。
- データ保護規制（GDPR、HIPAAなど）や社内セキュリティポリシーに準拠するため、API アクセスを厳密に制御する必要がある場合。
- FIPS 140-3 準拠が求められる政府機関や金融機関などのワークロードで、セキュアなファイル転送環境を構築する場合。
- 誤操作による重要なリソースの削除を防ぐために、特定の API アクションをホワイトリスト形式で許可したい場合。
AWS Firewall ManagerがAWSアジアパシフィック（台北）リージョンで利用可能に #
投稿日: 2025年09月30日
何ができるようになったのか #
AWS Firewall ManagerがAWSアジアパシフィック（台北）リージョンで利用可能になりました。これにより、クラウドセキュリティ管理者やサイト信頼性エンジニアは、台北リージョンでホストされているアプリケーションのセキュリティを保護し、手動でのルール設定や管理に伴う運用上のオーバーヘッドを削減できるようになります。
何が嬉しいのか #
- 運用オーバーヘッドの削減: セキュリティルールの手動設定や管理の負担が軽減されます。
- セキュリティの強化: AWS台北リージョンでホストされているアプリケーションやワークロードに対して、AWSセキュリティサービスの全範囲に対応する多層防御ポリシーを適用できます。
- 一元的なセキュリティポリシー管理: AWS WAFなどのセキュリティアセットを使用する際に、AWS Firewall Managerを通じてセキュリティポリシーを一元的に作成・維持できます。
これまでとどう変わるのか #
- これまで
- AWSアジアパシフィック（台北）リージョンではAWS Firewall Managerが利用できなかったため、セキュリティルールの設定や管理は手動で行う必要があり、運用上の負担が大きかった。
- これから
- AWSアジアパシフィック（台北）リージョンでAWS Firewall Managerが利用可能になり、セキュリティポリシーの一元的な管理と自動化を通じて、運用オーバーヘッドを削減し、より堅牢なセキュリティ体制を構築できるようになる。
具体的なユースケース #
- AWS台北リージョンでアプリケーションやワークロードを運用している企業が、複数のAWSセキュリティサービス（AWS WAFなど）にわたるセキュリティポリシーを一元的に管理し、多層防御を実装する。
- セキュリティ管理者やサイト信頼性エンジニアが、新しいアプリケーションを台北リージョンにデプロイする際に、既存のセキュリティポリシーを自動的に適用し、コンプライアンスを維持する。
AWS IAM Identity Centerがアジアパシフィック (バンコク) およびメキシコ中部 (ケレタロ) リージョンで利用可能に #
投稿日: 2025年09月30日
何ができるようになったのか #
AWS IAM Identity Centerが、アジアパシフィック (バンコク) およびメキシコ中部 (ケレタロ) リージョンを含む36のAWSリージョンでデプロイ可能になりました。
何が嬉しいのか #
従業員のAWSアプリケーションへのアクセス管理がより広範なリージョンで可能になり、既存のIDソースを一度接続するだけで、AWS全体でシングルサインオン体験を提供できます。これにより、Amazon QのようなAWSアプリケーションでのパーソナライズされた体験や、Amazon RedshiftなどのAWSサービスにおけるデータへのユーザー認識型アクセスを定義・監査する機能が強化されます。また、複数のAWSアカウントへのアクセスを一元的に管理できるようになり、追加費用なしで利用できます。
これまでとどう変わるのか #
- これまで
- IAM Identity Centerが利用できるAWSリージョンの数が限られていました。特に、アジアパシフィック (バンコク) およびメキシコ中部 (ケレタロ) リージョンでは利用できませんでした。
- これから
- IAM Identity Centerが36のAWSリージョンで利用可能になり、アジアパシフィック (バンコク) およびメキシコ中部 (ケレタロ) リージョンを含む、より多くの地域で従業員のアクセス管理とシングルサインオンを導入できるようになります。
具体的なユースケース #
- 従業員が既存の企業ID (例: Active Directory) を使用して、AWSアカウントやアプリケーションにシングルサインオンでアクセスできるようにする。
- Amazon QなどのAWSアプリケーションで、ユーザーごとにパーソナライズされたエクスペリエンスを提供する。
- Amazon Redshiftのようなデータサービスにおいて、ユーザーの役割や属性に基づいたきめ細やかなデータアクセス制御を定義し、監査する。
- 複数のAWSアカウントを運用している企業が、すべてのアカウントへのアクセスを一元的に管理し、セキュリティと運用効率を向上させる。
Amazon SNSがAWS GovCloud (US) リージョンでIPv6サポートを拡大 #
投稿日: 2025年09月30日
何ができるようになったのか #
Amazon Simple Notification Service (Amazon SNS) が、AWS GovCloud (US) リージョンでInternet Protocol version 6 (IPv6) を介したAPIリクエストをサポートするようになりました。新しいエンドポイントは、Federal Information Processing Standard (FIPS) 140-3 プログラムの下で検証されています。これにより、SNSが利用可能なすべてのリージョン（AWS商用、AWS GovCloud (US)、中国リージョンを含む）でIPv6がサポートされるようになりました。
何が嬉しいのか #
お客様は、デュアルスタックのパブリックエンドポイントまたはVPCエンドポイントを介してリクエストを送信する際に、IPv6またはIPv4のいずれかを選択できるようになります。これにより、ネットワークの柔軟性が向上し、IPv6への移行を進めている組織や、FIPS 140-3に準拠したセキュリティ要件を持つ組織にとって、より安全でコンプライアンスに準拠したメッセージングが可能になります。
これまでとどう変わるのか #
- これまで
- AWS GovCloud (US) リージョンではAmazon SNSのIPv6サポートが利用できませんでした。
- IPv6エンドポイントに対するFIPS 140-3の検証は明示されていませんでした。
- これから
- AWS GovCloud (US) リージョンを含む、SNSが利用可能なすべてのリージョンでIPv6を介したAPIリクエストが可能になります。
- 新しいIPv6エンドポイントはFIPS 140-3の検証を受けており、より高いセキュリティとコンプライアンスを提供します。
- お客様はIPv4とIPv6のどちらかを選択して利用できます。
具体的なユースケース #
- 政府機関や規制の厳しい業界での利用: FIPS 140-3の要件を満たす必要がある政府機関や、高度なセキュリティとコンプライアンスが求められる業界のアプリケーションで、Amazon SNSをIPv6経由で安全に利用できます。
- IPv6へのネットワーク移行: IPv6へのネットワークインフラストラクチャの移行を進めている組織が、Amazon SNSとの通信をIPv6に切り替えることで、ネットワークの近代化を推進できます。
- デュアルスタック環境での柔軟なデプロイ: IPv4とIPv6が混在するデュアルスタック環境において、アプリケーションがどちらのプロトコルでもAmazon SNSと通信できるようになり、デプロイの柔軟性が向上します。