AWS Auroraを安全に運用するために｜アクセス制御・DR設計と広がるAuroraファミリー

Amazon Auroraは高いパフォーマンスと可用性で知られるAWSのデータベースサービスですが、本番環境で長期運用するには、基本機能を知るだけでは不十分です。IAMを使ったアクセス制御、障害・災害対策（DR）の設計、日々のモニタリング体制を整えて初めて、その性能を安全に活かせます。本記事では、企業がAuroraを運用するうえで押さえておきたいセキュリティ・可用性設計と、Aurora DSQLなど広がりつつあるAuroraファミリーの最新動向を整理します。

Auroraへのアクセスを制御する設計

本番データベースであるAuroraは、ネットワークとアクセス権限の両面から、多層的に保護する設計が求められます。

IAMデータベース認証の活用

AuroraのMySQL互換・PostgreSQL互換エンジンでは、通常のユーザー名・パスワードに加えて、IAMデータベース認証を利用できます。この機能を使うと、データベースへの接続時にIAMユーザーやIAMロールに紐づく一時的な認証トークンを利用でき、長期間有効なパスワードをアプリケーション側で管理する必要がなくなります。EC2やLambda、ECSなどのAWSリソースからAuroraへ接続する構成では、IAMロールを使った認証への切り替えを検討する価値があります。

VPC設計とセキュリティグループ

Auroraクラスターは、プライベートサブネット内に配置し、インターネットから直接アクセスできない構成にするのが基本です。アプリケーションサーバーが稼働するサブネットからのみ、必要なポート（MySQL互換は3306番、PostgreSQL互換は5432番）への通信を許可するよう、セキュリティグループを設計します。踏み台サーバーやAWS Systems Manager Session Managerを経由した運用アクセスに限定し、管理用ポートを不用意に外部公開しないことが重要です。

保存データ・通信の暗号化

Auroraでは、AWS Key Management Service（KMS）を使った保存データの暗号化（自動バックアップ・スナップショット・レプリカを含む）と、SSL/TLSによる通信の暗号化が利用できます。特に個人情報や機密情報を扱うシステムでは、暗号化を有効にしたうえで、KMSキーのアクセス権限やローテーションポリシーも含めて設計することが望まれます。

監査ログの取得と操作の可視化

複数の担当者がAuroraを運用する企業では、誰が・いつ・何を行ったかを追跡できる仕組みが欠かせません。

Aurora Activity Streamsによるデータベースアクティビティの監査

Aurora Activity Streamsを有効にすると、データベースへのログイン試行やSQL実行などのアクティビティを、ほぼリアルタイムでAmazon Kinesis Data Streamsへストリーミングできます。これにより、通常のデータベースログでは追いきれない詳細な操作履歴を、SIEM（セキュリティ情報イベント管理）ツールなどと連携させて監査することが可能になります。金融・医療など、コンプライアンス要件が厳しい業種でのAurora活用において、重要な機能の一つです。

AWS CloudTrailによる管理操作の記録

クラスターの作成・削除・スナップショット取得といった管理操作は、AWS CloudTrailで記録されます。データベース内部の操作（Activity Streams）と、AWS基盤側の管理操作（CloudTrail）の両方を組み合わせることで、Auroraに関する操作を包括的に可視化できます。

ディザスタリカバリ（DR）設計の考え方

本番システムでAuroraを利用する場合、単一リージョン内の障害だけでなく、リージョン規模の障害を想定したDR設計も検討課題になります。

マルチAZ構成による高可用性の基本

Auroraは標準構成でも、同一リージョン内の複数のAZにデータを複製し、プライマリインスタンスの障害時には自動フェイルオーバーが行われます。まずはこの基本的な高可用性の仕組みを正しく構成することが、DR設計の土台になります。

Aurora Global Databaseによるマルチリージョン構成

より高いレベルの災害対策が必要な場合は、Aurora Global Databaseを利用し、プライマリリージョンのデータを別リージョンへ低遅延でレプリケーションする構成を検討します。プライマリリージョンで障害が発生した場合、セカンダリリージョンを新たなプライマリへ昇格させることで、事業継続性を確保できます。DR設計を検討する際は、目標復旧時点（RPO）と目標復旧時間（RTO）を業務要件から明確にしたうえで、標準のマルチAZ構成で十分か、Global Databaseまで必要かを判断することが基本的な進め方です。

運用監視と接続管理の実践

安定運用のためには、性能の可視化と、アプリケーション側の接続管理の工夫も重要です。

Performance Insightsによる性能の可視化

Amazon RDS Performance Insightsを使うと、データベースの負荷状況や、負荷の原因となっているSQLクエリを直感的に可視化できます。性能劣化の予兆を早期に把握し、インスタンスタイプの見直しやクエリチューニングにつなげる運用が有効です。

Amazon RDS Proxyによる接続管理

Lambdaなどサーバーレスの構成でAuroraに接続する場合、大量の同時接続がデータベースの接続上限を圧迫することがあります。Amazon RDS Proxyを間に挟むことで、コネクションプーリングが行われ、接続の急増によるデータベースへの負荷を緩和できます。あわせて、IAM認証やSecrets Managerとの連携による認証情報管理の簡素化も図れます。

広がるAuroraファミリーの最新動向

Auroraは、従来のクラスター構成に加えて、より大規模・分散的なワークロードに対応する新しい選択肢を拡充しています。

Aurora Limitless Database

Aurora Limitless Databaseは、単一のAuroraクラスターでは難しかった書き込み性能のスケールアウトを実現する構成です。データを複数のシャードに自動的に分散させながら、アプリケーションからは単一のデータベースとして扱える点が特徴で、大規模なマルチテナントSaaSなど、書き込み負荷が非常に高いワークロード向けの選択肢として提供されています。なお、1台のインスタンスで賄えるワークロードであれば、従来のAuroraクラスターで十分対応できるため、まずは標準構成での対応可否を検討したうえでの採用が基本的な考え方です。

Aurora DSQL

Aurora DSQLは、実質的に無制限のスケーラビリティを持つ、サーバーレスの分散SQLデータベースです。3つのAZにまたがるActive-Active構成を単一リージョンで提供するほか、マルチリージョン構成では、各リージョンのエンドポイントから単一の論理データベースとして強い一貫性を持つ読み書きが可能です。日本国内では東京・大阪の2リージョンで一般提供されていますが、現時点でマルチリージョンクラスターに対応しているのはバージニア北部・オハイオ・オレゴンといった北米リージョンのみです。日本やヨーロッパのリージョンでは、シングルリージョンクラスターのみの提供にとどまっており、東京・大阪間で国内完結のマルチリージョン構成を組むことはできない点に注意が必要です。国内でのデータ保存要件がある場合は、まず東京または大阪のいずれかでシングルリージョン構成として利用し、マルチリージョン化が必要な場合は対応リージョンの制約を踏まえた設計を検討してください。楽観的同時実行制御を採用している点が、従来のAuroraクラスターとは異なる設計上の特徴で、コミット時に競合が発生した場合はアプリケーション側でリトライ処理を行う設計が必要になります。

これらの新しい選択肢は、従来のAurora（プロビジョンド構成）が抱えていた「単一プライマリインスタンスの書き込み性能が上限になる」という制約に対する解として位置づけられており、既存システムのリプレイスというよりも、新規の大規模システムやグローバル展開を見据えたシステムでの採用が検討されています。

よくある質問（FAQ）

AuroraへのアクセスをIAMで制御することはできますか？

はい。IAMデータベース認証を有効にすることで、IAMユーザーやIAMロールに紐づく一時的な認証トークンを使ってAuroraへ接続できます。長期間有効なパスワードを管理する必要がなくなり、セキュリティ向上につながります。

Auroraのデータベース操作を監査ログとして残すことはできますか？

Aurora Activity Streamsを有効にすることで、ログイン試行やSQL実行などのデータベースアクティビティを、ほぼリアルタイムでKinesis Data Streamsに送信できます。管理操作についてはAWS CloudTrailで記録されるため、両方を組み合わせて監査に活用します。

リージョン規模の障害に備えるにはどうすればよいですか？

Aurora Global Databaseを使い、プライマリリージョンのデータを別リージョンへレプリケーションする構成が代表的な対策です。業務要件から目標復旧時点（RPO）と目標復旧時間（RTO）を明確にしたうえで、標準のマルチAZ構成で十分か、Global Databaseが必要かを判断します。

Aurora Limitless DatabaseとAurora DSQLはどう違いますか？

Aurora Limitless Databaseは、既存のAuroraクラスターの延長線上で、データを自動的にシャーディングして書き込み性能をスケールアウトする構成です。一方Aurora DSQLは、完全にサーバーレスな分散SQLデータベースで、単一リージョンではActive-Active構成、対応リージョン間ではマルチリージョンでの強い一貫性を、単一の論理データベースとして提供する点が異なります。ただし、マルチリージョン構成が使えるのは現時点で北米の一部リージョンに限られます。

サーバーレスの構成でAuroraに大量接続する場合、何に気をつければよいですか？

Lambdaなどからの大量の同時接続は、データベースの接続上限を圧迫する可能性があります。Amazon RDS Proxyを利用してコネクションプーリングを行うことで、接続急増時の負荷を緩和し、あわせてSecrets Managerと連携した認証情報管理も簡素化できます。

まとめ

Amazon Auroraは高性能・高可用性なデータベースですが、その性能を安全に活かすには、アクセス制御・監査ログ・DR設計・運用監視という4つの観点での設計が欠かせません。

まずは自社のAurora環境について、IAM認証の有効化状況とバックアップ・DR設計を棚卸しするところから始めてみてください。