AWSの基礎力をつけるためにAWS What’s Newを毎日目を通す事を始めました。 最初は日本語訳されたものを見ていたのですが、1週間ほど遅れて訳されるようなので、英語の情報を訳して整理することにしました。
本情報が役立つ人もいるかなと思い公開します。 個人的な理解なので、実際の情報は原典をあたってください。
¥3,520 Amazonで見る![AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本（ソフトカバー） – 2025/7/11](https://m.media-amazon.com/images/I/61ftnZ09WvL._SY522_.jpg)
AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本（ソフトカバー） – 2025/7/11
感想 #
Amazon ECRがプッシュ時のリポジトリ作成をサポート したとのこと。 CICDでリポジトリ作ってからイメージをプッシュする順番を面倒と思った人に朗報。
Amazon SESがメール検証を発表。これは割と便利かもしれない。
Amazon ECSがAWS Fargateでのタスクリタイアメントをスケジュールするための週次イベントウィンドウを定義可能に。通常タスクが順次更新されるからいつタスクがリタイアしても問題ないはずだけど、スケジュールできると安心な気もする。
AWS Control Towerが176の新しいAWS Security Hubコントロールを発表 #
投稿日: 2025年12月18日
何ができるようになったのか #
AWS Control Towerのコントロールカタログにおいて、新たに176個のAWS Security Hubコントロールがサポートされました。これにより、セキュリティ、コスト、耐久性、運用といった多様なユースケースにおいて、これらのコントロールをAWS Control Towerから直接検索、発見、有効化、管理できるようになりました。
何が嬉しいのか #
マルチアカウント環境において、より広範なユースケースに対するガバナンスを強化できます。Security Hubの強力なコントロール群をControl Towerの管理下で一元的に扱えるため、運用負荷の軽減とセキュリティポスチャの向上が期待できます。
これまでとどう変わるのか #
- これまで: これらのSecurity HubコントロールはControl Towerのコントロールカタログから直接管理・適用することができませんでした。
- これから: コントロールカタログで「AWS Security Hub」を所有者としてフィルタリングすることで、これらすべてのコントロールを確認し、Control TowerコンソールやAPI（ListControls, GetControl, EnableControl）から直接有効化できるようになりました。
具体的なユースケース #
- セキュリティ基準に準拠するために、特定のSecurity Hubコントロールを組織全体のアカウントにControl Tower経由で適用する。
- コントロールカタログで必要な機能を検索し、そのままデプロイまでワンストップで行う。
Amazon Application Recovery Controllerのリージョンスイッチが3つの新機能をサポート #
投稿日: 2025年12月19日
何ができるようになったのか #
Amazon Application Recovery Controller (ARC) のリージョンスイッチ機能に、以下の3つの新しい機能が追加されました。
- AWS GovCloud (US) のサポート: AWS GovCloud (US-EastおよびUS-West) リージョンで一般利用可能になりました。
- 計画実行レポート: 各計画の実行から包括的なレポートを自動生成し、指定したAmazon S3バケットに保存できるようになりました。
- DocumentDB グローバルクラスター実行ブロック: 自動化されたマルチリージョンデータベース復旧のために、Amazon DocumentDBグローバルクラスターの実行ブロックをサポートしました。
何が嬉しいのか #
リージョンスイッチによる復旧作業のエンジニアリング工数を削減し、運用オーバーヘッドを排除します。特に自動生成されるレポート機能は、コンプライアンス担当者や監査人のための証拠収集や文書化の手間を大幅に削減します。また、DocumentDBを利用しているシステムでも、ARCを用いたフェイルオーバーのオーケストレーションが可能になります。
これまでとどう変わるのか #
- これまで: 復旧成功の証拠を手動で収集・文書化する必要がありました。また、DocumentDBのフェイルオーバーをARCの計画に組み込むためのネイティブなブロックがありませんでした。
- これから: 実行レポートが自動生成され、S3に保存されます。レポートにはイベントのタイムライン、対象リソース、アラーム状態、RTO計算などが含まれます。また、DocumentDBグローバルクラスターのフェイルオーバーとスイッチオーバーを計画内でオーケストレーションできるようになります。
具体的なユースケース #
- 定期的な災害復旧訓練（DR訓練）を実施し、その結果として自動生成された詳細なレポートを監査証跡として保存する。
- Amazon DocumentDBグローバルクラスターを使用するアプリケーションのリージョン切り替えプロセスをARCで自動化する。
Amazon AuroraがPostgreSQL 17.7, 16.11, 15.15, 14.20, 13.23をサポート #
投稿日: 2025年12月18日
何ができるようになったのか #
Amazon Aurora PostgreSQL互換エディションで、PostgreSQLの新しいマイナーバージョン（17.7, 16.11, 15.15, 14.20, 13.23）がサポートされました。
何が嬉しいのか #
PostgreSQLコミュニティによるバグ修正や改善に加え、Aurora固有の機能強化が含まれています。具体的には、プライマリインスタンスでの新しいコミットを制限することでスイッチオーバー時間を短縮したBlue/Greenデプロイメントの改善、クエリプラン管理（QPM）の強化、データベース復旧時のコミットログ読み込みの最適化によるインスタンス復旧時間の短縮などが挙げられます。
これまでとどう変わるのか #
- これまで: 以前のマイナーバージョンでは、最新のコミュニティフィックスや上記のAurora固有のパフォーマンス改善の一部が利用できませんでした。
- これから: 最新のマイナーバージョンにアップグレードすることで、セキュリティ修正やバグ修正の適用だけでなく、Blue/Greenデプロイの高速化や復旧時間の短縮といった恩恵を受けられます。
具体的なユースケース #
- 既存のAurora PostgreSQLデータベースを最新のマイナーバージョンにアップグレードし、システムの安定性とセキュリティを向上させる。
- Blue/Greenデプロイメントを利用して、ダウンタイムを最小限に抑えつつデータベースの更新を行う。
Amazon EC2がAPI全体でアベイラビリティーゾーンID (AZ ID) をサポート #
投稿日: 2025年12月18日
何ができるようになったのか #
Amazon EC2のAPIにおいて、アベイラビリティーゾーンID (AZ ID) パラメータがサポートされました。これにより、インスタンス、ボリューム、サブネットなどのリソースを作成・管理する際に、物理的な場所を一意に特定するAZ IDを直接指定できるようになりました。
何が嬉しいのか #
AZ IDはすべてのAWSアカウントにおいて同じ物理的な場所を表す静的な識別子です。これを使用することで、複数のAWSアカウントにまたがってリソースを運用する場合でも、リソースの配置場所（物理的ロケーション）を一貫させることが容易になります。
これまでとどう変わるのか #
- これまで: リソース作成時にAZ名（例:
us-east-1a）を使用していましたが、この名前と実際の物理的な場所のマッピングはAWSアカウントごとに異なる可能性がありました。そのため、マルチアカウント環境でリソースを同じ物理ロケーションに配置するには、アカウント間のマッピングを手動で管理・追跡する必要があり、複雑でした。 - これから: EC2 APIでAZ ID（例:
use1-az1）を直接指定できるため、アカウント間でAZ名のマッピングを気にする必要がなくなります。これにより、リソースの配置戦略を簡素化し、確実に行うことができます。
具体的なユースケース #
- 複数のAWSアカウントを使用してシステムを構築する際、レイテンシーを最小化するために、すべてのアプリケーションサーバーとデータベースを物理的に同じアベイラビリティーゾーンに配置する。
- インスタンス、起動テンプレート、ボリューム、サブネットなどの作成時にAZ IDを指定して、意図した物理ロケーションにリソースを作成する。
use1-az1, use1-az2）。
一方、AZ名（例: us-east-1a）は各AWSアカウントごとにランダムにマッピングされるため、アカウントAの us-east-1a とアカウントBの us-east-1a が物理的に異なる場所である可能性があります。AZ IDを使えば、この不一致を回避できます。
Amazon ECRがプッシュ時のリポジトリ作成をサポート #
投稿日: 2025年12月19日
何ができるようになったのか #
Amazon Elastic Container Registry (ECR) で、コンテナイメージをプッシュした際に、リポジトリが存在しなければ自動的に作成する機能がサポートされました。
何が嬉しいのか #
コンテナワークフローが簡素化されます。これまではイメージをプッシュする前にリポジトリを作成しておく必要がありましたが、この機能によりその手間が省けます。リポジトリ作成テンプレートの設定に従って、ECRが必要なリポジトリを自動的にセットアップしてくれます。
これまでとどう変わるのか #
- これまで: 存在しないリポジトリに対してイメージをプッシュしようとするとエラーになり、事前に手動またはIaCツールなどでリポジトリを作成する必要がありました。
- これから: イメージをプッシュするだけで、事前設定されたテンプレートに基づいて自動的にリポジトリが作成されるため、スムーズなデプロイが可能になります。
具体的なユースケース #
- CI/CDパイプラインにおいて、新しいマイクロサービスやブランチごとのイメージをビルド・プッシュする際、リポジトリ作成のステップを省略してプロセスを高速化する。
- 動的に生成される名前のリポジトリに対してイメージを保存するワークフローを構築する。
Amazon ECS Managed InstancesがAmazon EC2 Spot Instancesをサポート #
投稿日: 2025年12月18日
何ができるようになったのか #
Amazon ECS Managed Instancesで、Amazon EC2スポットインスタンスが利用できるようになりました。キャパシティプロバイダーの設定で、新しいパラメータ capacityOptionType を spot に設定することで利用可能です。
何が嬉しいのか #
ECS Managed Instancesの利点（インフラ管理のオーバーヘッド削減、自動スケーリング、最適なタスク配置など）を享受しつつ、オンデマンド価格と比較して最大90%の割引となるEC2スポットインスタンスを活用できます。これにより、耐障害性のあるワークロードを非常に低コストで実行可能になります。
これまでとどう変わるのか #
- これまで: ECS Managed Instancesではオンデマンドインスタンスのみがサポートされていました（またはスポットの明示的なサポートについての言及がありませんでした）。
- これから:
capacityOptionTypeを指定することで、オンデマンドかスポットかを選択できるようになりました。インフラ管理はAWSに任せたまま、コスト効率の高いコンピュートリソースを利用できます。
具体的なユースケース #
- ステートレスなWebアプリケーションやバッチ処理ジョブなど、中断が許容されるワークロードをECS Managed Instances上で実行し、コストを大幅に削減する。
Amazon RDSがAmazon S3へのスナップショットエクスポートの可観測性を強化 #
投稿日: 2025年12月19日
何ができるようになったのか #
Amazon RDSのスナップショットをS3にエクスポートする機能において、可観測性（Observability）が強化されました。エクスポートの進捗状況、失敗、パフォーマンスに関する詳細なインサイトが得られるようになりました。
何が嬉しいのか #
エクスポートタスクの状況をより詳細に把握できるため、運用の予測可能性が向上します。特に大規模なデータベースの場合、エクスポートがどこまで進んでいるか、どのテーブルに時間がかかっているかを知ることで、トラブルシューティングや計画が容易になります。
これまでとどう変わるのか #
- これまで: エクスポートの大まかなステータスは確認できましたが、詳細な進捗や特定のテーブルごとの状況までは把握しにくい場合がありました。
- これから: 新たに4つのイベントタイプが導入され、現在のエクスポート進捗や、長時間実行されているテーブルに関する通知を受け取れるようになりました。また、エクスポート済みおよび保留中のテーブル数やデータサイズも確認可能です。
具体的なユースケース #
- 数TB規模のRDSスナップショットをデータ分析のためにS3へエクスポートする際、Amazon SNS経由で進捗通知を受け取り、完了予定時間をより正確に見積もる。
- エクスポートが遅延している場合に、どのテーブルがボトルネックになっているかを特定して対策を検討する。
Amazon SageMaker StudioがSOCIインデックス作成をサポートしコンテナ起動時間を短縮 #
投稿日: 2025年12月19日
何ができるようになったのか #
Amazon SageMaker StudioがSOCI (Seekable Open Container Initiative) インデックス作成をサポートしました。これにより、カスタムコンテナイメージを使用する際の起動時間を30〜50%短縮できます。
何が嬉しいのか #
データサイエンティストが特定のライブラリや設定を含む大規模なカスタムイメージを使用する場合、これまでは環境の起動に数分かかることがあり、開発のボトルネックになっていました。SOCIを使用することで、イメージ全体をダウンロードするのを待たずに、必要なコンポーネントのみをオンデマンドで読み込む「遅延ロード（lazy loading）」が可能になり、数秒で作業を開始できます。
これまでとどう変わるのか #
- これまで: カスタムイメージを使用する場合、イメージ全体のダウンロードが完了するまで環境が起動しませんでした。
- これから: SOCIインデックスを作成（Finch CLI, nerdctl, Docker with SOCI CLIなどを使用）してECRにプッシュし、SageMakerイメージリソース作成時にそのインデックスURIを参照することで、高速な起動が可能になります。
具体的なユースケース #
- 大規模な機械学習フレームワークや多数の依存ライブラリを含むカスタムDockerイメージを使用してSageMaker Studioで実験を行う際、待ち時間を大幅に短縮して試行錯誤のサイクルを速める。
Amazon SESがEメール検証機能を発表 #
投稿日: 2025年12月18日
何ができるようになったのか #
Amazon Simple Email Service (SES) に、Eメールアドレスの有効性を検証する新機能「Eメールバリデーション」が追加されました。API経由で個々のアドレスを検証したり、送信されるすべてのメールに対して自動検証を有効にしたりできます。
何が嬉しいのか #
無効なメールアドレスへの送信を防ぐことで、バウンス率（不達率）を低減し、送信者のレピュテーション（信頼性）を保護できます。これはメール到達率の向上に直結します。
これまでとどう変わるのか #
- これまで: アドレスリストのクリーニングや検証は、サードパーティのツールを使用するか、実際に送信してバウンス処理を行う必要がありました。
- これから: SESのネイティブ機能として、構文チェックやDNSレコード確認を含む詳細な検証が可能になります。特に「自動検証（Auto Validation）」を有効にすれば、アプリケーションコードを変更することなく、SESが自動的に送信メールのアドレスをチェックしてくれます。
具体的なユースケース #
- 新規ユーザー登録時にAPIを使用してメールアドレスが有効かどうかを即座にチェックする。
- 既存の配信リストに対してキャンペーンメールを送信する前に、自動検証機能をONにして、無効なアドレスへの送信を未然に防ぎ、ドメインの信頼性を守る。
Amazon WorkSpaces ApplicationsがMicrosoft Windows Server 2025をサポート #
投稿日: 2025年12月19日
何ができるようになったのか #
Amazon WorkSpaces Applicationsで、Microsoft Windows Server 2025ベースのイメージが利用可能になりました。
何が嬉しいのか #
Microsoftの最新サーバーOSによるセキュリティ、パフォーマンス、および最新機能の強化を享受しながら、アプリケーションストリーミング環境を構築できます。特に、Windows Server 2025を使用することで、エンドユーザーにWindows 11のデスクトップエクスペリエンスを提供できるようになります。
これまでとどう変わるのか #
- これまで: Windows Server 2019や2022などが利用されていました。
- これから: 最新のWindows Server 2025を選択肢に加えられるようになり、組織の標準や特定のアプリケーション要件に合わせて、AWS提供のパブリックイメージまたはカスタムイメージを使用して環境を構築できます。
具体的なユースケース #
- 従業員に対して、最新のWindows 11ライクな操作感を持つデスクトップ環境をストリーミング配信し、リモートワーク環境の生産性を向上させる。
Amazon WorkSpaces ApplicationsがUbuntu Pro 24.04 LTSを搭載したElastic fleetsを発表 #
投稿日: 2025年12月18日
何ができるようになったのか #
Amazon WorkSpaces ApplicationsのElastic fleetsにおいて、Ubuntu Pro 24.04 LTSがサポートされました。
何が嬉しいのか #
ISV（独立系ソフトウェアベンダー）や企業のIT部門は、AWSクラウドの柔軟性やコスト効率を活かしながら、Ubuntuデスクトップアプリケーションをエンドユーザーにストリーミング配信できます。Elastic fleetsを使用するため、事前のキャパシティ予測やスケーリングポリシーの管理、イメージの作成・管理が不要です。
これまでとどう変わるのか #
- これまで: Elastic fleetsで選択できるOSの選択肢にUbuntu Pro 24.04 LTSが含まれていなかった可能性があります（またはWindowsのみだった可能性があります）。
- これから: 最新のUbuntu LTS環境で動作するアプリケーションを、サーバーレスなElastic fleetsを通じて手軽に配信できるようになります。
具体的なユースケース #
- LinuxベースのGUIアプリケーションを開発しているISVが、SaaSとしてアプリケーションをユーザーに提供する基盤として利用する。
- 社内ツールとしてLinuxデスクトップアプリを従業員に配布する際、VDIのインフラ管理をせずにWorkSpaces Applicationsを利用する。
AWS IoT CoreがHTTPルールアクションへのメッセージバッチ処理を追加 #
投稿日: 2025年12月18日
何ができるようになったのか #
AWS IoT CoreのHTTPルールアクションにおいて、複数のIoTメッセージを1つのバッチにまとめてから、ダウンストリームのHTTPエンドポイントにルーティングできるようになりました。
何が嬉しいのか #
IoTワークロードからのテレメトリを取り込む際に、メッセージをバッチ処理することでHTTPリクエストの数を減らし、コストとスループットのオーバーヘッドを削減できます。
これまでとどう変わるのか #
- これまで: IoTメッセージは個別にHTTPエンドポイントへルーティングされていたため、メッセージ量が多い場合にリクエスト数が増加し、コストや負荷が高くなる可能性がありました。
- これから: ルールアクションでバッチパラメータを定義することで、AWS IoT Coreがメッセージを指定通りにまとめてからHTTPエンドポイントに送信します。
具体的なユースケース #
- 多数のスマートホームデバイスから送信されるメッセージを1つのバッチにまとめ、スマートホームプラットフォームのAPIエンドポイントへ送信することで、APIコールの回数を削減する。
AWS IoTがイベントベースのロギングを提供開始し可観測性コストを最適化 #
投稿日: 2025年12月19日
何ができるようになったのか #
AWS IoTでイベントベースのロギングがサポートされました。これにより、個々のイベントタイプごとにログレベルやCloudWatchロググループの宛先をカスタマイズできるようになりました。
何が嬉しいのか #
すべてのイベントを同じ詳細度でログ出力する必要がなくなるため、Amazon CloudWatchのコストを削減しつつ、ログ管理の効率を向上させることができます。重要なイベントには詳細なログを、そうでないイベントには最小限のログを設定することで、必要な情報を維持しながらコストをコントロールできます。
これまでとどう変わるのか #
- これまで: ログレベルの設定は全体または特定のリソースに対して一律に適用される傾向があり、不要な詳細ログが出力されてコストが増加するか、逆に詳細度が足りないかのトレードオフがありました。
- これから: 例えば、証明書プロバイダーのイベントには「INFO」レベルを設定し、接続イベントのような頻繁に発生するが重要度の低いイベントには「ERROR」レベルのみを設定するといった細かな制御が可能になります。
具体的なユースケース #
- 運用上の重要度に基づいて、クリティカルなセキュリティイベントは詳細に記録し、日常的な接続イベントはエラーのみを記録することで、ログの検索性と分析効率を高めつつコストを抑える。
Amazon MSK Express BrokersがApache Kafka v3.9でKRaftをサポート #
投稿日: 2025年12月18日
何ができるようになったのか #
Amazon Managed Streaming for Apache Kafka (MSK) のExpress Brokersで、Apache Kafkaバージョン3.9がサポートされました。このリリースでは、メタデータ管理のためにApache ZooKeeperへの依存を排除する新しいコンセンサスプロトコルであるKRaft (Kafka Raft) が導入されています。
何が嬉しいのか #
KRaftにより、メタデータ管理が外部のZooKeeperノードからKafkaブローカー内のコントローラーグループに移行します。これにより、メタデータがKafkaトピックとして保存・複製されるようになり、メタデータの伝播が高速化されます。
これまでとどう変わるのか #
- これまで: Kafkaクラスターのメタデータ管理にはZooKeeperが必要でした。
- これから: Kafka v3.9を使用して作成された新しいExpress Brokerクラスターは、自動的にKRaftをメタデータ管理モードとして使用します。これにより、よりモダンで効率的なアーキテクチャの恩恵を受けることができます。
具体的なユースケース #
- 新規に高スループットなデータストリーミング環境を構築する際、管理コンポーネントが簡素化され、メタデータ処理が高速化されたKafka v3.9のMSK Express Brokersを採用する。
AWS Private CA OCSPが中国およびAWS GovCloud (US) リージョンで利用可能に #
投稿日: 2025年12月19日
何ができるようになったのか #
AWS Private Certificate Authority (AWS Private CA) のOnline Certificate Status Protocol (OCSP) サポートが、中国リージョン（北京、寧夏）およびAWS GovCloud (US) リージョン（US-East、US-West）で利用可能になりました。
何が嬉しいのか #
OCSPを使用することで、証明書の失効状態をリアルタイムで確認できます。これにより、巨大な証明書失効リスト（CRL）ファイルをダウンロードする代わりに、クエリあたり数百バイト程度の通信で済むため、帯域幅を節約し、検証プロセスを効率化できます。
これまでとどう変わるのか #
- これまで: これらのリージョンでは、証明書の失効確認にCRLを使用する必要があり、クライアントが大きなファイルをダウンロードする必要がある場合がありました。
- これから: OCSPレスポンダーを使用してリアルタイムかつ軽量な失効確認が可能になります。AWS Private CAがOCSPレスポンダーのインフラを完全に管理するため、ユーザーが高可用性サーバーを運用する必要はありません。
具体的なユースケース #
- 帯域幅が限られているIoTデバイスの認証において、データ転送量を最小限に抑えつつ証明書の有効性を確認する。
- 内部マイクロサービス間の通信において、リアルタイムの失効チェックを行い、ゼロトラストセキュリティアーキテクチャを強化する。
Amazon Bedrock Data Automationがドキュメントブループリントの指示最適化機能を開始 #
投稿日: 2025年12月19日
何ができるようになったのか #
Amazon Bedrock Data Automation (BDA) で、ブループリントの指示最適化（instruction optimization）がサポートされました。これにより、正解ラベル付きの少数のサンプルドキュメントを使用するだけで、カスタムフィールド抽出の精度を向上させることができます。
何が嬉しいのか #
モデルのトレーニングやファインチューニングを行うことなく、数分で実運用レベルの精度を達成できます。最適化プロセスは、期待される結果（正解データ）と実際の推論結果の差異を分析し、抽出精度を向上させるようにブループリント内の自然言語指示を自動的に調整します。
これまでとどう変わるのか #
- これまで: 抽出精度を上げるためには、プロンプトエンジニアリングを手動で繰り返し試行錯誤する必要がありました。
- これから: 最大10個の代表的なドキュメントと期待値を入力するだけで、システムが自動的に指示を洗練させてくれます。最適化後には、正解データに対する完全一致率やF1スコアなどの詳細な評価メトリクスも提供されます。
具体的なユースケース #
- 請求書の明細行、契約書の条項、税務フォームのフィールド、医療請求コードなどの抽出において、サンプルデータを用いて抽出ルール（指示）を自動的に最適化し、本番環境への導入を加速する。
AWS Clean Roomsが既存のコラボレーションに対する変更リクエストをサポート #
投稿日: 2025年12月18日
何ができるようになったのか #
AWS Clean Roomsにおいて、既存のコラボレーション設定を変更するための「変更リクエスト」機能がサポートされました。
何が嬉しいのか #
コラボレーションの管理に柔軟性が生まれます。これまでは設定変更が難しかった可能性がありますが、新しいメンバーの追加、メンバー権限の更新、自動承認設定の変更などをリクエストできるようになりました。セキュリティを維持するため、変更が適用されるには全メンバーの承認が必要となっており、透明性も確保されています。
これまでとどう変わるのか #
- これまで: コラボレーション開始後に構成を変更する場合、柔軟性に欠ける部分があったかもしれません。
- これから: パブリッシャーと広告主のコラボレーションに、後から広告代理店をメンバーとして追加するといった変更がスムーズに行えます。これにより、プライバシー制御を維持したまま、オンボーディング時間を短縮できます。
具体的なユースケース #
- 既存のデータ分析コラボレーションに新しいパートナー（分析企業など）を追加して、インサイトの取得を加速させる。
アカウントタグに対するコスト配分タグのサポートを発表 #
投稿日: 2025年12月19日
何ができるようになったのか #
AWSのコスト管理ツール全体で、アカウントタグに対するコスト配分タグのサポートが開始されました。これにより、AWS Organizationsで設定したアカウントレベルのタグを、Cost ExplorerやAWS Budgetsなどで直接利用できるようになります。
何が嬉しいのか #
複数のメンバーアカウントを持つ組織において、アカウントごとのコスト管理が大幅に楽になります。アカウントタグはそのアカウント内のすべての従量課金リソースに自動的に適用されるため、リソースごとにタグ付けできないコスト（サポート料金や前払い金など）も含めて、アカウント単位で綺麗にコストを分類・集計できます。
これまでとどう変わるのか #
- これまで: Cost Explorerなどでアカウントごとのグループを作成するには、手動でアカウントIDをリストアップして管理する必要があり、アカウントの増減に対応するのが手間でした。
- これから: AWS Organizationsで「Environment: Production」のようなタグをアカウントに付けておけば、新しいアカウントが増えても自動的にそのタグに基づいてコストが集計されます。手動でのグループメンテナンスが不要になります。
具体的なユースケース #
- 「CostCenter」タグを各AWSアカウントに付与し、Cost Explorerでそのタグを使って部署ごとのコストを即座に可視化する。
- 特定のプロジェクトタグが付いたアカウント群に対して、一括でAWS Budgetsのアラートを設定する。
Amazon ECSがAWS Fargateでのタスクリタイアメントをスケジュールするための週次イベントウィンドウを定義可能に #
投稿日: 2025年12月18日
何ができるようになったのか #
Amazon ECSにおいて、AWS Fargateのタスクリタイアメント（プラットフォーム更新などに伴うタスクの停止・再起動）が発生するタイミングを制御するための、週次イベントウィンドウを定義できるようになりました。
何が嬉しいのか #
インフラストラクチャの更新やタスクの置き換えがいつ行われるかを正確に制御できるため、ビジネスのピークタイムにミッションクリティカルなワークロードが中断されるのを防ぐことができます。
これまでとどう変わるのか #
- これまで: Fargateは定期的な更新のためにタスクをリタイアさせますが、通知から7日後（または設定により14日後、即時）に実行される仕様でした。ユーザーは通知を受け取ってから独自にタスクの置き換えを行う必要がありました。
- これから: Amazon EC2イベントウィンドウのインターフェースを使用して、「毎週土曜日の深夜」のように特定の時間枠を定義し、その期間内のみタスクリタイアメントを実行するように設定できます。
具体的なユースケース #
- 平日の日中に高可用性が求められる金融サービスにおいて、Fargateのプラットフォーム更新によるタスク再起動を週末のメンテナンスウィンドウに限定する。
Amazon Redshift ODBC 2.xドライバーがApple macOSをサポート #
投稿日: 2025年12月19日
何ができるようになったのか #
Amazon RedshiftのODBC 2.xドライバーがApple macOSをサポートしました。これにより、Macユーザーも最新のODBCドライバーを使用してRedshiftクラスターに接続できるようになりました。
何が嬉しいのか #
Macを使用する開発者やデータアナリストが、データ共有の書き込み機能やAmazon IAM Identity Centerとの統合など、Redshiftの最新機能をフルに活用できるようになります。
これまでとどう変わるのか #
- これまで: macOSユーザーは古いバージョンのドライバーを使用するか、互換性の制限がある環境で作業する必要があった可能性があります。
- これから: ネイティブなmacOSサポートにより、ETLツールやBIツール（Tableauなど）からの接続がシームレスになり、開発環境の選択肢が広がります。
具体的なユースケース #
- データアナリストがMacBook上のBIツールから、最新の認証機能（IAM Identity Center）を使用して安全にRedshiftへ接続し、分析を行う。
Timestream for InfluxDBがRestart APIコールをサポート #
投稿日: 2025年12月19日
何ができるようになったのか #
Amazon Timestream for InfluxDBにおいて、データベースインスタンスの再起動を行うための「Restart API」が提供されました（InfluxDB v2およびv3に対応）。マネジメントコンソール、API、CLIから実行可能です。
何が嬉しいのか #
運用管理が合理化されます。特に、データベース再起動時のアプリケーションの挙動を確認する「レジリエンス（回復力）テスト」を行ったり、サポートに連絡することなく自身で再起動を行って一時的な問題を解消したりすることが可能になります。
これまでとどう変わるのか #
- これまで: 再起動が必要な場合、ユーザー側で直接トリガーする手段がなかったか、限定的でした。
- これから: DevOpsチームはAPIを叩くだけで任意のタイミングで再起動を実施でき、運用の柔軟性が向上します。
具体的なユースケース #
- 本番環境へのデプロイ前に、データベースが予期せず再起動した際のアプリケーションの再接続ロジックが正しく動作するかをテストする。
自己管理型データベースソース向けのZero-ETLが新たに7つのリージョンで利用可能に #
投稿日: 2025年12月19日
何ができるようになったのか #
AWS Glueを使用した自己管理型データベース（Oracle, SQL Server, MySQL, PostgreSQL）からAmazon RedshiftへのZero-ETL統合が、新たに7つのリージョン（東京リージョンを含む）で利用可能になりました。
何が嬉しいのか #
オンプレミスやEC2上のデータベースからRedshiftへのデータレプリケーションパイプラインを、複雑なコードを書くことなく簡単に構築できます。これにより、データエンジニアリングの工数を大幅に削減し、運用負荷を軽減できます。
これまでとどう変わるのか #
- これまで: これらのリージョンでは、カスタムETLパイプラインを構築・維持する必要がありました。
- これから: 東京、香港、シンガポール、シドニー、ロンドン、サンパウロ、バージニア北部において、AWS Glueのシンプルなインターフェースを通じて自動的なデータレプリケーションを設定できるようになります。
具体的なユースケース #
- 東京リージョンのデータセンターにあるOracleデータベースの販売データを、ニアリアルタイムでRedshiftに同期し、BIダッシュボードで分析する。