/rds-db2

RDS for Db2 — Connectivity Reference

Installing the IBM Db2 client and connecting to RDS for Db2 from CloudShell, EC2, or laptop. The db2-driver.sh / db2client-configure.sh scripts automate install and DSN setup for online and airgap (private-subnet) deployments.

Source blog: https://aws.amazon.com/blogs/database/connect-to-amazon-rds-for-db2-using-aws-cloudshell/

VPC requirements

• RDS for Db2 lives in a VPC (not publicly accessible by default).
• Security group inbound: TCP 50000 (plain), 50443 (SSL, controlled by ssl_svcename).
• CloudShell MUST use a VPC environment (Actions → Create VPC Environment) in the same subnet/AZ as the RDS instance.
• EC2 clients: same VPC or peered VPC, with routing and SG rules.
• Private subnet: use airgap flow + VPC endpoints for S3, SSM, Secrets Manager.

Install — online mode

Works from EC2 or CloudShell with internet.

Step 1 — Download the installer scripts:

curl -sL https://bit.ly/getdb2driver | bash

Writes db2-driver.sh (RT client installer) and db2client-airgap.sh (airgap bundler) to the current directory.

Step 2 — Install the RT client (run as root or ec2-user):

REGION=us-east-1 ./db2-driver.sh                     # Db2 11.5 (default)
DB2_VER=12.1 REGION=us-east-1 ./db2-driver.sh        # Db2 12.1

DB2_VER defaults to 11.5. On completion the script prints the next command.

Step 3 — Configure DSN entries (as db2inst1):

sudo su - db2inst1
REGION=us-east-1 source db2client-configure.sh
# Or target a specific instance:
DB_INSTANCE_ID=my-db2-instance REGION=us-east-1 source db2client-configure.sh

Step 4 — Activate helper functions:

source ~/.bashrc
db2_help

source ~/functions.sh is added to ~/.bashrc automatically during configure.

Install — airgap mode

Private subnet with no internet. Artifacts staged in S3.

Step 1 — On internet-connected machine, download:

curl -sL https://bit.ly/getdb2driver | bash
./db2client-airgap.sh --mode download --region <region>
# Or for Db2 12.1:
DB2_VER=12.1 ./db2client-airgap.sh --mode download --region <region>

Produces ./db2client-artifacts/{scripts,drivers,ssl}/.

Step 2 — On AWS-configured machine, upload to S3:

./db2client-airgap.sh --mode upload --region <region>

Creates db2client-artifacts-<account-id>-<region>, uploads all artifacts, verifies every file, prints target-machine commands.

Step 3 — On target (private subnet, AWS configured):

aws s3 cp s3://db2client-artifacts-<account>-<region>/db2-driver.sh . && chmod +x db2-driver.sh
export BUCKET=db2client-artifacts-<account>-<region> REGION=<region>
./db2-driver.sh                      # Db2 11.5
# DB2_VER=12.1 ./db2-driver.sh       # Db2 12.1

Step 4 — Configure DSNs (as db2inst1):

sudo su - db2inst1
BUCKET=db2client-artifacts-<account>-<region> REGION=<region> source db2client-configure.sh
source ~/.bashrc

Reach EC2 via SSM: aws ssm start-session --target <ec2-instance-id> --region <region>.

What db2client-configure.sh creates

DSN entries in db2dsdriver.cfg:

Files written:

Connecting

db2 terminate
cat ~/CONN_HELP_README.txt
db2 "connect to RDSAT user admin using '$MASTER_USER_PASSWORD'"
db2 "connect to RDSAS user admin using '$MASTER_USER_PASSWORD'"
db2 connect reset && db2 terminate

Single quotes around $MASTER_USER_PASSWORD protect special characters (!, >, <, $).

Security considerations

• Passwords in shell history. db2 connect ... using '<password>' writes the password into shell history and the process list. Prefer db2_connect / db2_use, which read the password from ~/.db2env (env var, not a literal argument). If you must type a literal password, clear it from history afterward (history -d <n> or unset HISTFILE for the session).
• Prefer Secrets Manager. Provision with --manage-master-user-password so RDS stores and rotates the master password in Secrets Manager; db2_use fetches the current value automatically after each rotation.
• ~/.need_password is dev/test only. A plaintext password file is never acceptable for production. When used for local dev/test it must be chmod 600 and must never be committed to source control or shared.
• Use SSL DSNs (50443). Prefer the *S / *SK (SSL) DSNs over plain TCP (50000) so credentials and data are encrypted in transit. See connectivity-tls.md for certificate setup.
• Never log credentials. Do not log full connection strings, DSN parameters, or password values in application or diagnostic logs. Use structured logging and mask password fields before writing to CloudWatch Logs or any log sink.

Helper functions (source ~/functions.sh)

db2_test_connection decodes these:

For SSL/TLS, GSKit, and certificate setup, see connectivity-tls.md.

Manual password file (~/.need_password)

Warning — dev/test only. A plaintext password file is NEVER acceptable for production. For any production or shared instance use --manage-master-user-password so RDS stores and rotates the master password in Secrets Manager; db2_use then fetches it automatically. The ~/.need_password fallback exists solely for local dev/test instances that are not integrated with Secrets Manager, and must be chmod 600 and never committed to source control or shared.

If not using Secrets Manager:

vi ~/.need_password && chmod 600 ~/.need_password
# Format — one line per instance:
# end-to-end-trust  MyP@ssw0rd!
# trp-test-by-ibm   An0therP@ss#

Troubleshooting

Full diagnostics: db2_test_connection / db2_test_connection RDSAS.

Find Db2 version:

aws rds describe-db-instances --db-instance-identifier <id> \
  --query 'DBInstances[0].EngineVersion' --output text

SELECT SERVICE_LEVEL FROM TABLE(SYSPROC.ENV_GET_INST_INFO()) AS T

For Python/Java drivers, Kerberos/AD, MacBook laptop, and multi-instance workflow, see connection-drivers.md.