Category: Advanced (300)

AWS Quick のエージェント、アクションコネクタ、ナレッジベース、フロー、スペースを、開発アカウントから本番アカウントへ昇格させる作業は、これまで手作業でした。本記事では、Amazon Bedrock AgentCore 上で動く冪等で監査可能な MCP サーバー「Quick Resource Migrator」で、権限も含めたアカウント間の昇格を自動化する方法を紹介します。

社内ファイアウォールの内側やオンプレミスにあるデータソースに、パブリックインターネットを通らずに AWS Quick から接続する方法を説明します。AWS PrivateLink による VPC エンドポイント、VPC 接続、IAM Identity Center によるアイデンティティ制御、VPC エンドポイントによるアクセス制限を組み合わせた構成を紹介します。

Amazon Elastic Kubernetes Service (Amazon EKS) 向けに AWS Nitro Sandboxes の提供を開始しました。サンドボックス化されたポッドは AWS Nitro System を基盤とする専用の軽量 VM で実行されるため、ポッドごとにハードウェアベースのセキュリティ境界を設けられます。EKS Auto Mode ではポッド仕様を 1 行変更するだけで有効にでき、分離モードと機密モードを選べます。AI エージェント、マルチテナント SaaS、規制対象のワークロードを安全かつ効率的に実行する方法を、AI コーディングエージェントの実行例とともに紹介します。

Amazon Athena にシステムテーブルが加わり、第一弾として query_executions の提供が始まりました。すべてのワークグループで実行したクエリの記録が Amazon S3 Tables 上の Apache Iceberg テーブルに自動で保存され、Athena から直接クエリできます。本記事では、システムテーブルの概要と始め方に加え、コストの配分、パフォーマンス分析、監査、運用監視、キャパシティ予約の最適化に使えるクエリの例を紹介します。

Amazon Route 53 Resolver DNS Firewall による保護をオンプレミスワークロードへ拡張し、ハイブリッド AWS 環境全体で統一された DNS セキュリティポリシーを実現する方法を紹介します。AWS Direct Connect や AWS Site-to-Site VPN を使ったプライベート接続と、インターネット向け Network Load Balancer を使ったパブリック接続について、DNS クエリのフローを解説します。スケーラビリティ、高可用性、パフォーマンス、セキュリティに関する設計上の考慮事項も取り上げます。さらに、AWS Firewall Manager と AWS Security Hub を使って、マルチアカウント環境で DNS 保護を一元管理する方法も説明します。

Amazon VPC 内の DNS クエリは Amazon Route 53 Resolver を経由する独自の経路をたどるため、セキュリティグループや AWS Network Firewall などの制御をバイパスします。この記事では、従来のブロックリストでは捕捉できない DNS トンネリングやドメイン生成アルゴリズム (DGA) の仕組みに加え、Amazon Route 53 Resolver DNS Firewall Advanced によるリアルタイム検出と信頼度のしきい値の選び方を解説します。さらに、コンソールでのルール作成、AWS CloudFormation テンプレートによる推奨ルールグループのデプロイ、クエリログ記録、AWS Security Hub との統合も紹介します。

VMware Cloud Foundation (VCF) への既存投資がある企業は、アプリケーションの再設計や運用チームの再教育を行うことなく、Oracle データベースを AWS に移行したいと考えています。Amazon Elastic VMware Service (Amazon EVS) 上の Oracle は、既存の VMware 運用ワークフローを維持しながら、サブミリ秒のストレージレイテンシー、スナップショットベースのバックアップ、クロスリージョンディザスタリカバリ (DR)、および独立したストレージスケーリングを活用できます。

この記事では、Amazon FSx for NetApp ONTAP を使用して Amazon EVS 上に完全な Oracle Database 環境を設計する方法を紹介します。使い慣れた VMware 運用ツールを維持しながら、ストレージ、コンピューティング、ネットワーキング、ディザスタリカバリの各レイヤーがどのように連携して高可用性、クロスリージョン DR、サブミリ秒のストレージレイテンシーを実現するかを学びます。

この記事では、NFS データストアストレージとして Amazon FSx for NetApp ONTAP を使用して、Amazon Elastic VMware Service (Amazon EVS) 上に Oracle Database をデプロイするためのステップバイステップの手順を紹介します。ストレージボリュームのプロビジョニング、NFS データストアのマウント、Oracle のインストール、そしてクロスリージョンディザスタリカバリのための SnapMirror レプリケーションの設定を行います。

VMware 上で Oracle データベースを稼働させている企業は、再設計や再教育を行うことなく既存の運用ワークフローを維持できる AWS への移行パスを求めています。関連記事「Amazon EVS と FSx for ONTAP 上で高可用性の Oracle Database を設計する」では、Amazon Elastic Compute Cloud (Amazon EC2) ベアメタルインスタンスの選択、VM のサイジング、vSAN と FSx for ONTAP 間でのストレージの分割、クロスリージョン DR のための SnapMirror レプリケーションの計画など、環境を設計する方法を説明しました。

この記事は、アーキテクチャ編の続きです。Oracle VM のプロビジョニングと FSx for ONTAP ボリュームの作成から、NFS データストアのマウント、Oracle 19c のインストール、SnapMirror と SnapCenter の設定まで、スタック全体をデプロイするためのステップバイステップの手順を紹介します。また、既存のオンプレミス Oracle ワークロードを Amazon EVS に移行するための 4 つの移行パスと、スナップショットバックアップ、ポイントインタイムリカバリ、データベースクローニングを含む Day 2 運用についても説明します。

2026 年 8 月に、Amazon EKS で、Kubernetes のコントロールプレーンのコンポーネント (API サーバー、スケジューラ、コントローラーマネージャー) を EKS API で直接設定できるようになりました。この記事では、設定できる項目を説明し、2 つのウォークスルーで実際に試します。1 つは Pod の配置を最適化する MostAllocated のビンパッキングの有効化、もう 1 つはイベントの保持期間の調整です。

MCP は、 AI エージェントがツールやデータとやり取りするための標準的な方法として急速に普及しました。もともと MCP は、長時間のセッション、永続的な接続、クライアントとサーバーインスタンスの紐付けを前提としたステートフルなプロトコルでした。 2026 年 7 月 28 日の改定では、 MCP がステートレスな HTTP リクエスト/レスポンス型のプロトコルとして再設計されました。これにより、すべての MCP リクエストは自己完結した POST リクエストとなり、ネットワーク上ではほかの REST API 呼び出しと見分けがつかない形になりました。その結果、ほかの HTTP API の前段ですでに利用しているのと同じレイヤー 7 の検査、変換、最適化を、 MCP サーバーのコードを変更することなく CDN や AWS WAF のレイヤーで適用できるようになります。本記事では、Amazon CloudFront または Application Load Balancer (ALB) の背後にデプロイした MCP エンドポイントを、 AWS WAF で保護し、可視化する方法を紹介します。新しい仕様によって簡単に適用できる、次の 9 つのユースケースを順に説明します。