Skip to content

AWS RDS instances ‐ Health Checks

Jump to bottom
Pallavi Chitrada edited this page May 31, 2026 · 10 revisions

(05/30/2026)

RDS notification from AWS: You are receiving this message because you have one or more instances running Amazon RDS for PostgreSQL minor versions 14.14, 14.15, 14.16, 14.17, 15.9, 15.10, 15.11, 15.12, 16.5, 16.6, 16.7, 16.8, 17.1, 17.2, 17.3, 17.4, or 11.22-RDS.20241121 which will reach the end of standard support on May 31, 2026. To learn more about the RDS policies related to major and minor version support, please refer to the Database Engine Versions section in RDS FAQs [1].

Starting May 1, 2026, you will not be able to create new database instances on Amazon RDS for PostgreSQL minor versions 14.14, 14.15, 14.16, 14.17, 15.9, 15.10, 15.11, 15.12, 16.5, 16.6, 16.7, 16.8, 17.1, 17.2, 17.3, 17.4, or 11.22-RDS.20241121 from either the AWS Console or the CLI. During a scheduled maintenance window after May 31, 2026, Amazon RDS will automatically upgrade your Amazon RDS for PostgreSQL databases running minor versions 14.14, 14.15, 14.16, 14.17, 15.9, 15.10, 15.11, 15.12, 16.5, 16.6, 16.7, 16.8, 17.1, 17.2, 17.3, 17.4, or 11.22-RDS.20241121 to version 14.20, 15.15, 16.11, 17.7 (or higher). This also applies to any instances restored from snapshots of these versions.

The affected instances are listed in the 'Affected resources' tab of your AWS Health Dashboard.

This is a mandatory engine version upgrade, and it requires downtime. To minimize the downtime during the upgrade, you can use the fully managed Amazon RDS Blue/Green Deployments Service [2].

We recommend upgrading these instances to newer minor versions to benefit from patches for known security vulnerabilities, as well as bug fixes, performance improvements, and new functionalities added by the PostgreSQL community.

If you have any questions or concerns, please reach out to us on AWS re:Post [3] or AWS Support [4]. [1] https://aws.amazon.com/rds/faqs/#database-engine-versions--yfcwi2 [2] https://aws.amazon.com/blogs/aws/new-fully-managed-blue-green-deployments-in-amazon-aurora-and-amazon-rds/ [3] https://repost.aws [4] https://aws.amazon.com/support --- Reference: https://health.aws.amazon.com/health/home?region=us-east-1#/event-log?eventID=arn:aws:health:us-east-1::event/RDS/AWS_RDS_PLANNED_LIFECYCLE_EVENT/AWS_RDS_PLANNED_LIFECYCLE_EVENT_2bc1e3e85ae0b315f0a48876b497dc93f9c7a45bfd09e3b0a4afb493bd6ef2ac&eventTab=details

Message metadata Affected account 9923XXXXXXXX Event type code AWS_RDS_PLANNED_LIFECYCLE_EVENT Event region us-east-1 Service RDS Event type category scheduledChange Start time Sun, 31 May 2026 08:00:00 GMT

Instance Engine Checks -
saayam-dev-rds: us-east-1: 16.8
ireland-saayam-database: eu-west-1: 16.10
stockholm-saayam-database: eu-north-1a: 16.10

Target Version: We should aim to upgrade all instances to the latest stable minor version, which, according to the notification, is 14.20, 15.15, 16.11, 17.7 (or higher).
Note: It is highly recommended to stick to the same major version (16.x) and upgrade to the latest minor version (which is at least 16.11 or higher, such as 16.14) rather than jumping to 17.7. Moving from 16.10 to 16.14 is a "minor" upgrade. These are designed to be low-risk, backward-compatible, and do not change the internal data format of our database. They contain only security patches and bug fixes. Moving from 16.x to 17.x is a "major" upgrade. This changes the internal storage format and system tables. It is significantly more complex, carries a higher risk of breaking application queries, and requires more rigorous testing (like dump/reload or pg_upgrade).
Since the Ireland and Stockholm instances are already on 16.10, upgrading to a newer 16.x version is the safest and fastest way to comply with the AWS requirement without a major overhaul of the application code.

Use Blue/Green Deployments: This is the safest way to perform the upgrade because it creates a "Green" environment (staging) on the chosen version. It allows one to verify that the application works correctly against the new version. It performs a near-zero-downtime "Switchover" when we are ready.

Part 1: Verification (Checking Versions & Health)

Check Engine Versions:

  1. Open the RDS Console.
  2. Go to Databases and select instance (e.g., stockholm-saayam-database).
  3. On the Configuration tab, locate the Engine version.
  4. Compare this version against the list provided in the AWS notification. If it matches, the instance needs an update.

Check Health Events:

  1. Navigate to Health: Go to the AWS Health Dashboard.
  2. Check Scheduled Changes: Look at the Scheduled Changes tab. One should see a notification titled similar to "RDS PostgreSQL minor version upgrade."
  3. View Affected Resources: Click on the event to open the details pane. Select the Affected resources tab. This will list the specific database instances (DB Instance IDs) that require the upgrade.

Part 2: Preparation & Strategy

Select Target Version:
Staying within the same major version is the safest path as it avoids complex code changes.

Create a Backup:

  1. In your console, on the left-hand sidebar, click Snapshots.
  2. Click the Take snapshot button.
  3. Select instance
  4. Give it a name like pre-upgrade-snapshot-may30 and click Take snapshot.
  5. Wait for this to complete (the status will change from "Creating" to "Available").

Step 3: Execute the Blue/Green Deployment

This is the "zero-downtime" method that avoids direct modification of the current production database.

  1. Navigate back to database: Databases > stockholm-saayam-database.
  2. Click the Actions dropdown button at the top right.
  3. Select Create blue/green deployment.
  4. Configure the Green Environment:
    Deployment name: Use something descriptive like versionupgrade-16-14.
    Engine version: Select the highest version available in the 16.x series (e.g., 16.14 or the latest one in the list).
    Keep the instance class (db.t4g.micro) the same as the current database.
  5. Click Create.

Note: AWS will now spin up a "Green" clone of the database running the new version. This process takes a few minutes. One can monitor the progress on the main RDS Dashboard.

Step 4: Validate and Switchover

  1. Once the "Green" environment is Available: Replication: Wait for the green instance to be replicated properly without any lag, i.e., 0.
    Test: One will see a new database instance created. Connect your application to this new "Green" endpoint (you can find this in the Connectivity & security tab of the new instance) to ensure your app functions correctly.
  2. Once satisfied, go back to the original (Blue) database instance page. Click the Actions menu again.
    Select Switchover.

This will automatically promote the "Green" database to become the new primary production instance, and the old "Blue" database will be kept for a short time before being decommissioned.

Process Screenshots

image image

1:29 AM IST - 4 Seconds
1:56 AM IST - 79 Seconds

A fluctuating lag value is between numbers like 4 and 79. It confirms that our logical replication stream is healthy, active, and functioning exactly as designed. Why the Number Is Bouncing Around? Even though our application has no active API traffic or cron jobs, PostgreSQL is never truly idle.
Internal Heartbeats: AWS RDS continuously runs internal background queries to check database health and gather metrics.
The Fluctuations: When an internal health check writes a tiny system log, the lag jumps slightly (e.g., to 79). Milliseconds later, the Green instance processes it, and the lag plummets back down to near zero (e.g., 4).
The Verdict: The real-time replication is working in milliseconds. This tiny variance is completely harmless.
The lag value you see is simply a minor historical buffer of internal background system noise (like PostgreSQL internal housekeeping or AWS health checks) that hasn't officially closed out yet.

image image

Clone this wiki locally