👀概要
パーソルホールディングス エンジニアリング部 Technical Alliance室の三好です。
今回は、Azure Database for PostgreSQL Flexible Server（以下、Azure Flexible Serverと略す）についてAWS経験者向けに3分で解説します。
AWSのAurora Serverless v2に近い位置づけのマネージドなPostgreSQLサービスです。
👨👩👧👦対象者(Who)
- Azureを初めて触る方（特にAWS経験者）
- インフラエンジニア、クラウドエンジニア
📌関連リンク
- Azure Database for PostgreSQL フレキシブル サーバーとは
- Azure Database for PostgreSQL - フレキシブル サーバーのネットワーク
- Azure Database for PostgreSQL フレキシブル サーバーのコンピューティング オプション
- Azure Database for PostgreSQL フレキシブル サーバーのストレージ
🗒️ 目次
- AWSとAzureのネットワーク思想の違い
- パブリックアクセス・プライベートアクセス
- サブネットの委任 （Delegation）
- プライベート DNS ゾーン統合
- 高可用性（HA）
- 運用・ストレージの運用差分
📝 内容
Azure Database for PostgreSQL Flexible Serverとは
Azure Database for PostgreSQL Flexible Serverとは オープンソースのデータベース PostgreSQLを構築できる
フルマネージドの Azureのサービスです。
フルマネージドであるためバックアップ、パッチ適用、可用性の管理などが自動化されており、インフラ維持の手間を大幅に軽減できます。
Azureでは マイクロソフト商用のデータベースであるSQL Serverを構築することも可能ですが
オープンソースで比較的気軽に利用できる PostgreSQLも構築することが可能です。
データベースの使用感もセルフホストのPostgreSQLと大差なく、以降の解説はAzureに特化したものをピックアップしました。
AWSとAzureのネットワーク思想の違い
パブリックアクセス・プライベートアクセス
AWS経験者がAzureのネットワークで一番最初につまずくのは、「VPCの中にDBを置く感覚」のズレです。
AWSは「最初からVPCのサブネット内に配置する」という感覚が一般的ですが、Azure Database for PostgreSQL Flexible Serverでは、
パブリックアクセスとプライベートアクセス（VNet 統合）という2つのネットワーク方式から選択します。
そのため、AzureではVNetと接続する際に以下の考え方の違いが登場します。
| 分類 | Azureの接続方式 | AWSでの感覚的イメージ | 主な挙動 |
|---|---|---|---|
| パブリック | 許可されたIPアドレス | パブリック公開したDynamoDB/S3等のIP制限に近い | VNetの外に配置。パブリックIPを持ち、ファイアウォールで許可したIPのみ通信を許可する（検証向け）。 |
| パブリック | プライベート エンドポイント | VPC Endpointに近い | Private Endpoint経由でVNetから接続 |
| プライベート | VNet 統合 | Private Subnetに直接配置 | DBをVNet内の専用サブネットに配置 |
Azure Flexible Serverでは作成時にネットワーク接続方式を選択しますが、AWSでいう「Private SubnetにDBを置く標準構成」を作りたい場合は、「プライベート アクセス （VNet 統合）」を選択することになります。
サブネットの委任 （Delegation）
VNet 統合を選択してDBを作成する際、配置先のサブネットを指定します。ここでAWSにはないAzure特有のルールが登場します。それが 「サブネットの委任（Delegation）」 です。
- DBを配置するサブネットは「Flexible Server」専用に委任されるため、他のリソース（App ServiceやVMなど）と同居させることができません。
- そのサブネットには他のAzureリソースを配置できないため、必要なサーバー数やHA構成を考慮してCIDRサイズを決める必要があります。なお、最小サイズは/28で、利用可能なIPアドレスは11個です。
プライベート DNS ゾーン統合
VNet 統合時は、セットで「プライベート DNS ゾーン」の設定が求められます。
- 役割: 単なる名前解決だけでなく、フェイルオーバー時に Azure 基盤が A レコードを動的に書き換えて接続先を切り替えるために使われます。
- 注意点: AWS（Route 53）のように裏で隠蔽されず、VNet 内のリソースとして管理されます。
手動管理にしようとスキップすると障害時に自動追従しなくなるため、Private DNS zoneを適切に構成し、AzureによるDNSレコード更新を妨げないようにする必要があります。
高可用性（HA）
ゾーンの回復性
構成定義で「ゾーンの回復性」を有効（ZoneRedundant）にすると、別AZに予備のスタンバイ機が配置されるマルチAZ構成になります。障害発生時は自動でフェイルオーバーが行われますが、運用上の挙動に注意が必要です。
- スタンバイ機は待機専用
- 配置されたスタンバイ機は、同期処理を行う完全な待機機です。直接の接続権限はなく、参照クエリを投げることはできません。
- リードレプリカは別機能
- 参照負荷を分散したい場合は、この高可用性設定とは別に「リードレプリカ」を追加作成する必要があります。
運用・ストレージの差分
Aurora Serverless v2経験者が一番戸惑うのが、「何が自動でスケールし、何がスケールしないのか」という運用の前提条件です。
「スペック（CPU/メモリ）」と「ストレージ（容量）」の分離
Aurora Serverless v2のように「負荷に応じて CPU/メモリ（ACU）が自動でリアルタイムに伸縮する」仕組みは、Azure Flexible Serverには存在しません。
-
CPU / メモリ（Compute）
- Azure の挙動: 選択したSKU/vCore数で運用します。負荷が高くなっても自動でスペックは増えないため、スケールアップには設定変更が必要です。
-
ストレージ容量（Storage Auto-grow）
- Azure の挙動: Storage Auto-growを有効にすると、空き容量が一定の閾値を下回った際にストレージ容量を自動的に拡張できます。ただし、自動的に拡張されるのはストレージ容量のみで、CPU / メモリは自動では増加しません。
- 一度増えたストレージは縮小不可: ストレージ容量が自動拡張された場合、後からデータを削除してもストレージ容量を小さく戻す（スケールダウンする）ことはできません。不要なコスト増加を防ぐため、ストレージ使用量を監視することをおすすめします。
オートスケールと運用の整理
| 比較項目 | AWS Aurora Serverless v2 | Azure Flexible Server |
|---|---|---|
| CPU/メモリの伸縮 | ACU 指定で自動で伸び縮みする | 指定したサイズで運用（自動伸縮なし） |
| ストレージの自動拡張 | 自動拡張（データ量に応じて変動） | 自動拡張（Storage Auto-grow）あり |
| ストレージの縮小 | テーブル等の削除・再編成により条件に応じて縮小 | 自動では縮小しない |
まとめ
Aurora Serverless v2とAzure PostgreSQL Flexible Serverでは、同じマネージドDBでも設計や運用の考え方に違いがあります。
その違いを前提として、Azureの特性に合わせた設計・運用を行うことが、安定したサービス運用と予期せぬトラブルの防止につながります。
移行や設計の際、少しでも参考になれば幸いです。