AWS Database本番運用Vol6｜Blue/Green・延長サポート・IO最適化

1. この記事について

1-1. 本記事のゴール

本記事は「AWS Database 本番運用」シリーズのVol6として、すでに本番稼働しているRDS/Auroraクラスターを対象に、「止めずに更新する」「サポート終了後も延命する」「追加費用なしで速くする」という3つの運用課題を解決します。Vol1〜5が新規構築や用途別のDB選定を主題としてきたのに対し、本Vol6は既存クラスターの運用高度化に主眼を置く点が最大の違いです。

第一の柱であるBlue/Green Deploymentsは、本番(Blue)環境の完全なコピーとしてステージング(Green)環境を作成し、そこでメジャーバージョンアップやパラメータ変更を検証したうえで、数十秒〜1分未満のスイッチオーバーで本番反映する仕組みです。RDS for MySQL/MariaDB/PostgreSQLとAurora MySQL/PostgreSQLの双方に対応しており、2025年11月にはAurora Global Databaseを含む構成への対応拡大も発表されています。本記事ではTerraformのaws_db_instanceリソースが提供するblue_green_updateブロックを軸に、実際にどこまで自動化できるか、どこから手動オペレーションが必要になるかを明確にします。

第二の柱であるRDS Extended Supportは、エンジンの標準サポート終了後も追加課金で最大3年間パッチ提供を継続する仕組みです。標準サポート終了直後の1〜2年目と3年目とで単価が変わる段階課金であり、何も設定しなければ自動的にExtended Supportへエンロールされる点が運用上の落とし穴になります。本記事では、課金構造を理解したうえで「延命する」か「先にアップグレードする」かを判断するための試算方法を扱います。

第三の柱であるOptimized Reads/Writesは、RDS for MySQL/MariaDBにおいて、NVMeベースのインスタンスストアを搭載した対応インスタンスクラス(r5d/m5d/r6gd/m6gd等)を選ぶだけで有効になる性能機能です。Optimized Readsは一時オブジェクトの配置をEBSからローカルNVMeへ移すことでソートやハッシュ集計を高速化し、Optimized Writesはdoublewriteバッファの回避によって書込スループットを最大2倍に高めます。いずれも追加のライセンス費用は発生せず、インスタンスクラスとエンジンバージョンの条件を満たすだけで享受できる点が特徴です。

本記事を読み終えた時点で、Blue/Greenによる無停止更新の設計・Extended Supportのコスト試算に基づく延命判断・Optimized Reads/Writesの有効化条件の把握という3つの実務スキルを、Terraformコードとともに習得できる状態に到達します。コード例はすべてTerraform 1.9.x / hashicorp/aws provider ~> 5.0を前提とし、AWS CLIv2でも同等の操作を併記します。

なお、本記事のコード例はすべて教育目的のサンプルです。プロダクション環境で適用する際は、VPCエンドポイント・セキュリティグループ・KMS暗号化・スイッチオーバー時のアプリケーション接続設定・監視体制の整備を必ず検討してください。各機能の公式ドキュメントとAWS Well-Architected Frameworkのデータベース関連レンズも合わせて参照することを推奨します。

3つの機能の比較

Blue/Green Deployments・RDS Extended Support・Optimized Reads/Writesは、いずれも「既存クラスターを止めずに扱う」という共通点を持ちますが、目的も適用対象も異なります。全体像を以下の表に整理します。

この比較からもわかる通り、Blue/GreenとExtended Supportは「更新・延命」という時間軸の課題に、Optimized Reads/Writesは「性能」という別の軸の課題にそれぞれ対応します。3機能を組み合わせることで、既存クラスターをそのまま「止めずに・長く・速く」運用する土台が整います。

対象外とする範囲

本記事は既存のRDS/Auroraクラスターの運用高度化に焦点を絞るため、以下は対象外とします。

• Aurora Serverless v2固有のスケーリング設計(Vol1で扱い済みのため本記事では踏み込みません)
• RDS Customを使ったOS/エンジンレベルのカスタマイズ(本記事はマネージド標準機能の範囲に限定します)
• Amazon RDS on VMware等のオンプレミス系オプション

本記事の構成は、§3でBlue/Green、§4でExtended Support、§5でOptimized Reads/Writesをそれぞれ独立して扱い、§6で3機能に共通する詰まりポイントとアンチパターンを整理し、§7でシリーズ全体のクロスリンクとともにまとめます。

1-2. 読者像

本記事の対象読者は、すでにRDS/Auroraを本番運用しており、エンジンのEOL対応・無停止でのバージョンアップ・性能改善のいずれかに直面している運用担当者・SRE・データベース管理者です。

たとえば、MySQL 5.7やPostgreSQLの旧バージョンを本番運用しておりメジャーアップグレードのダウンタイムに悩んでいる方、標準サポート終了が近づきExtended Supportの課金額を試算したい方、既存のRDS for MySQL/MariaDBインスタンスをコード変更なしで高速化したい方が該当します。

AWSアカウントの基本操作とTerraformでのAWSリソース管理経験があれば、本記事の内容を実践できます。Vol1(RDS/Aurora/DynamoDB基礎編)の知識があるとより理解が深まりますが、既存のRDS/Auroraクラスターを運用した経験があれば必須ではありません。

本記事が特に役立つ場面は、次に予定しているメジャーバージョンアップのダウンタイムをできるだけ短くしたい場面、Extended Supportの自動エンロールに気づかずコストが想定外に増加していないか確認したい場面、そしてRDS for MySQL/MariaDBのインスタンスタイプ変更だけで性能改善できないか検討している場面です。

本記事の前提条件は、AWSアカウントが取得済みであり、対象となるRDS/Auroraクラスターがすでに稼働していることです。Terraformでリソースをインポート済み、またはこれからTerraform管理下に置く想定でコード例を提示します。VPC・サブネットグループ・セキュリティグループは既存の本番環境のものをそのまま利用し、本記事では新規作成しません。

各§はそれぞれ独立して読めるように構成しています。Blue/Green(§3)・Extended Support(§4)・Optimized Reads/Writes(§5)のうち、直面している課題に対応する§から優先して読み進めても問題ありません。最後の§6-§7は詰まりポイントとシリーズ全体のクロスリンクをまとめています。

典型的には、EOL通知メールを受け取ってExtended Supportの課金試算を急いでいる場面、次期メジャーアップグレードのダウンタイム見積もりを求められている場面、あるいはコスト削減の一環でOptimized Reads/Writesの適用可否を調査している場面など、きっかけは様々です。本記事はどの入口からでも該当する§へ直接アクセスできる構成です。

本記事で使用する検証環境

本記事のコード例は、RDS for MySQL 8.0系のシングルインスタンスと、Aurora PostgreSQLクラスターの2つを検証環境として想定しています。Blue/Green Deployments(§3)とOptimized Reads/Writes(§5)はRDS for MySQL側で、Extended Support(§4)の課金試算はエンジン共通の考え方として解説します。

既存の本番クラスターに対してBlue/Green環境を作成する際は、Blue環境と同等のインスタンスクラス・ストレージ容量を持つGreen環境が一時的に追加課金されます。検証は本番相当のクラスターではなく、同一構成の非本番環境で行うことを推奨します。

1-3. なぜ今これを書くか

本記事を執筆する動機は、3つの機能それぞれの公式情報は充実している一方、既存のRDS/Auroraクラスターを「無停止で更新し」「延命判断を行い」「追加費用なしで高速化する」という運用者視点で3機能を横断的にTerraformで扱う記事が見当たらなかったことです。

Blue/Green Deploymentsは2025年11月にAurora Global Databaseを含む構成への対応が拡大されましたが、Terraformのblue_green_updateパラメータはaws_db_instanceリソースにのみ提供され、Auroraクラスターを表すaws_rds_clusterリソースには提供されません。この制約はHashiCorp公式のデザインドキュメントで明記されているものの、単体の機能紹介記事では見落とされがちです。本記事では§2でこの制約を前提条件として明記し、§3で実際の適用範囲を整理します。

RDS Extended Supportについても、MySQL 5.7は2026年6月の発表により2029年6月まで延長されるなど、対象エンジンごとに延長スケジュールが更新され続けています。何も設定しなければ自動的に課金対象になる仕様は多くの運用者にとって意図せぬコスト増加の原因になっており、事前の試算と判断軸を持つことの重要性は年々高まっています。

Optimized Reads/Writesは、Nitroベースの世代(r5d/m5d/r6gd/m6gd等)が主流になったことで「対応インスタンスクラスに変更するだけ」という適用条件のシンプルさが際立つ機能ですが、Vol1で紹介したAurora I/O-Optimized(ストレージ課金モードの選択肢)と名称が似ているため混同されるケースが少なくありません。本記事ではこの違いを明確に切り分けて解説します。

Terraformリソースの対応状況

Blue/Green Deploymentsについては、Terraform上での対応範囲にも注意が必要です。HashiCorp公式のデザインドキュメントによれば、対応状況は以下の通りです。

Aurora環境でBlue/Green相当の無停止更新を行う場合は、AWSコンソールまたはAWS CLI(aws rds create-blue-green-deployment)を直接利用し、Terraform管理下のリソースへはterraform apply -refresh-only等で事後反映する運用を検討してください。この制約を踏まえた具体的な運用手順は§3で扱います。

3機能に関する公式発表タイムライン

本記事はこれらの発表内容のうち、本記事執筆時点(2026年7月)で一般提供済みの機能のみを対象とし、Preview段階の機能は扱いません。

本記事のセキュリティ・可用性設計の前提

Blue/GreenのGreen環境、Extended Support適用中のインスタンス、Optimized Reads/Writes有効化後のインスタンスは、いずれも既存のVPC・セキュリティグループ・KMS暗号化設定を引き継ぐことが前提です。本記事では新規のセキュリティ設計は行わず、AWS Well-Architected Frameworkの信頼性の柱とパフォーマンス効率の柱に沿った運用上の判断のみを扱います。

Vol5用途特化DB編(Neptune・DocumentDB・Keyspaces・Timestream)を読む

2. 前提・環境・準備

2-1. 前提環境

本章では、§3以降で実装するBlue/Green・Extended Support・Optimized Reads/Writesすべてに共通する前提環境を整えます。既存のRDS/Auroraクラスターがすでに稼働していることを前提とし、本章では新規のVPC・サブネット・クラスター構築は行いません。

ツールのバージョンは以下を必須とします。

E基準の妥当性については本記事執筆にあたり公式ソースで再裏取りを行いました。blue_green_updateパラメータはhashicorp/aws provider v4.42.0で導入されており、本シリーズの標準であるterraform 1.9.x / hashicorp/aws ~> 5.0の組み合わせと乖離はありません。なお、§4で扱うengine_lifecycle_support属性(Extended Supportの明示的な有効/無効切替)はv5.59.0で追加された比較的新しい属性のため、Extended Supportの制御までTerraformで完結させたい場合は、~> 5.0の範囲内でも>= 5.59を明示的に指定することを推奨します。

環境確認は以下のコマンドで行います。

# 実行アカウント・権限の確認
aws sts get-caller-identity

# 対象クラスターの現行エンジンバージョン確認
aws rds describe-db-instances \
  --query "DBInstances[].{ID:DBInstanceIdentifier,Engine:Engine,Version:EngineVersion,Class:DBInstanceClass}" \
  --output table

# Terraform/providerバージョン確認
terraform version

Terraformの初期化は以下の3点セットで行います。既存クラスターをTerraform管理下に置く場合は、terraform importで対象のaws_db_instanceまたはaws_rds_clusterをあらかじめ取り込んでおく必要があります。

# terraform.tf
terraform {
  required_version = ">= 1.9.0"

  required_providers {
 aws = {
source  = "hashicorp/aws"
version = ">= 5.59, < 6.0"
 }
  }

  backend "s3" {
 bucket= "your-org-terraform-state"
 key= "database/vol6-rds-bluegreen-extended-support-optimized-rw/terraform.tfstate"
 region= "ap-northeast-1"
 dynamodb_table = "terraform-lock"
 encrypt  = true
  }
}

provider "aws" {
  region = var.aws_region
}

variables.tfでは、対象クラスターの識別子とBlue/Green検証用のパラメータを変数化し、環境ごとに切り替えます。

# variables.tf
variable "aws_region" {
  description = "デプロイ先リージョン"
  type  = string
  default  = "ap-northeast-1"
}

variable "db_instance_identifier" {
  description = "対象RDSインスタンスの識別子(既存クラスター)"
  type  = string
}

variable "enable_blue_green_update" {
  description = "blue_green_updateブロックを有効化するかどうか"
  type  = bool
  default  = false
}

terraform importの例(既存のRDS for MySQLインスタンスを取り込む場合):

terraform import aws_db_instance.main <既存のDBInstanceIdentifier>

取り込み後はterraform planを実行し、既存構成とTerraformコードの差分がないことを確認します。差分がある場合は、lifecycle { ignore_changes = [...] }で意図的に無視する属性を明示するか、コード側を実インフラに合わせて修正してから次のステップへ進みます。

terraform init
terraform validate

terraform version
# Terraform v1.9.x
# + provider registry.terraform.io/hashicorp/aws v5.5x.x

terraform validate実行時にprovider versionが古い場合(v4.42.0未満)、blue_green_updateブロックの定義自体がスキーマエラーになります。CI/CDパイプラインではterraform init -upgradeを明示実行し、providerのバージョンドリフトを防ぎます。

2-2. 使用技術スタック

本Vol6で扱う3機能を、対象サービス・エンジンバージョン・インスタンスクラスの観点で整理します(D基準: 8項目以上)。

表の6-9行目にある通り、Blue/GreenとExtended Supportは対象エンジンが広い一方、Optimized Reads/Writesは「RDS単体インスタンス」かつ「対応インスタンスクラス」に限定される点が最大の制約です。Aurora環境ではOptimized Reads/Writesは利用できず、代わりにVol1で扱ったAurora I/O-Optimized(ストレージ課金モード)が性能・コスト最適化の選択肢になります。この住み分けは1-1のep-boxで示した差別化軸そのものです。

Optimized Reads対応インスタンスクラス(r5d/m5d/r6gd/m6gd)とOptimized Writes対応インスタンスクラス(db.m6gd/m6i/m5/m5d/r8g/r8gd/r7i/r7g/r6g/r6gd/r6i/r5/r5b/r5d/x2idn/x2iedn)は完全には一致しません。両機能を同時に有効化したい場合は、両方の条件を満たすインスタンスクラス(r6gd/m6gd/r5d/m5d等)を選択する必要があります。対応状況は変更され得るため、導入前に必ず公式ドキュメントの最新表を確認してください。

2-3. ゴール状態の定義

本章を完走した時点で、以下の状態に到達します。

• 対象のRDS/AuroraクラスターがTerraform管理下にあり、terraform planで差分が生じない状態
• Blue/Green Deployments検証用のGreen環境を作成・削除できる権限とコード(§3で実装)が準備できている状態
• Extended Supportの課金構造を理解し、対象クラスターが標準サポート内かExtended Support対象かをEngineVersionから判定できる状態
• Optimized Reads/Writesの対応条件(エンジンバージョン・インスタンスクラス)を、自身が運用するクラスターと照合できる状態

これらの前提が整った状態で、§3(Blue/Green)・§4(Extended Support)・§5(Optimized Reads/Writes)へと進みます。

2-4. IAM構成

3機能に共通して必要となる最小権限をJSON例で提示します。運用者ロールには機能単位でSidを分割し、監査時にどの権限がどの機能に対応するかを追跡しやすくしています。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "BlueGreenDeploymentManagement",
"Effect": "Allow",
"Action": [
  "rds:CreateBlueGreenDeployment",
  "rds:DescribeBlueGreenDeployments",
  "rds:SwitchoverBlueGreenDeployment",
  "rds:DeleteBlueGreenDeployment"
],
"Resource": "*"
 },
 {
"Sid": "InstanceAndClusterModification",
"Effect": "Allow",
"Action": [
  "rds:ModifyDBInstance",
  "rds:ModifyDBCluster",
  "rds:RebootDBInstance",
  "rds:DescribeDBInstances",
  "rds:DescribeDBClusters",
  "rds:DescribeDBEngineVersions",
  "rds:DescribeOrderableDBInstanceOptions"
],
"Resource": "*"
 }
  ]
}

BlueGreenDeploymentManagementはブルーグリーン環境の作成・監視・切替・削除を担い、InstanceAndClusterModificationはExtended Supportの対象確認やOptimized Reads/Writes適用のためのインスタンスクラス変更を担います。本番運用では、切替(SwitchoverBlueGreenDeployment)権限だけは変更管理プロセスを経た限定メンバーにのみ付与するなど、Sid単位でのアクセス制御分離を推奨します。

各Sidと3機能の対応関係を整理すると以下の通りです。

2-5. 検証手順の全体像

本章で整えた環境を使って§3以降へ進む前に、以下の順序で状態を確認しておくことを推奨します。

1. aws sts get-caller-identityで実行アカウントを確認する
2. aws rds describe-db-instancesで対象クラスターの現行エンジンバージョン・インスタンスクラスを確認する
3. 2-4のIAMポリシーが実行ロールにアタッチされていることを確認する
4. terraform init / terraform planでTerraform管理下の状態とAWS実環境の差分がないことを確認する
5. 上記1-4が揃った時点で、§3(Blue/Green)・§4(Extended Support)・§5(Optimized Reads/Writes)のうち、自身の課題に対応する§へ進む

この順序を踏むことで、§3以降で紹介するコード例をそのまま自身の環境に適用する際の事故(権限不足によるエラー・想定と異なるエンジンバージョンへの適用等)を未然に防げます。

3. RDS/Aurora Blue/Green Deployments — ゼロダウンタイム更新

3-1. 仕組みと対象範囲

Blue/Green Deploymentsは、本番稼働中のDBインスタンス(Blue環境)と同一トポロジーのステージング環境(Green環境)を作成し、Blueからの変更をレプリケーションでGreenへ同期し続ける仕組みです。Green環境にはMulti-AZ構成・Read Replica・ストレージ設定・DBスナップショット・自動バックアップ・Performance Insights・Enhanced Monitoringといった、Blue環境の機能がそのままコピーされます。Green環境は作成直後、既定で読み取り専用となり、メジャー/マイナーエンジンバージョンのアップグレードやパラメータグループの変更、ストレージタイプの変更などを本番影響なしに検証できます。

対象範囲はRDS単体インスタンスとAuroraクラスターとで公式ドキュメントの構成が分かれています。RDS(MariaDB/MySQL/PostgreSQL)の単体インスタンスに関する仕様は「Amazon RDS User Guide」、Auroraクラスターに関する仕様は「Amazon Aurora User Guide」でそれぞれ独立して記載されており、両者は機能の建て付けが異なる点に注意が必要です。

PostgreSQLでは、特定の条件下で物理レプリケーションの代わりに論理レプリケーションを使用する場合もあります。論理レプリケーションを使う構成ではDDL変更や大型オブジェクトの追加・変更がGreen環境との同期を壊す原因になるため、事前に対象条件を公式ドキュメントで確認することを推奨します。

3-2. Terraformによる実装(RDS単体インスタンス)

aws_db_instanceリソースにblue_green_updateブロックを追加しenabled = trueにすると、Terraform側でengine_versionやパラメータグループなどの更新を検知した際に、プロバイダーが内部でBlue/Green Deploymentを自動的に作成・同期・スイッチオーバー・削除まで実行し、単一のterraform applyの中でダウンタイムをスイッチオーバー時間のみに抑えます。Blue/Green Deploymentのオブジェクト自体はTerraformのstateに個別リソースとして現れない実装詳細です。

resource "aws_db_instance" "main" {
  identifier  = var.db_instance_identifier
  engine= "mysql"
  engine_version = "8.0.39"
  instance_class = "db.r6g.xlarge"

  allocated_storage  = 100
  storage_type = "gp3"
  backup_retention_period = 7

  parameter_group_name = aws_db_parameter_group.main.name

  blue_green_update {
 enabled = var.enable_blue_green_update
  }

  apply_immediately = false

  lifecycle {
 ignore_changes = [snapshot_identifier]
  }
}

blue_green_updateには以下の制約があります。

• 対応エンジンはMySQL・MariaDB・PostgreSQLのみです。それ以外のエンジンでは適用されません。
• Read Replicaを持つDBインスタンスには使用できません。Terraformは複数リソースにまたがるBlue/Green Deploymentを単一リソースとして扱えないためです。
• 自動バックアップの有効化(backup_retention_period > 0)が必要です。
• engine_versionやパラメータグループなど、Blue/Green Deploymentを介した更新に対応する属性の変更にのみ機能します。すべての属性変更がBlue/Green経由になるわけではありません。

enable_blue_green_update変数をfalseのまま運用し、実際にメジャーバージョンアップを行うタイミングだけtrueに切り替えてapplyする運用にすると、通常時の意図しないBlue/Green経由の更新を避けられます。

3-3. スイッチオーバーの制約と運用手順

スイッチオーバーはGreen環境を新しい本番環境へ昇格させる操作で、AWS Management Console・AWS CLI・RDS APIのいずれからも実行できます。スイッチオーバー時間は--switchover-timeoutオプションで30秒〜3,600秒(既定値300秒)の範囲で指定でき、指定時間を超えた場合はロールバックされ両環境とも変更されません。

aws rds switchover-blue-green-deployment \
  --blue-green-deployment-identifier bgd-xxxxxxxxxxxxxxxxx \
  --switchover-timeout 600

スイッチオーバー開始時、RDSは「スイッチオーバーガードレール」と呼ばれる準備状態チェックを自動実行し、条件を満たさない場合はスイッチオーバー自体を中止します。

ガードレールを通過すると、RDSは新規書込の停止→両環境への接続切断→レプリケーションの追いつき待ち→インスタンス名とエンドポイントの入れ替え→接続許可→新本番環境での書込再開、という順序で処理を進めます。スイッチオーバー完了後、旧Blue環境のインスタンスは-old1のようなサフィックスを付けて保持され、読み取り専用の状態で残ります(削除するまで通常課金が発生します)。

運用上のベストプラクティスとして、スイッチオーバー前にはCloudWatchのDatabaseConnections(またはPerformance Insights有効時はDBLoad)でアクティビティレベルを確認します。あわせてレプリカ遅延がほぼゼロであることをReplicaLag(MySQL/MariaDB)やOldestReplicationSlotLag(PostgreSQL論理レプリケーション)で確認し、トラフィックが最も少ない時間帯を選ぶことを推奨します。またDNSキャッシュのTTLをRDSの既定値(5秒)より長く設定していると、スイッチオーバー後もアプリケーションが旧Blue環境へ書込を送り続けるおそれがあるため、事前にクライアント側のTTL設定を確認してください。

2026年4月には、Amazon RDS ProxyがBlue/Green Deploymentsに対応しました。RDS Proxy経由で接続している場合、スイッチオーバー中はProxyが自動的に新しいGreen環境へ接続を切り替えるため、DNS伝播待ちによる接続断時間を短縮できます。既存接続はGreen昇格後に切断されるため、アプリケーション側での再接続処理は引き続き必要です。

3-4. メジャーバージョンアップ・パラメータ変更のユースケース

メジャーバージョンアップの場合は、engine_versionを新バージョンへ変更したうえでblue_green_update.enabled = trueのままapplyします。Green環境で新バージョンへのアップグレードとアプリケーション互換性を検証し、問題がなければスイッチオーバーします。問題が見つかった場合はGreen環境を削除するだけでBlue環境(本番)には一切影響を与えません。

パラメータグループの変更を検証する場合は、Green環境専用のパラメータグループを別途作成し、Blue/Green Deployment作成時にGreen側へ割り当てます。

resource "aws_db_parameter_group" "green_candidate" {
  name= "${var.db_instance_identifier}-green-candidate"
  family = "mysql8.0"

  parameter {
 name  = "innodb_buffer_pool_size"
 value = "{DBInstanceClassMemory*3/4}"
  }
}

いずれのユースケースでも、Green環境は既定で読み取り専用のため、書込を伴う検証(アプリケーションからの実接続テスト等)をする場合は、MySQLではread_onlyパラメータを0に、PostgreSQL(論理レプリケーション使用時)ではセッションレベルでdefault_transaction_read_onlyをoffに変更する必要があります。物理レプリケーションを使うPostgreSQL構成ではGreen環境での書込は許可されないため、検証範囲を読み取り系操作に限定してください。

3-5. Aurora環境での適用 — Terraformの非対応範囲と運用回避

2-1・2-2で確認した通り、Terraformのblue_green_updateはaws_db_instanceにのみ実装されており、aws_rds_cluster(Auroraクラスター)やaws_rds_cluster_instanceには提供されません。これはAWS API自体がAurora Blue/Green Deploymentsに対応していないためではなく、TerraformプロバイダーがAuroraクラスターを単一の自己完結したオブジェクトとしてではなく、aws_rds_clusterと複数のaws_rds_cluster_instanceの組み合わせでモデル化しているため、単一リソースの更新操作としてBlue/Green Deploymentを扱えないという設計上の制約です。

そのため、Aurora環境(Aurora MySQL/Aurora PostgreSQL単体、および2025年11月に対応が拡大されたAurora Global Databaseを含む)でBlue/Green Deploymentsを利用する場合は、AWS Management Console・AWS CLI・RDS APIのいずれかを直接利用し、Terraform管理下のリソースへは事後反映する運用が必要です。

# Aurora クラスターの Blue/Green Deployment 作成(AWS CLI)
aws rds create-blue-green-deployment \
  --blue-green-deployment-name aurora-mysql-major-upgrade \
  --source arn:aws:rds:ap-northeast-1:123456789012:cluster:my-aurora-cluster \
  --target-engine-version 8.0.mysql_aurora.3.08.0 \
  --target-db-cluster-parameter-group-name my-aurora-green-pg

# スイッチオーバー完了後、Terraform state をAuroraの新しい実体に合わせて同期
terraform apply -refresh-only
terraform plan

Aurora Global Databaseの場合、スイッチオーバーはプライマリリージョンとすべてのセカンダリリージョンを対象に一括で実行され、クラスター・インスタンス・エンドポイントの名前も自動的に本番名へ入れ替わるため、アプリケーション側の接続設定変更は不要です。ただしこの機能もAWS Management Console・SDK・CLIからの操作が前提であり、Terraformのネイティブなリソースとしては提供されていません。-refresh-onlyでの事後同期後、terraform planで差分がないことを必ず確認し、次回の意図しないterraform applyでGreen昇格後のクラスターが誤って変更されないようにしてください。

4. RDS Extended Support — 標準サポート終了後の延命戦略

4-1. 自動エンロールの仕組みと確認方法

RDS Extended Supportは、対象エンジンの標準サポート終了日の翌日から自動的に課金対象となる仕組みです。標準サポートが終了したメジャーバージョンをそのまま起動し続けているだけで、明示的な申込操作なしにExtended Supportへエンロールされます。この「何もしなければ自動加入」という仕様が、意図しないコスト増加の主な原因になっています。

対象となるのはRDS for MySQL・RDS for MariaDB・RDS for PostgreSQL、およびAurora MySQL・Aurora PostgreSQLの標準サポートが終了したメジャーバージョン全般です。自身の環境が対象かどうかは、まず現行エンジンバージョンを確認し、各エンジンの標準サポート終了日と突き合わせることで判定します。

# 対象クラスターの現行エンジンバージョンを確認
aws rds describe-db-instances \
  --query "DBInstances[].{ID:DBInstanceIdentifier,Engine:Engine,Version:EngineVersion,LifecycleSupport:EngineLifecycleSupport}" \
  --output table

EngineLifecycleSupportフィールドにはopen-source-rds-extended-support(Extended Support有効、既定値)またはopen-source-rds-extended-support-disabled(Extended Support無効化済み)が表示されます。標準サポート終了日はエンジンごとにリリースカレンダーで公開されているため、対象クラスターのエンジンバージョンと照合してください。

課金は標準サポート終了日の翌日から発生し、その後標準サポート内のバージョンへアップグレードした時点、またはインスタンス自体を削除した時点で自動的に停止します。将来別のメジャーバージョンが標準サポートを終了した際に再度Extended Support対象へ入れば、その時点から課金が再開する点にも注意してください。

4-2. 課金構造とコスト試算

Extended Supportの課金は、標準サポート終了からの経過年数に応じた段階制のvCPU時間課金です。米国東部リージョンの例では、標準サポート終了から1〜2年目は1vCPU時間あたり0.100ドル、3年目以降は0.200ドルと、単価が2倍になります。実際の単価はリージョンおよび時期によって異なるため、対象リージョンの最新価格は各エンジンの料金ページで確認してください。Multi-AZ構成のスタンバイインスタンスにもExtended Support料金が適用される点は見落とされがちです。

コスト試算の考え方として、対象インスタンスのvCPU数(インスタンスクラスに紐づく)×稼働時間×該当年数の単価で概算します。たとえばdb.r6g.xlarge(4vCPU)を24時間365日稼働させ、Year1-2の単価(0.100ドル/vCPU時間)を適用した場合、年間コストの概算は「4vCPU × 24時間 × 365日 × 0.100ドル」で算出できます。Year3に到達すると単価が2倍になるため、同条件でも年間コストはおよそ倍増します。Multi-AZ構成の場合はスタンバイ分も同様に課金対象となるため、試算にはプライマリとスタンバイ両方のvCPU数を含める必要があります。

4-3. Terraformでの制御

hashicorp/aws provider v5.59.0以降では、aws_db_instance(およびaws_rds_cluster・aws_rds_global_cluster)にengine_lifecycle_support属性が追加されており、Extended Supportへのエンロールを明示的に制御できます。

resource "aws_db_instance" "main" {
  identifier  = var.db_instance_identifier
  engine= "mysql"
  engine_version = "8.0.39"
  instance_class = "db.r6g.xlarge"

  # 標準サポート終了後、意図せずExtended Supportへ課金対象化させない場合
  engine_lifecycle_support = "open-source-rds-extended-support-disabled"

  backup_retention_period = 7
}

engine_lifecycle_supportをopen-source-rds-extended-support-disabledに設定すると、標準サポート終了日を過ぎた状態でのDBインスタンス作成・スナップショットからの復元がブロックされ、Extended Supportへの課金を未然に防げます。既存の稼働中インスタンスが標準サポート終了日を迎えてしまっている場合は、この属性だけで遡って課金を止めることはできず、標準サポート内のバージョンへ実際にアップグレードする必要がある点に注意してください。2-1で確認した通り、engine_lifecycle_supportは~> 5.0の範囲内でも>= 5.59を明示指定しないと利用できないため、required_providersブロックのバージョン指定を必ず見直してください。

4-4. 回避策 — アップグレード計画の立て方

Extended Supportの課金構造を踏まえると、選択肢は「延命しながら課金を受け入れる」か「標準サポート内のバージョンへ先にアップグレードする」かの二択です。判断軸として、まず対象インスタンス群のExtended Support試算コスト(4-2)と、メジャーバージョンアップグレードに要する検証工数・ダウンタイムコストを比較します。

• 短期(半年〜1年以内)に標準サポート内バージョンへ移行できる見込みがある場合は、Year1-2の単価で延命しながらアップグレード計画を進める選択肢が現実的です。
• 移行に長期間を要する、またはアプリケーション側の互換性検証に大きな工数がかかる場合は、Year3の単価上昇を織り込んだうえで、§3のBlue/Green Deploymentsを使ったゼロダウンタイムアップグレードを優先的に計画することを推奨します。
• Terraformでengine_lifecycle_support = "open-source-rds-extended-support-disabled"を先に設定しておくと、担当者が意図せずExtended Support対象のまま新規インスタンスを作成してしまう事故を構造的に防げます。

アップグレード計画には、対象インスタンスの棚卸し(エンジンバージョン・標準サポート終了日の一覧化)、Blue/Green Deploymentsによる検証環境での動作確認、アプリケーション側の互換性テスト、本番スイッチオーバーの時間帯選定、という順序を踏むことで、Extended Supportへの依存期間を最小化できます。

4-5. エンジン別の最新動向

Extended Supportの対象範囲・延長スケジュールはエンジンごとに更新され続けています。本記事執筆時点(2026年7月)で確認できている主要な動向は以下の通りです。

• MySQL 5.7: Aurora MySQL(MySQL 5.7互換)およびRDS for MySQL 5.7のExtended Supportが、2026年6月の発表により従来の終了予定(2027年2月28日)から2029年6月30日まで延長されました。この延長期間中、追加の値上げは行われず、Year3の単価がそのまま2029年6月30日まで適用されます。長期のExtended Support依存を計画している場合でも、単価が想定外に上昇することはありません。
• PostgreSQL 11/12/13: 2026年5月、RDS for PostgreSQLのExtended Support対象バージョン(11.22/12.22/13.23等)向けにマイナーバージョンの継続提供が発表されました。標準サポートが終了したメジャーバージョンであっても、Extended Support期間中はセキュリティパッチを含むマイナーバージョンアップデートが継続して提供されるため、Extended Support中であっても自動マイナーバージョンアップグレードを有効化し、最新のマイナーバージョンを適用し続けることが推奨されます。

エンジンごとの延長スケジュールは今後も更新される可能性があるため、対象インスタンスの棚卸しをする際は、必ず各エンジンのリリースカレンダーで最新の標準サポート終了日・Extended Support終了日を確認してください。

5. RDS Optimized Reads / Optimized Writes — RDS for MySQL/MariaDB 高速化

5-1. Optimized Reads — 仕組みと対象範囲

Optimized Readsは、NVMeベースのローカルインスタンスストアを搭載したDBインスタンスクラス(db.m5d・db.r5d・db.m6gd・db.r6gd等。2025年11月以降はGraviton4世代のdb.m8gd・db.r8gdも追加)を選択するだけで既定で有効になる機能です。MySQLやMariaDBがクエリ処理中に生成する内部一時ファイル・オンディスク一時テーブル・メモリマップファイル・バイナリログキャッシュファイルを、永続化用のAmazon EBSではなくホストサーバーに直結したローカルNVMe SSD(インスタンスストア)へ配置することで、ソート処理・ハッシュ集計・複雑なJOIN・CTE(共通テーブル式)・非インデックス列でのGROUP BY/ORDER BYといったワークロードのクエリ処理速度を最大2倍に高速化します。一時オブジェクトの処理をEBSから切り離すことで、永続データに対するEBS側のIOPS/スループットにも余裕が生まれます。

対応バージョンはRDS for MySQL 8.0.28以降、RDS for MariaDBは10.4.25以降(10.5系は10.5.16以降・10.6系は10.6.7以降・10.11系は10.11.4以降・11.4系以降は全マイナーバージョン)です。インスタンスストアは一時領域のため、手動・自動スナップショットには一時オブジェクトの内容は含まれません。

本記事の検証環境(1-2の「本記事で使用する検証環境」参照)に合わせ、本節ではRDS for MySQL/MariaDBでのOptimized Readsを中心に扱います。実はRDS for PostgreSQL(13.10/14.7/15.2以降)にもOptimized Readsは提供されており、最大50%のクエリ高速化を実現します(1-1の比較表に記載の通り)。ただし対応インスタンスクラスの世代・性能改善率がMySQL/MariaDB版と異なり、本記事の検証範囲外であるため詳細はRDS for PostgreSQLの公式ドキュメントを参照してください。

いずれのエンジンでも、Optimized ReadsはAuroraクラスターには提供されていません。Aurora PostgreSQLには「Aurora Optimized Reads」という名称の類似機能がGraviton4世代(db.r8gd等)のAuroraインスタンス向けに別途提供されていますが、これはRDS Optimized Readsとは適用条件やドキュメント体系が異なるAurora固有の機能であり、5-5で整理するAurora I/O-Optimizedとも別物の第三の概念です。本記事ではAurora側の性能機能には踏み込みません。

5-2. Optimized Writes — 仕組みと対象範囲

Optimized Writesは、InnoDBのdoublewriteバッファを経由せずに16KiBページを1回の書込でデータファイルへ直接反映する機能です。doublewriteバッファは、書込中の電源障害等によるページの部分書込みを検知・復旧するための仕組みですが、書込を2回行うぶんオーバーヘッドが発生します。Optimized WritesはAWS Nitro Systemのハードウェア構成を活用し、doublewriteバッファなしでもページ書込の信頼性・耐久性を保ったままACID特性を維持し、書込トランザクションのスループットを最大2倍に高めます。追加のライセンス費用は発生しません。

対応バージョンはRDS for MySQL 8.0.30以降、RDS for MariaDBは10.6.10以降(10.11系は10.11.4以降・11.4系は11.4.3以降・11.8系以降は全マイナーバージョン)です。対応インスタンスクラスはNitro Systemベースの世代に限られ、db.m5・db.m5d・db.r5・db.r5b・db.r5d・db.m6g・db.m6gd・db.m6i・db.r6g・db.r6gd・db.r6i・db.m7g・db.r7g・db.x2idn・db.x2iedn等が該当します。RDS for MySQLはさらにdb.m7i・db.r7i・db.m8g・db.m8gd・db.r8g・db.r8gdにも対応していますが、RDS for MariaDBは執筆時点(2026年7月)でGraviton4世代への対応が拡大されていません。Optimized ReadsとPostgreSQLの関係とは対照的に、Optimized WritesはRDS for PostgreSQL・Auroraのいずれにも提供されていません。

有効・無効はrds.optimized_writesパラメータ(既定値AUTO)で制御します。AUTOは対応条件を満たす場合に自動的に有効化し、OFFは対応条件を満たしていても明示的に無効化します。現在の状態はinnodb_doublewriteパラメータの値で確認でき、FALSE(0)であればOptimized Writesが有効です。

5-3. 有効化条件とTerraformでの実装

Optimized Readsは対応インスタンスクラスを選択するだけで自動的に有効化されるため、Terraform側に専用の属性は存在しません。instance_classを対応クラスに設定するだけで機能します。

resource "aws_db_instance" "main" {
  identifier  = var.db_instance_identifier
  engine= "mysql"
  engine_version = "8.0.39"

  # Optimized Reads は NVMe インスタンスストア搭載クラスの選択のみで有効化
  instance_class = "db.r6gd.xlarge"

  allocated_storage = 100
  storage_type = "gp3"
  backup_retention_period = 7
}

Optimized Writesはrds.optimized_writesパラメータを介した制御のため、aws_db_parameter_groupリソースでパラメータグループを明示的に作成し、DBインスタンスへ割り当てます。

resource "aws_db_parameter_group" "optimized_writes" {
  name= "${var.db_instance_identifier}-optimized-writes"
  family = "mysql8.0"

  parameter {
 name  = "rds.optimized_writes"
 value = "AUTO"
  }
}

resource "aws_db_instance" "main" {
  identifier  = var.db_instance_identifier
  engine= "mysql"
  engine_version = "8.0.39"
  instance_class = "db.r6gd.xlarge"

  parameter_group_name = aws_db_parameter_group.optimized_writes.name
  backup_retention_period = 7
}

有効化を確認するには、パラメータグループの実値をAWS CLIで確認します。

# innodb_doublewrite が FALSE(0) であれば Optimized Writes が有効
aws rds describe-db-parameters \
  --db-parameter-group-name my-db-instance-optimized-writes \
  --query "Parameters[?ParameterName=='innodb_doublewrite']"

5-4. 既存インスタンスへの適用 — Blue/Green Deploymentsとの連携

Optimized Writesを新規作成のDBインスタンスへ適用する場合、5-3の設定のみで完結します。ただし、既存の稼働中インスタンスへ適用する場合には制約があります。Optimized Writesが必要とするファイルシステム構成は、機能リリース以前に作成されたDBインスタンスと互換性がありません。対象はRDS for MySQL(2022年11月27日以前に作成)とRDS for MariaDB(2023年3月7日以前に作成)のインスタンスです。そのため、対応バージョン・対応インスタンスクラスへ変更するだけでは、既存インスタンスでOptimized Writesを有効化できません。

この制約を回避する公式な方法が、3で扱ったBlue/Green Deploymentsです。Blue/Green Deployment作成時にAWS Management Consoleで「Enable Optimized Writes on green database」を選択し、あわせて「Upgrade storage file system configuration」を選択すると、Green環境が互換性のあるファイルシステム構成で作成され、Optimized Writesが有効化された状態でスイッチオーバーできます。ただし、これら2つのオプションはTerraformのaws_db_instanceが提供するblue_green_updateブロック(enabled属性のみ)からは指定できません。既存インスタンスでOptimized Writesを有効化する目的でBlue/Green Deploymentを使う場合は、AWS Management ConsoleまたはAWS CLIのcreate-blue-green-deploymentを直接利用し、スイッチオーバー完了後にterraform apply -refresh-onlyでTerraform stateを同期する運用が必要です。この考え方は3-5で解説したAurora環境での運用回避パターンと同じです。

5-5. Aurora I/O-Optimizedとの違い(★最重要差別化ポイント)

1章冒頭の「Vol1〜5との住み分け」で予告した通り、本記事で最も混同されやすいのがVol1で紹介したAurora I/O-Optimizedと、本節のOptimized Reads/Writesです。両者は名称が似ているだけで、対象サービス・仕組み・費用構造のすべてが異なります。

Aurora I/O-Optimizedは「I/Oリクエスト数に応じた課金を避けたいAuroraクラスター」のためのストレージ課金モードであるのに対し、Optimized Reads/Writesは「RDS for MySQL/MariaDBのクエリ・書込処理そのものを高速化する」エンジンの性能機能です。対象サービス(AuroraかRDS単体か)がそもそも異なるため、Auroraクラスターのinstance_classをNVMe対応クラスに変更してもOptimized Reads/Writesは有効化されず、逆にRDS単体インスタンスのストレージ課金モードを変更してもAurora I/O-Optimizedには切り替わりません。両者を同一機能の言い換えと誤解すると、コスト試算や性能改善の見込みを大きく見誤るため、既存クラスターの運用方針を検討する際は、まず対象がAuroraクラスターかRDS単体インスタンスかを起点に整理することを推奨します。

6. 詰まりポイント / アンチパターン

6-1. Blue/Green切替時のレプリケーション遅延でスイッチオーバーが進まない

Blue環境の書込負荷が高い状態、またはGreen環境のインスタンスクラスをBlueより小さく作成した状態でスイッチオーバーすると、3-3で解説したスイッチオーバーガードレールの「レプリカ遅延がタイムアウト時間内であること」チェックを通過できず、指定した--switchover-timeout(既定300秒)以内に完了せずロールバックされる事象が発生します。ロールバック自体は両環境に変更を残さない安全な挙動ですが、メンテナンスウィンドウ内でのスイッチオーバーに失敗すると計画のやり直しが必要になります。

対策として、スイッチオーバー実施前に必ずReplicaLag(MySQL/MariaDB)またはOldestReplicationSlotLag(PostgreSQL論理レプリケーション)がゼロに近いことを確認し、Green環境のインスタンスクラスはBlue環境と同等以上に設定します。トラフィックが最も少ない時間帯を選ぶことに加え、書込の多いバッチ処理やバルクインポートの実行中はスイッチオーバーを避けてください。

# スイッチオーバー前にレプリカ遅延を確認(MySQL/MariaDB)
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name ReplicaLag \
  --dimensions Name=DBInstanceIdentifier,Value=my-green-instance \
  --start-time $(date -u -v-10M +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 60 \
  --statistics Average

6-2. Extended Support想定外課金 — 自動エンロールに気づかない

4-1で解説した通り、標準サポート終了日を過ぎたエンジンバージョンを起動し続けているだけで、明示的な申込操作なしにExtended Supportへ自動的にエンロールされます。運用担当者が標準サポート終了日を把握しないまま数ヶ月〜1年以上放置し、Year3の単価倍増(4-2)に達してから請求額の異常増加で気づくケースは珍しくありません。

対策として、Terraformでengine_lifecycle_support = "open-source-rds-extended-support-disabled"を明示設定し、標準サポート終了日を過ぎた状態での新規作成・スナップショット復元を構造的にブロックします。既存の稼働中インスタンスについては、対象エンジンバージョンと標準サポート終了日の一覧を定期的に棚卸しし、終了日が近づいたインスタンスをアップグレード計画(4-4)へ組み込む運用フローを整備してください。

6-3. Optimized Reads/Writes対応外インスタンスでの無効化に気づかない

コスト削減や需要変動を理由にインスタンスクラスをダウンサイズ・変更した結果、NVMeインスタンスストア非搭載クラスへ移行すると、Optimized Readsは自動的に無効化されます。Optimized Writesも同様に、対応条件を満たさないインスタンスクラスへ変更すると自動的にOFF相当の挙動となり、doublewriteバッファを使う従来の書込方式へ暗黙的に戻ります。

この無効化はエラーやアラームを伴わずサイレントに発生するため、アプリケーション側では「原因不明のクエリ遅延・書込スループット低下」としてしか観測されず、Optimized Reads/Writesの無効化が原因だと気づくまでに時間がかかりがちです。対策として、CloudWatchのFreeLocalStorage等インスタンスストア関連メトリクスの欠測(値を取得できなくなること自体がOptimized Reads無効化のシグナルです)を監視し、innodb_doublewriteパラメータの値を定期的にチェックする運用を組み込んでください。

6-4. 3機能共通のアンチパターン — チェックリスト

7. まとめ + シリーズクロスリンク

7-1. 到達点サマリ

本記事では、既存のRDS/Auroraクラスターを「止めずに更新する」「サポート終了後も延命する」「追加費用なしで速くする」という3つの運用課題への対処法を解説しました。

• Blue/Green Deployments: 本番環境の完全コピーであるGreen環境でメジャーバージョンアップ・パラメータ変更を検証し、数十秒〜1分未満のスイッチオーバーで本番反映します。TerraformはRDS単体インスタンス(aws_db_instanceのblue_green_update)のみ対応し、Auroraクラスターの場合はAWS CLI/コンソールでの直接操作と-refresh-onlyでの事後同期が必要です。
• RDS Extended Support: 標準サポート終了後も最大3年間パッチ提供を継続する仕組みで、何も設定しなければ自動的に課金対象となります。engine_lifecycle_support属性で明示的に制御し、延命かアップグレードかを課金試算に基づいて判断します。
• Optimized Reads/Writes: RDS for MySQL/MariaDBのNVMeインスタンスストア対応クラスを選択するだけでクエリ処理を最大2倍高速化し(Optimized Reads)、rds.optimized_writesパラメータでdoublewriteバッファを回避して書込スループットを最大2倍にします(Optimized Writes)。いずれも追加費用はかかりません。Vol1で紹介したAurora I/O-Optimized(ストレージ課金モード)とは対象サービス・仕組みが異なる別機能です。

3機能はいずれも既存クラスターに対する「無停止更新」「延命判断」「性能改善」という異なる軸の運用課題に対応します。Blue/Green Deploymentsで安全に更新し、Extended Supportの課金構造を理解して延命かアップグレードかを判断し、対応インスタンスクラスへの変更でOptimized Reads/Writesの恩恵を受ける、という3つの実務スキルを組み合わせることで、既存のRDS/Auroraクラスターを止めずに・長く・速く運用する土台が整います。

基礎編:Database Vol1(RDS×Aurora×DynamoDB)を読む
移行・レプリカ編:Database Vol2(DMS×Aurora Global)を読む
キャッシュ編:Database Vol3(ElastiCache×DAX×MemoryDB)を読む
分散SQL編:Database Vol4(Aurora DSQL×Limitless)を読む
用途特化DB編:Database Vol5(Neptune×DocumentDB×Keyspaces×Timestream)を読む

Aurora PostgreSQL — 人間がログインしないDB管理 完全ガイドを読む
Aurora × AWS Backup DR 演習完全ガイドを読む