本日の主なトピック #
- AWS サービスのアベイラビリティ更新（App Runner や Audit Manager などのメンテナンス/提供終了発表）
- AI エージェントの自動評価と運用の自動化（AgentCore Evaluations と DevOps Agent の一般提供開始）
- 自律的なペネトレーションテスト（AWS Security Agent の一般提供開始）
- CloudWatch ログ分析の強化（ルックアップコマンドとデータソースベースの集約）
¥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 Bedrock AgentCore Evaluations が一般提供開始（GA） #
投稿日: 2026年03月31日
何ができるようになったのか #
AI エージェントの品質を自動で評価する「Amazon Bedrock AgentCore Evaluations」が一般提供開始されました。本番トラフィックの継続的な評価（オンライン評価）と、テストワークフローによる検証（オンデマンド評価）の2種類を提供し、AI エージェントのパフォーマンスを測定・監視できます。
何が嬉しいのか #
13種類の組み込み評価指標（応答品質、安全性、タスク完了率、ツール使用状況など）を使用して、開発者はエージェントの品質を客観的に判断できます。また、Ground Truth を使用した期待値との比較や、Lambda 関数（Python/JS）を用いたカスタム評価ロジックの実装も可能で、ドメイン固有の要件にも柔軟に対応できます。
これまでとどう変わるのか #
- これまで: AI エージェントの品質評価は手動、あるいは個別のツール構築が必要で、本番環境での継続的な監視や CI/CD パイプラインへの統合が困難でした。
- これから: AgentCore Observability と統合された統一的なモニタリング環境で、自動評価とリアルタイムのアラート設定が可能になり、自信を持ってエージェントをデプロイ・更新できるようになります。
具体的なユースケース #
- CI/CD パイプラインにオンデマンド評価を組み込み、エージェントの変更によるデグレが発生していないか自動テストする。
- 本番環境でのエージェントの応答をサンプリングし、オンライン評価で継続的に品質スコアを監視する。
Amazon Athena がキャパシティ予約の提供リージョンを拡大 #
投稿日: 2026年03月30日
何ができるようになったのか #
Amazon Athena の「キャパシティ予約（Capacity Reservations）」が、大阪、ソウル、香港などを含むさらに多くの商用リージョンで利用可能になりました。これにより、重要なワークロードに対して専用のサーバーレスキャパシティを確保できます。
何が嬉しいのか #
キャパシティ予約を使用することで、クエリはアカウント内の他のワークロードから分離して実行され、並列実行されるクエリの数を制御できます。マルチテナント環境におけるリソースの競合を避け、一貫したパフォーマンスを必要とするビジネスクリティカルな分析やレポート作成に最適です。
これまでとどう変わるのか #
- これまで: 一部の主要リージョンでのみ提供されており、今回追加されたリージョンではオンデマンドの共有キャパシティを使用するしかありませんでした。
- これから: アジアパシフィック（大阪、ソウル、香港、ハイデラバード、ジャカルタ、マレーシア、メルボルン、タイ、台北）や欧州、北米の各リージョンでも専用キャパシティを予約できるようになります。
具体的なユースケース #
- 毎朝の定型レポート生成など、決まった時間内に確実に完了させる必要がある重要なクエリの実行。
- ユーザーへのレスポンスが求められる対話型分析ツールにおいて、安定したクエリパフォーマンスを保証する。
Amazon Connect がチャットのテストおよびシミュレーション機能を拡張 #
投稿日: 2026年03月31日
何ができるようになったのか #
Amazon Connect において、チャット体験を数クリックでテスト・シミュレートできるようになりました。顧客の属性やチャットの理由、期待される応答、営業時間外や待ち行列の状態などのビジネス条件を設定し、チャットのワークフローを検証できます。
何が嬉しいのか #
複数のテストを同時に実行できるため、チャットワークフローの大規模な検証が短時間で可能になります。テスト結果は成功/失敗の判定に加え、シミュレーションされた対話のパスや詳細なログが表示されるため、問題の診断が容易です。また、分析ダッシュボードで共通の失敗パターンを特定することもできます。
これまでとどう変わるのか #
- これまで: チャットのセルフサービス体験やカスタマーサービスワークフローの検証には、手動でのテストが必要で、大規模な検証には時間がかかっていました。
- これから: 数クリックでシミュレーションを実行でき、複雑な分岐や条件分岐を含むチャット体験を迅速かつ自信を持ってデプロイできるようになります。
具体的なユースケース #
- 新しいチャットボットのシナリオを追加した際、想定通りの応答が返ってくるか、また営業時間外に正しく転送されるかを自動シミュレーションで確認する。
- 複数の顧客属性パターンで同時にテストを実行し、パーソナライズされたワークフローの挙動を網羅的にチェックする。
Amazon Connect がクイックレスポンスのタグベースアクセス制御をサポート #
投稿日: 2026年03月27日
何ができるようになったのか #
Amazon Connect のクイックレスポンスにおいて、タグベースのアクセス制御（TBAC）がルーティングプロファイルの割り当てに適用されるようになりました。これにより、管理者はルーティングプロファイルに付与されたタグに基づいて、特定のクイックレスポンスを表示・制限することができます。
何が嬉しいのか #
組織全体で TBAC を使用している場合、他の Amazon Connect リソースと同様の一貫したアクセス制御をクイックレスポンスにも適用できます。例えば、法務コンプライアンスチームが管轄区域ごとにルーティングプロファイルをタグ付けし、特定の地域向けの免責事項テンプレートなどのクイックレスポンスを適切なエージェントにのみ表示させることが可能になります。
これまでとどう変わるのか #
- これまで: 管理者が TBAC で設定したクイックレスポンスは、ルーティングプロファイルのタグに関わらず、すべてのエージェントが利用可能でした。
- これから: ルーティングプロファイルのタグとクイックレスポンスの TBAC 権限が照合され、エージェントの役割に最も関連性の高いコンテンツのみが表示されるようになります。
具体的なユースケース #
- 地域固有の開示情報テンプレートを、特定のリージョンを担当するエージェントのルーティングプロファイルに紐付けて表示する。
- 特定の製品専門知識を持つエージェントにのみ、その製品に関連するクイックレスポンスを表示させる。
Amazon ECS Managed Instances が EC2 インスタンスストアをサポート #
投稿日: 2026年03月31日
何ができるようになったのか #
Amazon ECS Managed Instances において、コンテナワークロードのデータボリュームとして Amazon EC2 インスタンスストアを使用できるようになりました。これにより、EBS ボリュームをプロビジョニングすることなく、高速なローカルストレージを利用可能です。
何が嬉しいのか #
インスタンスストアを活用することで、ストレージコストを削減できるだけでなく、低遅延が求められるワークロードにおいて I/O パフォーマンスを向上させることができます。ECS Managed Instances の完全マネージドなコンピューティングオプションの利便性はそのままに、ローカルストレージの性能を享受できます。
これまでとどう変わるのか #
- これまで: ECS Managed Instances では、データボリュームとして Amazon EBS が自動的にプロビジョニングされていました。
- これから: カスタムキャパシティプロバイダーの設定でインスタンスストアを含むインスタンスタイプを選択し、ローカルストレージを有効にすることで、インスタンスストアを直接利用できるようになります。
具体的なユースケース #
- 一時的なデータのキャッシュや、高速な読み書きが必要なスクラッチ領域としてローカルストレージを利用する。
- 分散データベースやビッグデータ処理など、高い I/O スループットが求められるコンテナアプリケーションの実行。
Amazon Managed Service for Apache Flink が Apache Flink 2.2 をサポート #
投稿日: 2026年03月31日
何ができるようになったのか #
Amazon Managed Service for Apache Flink において、Apache Flink バージョン 2.2 がサポートされました。これは Java 17 のサポート、I/O パフォーマンスを向上させる RocksDB 8.10.0、シリアライゼーションの強化など、ランタイムの大幅なアップグレードが含まれています。
何が嬉しいのか #
Java 17 への対応により、最新の Java 機能やライブラリを活用できるようになります。また、RocksDB のバージョンアップにより I/O 性能が改善され、ストリーミング処理の効率が向上します。「インプレース・バージョンアップグレード」機能を利用することで、既存のアプリケーションも簡単に Flink 2.2 へ移行可能です。
これまでとどう変わるのか #
- これまで: 古いバージョンの Flink（1.x 系など）が中心で、Java 17 などの新しいランタイム機能の恩恵を十分に受けられませんでした。
- これから: 最新の Flink 2.2 機能をフルマネージド環境で利用できるようになります。なお、Dataset API および Scala API は非推奨となりました。
具体的なユースケース #
- Java 17 の最新機能を使用して、複雑なイベント処理やリアルタイム分析アプリケーションを構築する。
- 大規模なステート管理が必要なワークロードにおいて、RocksDB 8.10.0 による I/O パフォーマンス向上の恩恵を受ける。
Amazon RDS for Oracle が AWS Outposts で利用可能に #
投稿日: 2026年03月31日
何ができるようになったのか #
Amazon RDS for Oracle が AWS Outposts 上で利用可能になりました。これにより、データレジデンシー要件や低遅延が求められるオンプレミス環境において、クラウドと同じフルマネージドな Oracle データベースサービスを実行できます。
何が嬉しいのか #
自動バックアップ、パッチ適用、ポイントインタイムリカバリ、CloudWatch による監視、KMS による暗号化など、RDS の利便性をオンプレミスで享受できます。また、2つの Outposts ラックにまたがるマルチ AZ デプロイメントもサポートしており、オンプレミス環境でも高い可用性と自動フェイルオーバーを実現できます。
これまでとどう変わるのか #
- これまで: オンプレミスで Oracle データベースを運用する場合、ハードウェアの管理からバックアップ、パッチ適用まで自前で行う必要がありました。
- これから: AWS Outposts を導入している環境であれば、クラウドと全く同じ操作感でマネージドな Oracle DB を運用でき、運用負荷を大幅に削減できます。
具体的なユースケース #
- 金融や医療など、データの物理的な場所（データレジデンシー）が規制によって制限されているアプリケーションのデータベース運用。
- オンプレミスの基幹システムと極めて低い遅延で通信する必要がある Oracle データベースの構築。
Amazon SageMaker Data Agent が Unified Studio のクエリエディタで利用可能に #
投稿日: 2026年03月30日
何ができるようになったのか #
Amazon SageMaker Data Agent が、Unified Studio のクエリエディタから利用できるようになりました。これまではノートブック環境のみでしたが、クエリエディタ上でも自然言語による SQL 生成、失敗したクエリのデバッグ、対話形式でのデータ探索が可能です。
何が嬉しいのか #
「2025年の製品カテゴリ別四半期収益成長率を計算して」といった自然言語の問いかけに対し、エージェントがステップバイステップの計画を提示し、Redshift や Athena 向けの正確な SQL を生成します。複雑な結合や集計を自力で書く必要がなくなり、分析ワークフローが大幅に加速します。また、「Fix with AI」機能により、エラーの原因分析と修正案の提示も受けられます。
これまでとどう変わるのか #
- これまで: クエリエディタで SQL を書く際は、スキーマ情報を手動で確認しながら複雑なクエリを記述する必要がありました。Data Agent の対話型体験はノートブックに限定されていました。
- これから: SQL アナリティクスのメイン画面であるクエリエディタで、AI と対話しながら迅速にクエリを構築・修正できるようになります。
具体的なユースケース #
- SQL に詳しくないビジネスアナリストが、自然言語を使って Amazon Redshift から必要なデータを抽出する。
- 複雑なクエリでエラーが発生した際、AI にエラー箇所を特定させ、最適な修正案を適用して迅速に解決する。
Amazon Aurora DSQL が .NET と Rust 向けの新しいコネクタをリリース #
投稿日: 2026年03月31日
何ができるようになったのか #
Amazon Aurora DSQL において、.NET (Npgsql) および Rust (SQLx) 向けの専用コネクタがリリースされました。これらのコネクタは、IAM トークンの生成、SSL 設定、コネクションプーリングを自動的に処理し、開発者が認証ロジックを意識することなくアプリケーションを構築できるようにします。
何が嬉しいのか #
従来のパスワードベースの認証に伴うセキュリティリスクを排除し、常に有効なトークンを使用して安全に接続できます。また、オプティミスティック並行性制御 (OCC) に基づく指数バックオフ付きの再試行ロジックや、カスタム IAM 認証情報プロバイダーのサポートも含まれており、本番レベルのワークロードを容易にスケールさせることができます。
これまでとどう変わるのか #
- これまで: Aurora DSQL への接続には IAM 認証の手順を個別に実装する必要があり、特に .NET や Rust 環境では定型的なコードが多くなりがちでした。
- これから: 専用コネクタを導入するだけで、Npgsql や SQLx といった既存のライブラリと完全な互換性を保ちつつ、セキュアで回復性の高い接続を最小限のコードで実現できます。
具体的なユースケース #
- 高い信頼性とスケーラビリティが求められる Rust ベースのマイクロサービスから Aurora DSQL を利用する。
- エンタープライズ向けの .NET アプリケーションにおいて、パスワード管理を不要にし、IAM 統合によるセキュアなデータベース接続を実装する。
AWS DevOps Agent が一般提供開始（GA） #
投稿日: 2026年03月31日
何ができるようになったのか #
運用の自動化とインシデント防止を支援する「AWS DevOps Agent」が一般提供開始されました。プレビュー版から進化し、Azure やオンプレミス環境の調査、カスタムスキルの追加、高度な分析レポート作成などの機能が強化されています。
何が嬉しいのか #
経験豊富なチームメイトのように、アプリケーションの構成やツール、コードリポジトリ、CI/CD パイプラインを学習し、インシデント発生時に自律的に原因を切り分け、解決へと導きます。平均修復時間 (MTTR) を数時間から数分に短縮するだけでなく、過去のパターンを分析して将来の障害を未然に防ぐための推奨事項も提示します。
これまでとどう変わるのか #
- これまで: インシデント発生時はエンジニアが手動で複数のツール（監視、ログ、コードなど）を横断的に調査し、原因を特定する必要がありました。
- これから: AI エージェントがテレメトリ、コード、デプロイデータを相関させて分析し、迅速な解決案を提示することで、運用の属人化を防ぎ、システムの信頼性を向上させることができます。
具体的なユースケース #
- システム障害発生時に、DevOps Agent に原因調査を依頼し、修正が必要なコード箇所や関連するデプロイメントを即座に特定させる。
- ハイブリッドクラウド環境（AWS + Azure + オンプレ）全体の運用状況を監視し、一元的なインシデント対応とパフォーマンス最適化を行う。
AWS HealthOmics が VPC 接続ワークフローを導入 #
投稿日: 2026年03月30日
何ができるようになったのか #
AWS HealthOmics において、顧客の Virtual Private Cloud (VPC) を経由してネットワーク通信を行う「VPC 接続ワークフロー」が利用可能になりました。これにより、バイオインフォマティクスのパイプラインが、異なるリージョンの AWS リソースやパブリックインターネット上のリソースに直接アクセスできるようになります。
何が嬉しいのか #
データの局所性に縛られることなく、複数のリージョンに分散したデータセットや、外部で公開されているゲノムデータベースを活用した分析を容易に行えます。データを解析用リージョンに事前に移行する手間が省けるため、研究開発のスピードが向上します。また、ワークフローごとに VPC 接続のオン/オフを選択できる柔軟性も備えています。
これまでとどう変わるのか #
- これまで: 分析を実行する前に、すべての依存データやリソースを HealthOmics ワークフローと同じリージョンに配置する必要がありました。
- これから: VPC を適切に構成するだけで、ワークフローコードを変更することなく、リージョンを跨いだリソースアクセスやインターネット経由のデータ取得が可能になります。
具体的なユースケース #
- 米国リージョンにある大規模な公開ゲノムデータセットを参照しながら、日本リージョンで HealthOmics ワークフローを実行する。
- 解析プロセスの中で、インターネット上で公開されている最新のバイオインフォマティクスツールやデータベースにリアルタイムでアクセスする。
AWS Private CA が CloudWatch への利用状況メトリクスの出力を開始 #
投稿日: 2026年03月31日
何ができるようになったのか #
AWS Private Certificate Authority (AWS Private CA) が、証明書発行数やリージョンあたりの CA 作成数などの利用状況メトリクスを Amazon CloudWatch へ出力するようになりました。これにより、サービスクォータに対する現在の使用量を可視化し、監視することができます。
何が嬉しいのか #
CloudWatch アラームを設定することで、クォータ制限によるサービスの中断を未然に防ぐことができます。例えば、証明書発行制限に近づいた際にアラームを通知し、新しい CA への移行を自動化するといった運用が可能になります。特に Amazon EKS や ECS Service Connect など、Private CA を基盤とするサービスを利用している環境において、高可用性の維持に役立ちます。
これまでとどう変わるのか #
- これまで: 各 CA が発行した証明書の累計数や、クォータに対する残容量をリアルタイムで監視する標準的なメトリクスがなく、管理者が手動で確認するか、独自の実装が必要でした。
- これから: 標準の CloudWatch メトリクスとして提供されるため、既存の監視ダッシュボードやアラーム設定に簡単に組み込むことができ、CA のライフサイクル管理が容易になります。
具体的なユースケース #
- 大規模なコンテナ環境（EKS/ECS）において、サービス間通信用の証明書発行数が CA の上限に達する前に検知し、自動で新しい CA をプロビジョニングする。
- 複数のリージョンで展開している CA の総数を監視し、組織全体のポリシーに合わせたリソース管理を行う。
AWS Security Agent のオンデマンドペネトレーションテストが一般提供開始 #
投稿日: 2026年03月31日
何ができるようになったのか #
自律的なセキュリティエージェントが 24 時間 365 日体制でペネトレーションテスト（侵入テスト）を実行する「AWS Security Agent」が一般提供開始されました。AWS だけでなく、Azure、GCP、オンプレミス環境にも対応しており、インフラ全体のセキュリティテストを一元化できます。
何が嬉しいのか #
従来、専門家が手動で行っていたペネトレーションテストを、AI エージェントが自律的に実行します。アプリケーションごとにカスタマイズされた多段階の攻撃シナリオを通じて脆弱性を発見・検証し、詳細なレポート（CVSS スコア、再現手順、修正案を含む）を提供します。手動テストに比べて大幅にコストを抑えつつ、開発スピードに合わせたオンデマンドな実行が可能です。
これまでとどう変わるのか #
- これまで: ペネトレーションテストは定期的なイベントとして行われることが多く、コストやスケジュールの制約から開発のボトルネックになったり、テスト間隔が空いて最新の脅威に対応できなかったりしました。
- これから: 必要な時にいつでも実行できる「オンデマンド機能」となり、持続的にシステムを保護する「フロンティアエージェント」として機能します。
具体的なユースケース #
- 新機能のリリース前に、パブリックインターネットからアクセス可能なエンドポイントに対して、最新の攻撃手法を用いたシミュレーションを自動実行する。
- マルチクラウド環境（AWS + GCP）において、一貫した基準でペネトレーションテストを実施し、セキュリティレベルを統一する。
AWS Security Hub が AWS GovCloud (US) リージョンで利用可能に #
投稿日: 2026年03月30日
何ができるようになったのか #
AWS Security Hub が AWS GovCloud (US-East) および GovCloud (US-West) リージョンで利用可能になりました。これにより、米国の政府機関や規制の厳しい業界の顧客も、統合されたクラウドセキュリティソリューションを使用してセキュリティ体制を管理できるようになります。
何が嬉しいのか #
GuardDuty、Inspector、Security Hub CSPM などからのセキュリティ信号を相関・強化し、環境内のアクティブなリスクを迅速に特定して優先順位付けできます。攻撃パスの可視化機能により、攻撃者が脅威、脆弱性、設定ミスをどのように組み合わせて重要なリソースを侵害する可能性があるかを視覚的に理解でき、効果的な対策を講じることが可能です。
これまでとどう変わるのか #
- これまで: GovCloud リージョンを利用する顧客は、複数のセキュリティサービスの情報を個別に集約・分析する必要がありました。
- これから: Security Hub による一元的なダッシュボード、高度なトレンド分析、自動化されたレスポンスワークフローを GovCloud 環境でも活用でき、チームの生産性が向上します。
具体的なユースケース #
- 政府系ワークロードを運用する環境において、法規制（FedRAMP など）に基づいたセキュリティチェックを自動実行し、コンプライアンス状況を継続的に監視する。
- 複雑なネットワーク構成において、攻撃パスの可視化機能を用いて、重要なデータへの潜在的な侵入経路を特定・遮断する。
AWS サービスのアベイラビリティに関する重要なアップデート（2026年3月） #
投稿日: 2026年03月31日
何ができるようになったのか #
複数の AWS サービスおよび機能について、メンテナンス（新規受付停止）やサンセット（提供終了）のスケジュールが発表されました。これには AWS App Runner や AWS Audit Manager などの主要サービスも含まれており、利用者は移行計画を立てる必要があります。
メンテナンス（新規受付停止：2026年4月30日〜） #
以下のサービスは、新規顧客による利用ができなくなります。既存顧客は引き続き利用・サポートが継続されます。
- AWS App Runner
- AWS Audit Manager
- AWS CloudTrail Lake
- AWS IoT FleetWise
- Amazon ARC (Readiness Check 機能)
- Amazon Comprehend (一部機能)
- Amazon Rekognition (一部機能)
- Amazon SNS (MDP 機能)
- AWS Glue (Ray Jobs 機能)
サンセット（提供終了：日付はリンク先参照） #
以下のサービスは運用およびサポートが完全に終了します。
- Amazon RDS Custom for Oracle
- Amazon WorkMail
- Amazon WorkSpaces Thin Client
- AWS Service Management Connector
何が嬉しいのか（今後の対応） #
AWS はこれらの変更に対する包括的な移行ガイドを用意しており、サポートチームによる支援も提供されます。利用者は最新の製品ページやドキュメントを確認し、代替サービス（例：App Runner から ECS/Fargate への移行など）への移行を計画することが推奨されます。
これまでとどう変わるのか #
- これまで: これらのサービスは新規・既存を問わず自由に利用可能でした。
- これから: メンテナンス対象サービスは新規利用ができなくなり、サンセット対象サービスは指定された期日をもって利用不能となります。
具体的なユースケース #
- App Runner で稼働させている Web アプリケーションを、Amazon ECS on Fargate などの推奨される代替サービスへ移行する計画を開始する。
- WorkMail を利用している組織において、他のメッセージングソリューションへの移行スケジュールを策定する。
Amazon CloudWatch がデータソースに基づいたログのマルチアカウント・リージョン集約をサポート #
投稿日: 2026年03月30日
何ができるようになったのか #
Amazon CloudWatch のログ集約機能において、データソース名やタイプ（VPC Flow Logs、EKS Audit Logs、CloudTrail Logs など）に基づいてログを中央のアカウントにコピーできるようになりました。これまでのロググループ名による指定に加え、より柔軟な集約ルールを定義可能です。
何が嬉しいのか #
中央のセキュリティチームなどは、組織内の個々のロググループ名を把握・管理することなく、「すべての CloudTrail ログ」や「すべての VPC フローログ」といった単位でログを一元的に収集できます。AWS サービスログについては CloudWatch が自動的にデータソースを識別し、アプリケーションログについてはタグに基づいて識別されるため、設定の自動化と管理の簡素化が図れます。
これまでとどう変わるのか #
- これまで: ログを集約するためには、個別のロググループ名を正確に指定するか、命名規則に頼ってルールを作成する必要がありました。
- これから: 「データソースタイプ」という抽象化されたパラメータを使用できるため、新しいリソースが作成されてロググループが増えても、ルールを変更することなく自動的に集約対象に含めることができます。
具体的なユースケース #
- 組織全体のセキュリティ監視のために、全アカウント・全リージョンの CloudTrail ログと VPC Flow Logs を、中央のセキュリティ分析用 AWS アカウントに自動集約する。
- EKS クラスターが増設されるたびに、その監査ログ（Audit Logs）を自動的に中央のログ基盤へ転送する設定を共通化する。
Amazon CloudWatch Logs がルックアップ・クエリコマンドを導入 #
投稿日: 2026年03月31日
何ができるようになったのか #
Amazon CloudWatch Logs Insights において、新しい lookup コマンドがサポートされました。これにより、ログクエリの結果を外部の参照テーブル（CSV ファイル）のデータと結合し、ログ内の値を意味のある情報で補完できるようになります。
何が嬉しいのか #
分散システムでは、ログに GUID や内部 IP アドレスなどの解読しにくい識別子が含まれることがよくあります。lookup コマンドを使えば、クエリ実行時に「顧客 ID を顧客名に変換する」や「内部 IP アドレスを所有チーム名にマッピングする」といったことが可能になります。事前処理パイプラインを構築することなく、ログ分析をより直感的かつ迅速に行えます。なお、参照用 CSV データのアップロードは CloudWatch の設定画面から行え、このデータはクエリの課金対象（スキャン量）にはカウントされません。
これまでとどう変わるのか #
- これまで: ログ内の識別子を意味のある名前に変換するには、アプリケーション側でログ出力時に付与するか、ログ集約後に複雑な加工処理を行う必要がありました。
- これから: ログクエリの中で直接参照テーブルを結合できるため、アドホックな調査においてもコンテキスト豊かな分析が容易になります。
具体的なユースケース #
- エラーログに含まれるサーバー ID を、参照テーブルを用いて「物理的な設置場所」や「管理担当者」の情報と紐付けて表示する。
- ユーザーのアクティビティログに含まれるプラン ID を、プラン名や特典内容に変換してレポートを作成する。
AWS Deadline Cloud がレンダリングファーム向けの新しいフリートスケーリング設定をサポート #
投稿日: 2026年03月31日
何ができるようになったのか #
フルマネージドなレンダリング管理サービス「AWS Deadline Cloud」において、3つの新しいフリートスケーリングオプション（ワーカーのアイドル期間、スタンバイワーカー数、スケールアウトレート）が導入されました。これにより、レンダーファームのキャパシティとパフォーマンスをより柔軟に管理できるようになります。
何が嬉しいのか #
レンダリング速度とコスト効率のバランスを直接コントロールできます。「アイドル期間」の設定により、ジョブ完了後の待機時間を調整して次のジョブへの着手を早めることができます。「スタンバイワーカー」は事前に起動したワーカーを維持し、ジョブ投入後すぐにレンダリングを開始させます。「スケールアウトレート」では、1分間に最大500ワーカーまでフリートを拡張する速度を調整可能です。
これまでとどう変わるのか #
- これまで: スケーリングの挙動は高度に自動化されていましたが、特定のワークフローにおいて「起動時間を短縮したい」や「コストを抑えるためにアイドル時間を最小化したい」といった細かな制御は限定的でした。
- これから: クリエイティブチームのニーズに合わせて、インフラの応答性とコストの最適化を詳細にカスタマイズできるようになります。
具体的なユースケース #
- アーティストの試行錯誤を速めるため、スタンバイワーカーを常時確保し、ジョブを投げた瞬間にレンダリングが始まるようにする。
- 大規模なプロジェクトの締め切り前に、スケールアウトレートを最大に設定して、短時間で数千台規模のレンダーファームを構築する。
AWS Transform custom のコードベース分析機能が一般提供開始 #
投稿日: 2026年03月31日
何ができるようになったのか #
コードの近代化を支援する AWS Transform custom において、包括的な「コードベース分析」機能が一般提供開始されました。深い静的解析を行い、アーキテクチャ、技術的負債、コードメトリクス、移行計画などをカバーする構造化されたドキュメントや図を自動生成します。
何が嬉しいのか #
大規模なアップグレードや近代化（モダナイゼーション）を開始する前に、現状のコードベースを正確に把握できます。100万行を超えるような大規模なアプリケーションや、Python、Java、Node.js、.NET といった多様な言語に対応しており、手動での評価に頼ることなく、実際のコードの状態に基づいた近代化の優先順位付けが可能です。
これまでとどう変わるのか #
- これまで: コードの現状分析はエンジニアによる手動の調査やドキュメント確認が主で、多大な時間と推測が伴いました。
- これから: AWS Transform CLI を使用して自動的に詳細なレポートが生成され、古くなったコンポーネントや寿命を迎えた依存関係を特定し、推奨される AWS 管理の変換（トランスフォーメーション）を提案してくれるようになります。
具体的なユースケース #
- 数年間メンテナンスされてきた大規模なモノリスアプリケーションをマイクロサービス化する前に、依存関係の絡まり具合や技術的負債を可視化する。
- 組織内の多数のリポジトリに対して一括で分析を実行し、モダナイゼーションが必要な優先度の高いプロジェクトを特定する。
AWS Transform custom がコードの近代化を加速させる7つの新しい AWS 管理変換を導入 #
投稿日: 2026年03月31日
何ができるようになったのか #
AWS Transform custom に、さまざまな言語やフレームワークに対応する7つの新しい AWS 管理の変換（トランスフォーメーション）が追加されました。これには Node.js のバージョンアップグレードの一般提供開始や、Angular から React への移行（早期アクセス）などが含まれます。
新しく追加・強化された主な変換 #
- Node.js バージョンアップグレード (GA): 任意のソースバージョンから任意のターゲットバージョンへ、ライブラリも含めた包括的なアップグレード。
- Java パフォーマンス最適化 (Early Access): JFR プロファイリングデータを分析し、CPU/メモリのホットスポットを特定してコードを自動修正。
- Angular から React への移行 (Early Access): Angular アプリケーションを React へ変換。
- Log4j から SLF4J への移行 (Early Access): ログライブラリの依存関係を修正。
- Angular/Vue バージョンアップグレード (Early Access): それぞれ最新バージョンへのアップグレード。
何が嬉しいのか #
手動で行うと非常に手間がかかり、ミスが発生しやすい大規模なフレームワーク移行やバージョンアップを、AWS が検証済みの自動変換機能によって迅速かつ安全に実施できます。これらの変換は実行されるたびに学習を続け、品質が継続的に向上します。
これまでとどう変わるのか #
- これまで: フレームワークの変更（Angular → React）や大規模なバージョンアップは、数ヶ月単位のプロジェクトになりがちでした。
- これから: CLI ツールから変換コマンドを実行することで、機械的に対応可能な部分を自動化し、エンジニアはより高度なロジックの修正に集中できるようになります。
具体的なユースケース #
- 古いバージョンの Node.js で動作している多数のマイクロサービスを一括で最新 LTS バージョンへ引き上げる。
- フロントエンドの技術スタックを Angular から React に統合するための足がかりとして自動変換を利用する。