Connect Spring Boot to Amazon RDS PostgreSQL Securely

A practical guide to database connectivity, network access, credentials, and troubleshooting

Overview

Amazon Relational Database Service (Amazon RDS) for PostgreSQL provides a managed PostgreSQL database. A Spring Boot application can connect to it through JDBC and Spring Data JPA, while AWS networking and identity services help control access and protect credentials.

This article describes a common reference architecture in which a Spring Boot application runs on Amazon EC2 in private subnets and connects to an RDS for PostgreSQL database that is not publicly accessible. Adapt the design to your workload, compliance requirements, and AWS environment.

Important: This is an implementation guide, not a claim that a live AWS deployment has been tested. Validate every setting in a non-production environment and check current AWS pricing and documentation.

Architecture

The companion file spring_boot_rds_postgresql_architecture.svg shows the major components and the intended network path.

Request and connection flow

1. A client sends an application request to the Spring Boot service.
2. Spring Boot obtains a database connection from its configured connection pool.
3. The connection travels over the VPC network to the RDS PostgreSQL endpoint on TCP port 5432.
4. RDS authenticates the database user and processes the SQL statement.
5. The result returns to the application, which sends the response to the client.

The database should not be directly reachable from the public internet in this reference design. The EC2 application security group is allowed to connect to the RDS security group on port 5432.

Components and responsibilities

Component	Responsibility
Spring Boot	Application logic and database access
Spring Data JPA / Hibernate (optional)	Repository abstraction and ORM
PostgreSQL JDBC driver	JDBC connectivity to PostgreSQL
Amazon EC2 or another compute service	Runs the application
Amazon RDS for PostgreSQL	Managed relational database
Amazon VPC and private subnets	Network isolation
Security groups	Restrict application-to-database traffic
AWS Secrets Manager (recommended for managed secrets)	Stores and controls access to database credentials
AWS IAM role	Grants the application permission to retrieve the secret
Amazon CloudWatch	Database and application monitoring when configured

1. Create or select an RDS PostgreSQL database

In the AWS console, create an RDS for PostgreSQL database or select an existing one. Exact console labels can change, but review the following settings:

• Connectivity: Place the DB instance in the VPC used by the application.
• Subnets: Use a DB subnet group with private subnets in the required Availability Zones.
• Public access: Set the database to not publicly accessible unless there is a documented, reviewed reason otherwise.
• Security group: Attach a database security group that permits PostgreSQL connections from the application security group only.
• Credentials: Use a managed secret or another approved secrets-management approach; avoid embedding credentials in source code.
• Encryption: Enable encryption at rest and use TLS for connections where supported and required by your security policy.
• Backups: Configure retention, maintenance windows, and recovery objectives appropriate to the workload.
• Availability: Consider Multi-AZ deployment for workloads that require managed failover; verify the selected deployment option and its cost.

Record the database endpoint, database name, port, and secret identifier. Do not put passwords in the article, source control, screenshots, or logs.

2. Configure security groups

Use security-group references instead of opening PostgreSQL to all IP addresses.

Application security group

Allow only the inbound traffic needed to reach the Spring Boot application. For outbound database traffic, allow TCP 5432 to the database security group, in accordance with your organization's network policy.

RDS security group

Add an inbound rule:

• Type: PostgreSQL
• Protocol: TCP
• Port: 5432
• Source: the application EC2 security group, not 0.0.0.0/0

Security groups are stateful. Ensure route tables, network ACLs, DNS resolution, and VPC connectivity also permit the connection. Do not make the RDS database publicly accessible just to work around a network configuration problem.

3. Add the PostgreSQL JDBC dependency

For a Maven-based Spring Boot project, include the PostgreSQL driver. Let the Spring Boot dependency management control the version unless your project has a reason to pin it explicitly.

<dependency>
    <groupId>org.postgresql</groupId>
    <artifactId>postgresql</artifactId>
    <scope>runtime</scope>
</dependency>

If the application uses Spring Data JPA, include the appropriate Spring Boot JPA starter as well.

4. Configure the datasource without hardcoding secrets

A minimal application.properties example:

spring.datasource.url=jdbc:postgresql://${DB_HOST}:${DB_PORT:5432}/${DB_NAME}
spring.datasource.username=${DB_USERNAME}
spring.datasource.password=${DB_PASSWORD}

# Tune these for the application and database size.
spring.datasource.hikari.maximum-pool-size=${DB_POOL_MAX:10}
spring.datasource.hikari.connection-timeout=30000

Set environment variables through your approved deployment and secrets-management mechanism. Do not commit real values or credentials to Git.

For example, DB_HOST should be the RDS endpoint hostname, not a guessed IP address. RDS endpoints can resolve to different addresses over time, so use the endpoint DNS name.

Using AWS Secrets Manager

A typical secure pattern is:

1. Store the database username and password in AWS Secrets Manager.
2. Attach an IAM role to the compute environment.
3. Grant that role permission to retrieve only the required secret.
4. Retrieve the secret at runtime through an approved integration or application code.
5. Avoid logging the secret and plan for credential rotation.

The exact implementation depends on the compute platform and Spring Boot/AWS integration you choose. Do not assume that placing a secret in Secrets Manager automatically populates DB_USERNAME and DB_PASSWORD; configure the retrieval and mapping explicitly.

5. Use TLS for database connections

Enable and validate TLS according to your security requirements. For RDS PostgreSQL, consult current AWS guidance for downloading the appropriate CA bundle and configuring the JDBC driver to verify the server certificate. Avoid disabling certificate validation as a shortcut.

A JDBC URL can include TLS-related options, but the exact parameters should match the driver version and AWS's current recommended configuration. Test certificate validation in a non-production environment before rollout.

6. Configure connection pooling thoughtfully

Spring Boot commonly uses HikariCP as its JDBC connection pool. Pool sizing matters because every application instance can open multiple database connections.

A starting point might be:

spring.datasource.hikari.maximum-pool-size=10
spring.datasource.hikari.minimum-idle=2
spring.datasource.hikari.connection-timeout=30000

These are examples, not universal production values. Estimate the total possible connections across all application instances and compare that with the database's connection capacity and workload. For example, 6 instances with a maximum pool of 10 could permit up to 60 pooled connections, before accounting for migrations, admin sessions, and other clients.

Tune pool size using load tests and database metrics. Increasing the pool without measuring can worsen database contention rather than improve throughput.

7. Validate the connection

Before debugging Spring Boot, confirm the basic network and database details:

• The application and RDS instance are in reachable VPC network paths.
• The application uses the exact RDS endpoint and database name.
• The RDS security group accepts TCP 5432 from the application security group.
• The database user exists and has the necessary privileges.
• The application runtime can resolve the endpoint hostname.
• TLS configuration trusts the relevant RDS certificate chain.
• The connection pool settings are appropriate for expected concurrency.

A successful connection from a developer laptop does not prove that an EC2 instance in a private subnet can connect, because the network path and security rules may differ.

8. Troubleshooting common errors

Error or symptom	Likely areas to investigate
Connection timed out	Security groups, route tables, network ACLs, VPC connectivity, subnet selection, and whether the database is reachable from the application network
Connection refused	Wrong endpoint or port, database availability, or a connection path reaching the wrong destination
password authentication failed	Secret value, username, password rotation, database user, and the application environment receiving the expected credentials
database does not exist	Database name in the JDBC URL and actual database configuration
Unknown host / DNS failure	Endpoint typo, DNS configuration, VPC DNS settings, and runtime name resolution
SSL or certificate error	JDBC TLS settings, CA bundle, certificate validation, and driver compatibility
Too many connections	Pool size across all application instances, leaked connections, concurrent workloads, and database capacity
Slow queries or high latency	Query plans, indexes, locks, database load, network latency, and connection-pool waits

Avoid printing passwords, complete secret payloads, or sensitive connection strings in diagnostic logs. Redact credentials before sharing logs.

9. Monitoring and operations

Monitor both application and database layers:

• Application errors, request latency, and connection-pool active/idle/pending connections.
• RDS CPU, free memory, storage, database connections, read/write latency, and relevant engine metrics.
• Slow queries and query plans using approved PostgreSQL/RDS tooling.
• Backup success, restore procedures, and storage growth.
• Alerts for sustained resource pressure and unusual connection spikes.

CloudWatch provides RDS metrics; enhanced monitoring and database performance tooling may provide additional detail depending on configuration and cost. Use the current AWS service documentation to select appropriate metrics and retention.

10. Production-readiness checklist

• RDS is not publicly accessible for this private application design.
• RDS security group allows TCP 5432 from the application security group only.
• Database credentials are stored and retrieved through an approved secrets mechanism.
• The application uses the RDS endpoint DNS name.
• TLS certificate validation is configured and tested where required.
• Database user privileges follow least privilege.
• Connection pool sizing has been load-tested across all application instances.
• Database backups and restore procedures are tested.
• Monitoring and alerts cover both application and database health.
• Secrets and sensitive connection details are excluded from source control and logs.
• AWS costs, retention, and operational ownership have been reviewed.

Conclusion

Connecting Spring Boot to Amazon RDS PostgreSQL is more than adding a JDBC URL. Secure connectivity depends on private network placement, narrow security-group rules, managed credentials, TLS validation, sensible connection pooling, and monitoring. Treat the database as a protected dependency and validate the complete application-to-database path before production rollout.

AWS console labels, service options, and pricing can change. Check current AWS documentation and regional pricing before implementation.