2026年5月14日 AWS アップデート情報

はじめに

2026年5月14日、AWSから3件のアップデートが発表されました。本日の注目ポイントは、Amazon RDS for Oracle への新世代インスタンスタイプの追加、Amazon FSx for OpenZFS の共有VPC環境での可用性向上、そして AWS Security Agent による AI を活用した全リポジトリコードレビュー機能のプレビュー提供開始 です。いずれもエンタープライズ環境での運用柔軟性とセキュリティ強化に寄与するアップデートとなっています。

注目アップデート深掘り

Amazon RDS for Oracle：M8i / R8i インスタンスとライセンス込みオプション

なぜこのアップデートが重要なのか

Oracle データベースのクラウド移行において、ライセンスコストの予測可能性とインフラのパフォーマンスは常に重要な検討事項です。今回、Amazon RDS for Oracle が新たにサポートした M8i および R8i インスタンスは、AWS 専用のカスタム Intel Xeon 6 プロセッサを搭載し、従来世代と比べて最大 15% 優れた価格性能比を実現します。さらにメモリ帯域幅は従来の 2.5 倍に向上しており、メモリ集約的なワークロード（アナリティクスやレポーティング）において大きな効果が期待できます。

特に注目すべきは、Oracle Database Standard Edition 2（SE2）の License Included（ライセンス込み） オプションが提供されている点です。これにより、従来の Oracle ライセンスの購入・保守契約を別途行う必要がなく、月額定額制でコンピュート、ストレージ、マネージドサービスをすべて利用できます。ライセンス管理の複雑さが排除されるため、クラウド移行のハードルが大幅に下がります。

インスタンスタイプとライセンスモデルの比較

M8i はメモリ最適化型、R8i はさらにメモリ比率の高いメモリ集約型インスタンスです。従来世代（M7i / R7i）と比較して、以下のような改善が見られます。

ライセンスモデルについては、以下の 2 つが選択可能です。

• License Included（LI）: ライセンスと保守が RDS 料金に含まれる。Oracle と直接契約する必要がなく、月額料金ですべてカバー。
• Bring Your Own License（BYOL）: 既存の Oracle ライセンスを持ち込む。ライセンスコストは別途発生するが、既存資産を活用可能。

License Included オプションは、ライセンス管理の手間を削減し、予測可能なコスト構造を実現するため、新規のクラウド移行プロジェクトや、ライセンス管理リソースが限られている組織に適しています。

実際の構築手順

AWS CLI を使用して M8i インスタンスで RDS for Oracle SE2（License Included）を作成する例を示します。

$ aws rds create-db-instance \
  --db-instance-identifier my-oracle-se2-m8i \
  --db-instance-class db.m8i.xlarge \
  --engine oracle-se2 \
  --license-model license-included \
  --master-username admin \
  --master-user-password MySecurePassword123! \
  --allocated-storage 100 \
  --storage-type gp3 \
  --backup-retention-period 7 \
  --preferred-backup-window 03:00-04:00 \
  --preferred-maintenance-window sun:04:00-sun:05:00 \
  --engine-version 19.0.0.0.ru-2024-01.rur-2024-01.r1 \
  --vpc-security-group-ids sg-0123456789abcdef0 \
  --db-subnet-group-name my-db-subnet-group

AWS Management Console からも同様に、インスタンスクラスで db.m8i.xlarge や db.r8i.2xlarge などを選択し、ライセンスモデルで license-included を指定することで簡単に構成できます。

Note: M8i / R8i インスタンスは特定のリージョンから順次展開されるため、利用可能リージョンを事前に確認してください。

メモリ帯域幅の向上がもたらす効果

メモリ帯域幅が 2.5 倍に向上したことにより、大量のデータをメモリ上で処理するワークロード（例：大規模な JOIN クエリ、集計処理、インメモリ分析）でのパフォーマンス改善が期待できます。特に Oracle のインメモリ機能（Database In-Memory）を活用している場合、この帯域幅向上は顕著な効果をもたらす可能性があります。

既存の M7i / R7i インスタンスから M8i / R8i への移行は、スナップショットを用いたインスタンスタイプ変更により実施可能です。本番環境での移行前に、開発環境やステージング環境でベンチマークを実施し、実際のワークロードにおけるパフォーマンス向上を測定することを推奨します。

Amazon FSx for OpenZFS：共有 VPC でのマルチ AZ ファイルシステム作成

共有 VPC でのマルチ AZ 制約の解消

AWS Organizations を活用した大規模組織では、ネットワーク管理を集中化するために共有 VPC（VPC Sharing）構成が広く採用されています。中央のネットワーク管理アカウントが VPC とサブネットを所有し、組織内の参加アカウント（Participant Account）にサブネットを共有することで、ネットワーク設計とセキュリティポリシーを統一管理できる構成です。

しかし従来、Amazon FSx for OpenZFS では、共有 VPC の参加アカウントから マルチ AZ ファイルシステム を作成することができませんでした。シングル AZ 構成は可能だったため、高可用性が必要なワークロードを参加アカウントで運用する場合、参加アカウント側で別途 VPC を用意してマルチ AZ ファイルシステムを構築する必要がありました。これはネットワーク管理の一元化を妨げ、運用上のオーバーヘッドとなっていました。

今回のアップデートにより、参加アカウントから共有 VPC 内に直接マルチ AZ の FSx for OpenZFS ファイルシステムを作成できるようになりました。中央管理されたサブネット上に高可用性ストレージを構築できるため、ネットワーク設計の一貫性を保ちながら、アカウント間で柔軟にワークロードを配置できます。

共有 VPC 環境でのアーキテクチャ整理

設定上の留意点

参加アカウントで共有 VPC 内にマルチ AZ ファイルシステムを作成する際には、以下を事前に整理しておくと運用が安定します。

• サブネット選定: VPC 所有アカウント側で、2 つの AZ にまたがる共有サブネットが用意されていること。FSx for OpenZFS のマルチ AZ では、プライマリ AZ と スタンバイ AZ の 2 サブネットを指定します。
• セキュリティグループ: 参加アカウントが作成・管理できるセキュリティグループで NFS（TCP/2049）アクセスを制御。VPC 所有アカウントとのルール責任分担を明確にしておく。
• IAM 権限: 参加アカウントが fsx:CreateFileSystem などのアクションを共有サブネット上で実行できるよう、適切な IAM ポリシーと SCP を設定。
• タグとコスト配賦: 参加アカウント側で課金される構成のため、コスト配賦タグを統一しておくと FinOps 観点で扱いやすくなります。

これにより、ハブ＆スポーク型の AWS マルチアカウントアーキテクチャにおいて、共有ネットワークを維持したまま参加アカウントごとに独立した高可用性ファイルシステムを展開できます。

AWS Security Agent：全リポジトリコードレビュー機能のプレビュー

AI 駆動のシステム的脆弱性検出

従来の静的解析ツールは、パターンマッチングに基づいて既知の脆弱性パターンを検出する手法が主流でした。しかし、マイクロサービスアーキテクチャやクラウドネイティブアプリケーションが普及する中で、単一ファイル内の脆弱性だけでなく、システム全体のアーキテクチャ、信頼境界、データフロー を考慮した脆弱性検出が求められています。

AWS Security Agent の新しい 全リポジトリコードレビュー 機能は、AI を活用してアプリケーション全体を解析し、従来のツールでは見落とされていた システム的な脆弱性 を検出します。たとえば、マイクロサービス A からマイクロサービス B へのデータフローにおいて、信頼境界を越える際の検証漏れや、複数コンポーネント間での権限チェックの不整合などが検出対象となります。

さらに、脆弱性が検出された場合には、具体的なファイル名と行番号が特定され、コード修復提案が自動生成されます。これにより、セキュリティ修復のスピードが大幅に向上します。

従来の静的解析ツールとの違い

実際の利用手順

AWS Security Agent はプレビュー期間中、既存ユーザーに対して追加料金なしで利用可能です。コンソールから全リポジトリコードレビュー機能を有効化し、対象リポジトリを指定することでスキャンを開始できます。

# AWS CLI での全リポジトリスキャンの例（※コマンド構文は実際のドキュメントに従ってください）
$ aws security-agent start-full-repository-scan \
  --repository-arn arn:aws:codecommit:us-east-1:123456789012:my-repo \
  --scan-type full-architecture

スキャン完了後、コンソール上で検出された脆弱性の一覧と、各脆弱性に対する修復提案が表示されます。修復提案には、具体的なコード例や、どのファイルのどの行を修正すべきかが含まれます。

DevSecOps パイプラインへの統合

この機能は、CI/CD パイプラインに組み込むことで、プルリクエスト段階での自動セキュリティチェックを実現できます。大規模なマイクロサービス環境やマルチテナント環境での開発では、複数チームが異なるコンポーネントを開発するため、システム全体の信頼境界を意識したセキュリティ検証が不可欠です。

全リポジトリコードレビュー機能を活用することで、設計レベルの脆弱性を早期に発見し、修復工数を最小化できます。特に金融や医療など、コンプライアンス要件が厳しい業界では、セキュリティ監査前に包括的なコードベーススキャンを実施することで、監査対応の負荷を軽減できます。

SRE 視点での活用ポイント

RDS for Oracle M8i / R8i の運用改善シーン

SRE の観点では、パフォーマンスとコストのバランスを取りながら、安定したデータベース運用を実現することが求められます。M8i / R8i インスタンスは、従来世代と比較して価格性能比が 15% 向上し、メモリ帯域幅が 2.5 倍になったことで、同じコストでより高いパフォーマンスを得られる可能性があります。

特に、License Included オプションを採用することで、ライセンス管理の運用負荷が削減されます。Oracle ライセンスの監査対応やライセンス数の最適化に費やす時間を、システムのパフォーマンス最適化や障害対応の改善に振り向けることができます。Terraform などのインフラコード管理ツールを使用している場合、インスタンスタイプの変更は以下のようにシンプルに記述できます。

resource "aws_db_instance" "oracle_se2" {
  identifier           = "my-oracle-se2-m8i"
  instance_class       = "db.m8i.xlarge"
  engine               = "oracle-se2"
  license_model        = "license-included"
  allocated_storage    = 100
  storage_type         = "gp3"
  username             = "admin"
  password             = var.db_password
  # その他の設定...
}

既存の RDS インスタンスからの移行は、メンテナンスウィンドウ中にスナップショットベースでのインスタンスタイプ変更により実施可能です。移行前に CloudWatch メトリクスを活用し、CPU 使用率、メモリ使用率、IOPS などの現在のリソース使用状況を把握しておくことで、適切なインスタンスサイズを選定できます。

FSx for OpenZFS の共有 VPC 対応と高可用性設計

大規模な AWS 組織では、複数のアカウントを用いてワークロードを分離しつつ、ネットワークは集中管理する共有 VPC 構成が一般的です。従来、FSx for OpenZFS では共有 VPC の参加アカウントでマルチ AZ ファイルシステムを作成できなかったため、高可用性が必要なワークロードでは自身が所有する VPC を別途用意する必要がありました。

今回のアップデートにより、参加アカウントでも共有 VPC 内にマルチ AZ の FSx for OpenZFS を直接作成できるようになり、ネットワーク管理の一元化と高可用性ファイルシステムの柔軟な展開が両立できます。

SRE の立場では、災害復旧（DR）構成の設計や、障害時の自動フェイルオーバー設定において、マルチ AZ 構成は重要な要素です。CloudWatch アラームと組み合わせて、ファイルシステムの可用性やレイテンシを監視し、異常時には自動通知やランブック（障害対応手順書）の起動を実施する運用が考えられます。

また、Terraform や CloudFormation でインフラをコード管理している場合、共有 VPC 内でのマルチ AZ FSx リソース定義が可能になったことで、複数環境（開発・ステージング・本番）の一貫した管理がより容易になります。セキュリティグループや IAM ポリシーによるアクセス制御を適切に設定し、参加アカウント間での責任範囲を明確にすることで、安全かつ効率的な運用を実現できます。

AWS Security Agent のセキュリティ運用への組み込み

セキュリティ脆弱性の早期発見と迅速な修復は、SRE が担うシステムの信頼性向上において不可欠です。AWS Security Agent の全リポジトリコードレビュー機能は、従来のパターンマッチング型ツールでは見落とされがちなシステム全体の設計上の脆弱性を AI で検出します。

CI/CD パイプラインにこの機能を組み込むことで、プルリクエスト段階で脆弱性を自動検出し、コードレビュー時にセキュリティチェックを含めることができます。特に複数チームが異なるマイクロサービスを開発している環境では、信頼境界を跨いだデータフローの検証が重要です。

プレビュー期間中は追加料金なしで利用できるため、既存の静的解析ツールと並行して導入し、検出結果の精度や誤検知率を評価するのが現実的な導入アプローチです。検出された脆弱性に対しては、具体的なコード修復提案が提示されるため、開発チームへのフィードバックが迅速化され、修復サイクルの短縮が期待できます。

ただし、AI 駆動の解析であっても完全ではないため、人間によるレビューとの組み合わせが重要です。脆弱性の優先順位付けや、ビジネス影響の評価は SRE やセキュリティチームの判断が必要です。

全アップデート一覧

まとめ

2026年5月14日のアップデートは、パフォーマンスとコスト最適化、運用柔軟性の向上、セキュリティの強化 という 3 つのテーマで構成されています。

RDS for Oracle の M8i / R8i インスタンスは、エンタープライズデータベースのクラウド移行を加速するとともに、ライセンス管理の複雑さを排除する License Included オプションにより、予測可能なコスト構造を提供します。FSx for OpenZFS の共有 VPC 対応は、大規模組織でのネットワーク集中管理と高可用性ストレージの両立を可能にし、運用効率を大きく向上させます。

AWS Security Agent の全リポジトリコードレビュー機能は、AI を活用したシステム全体の脆弱性検出により、DevSecOps の自動化と迅速な脆弱性修復を実現します。プレビュー期間中の無料提供は、既存ツールとの比較評価を行う絶好の機会です。

いずれのアップデートも、エンタープライズ環境でのクラウド活用を加速し、SRE や開発チームの運用負荷を軽減する重要な機能強化と言えます。

📚 AWSをもっと深く学ぶなら

AWS認定ソリューションアーキテクト - アソシエイト 完全攻略（楽天ブックス）

• AWS公式ドキュメント