本日の主なトピック #
- AWS IAM Identity Center がマルチリージョンでのアカウントアクセスとアプリケーション利用をサポート（可用性が向上）
- Amazon DynamoDB Global Tables が複数アカウント間のレプリケーションをサポート（アカウントレベルでの分離とDR強化）
- Amazon CloudWatch Application Signals が Kiro powers (AI IDE拡張) との統合をサポート
- Amazon Quick Suite (旧 QuickSight) でマップ上の曖昧な場所を簡単に解決可能に（QuickSightのリブランドも判明）
- Amazon Aurora DSQL が NUMERIC データ型のインデックスをサポート
¥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
SageMaker JumpStart で NVIDIA NIM を使用して創薬とロボティクスのパイプライン構築が可能に #
投稿日: 2026年02月02日
何ができるようになったのか #
Amazon SageMaker JumpStart において、バイオサイエンスと物理 AI 向けに特化した以下の4つの NVIDIA NIM モデルをワンクリックでデプロイできるようになりました。
- ProteinMPNN: 構造データをガイドとして、タンパク質配列の最適化を高速かつ効率的に行うモデル。
- MSA Search NIM: クエリのアミノ酸配列をタンパク質配列データベースセットに対して GPU アクセラレーションで多重配列アライメント (MSA) するモデル。
- Nemotron-3.5B-Instruct: 高い推論パフォーマンス、ネイティブなツール呼び出しサポート、256k トークンのコンテキストウィンドウを持つモデル。
- Cosmos Reason: 物理 AI とロボティクス向けの、オープンでカスタマイズ可能な推論ビジョン言語モデル (VLM)。
何が嬉しいのか #
研究者や開発者は、これらの高度なモデルを AWS インフラストラクチャ上に迅速にデプロイし、バイオサイエンス研究、創薬、身体性を持つ AI (Embodied AI) アプリケーションの開発を加速できます。 NVIDIA によって最適化された推論マイクロサービス (NIM) として提供されるため、構築の手間を省き、すぐに利用を開始できます。
これまでとどう変わるのか #
- これまで: これらの特定の科学技術計算用モデルやロボティクス用モデルを使用するには、自分で環境構築や最適化を行う必要があったか、あるいは別のプラットフォームを使用する必要がありました。
- これから: SageMaker JumpStart から数クリックで、または SageMaker Python SDK を使用して、自身の AWS アカウントに最適化された状態でデプロイできるようになります。
具体的なユースケース #
- 創薬: ProteinMPNN を使用して、結合親和性と安定性が向上した高品質なタンパク質配列を生成する。
- ロボティクス: Cosmos Reason を使用して、ロボットが人間のように推論し、物理世界での行動計画を立てられるようにする。
Amazon Aurora DSQL が NUMERIC データ型のインデックスをサポート #
投稿日: 2026年02月03日
何ができるようになったのか #
Amazon Aurora DSQL において、NUMERIC データ型に対するインデックス作成がサポートされました。
これにより、NUMERIC カラムを主キー（Primary Key）およびセカンダリインデックスの両方で使用できるようになりました。
何が嬉しいのか #
通貨金額、測定値、統計データなど、高精度な数値データを扱うワークロードにおいて、クエリパフォーマンスが向上します。
これまでは NUMERIC 型のカラムで効率的な検索やソートを行うことが難しかった（または主キーにできなかった）制限が解消され、より柔軟なデータモデリングが可能になります。
これまでとどう変わるのか #
- これまで:
NUMERICデータ型はサポートされていましたが、インデックスを作成することができませんでした（したがって主キーにも使用できませんでした）。高精度な数値検索を行う場合、パフォーマンスに制約がありました。 - これから:
NUMERIC型に対してインデックスを作成できるため、高速な検索が可能になり、主キーとして使用して一意性を保証することもできるようになります。
具体的なユースケース #
- 金融アプリケーションで、正確な金額（
NUMERIC型）に基づいて取引データを高速に検索する。 - 科学技術計算で、高精度な測定値を主キーとしてデータを管理する。
Amazon Connect がエージェントパフォーマンス評価に対する異議申し立てワークフローを提供開始 #
投稿日: 2026年02月03日
何ができるようになったのか #
Amazon Connect において、エージェントが自身のパフォーマンス評価に対して異議を申し立て（アピール）を行い、それを解決するための統合されたワークフローが利用可能になりました。 エージェントが評価結果に同意できない場合、Amazon Connect の UI 上で直接、その理由を添えて異議を申し立てることができます。 指定されたマネージャーには自動的にメール通知が届き、異議内容を確認して解決することができます。
何が嬉しいのか #
これまでは評価に対するフィードバックや異議申し立てを管理する標準的なプロセスがシステム内に統合されていなかった可能性がありますが、本機能により、評価の公平性が向上し、エージェントのエンゲージメントを高めることができます。 マネージャーは、どの評価に対して異議が出されているかを監視し、ステータスを追跡することで、タイムリーな解決が可能になります。
これまでとどう変わるのか #
- これまで: エージェントパフォーマンス評価機能（2023年4月リリース）はありましたが、評価結果に対する異議申し立てを管理するための Connect 統合機能はなく、メールや口頭、別システムでのやり取りが必要だったと考えられます。
- これから: Amazon Connect の UI 内で完結する形で、エージェントが異議を申し立て、マネージャーがそれを審査・解決するワークフローが統合されました。
具体的なユースケース #
- エージェントが「積極的な傾聴（Active Listening）」の項目で低いスコアを受けた際、顧客の問題を認識し傾聴していた具体的な場面を例に挙げて、評価の見直しを求める。
- マネージャーがチーム全体の異議申し立て状況をダッシュボードで確認し、未解決の案件を処理する。
Amazon Lightsail でメモリ最適化インスタンスバンドルが利用可能に #
投稿日: 2026年02月02日
何ができるようになったのか #
Amazon Lightsail において、最大 512 GB のメモリを搭載したメモリ最適化インスタンスバンドルが利用可能になりました。 これらの新しいバンドルは 7 つのサイズで提供され、Linux および Windows の OS ブループリントやアプリケーションブループリント（WordPress, cPanel など）ですぐに使用できます。 IPv6-only およびデュアルスタック（IPv4/IPv6）の両方のネットワークタイプに対応しています。
何が嬉しいのか #
Lightsail のシンプルさを維持したまま、高い RAM 対 vCPU 比率を必要とするメモリ集約型のワークロードを実行できるようになります。 インメモリデータベース、リアルタイムビッグデータ分析、インメモリキャッシュシステム、HPC アプリケーション、大規模なエンタープライズアプリケーションなどに最適です。
これまでとどう変わるのか #
- これまで: Lightsail では汎用的なバンドル構成が主であり、大量のメモリを必要とするワークロードを実行するにはスペックが不足するか、メモリのためだけに vCPU 数が多い高価なプランを選ぶ、あるいは Amazon EC2 へ移行する必要がありました。
- これから: メモリリソースを重視したバンドルを選択できるため、メモリ集約型アプリケーションを Lightsail 上でコスト効率よく実行できるようになります。
具体的なユースケース #
- Redis や Memcached などのインメモリキャッシュサーバーの運用。
- 大規模なデータセットをメモリ上で処理する分析アプリケーションのホスティング。
Amazon Quick Suite (Quick Sight) でマップ上の曖昧な場所を簡単に解決可能に #
投稿日: 2026年02月03日
何ができるようになったのか #
Amazon Quick Suite 内の Quick Sight 機能において、マップビジュアル上で曖昧な場所（同じ名前で複数の場所に存在する都市など）を直接解決または更新できるようになりました。 以下の3つの方法で正確な地理的コンテキストを定義できます。
- 階層を作成するためのサポートフィールド（例：州など）を追加する。
- 地理データベースから特定の場所を検索して選択する。
- 正確な緯度と経度を入力する。
何が嬉しいのか #
「Springfield」（米国各地にある地名）のようなデータが含まれている場合でも、意図した通りの場所を表示できるようになります。 「解決済み（Matched）」「不一致（Unmatched）」などのステータスが明確に表示されるため、ダッシュボード作成者は地理データのマッピング状況を効率的に管理し、信頼性の高い地理的インサイトを提供できます。
これまでとどう変わるのか #
- これまで: データセット側に正確な階層情報が不足している場合、曖昧な地名が正しくマップされず、意図しない場所が表示されたり、表示されなかったりする場合がありました。修正にはデータソース側での加工が必要な場合もありました。
- これから: Quick Sight の画面上で、曖昧な場所に対して「今すぐ解決 (Resolve now)」を選択し、インタラクティブに修正できるようになります。
具体的なユースケース #
- 売上データを地図上に表示する際、同名の都市があるため集計が正しく表示されているか不安な箇所を、マップ上で個別に確認して修正する。
Amazon RDS がデータベース接続のための拡張されたコンソールエクスペリエンスを提供開始 #
投稿日: 2026年02月03日
何ができるようになったのか #
Amazon RDS のコンソールにおいて、データベースへの接続に必要な情報が 1 か所に集約され、より簡単に接続できるようになりました。 具体的には以下の機能が提供されます。
- コードスニペットの提供: Java, Python, Node.js などのプログラミング言語や、psql などのコマンドラインツール向けの接続用コードスニペットが用意されます。
- 設定の自動反映: データベースの認証設定（例：IAM データベース認証）に応じて、コードスニペットの内容（トークンベース認証の使用など）が自動的に調整されます。
- CloudShell の統合: RDS コンソールから直接 CloudShell を起動し、データベースに接続することが可能になりました。
何が嬉しいのか #
開発者は、エンドポイント、ポート、認証方法などを個別に調べてコードを記述する手間が省けます。 特に IAM 認証のような少し複雑な手順を要する場合でも、生成されたスニペットを使用することでスムーズに実装を開始できます。 また、CloudShell の統合により、ローカル環境にツールをインストールすることなく、ブラウザ上ですぐに接続確認が行えます。
これまでとどう変わるのか #
- これまで: 接続エンドポイントをコピーし、ドキュメントを参照しながら適切なドライバや認証設定を含む接続コードを自力で作成する必要がありました。IAM 認証を使う場合は特に手順が煩雑でした。
- これから: コンソール上に表示される「接続」セクションから、すぐに使えるコードやコマンドをコピー＆ペーストするだけで済みます。
具体的なユースケース #
- 新しく立ち上げた RDS インスタンスに対して、Python アプリケーションから接続するためのボイラープレートコードを即座に取得する。
- 接続トラブルシューティングのために、コンソールから CloudShell を開いて psql コマンドで直接アクセスを試みる。
AWS IAM Identity Center がマルチリージョンでのアカウントアクセスとアプリケーション利用をサポート #
投稿日: 2026年02月03日
何ができるようになったのか #
AWS IAM Identity Center (旧 AWS SSO) の設定（ID、権限セットなど）を、最初に有効化したプライマリリージョンから、選択した追加のリージョンに自動的に複製できるようになりました。 これにより、ユーザーは追加のリージョン経由でも AWS アカウントやアプリケーションにアクセスできるようになります。
何が嬉しいのか #
- レジリエンス（回復力）の向上: プライマリリージョンで障害が発生しても、ユーザーは追加リージョンを使用して AWS アカウントへのアクセスを継続できるため、業務への影響を最小限に抑えられます。
- データレジデンシーとパフォーマンス: アプリケーションのデータレジデンシー要件や、ユーザーに近いリージョンへのアプリケーションデプロイが可能になります。
これまでとどう変わるのか #
- これまで: IAM Identity Center は単一のリージョンにデプロイされるサービスであり、そのリージョンが障害の影響を受けると、SSO ログインやポータルへのアクセスができなくなるリスクがありました（単一障害点になり得た）。
- これから: 複数のリージョンでアクティブに機能するため、可用性が大幅に向上します。管理自体は引き続きプライマリリージョンで行い、変更内容は自動的に他のリージョンへ同期されます。
具体的なユースケース #
- 東京リージョンをプライマリとし、大阪リージョンを追加リージョンとして設定することで、大規模災害時などの BCP (事業継続計画) 対策を強化する。
- グローバル展開している企業が、各地域のユーザーに近いリージョンで認証基盤を提供し、レイテンシーを低減する。
AWS Lake Formation がアジアパシフィック（ニュージーランド）リージョンで利用可能に #
投稿日: 2026年02月03日
何ができるようになったのか #
AWS Lake Formation がアジアパシフィック（ニュージーランド）リージョン (ap-southeast-5) で利用可能になりました。
何が嬉しいのか #
ニュージーランドリージョンを利用しているユーザーは、Lake Formation を使用して、きめ細かいデータアクセス許可を一元管理し、組織内外でデータを安全に共有できるようになります。 データレジデンシー要件を満たしつつ、安全なデータレイクを構築しやすくなります。
これまでとどう変わるのか #
- これまで: ニュージーランドリージョンでは Lake Formation が利用できなかったため、IAM ポリシーやバケットポリシーなどを組み合わせて個別にアクセス制御を行う必要があったか、あるいは他のリージョンを使用する必要がありました。
- これから: 同リージョンで Lake Formation の一元化されたセキュリティ管理機能が利用可能になります。
具体的なユースケース #
- ニュージーランド国内にデータを保持しながら、Amazon Athena や Amazon Redshift など複数の分析サービスから安全にデータへアクセスさせる。
- 行レベル・列レベルの細かいアクセス制御を適用する。
AWS Marketplace が EMEA 地域でのプロフェッショナルサービス購入においてローカライズされた請求処理を導入 #
投稿日: 2026年02月03日
何ができるようになったのか #
EMEA (ヨーロッパ、中東、アフリカ) 地域の顧客が AWS Marketplace を通じてプロフェッショナルサービス（コンサルティングや導入支援など）を購入する際、AWS EMEA から直接請求書を受け取り、SEPA (Single Euro Payment Area) などの現地通貨・支払い方法を利用できるようになりました。
何が嬉しいのか #
これまでは支払い送金プロセスが複雑で調達の障壁となっていましたが、今回の変更により、AWS 利用料と Marketplace の購入を一元化し、現地の商習慣に合わせた支払いが可能になります。
これまでとどう変わるのか #
- これまで: プロフェッショナルサービスの購入において、異なる AWS エンティティ間での決済処理が必要で、手続きが煩雑な場合がありました。
- これから: AWS EMEA がマーケットプレイスオペレーターとして機能し、一貫した請求とローカル決済手段（SEPAダイレクトデビットなど）を提供します。
具体的なユースケース #
- ヨーロッパに拠点を持つ企業が、現地のコンサルティングパートナーから導入支援サービスを Marketplace 経由で購入し、ユーロ建ての口座振替で支払う。
AWS Multi-Party Approval が承認投票時にワンタイムパスワード検証を必須化 #
投稿日: 2026年02月02日
何ができるようになったのか #
AWS Multi-Party Approval (MPA) において、承認者が投票（承認または拒否）を行う際、AWS Identity Center に登録されたメールアドレスに送信されるワンタイムパスワード (OTP) による検証が必須となりました。
何が嬉しいのか #
この追加のセキュリティレイヤーにより、AWS IAM Identity Center の管理者権限を持つユーザーが、承認者の認証情報をリセットしたり認証エンドポイントを変更したりして承認者になりすまし、MPA の承認プロセスを不正にバイパスすることを防ぐことができます。 より強固な内部統制とセキュリティが実現できます。
これまでとどう変わるのか #
- これまで: 承認者はポータルにログインして承認ボタンを押すだけで投票できた可能性がありますが、管理者がそのアカウントを乗っ取った場合のリスクがありました。
- これから: 投票アクションの直前に6桁の検証コードがメールで送信され、その入力が必須となるため、登録されたメールアドレスにアクセスできない限り（つまり本人でない限り）、投票を完了できなくなります。
具体的なユースケース #
- 重要なリソース変更やアクセス権限の付与に対して、システム管理者自身による不正やミスを防ぎ、確実に指定された承認者本人の合意を得る。
Amazon CloudWatch Application Signals が Kiro powers との統合をサポート #
投稿日: 2026年01月30日
何ができるようになったのか #
Amazon CloudWatch Application Signals が「Kiro powers」との統合をサポートしました。 これにより、AWS の AI 搭載 IDE である Kiro IDE 内で、AI エージェントの支援を受けながらアプリケーションの健全性に関する問題を迅速に調査できるようになります。 Kiro power for Amazon CloudWatch Application Signals は、Application Signals の MCP (Model Context Protocol) サーバーとターゲットを絞った可観測性ガイダンスをパッケージ化したものです。
何が嬉しいのか #
開発者は IDE を離れることなく、AI エージェントに対して「このサービスの SLO 違反の原因は？」といった自然言語での質問が可能になります。 Kiro power は、サービスの健全性監視、SLO 準拠状況、調査ワークフローに関するコンテキストを AI エージェントに即座に提供するため、分散アプリケーションのトラブルシューティング時間を数時間から数分へと大幅に短縮できます。
これまでとどう変わるのか #
- これまで: アプリケーションの問題を調査するには、AWS コンソールを行き来したり、ログやメトリクスを手動で相関させたりする必要があり、IDE とのコンテキストスイッチが発生していました。
- これから: Kiro IDE 内で必要なガイダンスと運用シグナルが動的にロードされ、AI エージェントが必要なコンテキスト（特定のタスクに必要な情報のみ）を受け取って分析を支援してくれるため、シームレスなデバッグが可能になります。
具体的なユースケース #
- SLO（サービスレベル目標）違反が発生した際、Kiro IDE 内で AI エージェントに調査を依頼し、影響を受けているサービスや操作を特定する。
- 関連するメトリクスやトレースを AI が自動的に提示し、根本原因の特定を支援する。
AWS Kiro とは: AWS が開発している実験的な AI 搭載統合開発環境 (IDE) です。VS Code (Code-OSS) をベースにしており、自律的な「エージェント AI」がコードベースの調査や変更、仕様書作成などを支援します。
Kiro powers とは: Kiro エージェントの機能を拡張するためのパッケージです。MCP (Model Context Protocol) サーバー、ステアリングファイル（AI への指示書）、フックなどが含まれており、特定のツールやサービス（今回であれば CloudWatch Application Signals）の専門知識を AI エージェントにオンデマンドで提供します。
AWS マネジメントコンソールのナビゲーションバーにアカウント名が表示されるように #
投稿日: 2026年02月03日
何ができるようになったのか #
AWS マネジメントコンソールの右上のナビゲーションバーに、現在ログインしている「アカウント名」が直接表示されるようになりました（これまではアカウント ID などが表示されていました）。
何が嬉しいのか #
複数の AWS アカウント（開発用、本番用、検証用など）を使い分けているユーザーにとって、現在どのアカウントを操作しているかが一目でわかるようになります。 これにより、誤って本番環境のアカウントで操作してしまうといったミス（誤操作）のリスクを減らすことができます。
これまでとどう変わるのか #
- これまで: ナビゲーションバーには主にアカウント ID が表示されており、アカウント名を確認するにはメニューをクリックしてドロップダウンを開く必要があったか、ID を暗記している必要がありました。
- これから: アカウント名が常時表示されるため、視覚的に即座に識別できます。
具体的なユースケース #
- ブラウザのタブを複数開いて作業している際に、タブを切り替えた直後に「ここは本番環境だ」と名前を見て即座に認識する。
Amazon DynamoDB Global Tables が複数アカウント間のレプリケーションをサポート #
投稿日: 2026年02月03日
何ができるようになったのか #
Amazon DynamoDB Global Tables において、異なる AWS アカウント間でのテーブルレプリケーションが可能になりました。 これまでは同一アカウント内の複数リージョン間でのみレプリケーションが可能でしたが、今後はアカウントの境界を越えてデータを同期できます。
何が嬉しいのか #
- セキュリティとガバナンスの向上: ワークロードをアカウントレベルで分離し、それぞれに異なるセキュリティポリシーやアクセス制御を適用できます。
- 耐障害性の強化: 万が一特定のアカウントにセキュリティ侵害や障害が発生した場合でも、別のアカウントにあるデータは保護され、可用性を維持しやすくなります（アカウントレベルの障害隔離）。
- 組織構造への適合: 事業部門ごとにアカウントを分けている場合でも、必要なデータを共有・同期することが容易になります。
これまでとどう変わるのか #
- これまで: Global Tables は単一の AWS アカウント内でのみ構成可能でした。異なるアカウントにデータを複製するには、DynamoDB Streams と Lambda などを組み合わせて自前で実装する必要がありました。
- これから: Global Tables のマネージドな機能として、マルチアカウント・マルチリージョンのレプリケーションを簡単に設定できます。
具体的なユースケース #
- 本番環境のアカウントと、DR（災害復旧）用のアカウントを完全に分離し、DR アカウントへのデータ同期を Global Tables で行う。
- 異なるビジネスユニット（別アカウント）間で共有すべきマスターデータをリアルタイムに同期する。
Oracle Database@AWS がカナダ中部およびシドニーリージョンで利用可能に #
投稿日: 2026年02月03日
何ができるようになったのか #
Oracle Database@AWS が、カナダ中部 (CA-Central-1) および アジアパシフィック（シドニー） (AP-Southeast-2) の 2 つのリージョンで利用可能になりました。 これにより、利用可能なリージョンは合計 7 リージョン（バージニア北部、オレゴン、オハイオ、フランクフルト、東京、カナダ中部、シドニー）となりました。
何が嬉しいのか #
カナダやオーストラリアにデータレジデンシー要件を持つ顧客が、オンプレミスの Oracle Exadata や Oracle RAC (Real Application Clusters) アプリケーションを、AWS 環境上の同等の環境へ容易に移行できるようになります。 移行後は、AWS KMS による暗号化や Amazon CloudWatch による監視など、AWS サービスとの統合メリットを享受できます。
これまでとどう変わるのか #
- これまで: 該当リージョンの顧客は、AWS 上で Exadata レベルのパフォーマンスや RAC を必要とする場合、他のリージョンを使用するか、AWS 上で EC2 ベースの構成を組むなどの代替手段を検討する必要がありました。
- これから: ローカルリージョンの AWS データセンター内に配置された OCI 管理の Exadata システムを利用できるようになります。