Endpoints, not IPs
RDS gives your database an endpoint, a DNS hostname like:
myapp-db.c9xkzq2b1f.us-east-1.rds.amazonaws.com port 5432
Your app connects to it exactly as it would to any PostgreSQL host, no AWS-specific driver:
psql -h myapp-db.c9xkzq2b1f.us-east-1.rds.amazonaws.com -U appuser -d myappAlways configure the hostname, never the IP behind it. During a Multi-AZ failover (lesson 6-1) the hostname is repointed at the standby, so apps that use the endpoint recover automatically, and apps that cached the IP stay down.
Code exercise · bash
Why the hostname rule matters, played out. The endpoint is a DNS record (lesson 5-3) that RDS controls: during failover, RDS repoints it at the standby's IP. Run the simulation and compare the two apps.
Security group chaining
The database sits in a private subnet, and its security group needs an inbound rule for port 5432. What source? You could enter the app servers' IP range, but servers come and go, and their IPs change.
The idiomatic answer, promised in lesson 3-3: use another security group as the source.
| security group | inbound rule |
|---|---|
| sg-app (on app servers) | 443 from the ALB's group |
| sg-db (on the database) | 5432 from sg-app |
Read the second row as: port 5432, from any machine that wears sg-app. Launch a third app server tomorrow, give it sg-app, and it can reach the database with zero rule edits. Membership in the group IS the credential.
Quiz
During a Multi-AZ failover, apps configured with the RDS endpoint hostname reconnect within a couple of minutes, but one legacy service stays broken for hours. The likely cause?
Problem
Spot the misconfiguration. The database's security group allows port 5432 from source 0.0.0.0/0. To follow this lesson's chaining pattern, the source should instead be the app tier's ______ ______. (two words)