はじめに #
AWSの基礎力をつけるためにAWS What’s Newを毎日目を通す事を始めました。 最初は日本語訳されたものを見ていたのですが、1週間ほど遅れて訳されるようなので、英語の情報を訳して整理することにしました。
本情報が役立つ人もいるかなと思い公開します。 個人的な理解なので、実際の情報は原典をあたってください。
まとめと気づき #
「Amazon S3 が S3 汎用バケットでの条件付き削除をサポート」は便利そうですね。API呼び出しの削減や処理のアトミック性が高まることで実装容易性が高まりそうです。
Amazon AppStream 2.0 が分数型 GPU インスタンスのサポートを追加 #
投稿日: 2025年09月16日
何ができるようになったのか #
Amazon AppStream 2.0 が、EC2 G6 ファミリーをベースにした分数型 GPU サイズの Graphics G6 インスタンス (G6f および Gr6f) をサポートするようになりました。これにより、ユーザーは必要な GPU リソースのみを利用し、フル GPU インスタンスをプロビジョニングすることなく、共有 GPU 容量を通じてリソースを最適化できるようになります。1/2、1/4、1/8 といったより小さな GPU 分数を選択できる柔軟性が提供されます。
何が嬉しいのか #
フル GPU パワーを必要としないグラフィックアプリケーション向けに、GPU リソースの過剰なプロビジョニングを回避することでコストを削減できます。必要な分だけの GPU 容量を利用できるため、リソースの最適化が進み、費用対効果の高い運用が可能になります。
これまでとどう変わるのか #
- これまで
- グラフィックアプリケーションで GPU を利用する場合、フル GPU インスタンスをプロビジョニングする必要があり、必要以上のリソースを消費し、コストが増加する可能性がありました。
- これから
- 分数型 GPU サイズのインスタンスを選択できるようになり、アプリケーションの要件に合わせて 1/2、1/4、1/8 といった小さな GPU 分数を柔軟に利用することで、リソースの最適化とコスト削減が可能になります。
具体的なユースケース #
- フル GPU パワーを必要としない、より小さな GPU 分数で十分なグラフィックアプリケーションの実行。
- コスト効率を重視し、GPU リソースの過剰なプロビジョニングを避けたい組織。
Amazon EKS が AWS GovCloud (US) リージョンでコミュニティアドオンの新しいカタログを導入 #
投稿日: 2025年09月16日
何ができるようになったのか #
Amazon Elastic Kubernetes Service (EKS) が、metrics-server、kube-state-metrics、cert-manager、prometheus-node-exporter、fluent-bit、external-dns などのコミュニティアドオンの新しいカタログを導入しました。これにより、EKS を通じて直接、人気のオープンソース Kubernetes アドオンを簡単に見つけ、選択し、設定し、管理できるようになりました。各アドオンは EKS によってパッケージ化、スキャン、互換性検証が行われ、コンテナイメージは EKS が所有するプライベートな Amazon Elastic Container Registry (ECR) リポジトリに安全にホストされています。この機能はすべての AWS GovCloud (US) リージョンで利用可能です。
何が嬉しいのか #
Kubernetes クラスターを本番環境対応にするために必要な様々な運用ツールやアドオンの統合が大幅に簡素化されます。EKS がアドオンの互換性を検証し、安全にホストするため、ユーザーはアドオンの選定や管理にかかる手間を削減し、より広範なアドオンを安心して利用できます。AWS およびコミュニティアドオンの両方に対して統一された管理体験が提供され、EKS コンソール、API、CLI、eksctl、または AWS CloudFormation のような IaC ツールを通じて直接管理できます。
これまでとどう変わるのか #
- これまで
- ユーザーは、Kubernetes クラスターに必要な運用ツールやアドオンを様々なソースから個別に探し、手動で統合し、互換性を確認し、コンテナイメージのセキュリティを自身で管理する必要がありました。これは複雑で時間のかかる作業でした。
- これから
- EKS がキュレーションしたコミュニティアドオンのカタログが提供され、アドオンは事前にパッケージ化、スキャン、検証済みで、安全な ECR リポジトリにホストされています。これにより、アドオンの発見、インストール、管理が簡素化され、統一されたエクスペリエンスで利用できるようになります。
具体的なユースケース #
- モニタリングとメトリクス収集の導入:
metrics-server
やprometheus-node-exporter
を利用して、Kubernetes クラスターのパフォーマンスとリソース使用状況を監視します。 - TLS 証明書の自動管理:
cert-manager
を使用して、クラスター内のサービスに対する TLS 証明書のプロビジョニングと更新を自動化します。 - 集中型ログ収集:
fluent-bit
をデプロイして、クラスター内のコンテナログを収集し、中央のログ管理システムに転送します。 - 外部 DNS の管理:
external-dns
を利用して、Kubernetes サービスを外部 DNS プロバイダーに自動的に公開します。 - GovCloud 環境でのコンプライアンス要件の簡素化: AWS GovCloud (US) リージョンで、EKS によって検証され、安全にホストされたアドオンを使用することで、セキュリティとコンプライアンスの要件を満たしやすくなります。
Fluent Bitは、軽量で高性能なログプロセッサおよびフォワーダです。
様々なソースからログやメトリクスを収集し、フィルタリング、変換、そして異なる宛先(ストレージ、分析ツールなど)へ転送することができます。
主な特徴は以下の通りです。
- 軽量性: 非常に少ないリソース(CPU、メモリ)で動作するように設計されており、エッジデバイスや組み込みシステム、コンテナ環境など、リソースが限られた環境での使用に適しています。
- 高性能: 高いスループットと低いレイテンシでデータを処理できます。
- 柔軟性: 多数の入力プラグイン(ファイル、システムログ、HTTPなど)と出力プラグイン(Amazon S3, Elasticsearch, Kafka, Datadogなど)をサポートしており、様々なデータパイプラインを構築できます。
- コンテナ対応: Kubernetesなどのコンテナオーケストレーション環境でのログ収集によく利用されます。
Fluentdと似ていますが、Fluent Bitはより軽量で、主にエッジやコンテナ環境でのログ収集に特化しています。
Amazon Aurora PostgreSQL Limitless Database が AWS GovCloud (米国東部、米国西部) リージョンで利用可能に #
投稿日: 2025年09月16日
何ができるようになったのか #
AWS GovCloud (米国東部、米国西部) リージョンで Amazon Aurora PostgreSQL Limitless Database が利用可能になりました。これにより、リレーショナルデータベースのワークロードを簡単にスケールできるようになります。この機能は、複数の Amazon Aurora Serverless インスタンス間でデータとクエリを自動的に分散するサーバーレスエンドポイントを提供し、単一データベースのトランザクション整合性を維持します。分散クエリプランニングとトランザクション管理の機能も提供されます。
何が嬉しいのか #
カスタムソリューションを作成したり、スケールするために複数のデータベースを管理したりする必要がなくなります。ワークロードが増加すると、Aurora PostgreSQL Limitless Database は指定された予算内で追加のコンピューティングリソースを自動的に追加するため、ピーク時のプロビジョニングが不要になり、需要が低いときにはコンピューティングが自動的にスケールダウンします。これにより、運用が簡素化され、コストが最適化されます。
これまでとどう変わるのか #
- これまで
- GovCloud でリレーショナル PostgreSQL データベースをスケールするには、手動でのシャーディング、複数のデータベースインスタンスの管理、またはワークロードを分散するためのカスタムソリューションが必要でした。これにより、過剰なプロビジョニングや不足が生じたり、運用上のオーバーヘッドが増加したりする可能性がありました。
- これから
- GovCloud の Aurora PostgreSQL Limitless Database は、スケーリングを自動化し、データとクエリを分散し、トランザクションを管理し、コンピューティングを自動的にスケールアップおよびスケールダウンするため、運用が簡素化され、コストが最適化されます。
具体的なユースケース #
- AWS GovCloud で、トランザクション整合性を維持しながら、高いスケーラビリティを必要とするリレーショナルデータベースワークロード。
- 需要の変動が大きく、ピーク時のプロビジョニングを避けたいワークロード。
- 複数のデータベースインスタンスを管理することなく、データベースのスケーリングを簡素化したい場合。
Amazon Lex が生成 AI ベースの自然言語理解を 8 つの新しい言語で提供開始 #
投稿日: 2025年09月16日
何ができるようになったのか #
Amazon Lex が、生成AI(大規模言語モデル、LLM)を活用して、決定論的な会話型AIボットの自然言語理解能力を向上させることができるようになりました。この機能は、中国語、日本語、韓国語、ポルトガル語、カタロニア語、フランス語、イタリア語、ドイツ語の8つの新しい言語で利用可能です。
何が嬉しいのか #
音声およびチャットボットが、より複雑な発話を適切に処理し、スペルミスがあっても精度を維持し、冗長な入力から重要な情報を抽出して顧客のリクエストを正確に満たすことができるようになります。これにより、顧客体験が向上し、ボットの効率性が高まります。
これまでとどう変わるのか #
- これまで
- Amazon Lexの会話型AIボットは、特定の言語において、複雑な発話、スペルミス、冗長な入力に対する自然言語理解の精度に限界がありました。
- これから
- 生成AI(LLM)の活用により、8つの新しい言語(中国語、日本語、韓国語、ポルトガル語、カタロニア語、フランス語、イタリア語、ドイツ語)で、より高度な自然言語理解が可能になり、ボットが顧客の意図をより正確に把握できるようになります。
具体的なユースケース #
- 顧客が「妻と2人の子供と私のためにフライトを予約したい」と発話した場合でも、LLMが「4人分のフライトチケットを予約する」という意図を適切に識別し、予約処理を進めることができます。
Amazon Lex(アマゾン レックス)は、音声やテキストを使用して、あらゆるアプリケーションに会話型インターフェースを構築するためのフルマネージド型サービスです。
主な特徴は以下の通りです。
- 自然言語理解 (NLU): ユーザーの意図を理解し、会話から関連情報を抽出します。
- 自動音声認識 (ASR): 音声をテキストに変換します。
- ボットの構築: 質問応答、タスクの実行、複雑な会話フローの管理などを行うボットを簡単に作成できます。
- スケーラビリティ: AWSのインフラストラクチャ上で動作するため、高いスケーラビリティと信頼性を提供します。
- 統合: AWS Lambda、Amazon Connect、Amazon Cognitoなどの他のAWSサービスと簡単に統合できます。
Amazon Lexは、Amazon Alexaの基盤となっている技術と同じものであり、チャットボット、コールセンターの自動応答、IoTデバイスの音声インターフェースなど、幅広いユースケースで利用されています。
Amazon EC2 がすべての NVMe ローカルボリュームで詳細なパフォーマンス統計をサポート #
投稿日: 2025年09月16日
何ができるようになったのか #
Amazon EC2 インスタンスストア NVMe ボリュームの詳細なパフォーマンス統計が利用可能になりました。これにより、AWS Nitro System ベースの EC2 インスタンスストア NVMe ボリュームのパフォーマンスをリアルタイムで可視化できるようになります。キュー長、IOPS、スループット、詳細な I/O レイテンシーヒストグラムを含む11種類の包括的なメトリクスを1秒間隔で監視できます。
何が嬉しいのか #
ストレージの状態を簡単に監視し、アプリケーションのパフォーマンス問題を迅速に解決できるようになります。これらの詳細なメトリクスにより、パフォーマンスの変動によって影響を受ける特定のワークロードを特定し、アプリケーションの I/O パターンを最適化して最大の効率を実現できます。また、I/O サイズ別に分類されたレイテンシーヒストグラムにより、パフォーマンスパターンに関するさらに詳細な洞察が得られます。EBS ボリュームと同様の一貫した監視エクスペリエンスが提供されます。
これまでとどう変わるのか #
- これまで
- EC2 インスタンスストア NVMe ボリュームの I/O パフォーマンスに関する詳細なリアルタイム統計が直接利用できませんでした。
- ストレージの健全性やアプリケーションのパフォーマンス問題を特定する際に推測に頼る必要がありました。
- これから
- EC2 インスタンスストア NVMe ボリュームの I/O パフォーマンスに関する11種類の詳細なメトリクス(キュー長、IOPS、スループット、レイテンシーヒストグラムなど)を1秒間隔で監視できます。
- ストレージの健全性をリアルタイムで把握し、アプリケーションのパフォーマンス問題を迅速かつ正確に診断・解決できるようになります。
- EBS ボリュームと同様の監視エクスペリエンスにより、ストレージタイプ間での一貫性が向上します。
具体的なユースケース #
- パフォーマンス問題のトラブルシューティング: アプリケーションの I/O 性能が低下した際に、どの NVMe ボリュームがボトルネックになっているか、具体的な IOPS、スループット、レイテンシーの数値を確認して原因を特定します。
- ワークロードの最適化: 特定の I/O パターン(例:小さな I/O サイズでの高レイテンシー)を詳細なレイテンシーヒストグラムで分析し、アプリケーションのコードや設定を調整してストレージ効率を最大化します。
- キャパシティプランニング: NVMe ボリュームの使用状況とパフォーマンス傾向を長期的に監視し、将来のワークロード増加に備えて適切なインスタンスタイプやストレージ構成を計画します。
- コスト最適化: 不要な高性能インスタンスの使用を避け、実際の I/O 要件に基づいて最適な EC2 インスタンスを選択することで、コストを削減します。
AWS Storage Gateway が IPv6 をサポート #
投稿日: 2025年09月16日
何ができるようになったのか #
AWS Storage Gateway のエンドポイント、API、およびゲートウェイアプライアンスインターフェースで Internet Protocol version 6 (IPv6) がサポートされるようになりました。これにより、新しいデュアルスタックエンドポイントを通じて IPv6 と IPv4 の両方でアクセスできるようになります。
何が嬉しいのか #
顧客は、AWS Storage Gateway リソースを管理するためのアプリケーションとワークフローを IPv6 に標準化できると同時に、IPv4 クライアントとの後方互換性を維持できます。新しいデュアルスタック機能を使用することで、一度にすべてのネットワークを切り替えることなく、IPv4 から IPv6 へ段階的に移行することが可能になります。
これまでとどう変わるのか #
- これまで
- AWS Storage Gateway は IPv4 のみをサポートしていました。
- これから
- IPv6 と IPv4 の両方をサポートするデュアルスタックエンドポイントが利用可能になり、既存の IPv4 のみのエンドポイントも引き続き利用できます。
具体的なユースケース #
- IPv6 への移行を計画している企業が、Storage Gateway リソースの管理において IPv6 を標準化し、段階的に移行を進める場合。
- IPv6 のみで構成されたネットワーク環境から AWS Storage Gateway にアクセスする必要がある場合。
AWS Storage Gatewayは、オンプレミス環境とAWSクラウド間のストレージ統合を容易にするハイブリッドクラウドストレージサービスです。オンプレミスのアプリケーションから、実質的に無制限のクラウドストレージ(Amazon S3、Amazon FSx for Windows File Serverなど)へアクセスできるようにします。
主な特徴は以下の通りです。
- ハイブリッドクラウドの実現: オンプレミス環境のアプリケーションをそのままに、データ保存領域だけをクラウドに拡張・移行できます。
- プロトコル変換: オンプレミスで一般的に使用されるNFS/SMBプロトコルやiSCSIプロトコルと、クラウドストレージ(Amazon S3など)のHTTPS通信との橋渡しをします。
- ストレージ容量の柔軟性: Amazon S3やAmazon FSx for Windows File Serverをデータ格納先として利用するため、事実上無制限のデータ格納容量を利用できます。
- パフォーマンスの向上: オンプレミス側のユーザーから見て、Storage Gatewayにデータが書き込まれた時点で書き込みが完了するため、クラウドストレージに直接書き込むよりも低レイテンシーでのデータ書き込みを実現できます。
- セキュリティ: ゲートウェイアプライアンスとAWS間のデータ転送はSSLで暗号化され、セキュアなアップロードとダウンロードが可能です。
AWS Storage Gatewayには、データの特性や用途に応じて以下の3つのタイプがあります。
- ファイルゲートウェイ (File Gateway): オンプレミスのファイルデータをNFS/SMBプロトコルでS3オブジェクトとして保存します。
- ボリュームゲートウェイ (Volume Gateway): オンプレミスアプリケーションにiSCSIブロックストレージボリュームを提供し、データをAmazon S3に保存したり、Amazon EBSに移行したりできます。キャッシュ型と保管型の2種類があります。
- キャッシュ型ボリューム: 頻繁にアクセスするデータのみをローカルにキャッシュし、プライマリデータはS3に保存されます。
- 保管型ボリューム: すべてのデータをローカルディスクに保存し、非同期的にAWSにバックアップします。
- テープゲートウェイ (Tape Gateway): 物理テープライブラリの代替として仮想テープライブラリを提供し、バックアップデータをAmazon S3やGlacierに保存します。
Amazon EC2 R8i および R8i-flex インスタンスが追加リージョンで利用可能に #
投稿日: 2025年09月16日
何ができるようになったのか #
Amazon Elastic Compute Cloud (Amazon EC2) R8i および R8i-flex インスタンスが、アジアパシフィック (マレーシア、シンガポール) およびヨーロッパ (フランクフルト) リージョンで利用可能になりました。これらのインスタンスは、AWS専用のカスタムIntel Xeon 6プロセッサを搭載しており、クラウド上の同等Intelプロセッサの中で最高のパフォーマンスと最速のメモリ帯域幅を提供します。
何が嬉しいのか #
以前の世代のIntelベースのインスタンスと比較して、最大15%優れた価格性能と2.5倍のメモリ帯域幅を提供します。R7iインスタンスと比較して20%優れたパフォーマンスを提供し、特定のワークロードではさらに高いゲインが得られます。R8i-flexは、メモリ集約型ワークロードの大部分で価格性能のメリットを最も簡単に得られる方法であり、R8iインスタンスは、最大のインスタンスサイズや継続的な高いCPU使用率を必要とするすべてのメモリ集約型ワークロードに最適です。また、R8iインスタンスはSAP認定を受けており、ミッションクリティカルなSAPワークロードに優れたパフォーマンスを提供します。
これまでとどう変わるのか #
- これまで
- Amazon EC2 R8i および R8i-flex インスタンスは、アジアパシフィック (マレーシア、シンガポール) およびヨーロッパ (フランクフルト) リージョンでは利用できませんでした。
- 以前の世代のIntelベースのインスタンスやR7iインスタンスは、R8i/R8i-flexインスタンスと比較して、価格性能、メモリ帯域幅、および特定のワークロードにおけるパフォーマンスが劣っていました。
- これから
- Amazon EC2 R8i および R8i-flex インスタンスが、アジアパシフィック (マレーシア、シンガポール) およびヨーロッパ (フランクフルト) リージョンで利用可能になり、これらのリージョンで高性能なメモリ集約型ワークロードを実行できるようになります。
- 最大15%優れた価格性能、2.5倍のメモリ帯域幅、R7iインスタンスと比較して20%優れたパフォーマンス、および特定のワークロード(PostgreSQL、NGINX、AIディープラーニング、SAP)で大幅な高速化を実現します。
具体的なユースケース #
- メモリ集約型ワークロード全般(R8i-flexは価格性能を重視する場合、R8iは最大のインスタンスサイズや継続的な高いCPU使用率を必要とする場合)
- PostgreSQLデータベース (最大30%高速)
- NGINXウェブアプリケーション (最大60%高速)
- AIディープラーニング推奨モデル (最大40%高速)
- ミッションクリティカルなSAPワークロード
Amazon OpenSearch Service がストレージ最適化のための Derived Source を発表 #
投稿日: 2025年09月16日
何ができるようになったのか #
Amazon OpenSearch Service が Derived Source のサポートを開始しました。これにより、_source
フィールドの保存をスキップし、必要に応じて動的に再構築できるようになり、OpenSearch Service ドメインに必要なストレージ量を削減できます。
何が嬉しいのか #
OpenSearch Service ドメインのストレージ使用量を大幅に削減できるため、運用コストの削減につながります。
これまでとどう変わるのか #
- これまで
- OpenSearch は、取り込まれた各ドキュメントを
_source
フィールドに保存し、個々のフィールドも検索用にインデックス化していました。この_source
フィールドがかなりのストレージ容量を消費していました。
- OpenSearch は、取り込まれた各ドキュメントを
- これから
- Derived Source を有効にすることで、
_source
フィールドの保存をスキップし、検索、取得、複数取得、再インデックス、更新などの操作時に必要に応じて動的に再構築できるようになります。
- Derived Source を有効にすることで、
具体的なユースケース #
_source
フィールドが大きく、ストレージコストが懸念されるが、検索や更新などの操作時に_source
データが必要となるワークロード。- ストレージ容量を最適化し、OpenSearch Service ドメインの運用コストを削減したい場合。
- インデックス作成時に複合インデックス設定を使用して、特定のインデックスでストレージ最適化を細かく制御したい場合。
Amazon OpenSearch Service が Star-Tree Index を発表 #
投稿日: 2025年09月16日
何ができるようになったのか #
OpenSearch に Star-Tree Index という新機能が導入されました。これにより、カーディナリティの高い多次元クエリにおける集計パフォーマンスが大幅に向上します。このインデックスは、取り込み時に設定されたディメンションとメトリクスにわたってデータを事前集計し、terms
、histogram
、range
のような頻繁な集計に対して秒以下の応答時間を可能にします。クエリ構文の変更は不要で、OpenSearch がサポートされているクエリを検出すると自動的に最適化されたパスを使用します。
何が嬉しいのか #
リアルタイム分析において、大規模なデータセットに対する集計パフォーマンスが劇的に向上し、秒以下の応答時間で結果を得られるようになります。これにより、ユーザーはより迅速に洞察を得て、意思決定を行うことができます。また、既存のクエリ構文を変更する必要がないため、導入が容易です。
これまでとどう変わるのか #
- これまで
- カーディナリティの高い多次元クエリの集計には時間がかかり、大規模なデータセットでは応答時間が長くなる可能性がありました。
- リアルタイム分析のパフォーマンスを最適化するためには、手動でのデータ集計や複雑なクエリの調整が必要になる場合がありました。
- これから
- Star-Tree Index がデータを事前集計するため、カーディナリティの高い多次元クエリでも秒以下の応答時間で集計結果が得られます。
- OpenSearch が自動的に最適化されたパスを使用するため、クエリ構文を変更することなく、リアルタイム分析のパフォーマンスが向上します。
具体的なユースケース #
- オブザーバビリティ: ログやメトリクスデータに対するリアルタイムな集計と分析により、システムの健全性やパフォーマンスを迅速に監視できます。
- パーソナライゼーション: ユーザー行動データに対する高速な集計を通じて、パーソナライズされたコンテンツや推奨事項をリアルタイムで提供できます。
- 時系列ダッシュボード: 大量の時系列データから、トレンドや異常を迅速に特定するためのインタラクティブなダッシュボードを構築できます。
Amazon EC2 I7i インスタンスが南米 (サンパウロ)、カナダ西部 (カルガリー) リージョンで利用可能に #
投稿日: 2025年09月16日
何ができるようになったのか #
高性能なストレージ最適化Amazon EC2 I7iインスタンスが、AWS南米 (サンパウロ) およびカナダ西部 (カルガリー) リージョンで利用可能になりました。これらのインスタンスは、第5世代Intel Xeon Scalableプロセッサと第3世代AWS Nitro SSDを搭載しており、最大16KBブロックサイズまでのtorn write prevention機能をサポートしています。
何が嬉しいのか #
I7iインスタンスは、以前の世代のI4iインスタンスと比較して、最大23%優れたコンピューティング性能と10%以上の価格性能を提供します。ストレージ性能は最大50%向上し、ストレージI/Oレイテンシーは最大50%低減、ストレージI/Oレイテンシーの変動性は最大60%低減されます。これにより、I/O集中型およびレイテンシーに敏感なワークロードにおいて、より高いパフォーマンスと安定性を実現できます。また、torn write prevention機能により、データベースのパフォーマンスボトルネックを解消できます。
これまでとどう変わるのか #
- これまで
- I4iインスタンスでは、コンピューティング性能、ストレージ性能、I/Oレイテンシー、レイテンシー変動性、価格性能がI7iインスタンスよりも劣っていました。また、16KBブロックサイズまでのtorn write prevention機能は利用できませんでした。
- これから
- I7iインスタンスにより、コンピューティング性能が最大23%向上し、価格性能も10%以上向上します。ストレージ性能は最大50%向上し、I/Oレイテンシーは最大50%低減、レイテンシー変動性は最大60%低減されます。さらに、16KBブロックサイズまでのtorn write prevention機能が利用可能になり、データベースのボトルネックを解消できます。
具体的なユースケース #
- I/O集中型でレイテンシーに敏感なワークロード
- リアルタイムのレイテンシーで中小規模のデータセット (数TB) にアクセスするために、非常に高いランダムIOPS性能を必要とするワークロード
- データベースのパフォーマンスボトルネックの解消
AWS FIS に Amazon EBS ボリュームへの I/O レイテンシー注入を可能にする新しいフォールトアクションが追加 #
投稿日: 2025年09月16日
何ができるようになったのか #
AWS Fault Injection Service (FIS) に、Amazon EBS ボリュームに I/O レイテンシーを注入する新しいフォールトアクションが追加されました。これにより、ミッションクリティカルなアプリケーションがストレージ障害にどのように応答するかを理解するための、制御されたテスト実験を実行できるようになりました。
何が嬉しいのか #
この機能により、以下の恩恵が受けられます。
- ストレージ障害に対するミッションクリティカルなアプリケーションの応答を理解し、高可用性を確保するための監視および復旧プロセスを微調整できます。
- アプリケーションがストレージの I/O レイテンシー上昇による中断に耐え、迅速に復旧できるという確信を深めることができます。
- Amazon CloudWatch アラームやオペレーティングシステムのタイムアウトなど、ストレージパフォーマンスの問題中に発生する実際の信号をシミュレートできます。
これまでとどう変わるのか #
- これまで
- EBS ボリュームの I/O レイテンシー上昇に対するアプリケーションの耐性をテストするには、手動でのシミュレーションやカスタムツールの開発が必要で、制御が難しく、実際の障害シナリオを再現するのが困難でした。
- これから
- AWS FIS を利用して、EBS ボリュームに I/O レイテンシーを簡単に注入し、パフォーマンス低下をシミュレートできるようになりました。これにより、カオスエンジニアリングやストレージ障害に対する回復力テストが簡素化され、より体系的かつ効率的に実施できるようになります。
具体的なユースケース #
- 高いストレージレイテンシーに対するアーキテクチャのテスト。
- アプリケーションの動作を観察し、監視および復旧プロセスを微調整する。
- 既存のカオスエンジニアリングテスト、継続的インテグレーション、およびリリーステストにレイテンシー注入実験を統合する。
- 複数の FIS アクションを組み合わせて、より複雑な障害シナリオをシミュレートする。
- Oracle、SAP HANA、Microsoft SQL Server などのレイテンシーに敏感なアプリケーションの回復力テスト。
Amazon S3 が S3 汎用バケットでの条件付き削除をサポート #
投稿日: 2025年09月16日
何ができるようになったのか #
Amazon S3 汎用バケットで条件付き削除がサポートされるようになりました。これにより、オブジェクトが変更されていないことを確認してから削除できるようになります。具体的には、HTTP の if-match
ヘッダーと ETag 値を使用して条件付き削除を実行できます。提供された ETag がオブジェクトの ETag と一致する場合にのみ、削除リクエストが成功します。さらに、S3 バケットポリシーで s3:if-match
条件キーを使用して、条件付き削除操作を強制することも可能です。
何が嬉しいのか #
高並行性、複数書き込みのシナリオにおいて、意図しない削除を防ぐことができます。これにより、バケット内のオブジェクトが誤って削除されるリスクを最小限に抑え、データの整合性と安全性を向上させることができます。
これまでとどう変わるのか #
- これまで
- オブジェクトの削除時に、そのオブジェクトが他のプロセスによって変更されていないかを確認するメカニズムが組み込まれていなかったため、高並行環境で意図しない削除が発生するリスクがありました。
- これから
if-match
ヘッダーやs3:if-match
条件キーを使用することで、削除前にオブジェクトの ETag を検証し、オブジェクトが変更されていないことを確認できるようになりました。これにより、誤削除のリスクを大幅に低減できます。
具体的なユースケース #
- 複数のアプリケーションやユーザーが同時に S3 オブジェクトを操作する環境で、
DeleteObject
やDeleteObjects
API リクエストに対して HTTPif-match
ヘッダーの使用をクライアントに要求することで、誤ってオブジェクトが削除されるのを防ぎます。 - 重要な設定ファイルやデータファイルが、古いバージョンに基づいて誤って削除されることを防ぎ、システムの安定性を確保します。
AWS Transfer Family が AWS アジアパシフィック (台北) リージョンで利用可能に #
投稿日: 2025年09月16日
何ができるようになったのか #
AWS Transfer Family が AWS アジアパシフィック (台北) リージョンで利用可能になりました。これにより、Secure File Transfer Protocol (SFTP)、File Transfer Protocol (FTP)、FTP over SSL (FTPS)、および Applicability Statement 2 (AS2) を介したファイル転送を、このリージョンで利用できるようになります。
何が嬉しいのか #
Amazon Simple Storage Service (Amazon S3) および Amazon Elastic File System (Amazon EFS) へのファイル転送を、SFTP、FTP、FTPS、AS2 プロトコルを介してフルマネージドで実行できるようになります。また、ファイル転送に加えて、マネージドファイル転送 (MFT) ワークフローのための一般的なファイル処理とイベント駆動型自動化が可能になり、顧客はビジネス間のファイル転送をモダナイズし、AWS に移行できるようになります。
これまでとどう変わるのか #
- これまで
- AWS アジアパシフィック (台北) リージョンでは、AWS Transfer Family を利用できず、このリージョンでセキュアなマネージドファイル転送サービスを利用するには、他の方法を検討する必要がありました。
- これから
- AWS アジアパシフィック (台北) リージョンのお客様は、SFTP、FTP、FTPS、AS2 を使用して、Amazon S3 および Amazon EFS へのセキュアでフルマネージドなファイル転送を容易に設定・実行できるようになります。
具体的なユースケース #
- ビジネス間のファイル転送 (B2B) を AWS にモダナイズし、移行する。
- SFTP、FTP、FTPS、AS2 プロトコルを使用して、Amazon S3 や Amazon EFS にファイルをセキュアに転送する。
- マネージドファイル転送 (MFT) ワークフローを自動化し、ファイル処理を効率化する。

AWSの基本・仕組み・重要用語が全部わかる教科書 (見るだけ図解) 単行本(ソフトカバー) – 2022/8/23
¥2,970
Amazonで見る