はじめに
AWSの基礎力をつけるためにAWS What's Newを毎日目を通す事を始めました。
最初は日本語訳されたものを見ていたのですが、1週間ほど遅れて訳されるようなので、英語の情報を訳して整理することにしました。
本情報が役立つ人もいるかなと思い公開します。
個人的な理解なので、実際の情報は原典をあたってください。
AWS Outposts racksが新しいAmazon CloudWatchメトリクスをサポート
投稿日: 2025年8月6日
何ができるようになったのか
AWS Outposts racksで、新しいAmazon CloudWatchメトリクスであるVifConnectionStatus
とVifBgpSessionState
が利用可能になりました。これらのメトリクスにより、Outposts racksのローカルゲートウェイ(LGW)およびサービスリンク仮想インターフェイス(VIF)と、オンプレミスデバイスとの接続状態をより詳細に可視化できます。
何が嬉しいのか
外部のネットワークツールや他チームとの連携に頼ることなく、CloudWatchコンソール内で直接Outposts VIFの接続状態を監視できます。これにより、アラームの設定、接続問題のトラブルシューティング、オンプレミスインフラとの適切な統合の確認が容易になります。
これまでとどう変わるのか
-
これまで
- Outposts VIFの接続状態を監視するには、外部のネットワークツールを使用したり、ネットワークチームと連携する必要がありました。
-
これから
- CloudWatchコンソールから直接、
VifConnectionStatus
(VIFがトラフィックを転送できるか)とVifBgpSessionState
(BGPセッションの状態)の2つのメトリクスで接続状態を監視できるようになります。
- CloudWatchコンソールから直接、
具体的なユースケース
- Outposts racksを利用している環境で、オンプレミスネットワークとの接続性を継続的に監視する。
- 接続に問題が発生した際に、CloudWatchアラームで迅速に通知を受け取り、トラブルシューティングを開始する。
- ネットワークの変更後に、BGPセッションが正しく確立されているかをCloudWatchメトリクスで確認する。
AWS Outposts racksとは、AWSが構築・管理するラック(物理サーバ)を、ユーザーのデータセンターに設置し、そこからAWSの各種サービスを使えるようにする仕組みです。
Amazon RDSがMicrosoft SQL Serverの新しいCUとGDRをサポート
投稿日: 2025年8月6日
何ができるようになったのか
Amazon RDS for SQL Serverが、SQL Server 2022の累積更新プログラム(CU)20、およびSQL Server 2016、2017、2019の一般配布リリース(GDR)をサポートするようになりました。
何が嬉しいのか
これらの更新には、重要なセキュリティ修正、パフォーマンスの向上、バグ修正が含まれています。特に、複数のCVE(共通脆弱性識別子)で報告されている脆弱性に対処しているため、データベースのセキュリティが大幅に向上します。
これまでとどう変わるのか
-
これまで
- ユーザーは、これらの最新の累積アップデートやGDRに含まれるセキュリティ修正や機能改善をRDS for SQL Serverで利用できませんでした。
Amazon RDS for SQL Server では、これまでもセキュリティ修正(Security Updates)は一部提供されていましたが、CU(Cumulative Update)や GDR(General Distribution Release)などをすぐには取り込めない制限がありました。
- RDS for SQL Server は「マネージドサービス」であるため、Microsoftが出したばかりのCUやGDRを即時には適用できません。
- AWS がそれらを 社内でテスト・検証した後に提供開始する方式です。
- 利用者は AWS 側が提供しているバージョンの中から選んでアップグレードする運用でした。
-
これから
- Amazon RDS管理コンソール、AWS SDK、またはCLIを使用して、RDS for SQL Serverインスタンスを最新バージョンに簡単にアップグレードし、最新のセキュリティパッチや改善を適用できるようになります。
具体的なユースケース
- RDS for SQL Serverを利用しているシステムで、最新のセキュリティ脆弱性に対応するためにデータベースインスタンスをアップグレードする。
- SQL Serverのパフォーマンス向上やバグ修正の恩恵を受けるために、CUやGDRを適用する。
VPC Reachability AnalyzerとNetwork Access Analyzerが5つの新リージョンで利用可能に
投稿日: 2025年8月6日
何ができるようになったのか
Amazon VPC Reachability AnalyzerとAmazon VPC Network Access Analyzerが、新たに5つのAWSリージョン(ジャカルタ、マレーシア、タイ、チューリッヒ、UAE)で利用可能になりました。
何が嬉しいのか
これまでこれらのリージョンでは利用できなかったネットワークの可達性診断や、意図しないネットワークアクセスを特定する機能が使えるようになり、セキュリティとコンプライアンスのガイドラインを満たすのに役立ちます。
これまでとどう変わるのか
-
これまで
- 対象の5リージョンでは、VPC Reachability AnalyzerやVPC Network Access Analyzerを利用できず、ネットワークのトラブルシューティングやセキュリティ分析に他の手段を用いる必要がありました。
-
これから
- 対象の5リージョンでも、これらの分析ツールをネイティブに利用できるようになり、VPC内のリソース間の接続性問題を診断したり、意図しないネットワークアクセスを検出したりすることが容易になります。
具体的なユースケース
-
VPC Reachability Analyzer:
- 異なるアカウントのVPCにあるEC2インスタンス間で通信ができない場合に、原因(例:ルートテーブルのエントリ不足)を特定する。
-
VPC Network Access Analyzer:
- Webアプリケーションからインターネットへの全ての通信が、指定したファイアウォールを経由していることを確認し、バイパスしている経路がないかを検出する。
Amazon DynamoDBがConsole-to-Codeをサポート
投稿日: 2025年8月6日
何ができるようになったのか
Amazon DynamoDBが、Amazon Q Developerを搭載した「Console-to-Code」のサポートを開始しました。これにより、コンソールでの操作をコードに変換し、インフラの自動化を簡単に行えるようになります。
何が嬉しいのか
DynamoDBコンソールでのプロトタイピングや学習目的の操作を記録し、その操作に対応するInfrastructure as Code (IaC) 形式のコード(AWS CDKやCloudFormation)を生成AIが提案してくれます。これにより、手動でのプロトタイピングから本番環境のインフラ自動化への移行が、簡単、迅速、かつコスト効率よく行えるようになります。
これまでとどう変わるのか
-
これまで
- コンソールで作成したDynamoDBテーブルなどのリソースをコード化するには、手動でCDKやCloudFormationのテンプレートを記述する必要がありました。
-
これから
- コンソールでの操作を記録するだけで、好みのIaCフォーマット(CDKのTypeScript/Python/JavaやCloudFormationのYAML/JSON)のコードが自動生成され、それをベースに本番用のインフラコードを開発できるようになります。
具体的なユースケース
- 開発者がDynamoDBコンソールでテーブルを作成し、その設定を元にConsole-to-Code機能を使ってAWS CDKのコードを生成し、アプリケーションのインフラ定義に組み込む。
- インフラ担当者が、プロトタイプとして作成されたDynamoDBリソースの設定を、CloudFormationテンプレートとしてエクスポートし、本番環境のデプロイメントパイプラインに統合する。
AWSコンソールモバイルアプリがAWSサポートへのアクセスを提供開始
投稿日: 2025年8月6日
何ができるようになったのか
AWSコンソールモバイルアプリから、AWSサポートケースの表示と管理ができるようになりました。
何が嬉しいのか
外出先やPCから離れている時でも、モバイルアプリを使ってサポートケースのやり取りの表示・返信、ケースの解決・再開、新規作成ができるようになり、迅速な対応が可能になります。
これまでとどう変わるのか
-
これまで
- サポートケースを管理するには、PCなどからAWSマネジメントコンソールにアクセスする必要がありました。
-
これから
- AWSコンソールモバイルアプリの「サービス」タブから「サポート」を選択するだけで、いつでもどこでもサポートケースを管理できるようになります。
具体的なユースケース
- システムに障害が発生した際に、移動中のエンジニアがスマートフォンからサポートケースを作成し、AWSサポートとやり取りを開始する。
- 担当者が休暇中であっても、緊急のサポートリクエストに対してモバイルアプリから状況を確認し、対応の指示を出す。
Amazon Aurora Serverless v2が最大30%のパフォーマンス向上を提供
投稿日: 2025年8月7日
何ができるようになったのか
Amazon Aurora Serverless v2が、最新のプラットフォームバージョン(バージョン3)で最大30%のパフォーマンス向上を実現しました。また、0から256 Auroraキャパシティユニット(ACU)までのスケーリングをサポートします。
何が嬉しいのか
パフォーマンスが向上したことで、より要求の厳しいワークロードにもAurora Serverless v2を利用できるようになります。コスト効率の良いオンデマンドのスケーリングと高いパフォーマンスを両立できます。
これまでとどう変わるのか
-
これまで
- 以前のバージョンでは、パフォーマンスに制約があり、特定の高負荷なワークロードには不向きな場合がありました。
-
これから
- 最新のプラットフォームバージョンではパフォーマンスが最大30%向上し、より幅広いワークロードに対応可能になります。既存のクラスターも、停止・再起動やBlue/Greenデプロイメントによってアップグレードできます。
具体的なユースケース
- トラフィックの変動が激しいeコマースサイトのデータベースとして、ピーク時には高いパフォーマンスを発揮し、閑散期にはコストを抑える。
- 開発・テスト環境で、普段は最小限のキャパシティで運用し、負荷テストの時だけ自動でスケールアップさせる。
こういう何もしなくてもパフォーマンスが上がったり、安くなったりするのすごい嬉しいですよね 😄
Amazon QuickSightがApache Impalaへの接続をサポート
投稿日: 2025年8月6日
何ができるようになったのか
Amazon QuickSightが、ネイティブのApache Impalaコネクタの一般提供を開始しました。
何が嬉しいのか
QuickSightユーザーは、Impalaのユーザー名とパスワード認証情報を使用して接続し、データをSPICE(QuickSightのインメモリ計算エンジン)にインポートできるようになります。これにより、Hadoop上の大規模データに対して高速なSQLクエリを実行し、その結果をQuickSightで可視化・分析することが容易になります。
これまでとどう変わるのか
-
これまで
- QuickSightからImpalaに接続するには、ODBC/JDBCなどの汎用的なコネクタを使用する必要があり、設定が複雑だったり、パフォーマンスが最適でなかったりする可能性がありました。
-
これから
- ネイティブコネクタが提供されることで、より簡単かつパフォーマンスの高い方法でImpalaに接続し、データをSPICEにインポートして高速な分析ができるようになります。
具体的なユースケース
- 企業がオンプレミスやEC2上のHadoopクラスタに保存されている大量のデータを、Impala経由でQuickSightに接続し、ビジネスインテリジェンスダッシュボードを作成する。
- データアナリストが、Impalaの高速クエリエンジンを活用して、大規模データセットから必要なデータを抽出し、QuickSightでインタラクティブな分析を行う。
ImpalaというのはHadoopのクエリエンジンのことです。
Amazon Bedrock Guardrailsで自動推論チェックが利用可能に
投稿日: 2025年8月6日
何ができるようになったのか
Amazon Bedrock Guardrails内で、自動推論チェック(Automated Reasoning checks)が一般提供開始されました。これは、形式検証技術を使用して生成AIモデルの出力の正確性とポリシーコンプライアンスを検証するセーフガードです。
何が嬉しいのか
LLMからの正しい応答を最大99%の精度で検出し、AIのハルシネーション(幻覚)を検出する上で証明可能な保証を提供します。また、モデルの応答における曖昧さの検出も支援します。これにより、特に規制の厳しい業界で求められる、AI出力の明確な検証が可能になります。
これまでとどう変わるのか
-
これまで
- AIの出力品質は、主にサンプリングによるテストに依存していました。これは、すべての応答がビジネスルールに準拠していることを数学的に保証するものではありませんでした。
-
これから
- 自動推論チェックは、AIの応答が定義されたビジネスルールやドメイン知識に準拠していることを数学的に厳密に保証する、根本的に異なるアプローチを提供します。
具体的なユースケース
- 金融機関が、顧客に提供する投資アドバイスが、社内のコンプライアンスポリシーや規制に完全に準拠していることを、自動推論チェックを用いて検証する。
- ヘルスケア分野で、AIが生成する医療情報が、定義された医学的知識と矛盾しないことを保証し、誤った情報が提供されるリスクを最小限に抑える。
ハルシネーションや曖昧さを検出できるということでとても便利そうですね。
とは言え最大99%の精度、ということで100%ではないのでよく考えて使う必要がありそうです。
OpenAIオープンウェイトモデルがAmazon BedrockとSageMaker JumpStartで利用可能に
投稿日: 2025年8月6日
何ができるようになったのか
AWS は、最先端の基盤モデルへのアクセスをさらに拡大しています。現在、OpenAI のオープンウェイトモデルが Amazon Bedrock および Amazon SageMaker JumpStart で利用可能になりました。
AWS 上で利用できるこれらの新しい OpenAI のオープンウェイトモデル(gpt-oss-120b および gpt-oss-20b)を使うことで、特定のユースケースに最適なモデルを選び、革新を進める自由度がさらに高まり、同時にデータの完全な制御も維持できます。
何が嬉しいのか
これらの OpenAI のオープンウェイトモデルは、コーディング、科学的分析、数学的推論といったタスクに優れており、主要な他のモデルと同等の性能を発揮します。両モデルとも 128K のコンテキストウィンドウと、特定の要件に応じて調整可能な推論レベル(低/中/高)を備えています。外部ツールとの統合をサポートし、Strands Agents のようなフレームワークを通じてエージェント的なワークフローにも利用できます。完全なチェイン・オブ・ソート(思考の連鎖)出力機能を備えており、モデルの推論プロセスを詳細に可視化できます。
これらのモデルには、Amazon Bedrock の統一 API 経由でアクセスでき、コードを書き直すことなく複数のプロバイダー間でシームレスに試行・切り替えが可能です。OpenAI の SDK を使ってエンドポイントを更新するだけで Amazon Bedrock を直接呼び出すこともできます。これらのモデルは、エンタープライズグレードのセキュリティとスケーラビリティを享受しながら、ビジネス要件に合わせた柔軟な変更やカスタマイズも可能です。
これまでとどう変わるのか
-
これまで
- AWS上でOpenAIのモデルを利用するには、特定のAPIエンドポイントや統合方法が必要でした。また、モデルのカスタマイズや運用には専門知識が必要でした。
-
これから
- Amazon Bedrockの統一APIを通じて、コードの書き換えなしにシームレスにモデルを実験・切り替えできるようになります。OpenAI SDKを使用してBedrockに直接アクセスでき、エンドポイントを更新するだけで済みます。また、エンタープライズグレードのセキュリティとシームレスなスケーリングの恩恵を受けながら、モデルの変更やカスタマイズが容易になります。
具体的なユースケース
- 開発者が、AWS BedrockのAPIを利用して、gpt-oss-120bモデルを使用してコード生成やデバッグを行い、開発効率を向上させる。
- データサイエンティストが、SageMaker JumpStartを通じてgpt-oss-20bモデルをデプロイし、科学的データセットの分析や複雑な数学的問題の解決に活用する。
- エージェントワークフローにおいて、Strands Agentsフレームワークと連携させ、外部ツールを呼び出す能力を持つAIエージェントを構築する。
「完全な制御が維持できる」とは以下の背景によるもので、ユーザーはデータの保管場所、アクセス制御、暗号化などを完全に設定可能になります
- モデルがオープンウェイト(open weight)であるため
- OpenAI の「gpt-oss-120b」や「gpt-oss-20b」は、学習済み重み(weights)が公開されているモデル
- ファインチューニングや推論を自分の環境(AWSの中)で完結できる
- 実行環境が AWS 上にあるため、ユーザーはデータの保管場所、アクセス制御、暗号化などを完全に設定可能
- Bedrock や SageMaker JumpStart はAWS上の管理されたインフラ
- モデルへの入力・出力は AWSのネットワーク・ストレージ内にとどまる
- 外部のモデルプロバイダーにデータが送られない
- ChatGPTのようなSaaS型LLMでは、プロンプトやデータが外部(OpenAI)に送られる
- 今回の「open weightモデル」はそうではなく、AWS上にデプロイして動かすスタイル
さいごに
LLMの活用がどんどん進んでいきますね。
DynamoDBのコンソールではLLMの力を借りてテーブルの設定などを実施しIaCに落とすことができるようになりました。
便利そうな気もしますが、コンソールを経由するとAWS環境にゴミが残ることが増えそうな気もしますね。
Amazon Bedrock Guardrailsもとても便利そうです。
日進月歩(秒進時歩くらいか?)ですし、お金もかかるのでなかなかついていけないですが、読むくらいはしておいたほうが良さそうですね。