本日の主なトピック #
- Amazon Bedrock が DeepSeek V3.2 など 6 つのオープンウェイトモデルをサポート開始
- Amazon Athena が 1 分単位のキャパシティ予約と最小 4 DPU をサポート
- Amazon Aurora Global Database がマネージドマイナーバージョンアップグレードをサポート
- Amazon Connect が騒がしい環境向けの音声拡張機能を導入
- Amazon OpenSearch Serverless がコレクションのグループ化をサポート
¥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 Athena が 1 分単位のキャパシティ予約と最小 4 DPU をサポート #
投稿日: 2026年02月10日
何ができるようになったのか #
Amazon Athena のキャパシティ予約 (Capacity Reservations) において、予約の最小期間が 1分 に短縮され、最小容量も 4 DPU (Data Processing Units) から利用可能になりました。これにより、ワークロードのパターンに合わせてより頻繁かつきめ細かな調整が可能になります。長期的なコミットメントなしで開始でき、短時間のクエリワークロードに対して最大 95% のコスト削減が期待できます。
何が嬉しいのか #
キャパシティ予約は、クエリの優先順位付けや同時実行制御が必要なワークロードに最適な、専有のサーバーレスコンピュート環境を提供します。これまでは、短時間のスパイク的な負荷に対しても長時間の予約が必要でしたが、今回のアップデートにより、必要な時に必要な分だけ最小限のコストでリソースを確保できるようになります。予約されたキャパシティは既存の Athena クエリやワークグループとシームレスに連携するため、SQL クエリやアプリケーションコードを変更する必要はありません。
これまでとどう変わるのか #
- これまで: キャパシティ予約の最小期間は通常 8時間 であり、最小容量も 24 DPU (一部情報では 8 DPU) と比較的大規模なリソース確保が必要でした。
- これから: 最小期間が 1分、最小容量が 4 DPU となり、短時間かつ小規模なワークロードでも柔軟にキャパシティ予約を利用できるようになりました。
具体的なユースケース #
- 定期的に発生する短時間のバッチ処理やレポート生成クエリのために、その時間帯だけ最小限のリソースを確保する。
- 突発的なクエリ需要に対して、迅速にキャパシティを確保し、処理完了後すぐに解放することでコストを最適化する。
Amazon Aurora DSQL が 4 つの AWS リージョンで利用可能に #
投稿日: 2026年02月11日
何ができるようになったのか #
Amazon Aurora DSQL (単一リージョンクラスター) が以下の 4 つの AWS リージョンで新たに利用可能になりました。
- アジアパシフィック (メルボルン)
- アジアパシフィック (シドニー)
- カナダ (中部)
- カナダ西部 (カルガリー)
何が嬉しいのか #
Aurora DSQL は、サーバーレスかつ分散型の SQL データベースであり、実質的に無制限のスケーラビリティと高い可用性を提供します。インフラストラクチャの管理が不要で、スケーリングや耐障害性の確保が容易になります。今回、オーストラリアとカナダのリージョンが追加されたことで、これらの地域のユーザーはより低遅延で Aurora DSQL を利用できるようになります。
これまでとどう変わるのか #
- これまで: これらのリージョンでは Aurora DSQL は利用できませんでした。
- これから: 上記 4 リージョンを含む合計 14 リージョンで Aurora DSQL を利用して、高可用性かつスケーラブルなアプリケーションを構築できるようになりました。
具体的なユースケース #
- オーストラリアやカナダに拠点を置く企業が、現地のデータレジデンシー要件を満たしながら、フルマネージドの分散 SQL データベースを利用する。
- グローバル展開するアプリケーションのために、これらの地域にデータストアを配置し、現地のユーザーに対するレイテンシを削減する。
Amazon Aurora Global Database がマネージドマイナーバージョンアップグレードをサポート #
投稿日: 2026年02月10日
何ができるようになったのか #
Amazon Aurora Global Database (Aurora PostgreSQL 互換) において、グローバルトポロジ全体に対するマネージドなマイナーバージョンアップグレードが可能になりました。AWS マネジメントコンソール、SDK、または CLI から操作することで、グローバルデータベース内のすべてのリージョンのクラスターを一括して指定したマイナーバージョンへアップグレードできます。
何が嬉しいのか #
Aurora Global Database は、災害対策や低遅延なローカル読み取りのために最大 11 のリージョンにデータベースを分散配置できます。これまでは各クラスターを個別にアップグレードする必要があり、管理の手間がかかっていました。今回のアップデートにより、運用負荷を大幅に削減し、ダウンタイムを最小限に抑えつつ、グローバルなデータベース環境を常に最新の状態に保つことが容易になります。
これまでとどう変わるのか #
- これまで: グローバルデータベースを構成する各リージョンのクラスターに対し、手動で個別にマイナーバージョンアップグレードを実行する必要がありました。
- これから: 一度の操作で、グローバルクラスター内のすべてのクラスターを自動的にアップグレードできるようになり、運用の複雑さとリスクが軽減されます。
具体的なユースケース #
- 世界中にユーザーを持つアプリケーションのバックエンドとして Aurora Global Database を利用しており、セキュリティパッチ適用や機能向上のために、手間なく迅速にすべてのリージョンでデータベースエンジンを更新する。
Amazon Bedrock が DeepSeek V3.2 など 6 つのオープンウェイトモデルをサポート開始 #
投稿日: 2026年02月10日
何ができるようになったのか #
Amazon Bedrock にて、以下の 6 つの新しいオープンウェイトモデルがフルマネージドサービスとして利用可能になりました。
- DeepSeek V3.2: 推論能力とエージェント機能に優れたモデル。
- MiniMax M2.1: 大規模な出力ウィンドウを持つ自律的なコーディング向けモデル。
- GLM 4.7: 同じくコーディング能力に優れたモデル。
- GLM 4.7 Flash: 本番環境向けの軽量でコスト効率の高いモデル。
- Kimi K2.5: 推論とエージェント機能のフロンティアモデル。
- Qwen3 Coder Next: 軽量でコスト効率の高いコーディング特化モデル。
何が嬉しいのか #
これにより、エンタープライズ AI ワークロードの全領域をカバーする多様なモデルの選択肢が増え、最先端のパフォーマンスをより低コストで利用できるようになります。また、これらのモデルは Amazon Bedrock の新しい分散推論エンジンである Project Mantle によって提供されており、高いパフォーマンスと信頼性、OpenAI API 互換性などを実現しています。
これまでとどう変わるのか #
- これまで: これらの特定のオープンウェイトモデルは、Amazon Bedrock 上では直接利用できなかったか、利用可能なモデルの選択肢に含まれていませんでした。
- これから: マネージドサービスとして手軽にこれらの最新モデルを利用でき、インフラ管理の手間なくアプリケーションに組み込むことが可能です。
具体的なユースケース #
- DeepSeek V3.2 や Kimi K2.5 を使用して、複雑な推論を必要とする AI エージェントを構築する。
- MiniMax M2.1 や GLM 4.7 を活用して、大規模なコード生成やリファクタリングを行う開発支援ツールを作成する。
- GLM 4.7 Flash や Qwen3 Coder Next を採用して、応答速度とコストが重要なチャットボットやコード補完機能を本番環境に展開する。
Amazon Connect が騒がしい環境向けの音声拡張機能を導入 #
投稿日: 2026年02月11日
何ができるようになったのか #
Amazon Connect に、騒がしいコンタクトセンター環境での通話品質と信頼性を向上させる「音声拡張 (Audio Enhancement)」機能が追加されました。 この機能には、以下の 2 つのモードがあります。
- Voice Isolation (音声分離): 周囲の騒音だけでなく、背景の話し声も抑制し、エージェントの声だけをクリアに抽出します。
- Noise Suppression (ノイズ抑制): 背景の騒音のみを抑制します。
管理者はエージェントごとに適切なモードを設定でき、権限を持つエージェントは Contact Control Panel (CCP) から設定を調整することも可能です。
何が嬉しいのか #
コンタクトセンター内では、他のエージェントの話し声や周囲の雑音が顧客との会話を妨げることがあります。この機能により、エージェント側の背景ノイズをソフトウェア的に除去し、顧客に対してよりクリアな音声を届けることができます。特に「音声分離」モードは、隣のエージェントの声が入り込むような混雑した環境で効果を発揮します。
これまでとどう変わるのか #
- これまで: エージェントの声の品質は、使用するヘッドセットのノイズキャンセリング機能や物理的な環境（静かな部屋の確保など）に大きく依存していました。
- これから: Amazon Connect 側で高度なノイズ抑制と音声分離が可能になり、物理的な環境や機材に依存せず、より高品質な通話体験を提供できるようになります。
具体的なユースケース #
- 混雑したオフィスやコールセンター: 隣のエージェントとの距離が近く、話し声がマイクに入りやすい環境で「音声分離」モードを使用する。
- 在宅勤務: 生活音や外部の騒音が気になる環境で「ノイズ抑制」モードを使用し、プロフェッショナルな通話環境を維持する。
Amazon Connect がチャット、タスク、メールの ACW タイムアウト設定をサポート #
投稿日: 2026年02月11日
何ができるようになったのか #
Amazon Connect において、チャット、タスク、メール、コールバックに対する「後処理 (After Contact Work: ACW)」のタイムアウト時間を個別に設定できるようになりました。これにより、エージェントが各問い合わせの対応後に ACW に費やす時間を制限し、タイムアウト後に自動的に「待機可能 (Ready)」状態に戻すことができます。
何が嬉しいのか #
これまでは、エージェントの ACW 時間管理が柔軟に行えない場合がありましたが、今回のアップデートにより、チャネルごとに最適なタイムアウト時間を設定できるようになりました。例えば、電話対応の後にはクールダウンのために長い ACW 時間を設けつつ、メール対応の後には短い ACW 時間を設定して効率を高める、といった運用が可能になります。これにより、エージェントの稼働率を最適化し、次の顧客対応への切り替えをスムーズに行うことができます。
これまでとどう変わるのか #
- これまで: ACW タイムアウト設定が音声通話に限定されていたか、あるいはチャネルごとに細かく制御することが難しかった可能性があります。
- これから: 音声以外のチャネル（チャット、タスク、メール）に対しても個別にタイムアウト時間を設定できるようになり、マルチチャネル環境での運用効率が向上します。
具体的なユースケース #
- メール対応: 後処理時間が短い傾向にあるため、ACW タイムアウトを短く設定し、次の問い合わせへの対応サイクルを速める。
- 複雑なチャット対応: 詳細な記録が必要な場合があるため、余裕を持った ACW 時間を設定する。
Amazon Connect がチャット、タスク、メールの自動応答をサポート #
投稿日: 2026年02月11日
何ができるようになったのか #
Amazon Connect において、チャット、タスク、メール、コールバックに対する「自動応答 (auto-accept)」を設定できるようになりました。この機能が有効な場合、受信した問い合わせは手動で受諾または拒否するのを待つことなく、自動的に利用可能なエージェントに接続されます。
何が嬉しいのか #
これまでは、音声通話以外のチャネルではエージェントが手動で応答する必要があったため、応答までの待ち時間が発生したり、取りこぼしが生じたりする可能性がありました。自動応答を導入することで、顧客への対応を迅速化し、エージェントが応答ボタンを押す手間を省くことができます。チャネルごとに有効化できるため、例えばタスク処理は自動で開始し、音声通話は準備が整ってから手動で受けるといった柔軟な運用が可能です。
これまでとどう変わるのか #
- これまで: 自動応答の設定は、インバウンドの音声通話に対してのみ利用可能でした。
- これから: 音声以外のチャネル（チャット、タスク、メール）に対しても自動応答を設定できるようになり、オムニチャンネルでの運用効率と応答速度が向上します。
具体的なユースケース #
- 迅速なチャット対応: チャットの問い合わせが来たら即座にエージェントに割り当て、顧客を待たせないようにする。
- タスクの自動割り当て: バックオフィスの事務処理タスクなどを自動的にエージェントに振り分け、業務フローを途切れさせないようにする。
Amazon DocumentDB (MongoDB 互換) がメルボルンリージョンで利用可能に #
投稿日: 2026年02月11日
何ができるようになったのか #
Amazon DocumentDB (MongoDB 互換) が、アジアパシフィック (メルボルン) リージョンで利用可能になりました。
何が嬉しいのか #
メルボルンリージョンを利用しているユーザーは、フルマネージドで MongoDB 互換のドキュメントデータベースをローカルリージョンで使用できるようになります。これにより、低遅延なアクセスやデータレジデンシー要件への対応が可能になります。
これまでとどう変わるのか #
- これまで: メルボルンリージョンでは DocumentDB を利用できず、シドニーリージョンなどの他のリージョンを利用する必要があった可能性があります。
- これから: メルボルンリージョン内でネイティブに DocumentDB クラスターを構築・運用できるようになります。
具体的なユースケース #
- オーストラリア南部のユーザー向けに、低遅延なドキュメントストアを提供するアプリケーションの構築。
Amazon DocumentDB (MongoDB 互換) がチューリッヒリージョンで利用可能に #
投稿日: 2026年02月11日
何ができるようになったのか #
Amazon DocumentDB (MongoDB 互換) が、欧州 (チューリッヒ) リージョンで利用可能になりました。
何が嬉しいのか #
スイス周辺のユーザーは、フルマネージドで MongoDB 互換のドキュメントデータベースをローカルリージョンで使用できるようになります。これにより、データレジデンシー要件（データの国内保管など）への対応や、低遅延なアクセスの実現が容易になります。
これまでとどう変わるのか #
- これまで: チューリッヒリージョンでは DocumentDB を利用できず、フランクフルトなどの近隣リージョンを利用する必要がありました。
- これから: チューリッヒリージョン内でネイティブに DocumentDB クラスターを構築・運用できるようになります。
具体的なユースケース #
- スイス国内のデータプライバシー規制に準拠しながら、スケーラブルなドキュメントデータベースを利用する。
Amazon EC2 C8gn インスタンスがソウル、メルボルンなど追加のリージョンで利用可能に #
投稿日: 2026年02月09日
何ができるようになったのか #
最新世代の AWS Graviton4 プロセッサを搭載した Amazon EC2 C8gn インスタンスが、以下の追加リージョンで利用可能になりました。
- アジアパシフィック (ソウル、メルボルン)
- カナダ (中部)
- 欧州 (スペイン)
- AWS GovCloud (米国東部、米国西部)
何が嬉しいのか #
C8gn インスタンスは、前世代の Graviton3 ベースの C7gn インスタンスと比較して、最大 30% 優れた計算性能を提供します。また、最新の第 6 世代 AWS Nitro Cards を搭載しており、ネットワーク最適化された EC2 インスタンスの中で最高の最大 600 Gbps のネットワーク帯域幅を実現します。これにより、ネットワーク仮想アプライアンス、データ分析、AI/ML 推論などのネットワーク集約型ワークロードのパフォーマンスとスループットを向上させつつ、コストを最適化できます。
これまでとどう変わるのか #
- これまで: これらのリージョンでは、Graviton4 搭載の C8gn インスタンスを利用できず、C7gn などの以前の世代を選択する必要がありました。
- これから: 最新の高性能かつ高帯域なインスタンスタイプを選択できるようになり、より高い処理能力とネットワーク性能を必要とするアプリケーションをこれらの地域で展開可能になります。
具体的なユースケース #
- 高トラフィックを処理するファイアウォールやロードバランサーなどのネットワーク仮想アプライアンス。
- 大規模なデータセットを扱うリアルタイムデータ分析基盤。
- 高速なネットワーク通信を必要とする分散型機械学習推論クラスター。
Amazon EC2 C8i および C8i-flex インスタンスがパリ、カナダ中部、北カリフォルニアリージョンで利用可能に #
投稿日: 2026年02月11日
何ができるようになったのか #
Intel Xeon 6 プロセッサを搭載した Amazon EC2 C8i および C8i-flex インスタンスが、以下のリージョンで利用可能になりました。
- 欧州 (パリ)
- カナダ (中部)
- 米国西部 (北カリフォルニア)
何が嬉しいのか #
これらのインスタンスは、前世代の C7i および C7i-flex インスタンスと比較して、最大 20% のパフォーマンス向上と最大 15% の価格パフォーマンス向上を実現しています。特に NGINX Web アプリケーションでは最大 60%、AI 深層学習のレコメンデーションモデルでは最大 40% の高速化が期待できます。
- C8i-flex: 一般的なコンピューティング集約型ワークロード（Web サーバー、データベース、キャッシュなど）に対して、優れたコストパフォーマンスを提供する選択肢です。
- C8i: 大規模なメモリ集約型ワークロードや、継続的に高い CPU 使用率を必要とするアプリケーションに最適で、最大 96xlarge サイズまで選択可能です。
これまでとどう変わるのか #
- これまで: これらのリージョンでは、最新の Intel Xeon 6 ベースのインスタンスを利用できませんでした。
- これから: パリ、カナダ、北カリフォルニアのユーザーも、最新世代の Intel プロセッサによる高い計算能力とコスト効率を享受できるようになります。
具体的なユースケース #
- 高トラフィックな Web アプリケーションサーバーのホスティング。
- 大規模なバッチ処理やデータ分析ジョブ。
- 高性能なデータベースキャッシュ (Memcached, Redis) の運用。
Amazon ECR がリポジトリ監視のための追加メトリクスをサポート #
投稿日: 2026年02月06日
何ができるようになったのか #
Amazon Elastic Container Registry (ECR) において、Amazon CloudWatch を通じて以下の新しいメトリクスを監視できるようになりました。
- RepositoryCount: リポジトリの総数。
- ImagesPerRepositoryCount: 各リポジトリ内のイメージ数。
何が嬉しいのか #
これまで、リポジトリやイメージの増加傾向を把握したり、サービスクォータに近づいていることを検知したりするには、API を定期的に呼び出すなどの工夫が必要でした。新しいメトリクスにより、イメージ数の急増などの異常な振る舞いを簡単に特定したり、クォータに達する前にアラートを設定して対処したりすることが容易になります。これらのメトリクスは追加費用なしで利用可能です。
これまでとどう変わるのか #
- これまで: リポジトリ数やイメージ数を監視するための直接的な CloudWatch メトリクスが不足していたため、カスタムスクリプトなどでの管理が必要でした。
- これから: CloudWatch ダッシュボードやアラームを使用して、ECR の使用状況を可視化し、プロアクティブに管理できるようになります。
具体的なユースケース #
- クォータ監視: リポジトリ数が上限に近づいた際にアラートを発報し、申請漏れによるデプロイ失敗を防ぐ。
- コスト管理: 想定外にイメージ数が増加しているリポジトリを特定し、ライフサイクルポリシーの見直しを行う。
Amazon EKS Auto Mode がマネージド機能のログ出力を強化 #
投稿日: 2026年02月10日
何ができるようになったのか #
Amazon EKS Auto Mode のマネージド機能（コンピューティングのオートスケーリング、ブロックストレージ、ロードバランシング、Pod ネットワーキングなど）から生成されるログを、Amazon CloudWatch Vended Logs として設定・配信できるようになりました。配信先として CloudWatch Logs、Amazon S3、Amazon Kinesis Data Firehose を選択可能です。
何が嬉しいのか #
EKS Auto Mode はインフラ管理を大幅に簡素化しますが、その内部動作の可視性はトラブルシューティングや監視において重要です。今回のアップデートにより、マネージドコンポーネントの詳細なログを簡単に収集・分析できるようになります。また、Vended Logs として提供されるため、標準の CloudWatch Logs よりも低価格で利用でき、コスト効率よくログを蓄積できます。
これまでとどう変わるのか #
- これまで: EKS Auto Mode の各マネージド機能の動作詳細を把握するためのログ収集設定が限定的だったか、あるいは個別の設定が必要でした。
- これから: 統合されたログ配信ソースとして設定でき、信頼性が高くセキュアな方法で、主要な宛先にログを一元管理できるようになります。
具体的なユースケース #
- トラブルシューティング: Pod の起動失敗やネットワーク接続の問題が発生した際に、オートスケーリングやロードバランサーのログを確認して原因を特定する。
- 監査とコンプライアンス: すべてのインフラ操作ログを S3 に長期保存し、監査証跡として利用する。
Amazon OpenSearch Serverless がコレクションのグループ化をサポート #
投稿日: 2026年02月10日
何ができるようになったのか #
Amazon OpenSearch Serverless において、「コレクションのグループ化 (Collection Groups)」が可能になりました。 これにより、以下の 2 つの重要な機能が利用できます。
- 異なる AWS KMS キーで暗号化された複数のコレクション間で、コンピュートリソース (OCU: OpenSearch Compute Units) を共有する。
- 最大 OCU に加えて、最小 OCU の割り当てを指定する。
何が嬉しいのか #
これまでは、異なる KMS キーを使用するコレクションは別々のコンピュートリソースを必要としていたため、特にマルチテナント環境などでコストが嵩む傾向がありました。今回のアップデートにより、暗号化によるセキュリティ分離を維持したまま OCU を共有できるため、リソース利用率が向上し、大幅なコスト削減が期待できます。 また、最小 OCU を設定できるようになったことで、コールドスタートによる遅延を回避し、立ち上がりから一貫したパフォーマンスを保証できるようになります。
これまでとどう変わるのか #
- これまで: 異なる KMS キーを持つコレクションは独立した OCU を消費し、リソースの共有ができませんでした。また、最小キャパシティの保証設定が柔軟でなかった可能性があります。
- これから: 複数のコレクションをグループ化して OCU を効率的に共有しつつ、必要な最小リソースを確保して安定稼働させることが可能になります。
具体的なユースケース #
- SaaS アプリケーション: 顧客（テナント）ごとに異なる KMS キーでデータを暗号化しつつ、裏側のコンピュートリソースは共有してコストを抑える。
- レイテンシに敏感なアプリケーション: 最小 OCU を設定して、トラフィックがない状態からの最初のリクエストでも高速に応答できるようにする。
Amazon RDS for MariaDB が複数のマイナーバージョン (11.8.6 など) をサポート #
投稿日: 2026年02月11日
何ができるようになったのか #
Amazon RDS for MariaDB において、以下のコミュニティ MariaDB マイナーバージョンが利用可能になりました。
- 10.6.25
- 10.11.16
- 11.4.10
- 11.8.6
何が嬉しいのか #
最新のマイナーバージョンにアップグレードすることで、以前のバージョンに含まれていたセキュリティ上の脆弱性の修正、バグ修正、およびパフォーマンス改善の恩恵を受けることができます。Amazon RDS の「マイナーバージョン自動アップグレード」機能を利用すれば、メンテナンスウィンドウ中に自動的にデータベースを更新し、安全かつ効率的に運用を続けることが可能です。
これまでとどう変わるのか #
- これまで: これらの特定のマイナーバージョンに含まれる修正や機能を利用できませんでした。
- これから: 新しいバージョンを選択して、データベース環境のセキュリティと安定性を向上させることができます。
具体的なユースケース #
- セキュリティ強化: 既知の脆弱性に対処するために、最新のマイナーパッチを適用した環境へ移行する。
- バグ修正: 運用中に遭遇した特定の問題が解消されていることを期待して、新しいバージョンへアップグレードする。
Amazon SageMaker HyperPod がコンソールからのノード操作をサポート #
投稿日: 2026年02月10日
何ができるようになったのか #
Amazon SageMaker HyperPod のコンソールから、クラスター内の個々のノードを直接管理できるようになりました。 具体的には以下の操作が可能です。
- 接続: AWS Systems Manager (SSM) を介してノードに接続するためのコマンドをコピーしたり、コンソール上で直接 SSM セッションを開始したりできます。
- 再起動: 応答しないインスタンスを手動で再起動できます。
- 置換:劣化したり問題のあるノードを新しいものに置き換えることができます。
- 削除: 異常なノードを削除できます。 これらの操作は、複数のノードに対して一括で行うことも可能です。
何が嬉しいのか #
大規模な AI/ML ワークロードを運用する場合、トラブルシューティングやメンテナンスのために特定のノードにアクセスしたり、再起動したりする必要が生じることがあります。これまでは、SSM の接続文字列を手動で作成したり、CLI コマンドを叩いたりと手間がかかっていました。今回のアップデートにより、すべてのノード操作をコンソール上の単一のインターフェースから簡単かつ迅速に実行できるようになり、ダウンタイムを最小限に抑えることが可能になります。
これまでとどう変わるのか #
- これまで: ノードへの接続や再起動、置換などの操作には CLI の使用や複雑な手順が必要で、オペレーションが煩雑でした。
- これから: コンソール上で視覚的に、かつ直感的にノードの状態を確認しながら、必要なアクションを即座に実行できるようになります。
具体的なユースケース #
- トラブルシューティング: メモリリークなどで応答しなくなった特定のノードにコンソールから即座に接続して調査を行う。
- 障害復旧: 自動復旧機能では検知できないハードウェア劣化などの問題が発生した際に、手動で該当ノードを再起動または置換して迅速に復旧させる。
AWS Elastic Beanstalk が GitHub Actions による自動デプロイをサポート #
投稿日: 2026年02月11日
何ができるようになったのか #
AWS Elastic Beanstalk 向けの公式 GitHub Action である aws-elasticbeanstalk-deploy がリリースされました。
これを使用することで、GitHub リポジトリへのコードや設定の変更をトリガーに、Web アプリケーションを Elastic Beanstalk へ自動的にデプロイする CI/CD パイプラインを簡単に構築できます。
何が嬉しいのか #
この Action は、デプロイメントパッケージの作成、S3 へのアップロード、バージョン管理、環境監視といった一連のプロセスを自動化します。また、必要に応じてアプリケーションや環境を自動作成したり、IAM OIDC 認証とシームレスに統合したりすることも可能です。これまで手動や複雑なスクリプトで行っていたデプロイ作業を、GitHub Actions のワークフローファイルに記述するだけで完結させることができます。
これまでとどう変わるのか #
- これまで: GitHub Actions から Elastic Beanstalk にデプロイするには、
ebCLI をインストールしてコマンドを実行するスクリプトを書くか、サードパーティ製の Action を利用する必要がありました。 - これから: AWS 公式の Action を利用して、宣言的かつ信頼性の高い方法でデプロイフローを構築できます。再試行ロジックやヘルスモニタリングも組み込まれており、デプロイの安定性が向上します。
具体的なユースケース #
- CI/CD の簡素化:
mainブランチへのマージをトリガーに、ビルド、テスト、ステージング環境へのデプロイまでを自動化する。 - インフラの自動プロビジョニング: 新しい機能ブランチ用に一時的な環境を自動作成し、プルリクエストのレビュー用に公開する。
AWS Lake Formation がクロスアカウント共有機能を強化 #
投稿日: 2026年02月11日
何ができるようになったのか #
AWS Lake Formation のクロスアカウント共有機能が強化され、数十万のテーブルを他のアカウントと共有できるようになりました。 新しい「クロスアカウントバージョン 5」にアップグレードすることで、AWS Resource Access Manager (RAM) 上で単一のリソース共有を作成し、その中に無制限のテーブルを含めることが可能になります。新しい共有設定では、個別のリソースを関連付ける代わりにワイルドカードパターンが自動的に使用されます。
何が嬉しいのか #
これまでは、クロスアカウントで大量のデータカタログリソース（データベース、テーブルなど）を共有しようとすると、AWS RAM のリソース関連付けの上限に達してしまうなどの制限がありました。今回の強化により、大規模なマルチアカウント分析環境においても、きめ細かなアクセス制御を維持しながら、スケーラブルかつ簡単にリソースを共有できるようになります。
これまでとどう変わるのか #
- これまで: 共有できるリソース数に制限があり、大量のテーブルを共有する際の管理が複雑でした。
- これから: 単一の RAM リソース共有で事実上無制限のテーブルを共有でき、管理オーバーヘッドが大幅に削減されます。既存の共有設定はそのまま機能し、API の互換性も維持されます。
具体的なユースケース #
- データメッシュ: 中央のデータカタログアカウントから、多数のコンシューマーアカウントに対して、数千のテーブルへのアクセス権を一括で付与する。
Amazon MSK Express Broker がブローカーログの出力をサポート #
投稿日: 2026年02月11日
何ができるようになったのか #
Amazon Managed Streaming for Apache Kafka (MSK) の Express Broker において、ブローカーログの出力が可能になりました。追加費用なしで利用でき、Amazon CloudWatch Logs や Amazon S3 にログを配信できます。
何が嬉しいのか #
これまでは Express Broker の内部動作を把握するためのログへのアクセスが制限されていた可能性がありますが、今回のアップデートにより、クライアント接続や可用性の問題のトラブルシューティング、リバランスやフェイルオーバー時のブローカーの挙動に関する洞察を得ることが容易になります。
これまでとどう変わるのか #
- これまで: Express Broker を使用している場合、詳細なブローカーログを取得できず、問題解決に時間がかかることがありました。
- これから: Standard Broker と同様にログを活用できるようになり、Kafka クラスターの運用監視能力が向上します。既存の Express Broker でも設定を有効化することで利用可能です。
具体的なユースケース #
- 接続トラブルシューティング: クライアントが接続できない理由を特定するためにエラーログを確認する。
- パフォーマンス分析: リバランス中の挙動を分析し、スループット低下の原因を調査する。
Amazon EC2 C8id, M8id, R8id インスタンスが東京リージョンなどで利用可能に #
投稿日: 2026年02月10日
何ができるようになったのか #
Intel Xeon 6 プロセッサと高速な NVMe SSD ストレージを搭載した Amazon EC2 C8id, M8id, R8id インスタンスが、以下の追加リージョンで利用可能になりました。
- C8id: 欧州 (フランクフルト)、アジアパシフィック (東京)
- M8id: 欧州 (フランクフルト、スペイン)、アジアパシフィック (東京)
- R8id: 欧州 (スペイン)、アジアパシフィック (東京)
何が嬉しいのか #
これらのインスタンスは、前世代の C6id, M6id, R6id インスタンスと比較して、最大 43% のパフォーマンス向上と 3.3 倍のメモリ帯域幅を提供します。また、I/O 集約型のデータベースワークロードでは最大 46% のパフォーマンス向上が期待できます。 ローカル NVMe SSD ストレージを備えているため、高いディスク I/O 性能を必要とするワークロードに最適です。
これまでとどう変わるのか #
- これまで: 東京リージョンなどの特定のリージョンでは、最新世代のディスク付きインスタンスを利用できませんでした。
- これから: 東京リージョンのユーザーも、最新のコンピュート性能と高速なローカルストレージを組み合わせたインスタンスを利用して、アプリケーションのパフォーマンスを最大化できます。
具体的なユースケース #
- C8id: 高性能 Web サーバー、ビデオエンコーディング、分散分析。
- M8id: アプリケーションサーバー、マイクロサービス、中小規模のデータベース。
- R8id: インメモリデータベース、リアルタイムビッグデータ分析、大規模キャッシュ。
AWS Payment Cryptography がフランスの Cartes Bancaires (CB) 認定を取得 #
投稿日: 2026年02月11日
何ができるようになったのか #
AWS Payment Cryptography が、フランスの国内カード決済ネットワークである Groupement des Cartes Bancaires (CB) の承認を取得しました。これは、クラウドベースの決済暗号化サービスとしては初の一つとなります。
何が嬉しいのか #
これまで、CB ネットワークの決済を処理する組織（アクワイアラ、決済代行会社、銀行など）は、コンプライアンス要件を満たすために物理的なハードウェアセキュリティモジュール (HSM) を自前で調達・管理する必要がありました。今回の承認により、AWS のマネージドサービスを利用して、CB 準拠の決済ワークロードをクラウド上で安全かつ柔軟に実行できるようになります。これにより、運用負担を軽減しつつ、PCI PIN、P2PE、3DS、DSS などの既存の認定と組み合わせて堅牢なセキュリティ体制を構築できます。
これまでとどう変わるのか #
- これまで: フランス市場向けの決済システムをクラウド化する際、CB コンプライアンスへの対応がハードルとなっていた可能性があります。
- これから: AWS Payment Cryptography が公式に認定されたことで、フランス国内および関連する決済事業者は、安心して決済インフラを AWS に移行できるようになります。
具体的なユースケース #
- フランスで事業を展開するフィンテック企業や銀行が、オンプレミスの HSM を廃止し、AWS 上でフルマネージドな決済処理システムを構築する。