Amazon RDS for Db2

Overview

Amazon RDS for Db2 is a managed IBM Db2 LUW service. RDS for Db2 is managed — you cannot SSH to the host, install agents, or run unfenced external stored procedures in C/COBOL. Java stored procedures work via

sqlj.install_jar

. This skill covers the operator lifecycle: provisioning with IBM licensing, client install and TLS connectivity, migration from self-managed Db2 on Linux/AIX/Windows/z/OS/AS400, S3 backup and restore, Multi-AZ and cross-region standby replicas, and RDSADMIN stored procedures that replace SYSCTRL/SYSMAINT authority.

It also covers six additional security and operations areas: customer-managed KMS keys (BYOK), self-managed Active Directory with Kerberos authentication, Db2 audit to S3, code page and collation selection (EBCDIC, CCSID), minimum IAM permissions, and EC2/RDS colocation for Multi-AZ latency and failover.

The AWS MCP server is recommended but not required; all operations are expressed in AWS CLI syntax and run with or without it.

Routes to the matching sub-skill reference. Load only the matching reference.

Common Tasks

Verify Dependencies

Before executing an RDS for Db2 workflow, confirm required tools exist. Do not run installers or API calls yet.

AWS CLI v2 for every RDS API call
AWS credentials via managed mechanism (IAM role, instance profile,
```
ada credentials update
```
) — not pasted credentials
Client install:
```
bash
```
/
```
curl
```
access, run as root and as
```
db2inst1
```
Airgap install: internet-connected machine + target with VPC endpoints for S3, SSM, Secrets Manager
Mainframe migration: z/OS access, IBM ADB2GEN license, Python 3
BYOK / customer-managed KMS:
```
openssl
```
(to wrap imported key material) and
```
jq
```
(to parse
```
get-parameters-for-import
```
output)
Self-managed Active Directory + Kerberos:
```
realmd
```
,
```
sssd
```
,
```
adcli
```
,
```
krb5-workstation
```
on the client, plus a valid Kerberos ticket (
```
kinit
```
produces a TGT — check with
```
klist
```
)
Kerberos JDBC test: a JDK and the Db2 JDBC driver
```
db2jcc4.jar
```
v4.33+ (earlier driver versions lack
```
securityMechanism=11
```
Kerberos support)

Constraints:

The agent MUST check dependencies before running any install or AWS API command.
The agent MUST NOT prompt the user to paste credentials because credentials MUST flow through an IAM role or instance profile.
The agent MUST tell the user which dependencies are missing and MUST respect the user's decision to abort.
The agent MUST explain, for each step, what it does, why, and which tool will be invoked — before invoking it.

Classify and Route

Map the user's question to the correct sub-skill reference, then load only that file.

User says	Sub-skill	Load
create / provision / parameter group / IBM customer ID / IBM site ID / License Manager / BYOL / GovCloud	provisioning	provisioning.md
connect / SQL30082N / SQL1531N / DSN / CLP / Python / Java / CloudShell / airgap	connectivity	connectivity.md
SSL / TLS / GSKit / certificate / truststore / bundle.pem	connectivity-tls	connectivity-tls.md
Python driver / JDBC / laptop / multi-instance / db2_use	connection drivers	connection-drivers.md
migrate / DMS / Q Replication / IIDR / AIX / Windows / AS400 / precheck	migration	migration.md
z/OS / mainframe / ADB2GEN / schema conversion	mainframe-migration	mainframe-migration.md
code page / collation / CCSID / EBCDIC / UTF-8 / CODEUNITS32 / territory	code page & collation	code-page-collation.md
snapshot / backup / restore / rollforward / PiTR / S3 integration	backup-restore	backup-restore.md
Multi-AZ / standby replica / read replica / HADR / cross-region / failover	ha-dr	ha-dr.md
parameter group / RDSADMIN / scale / storage / CloudWatch / registry variable	operations	operations.md
BYOK / customer-managed KMS / bring your own key / imported key material / multi-region key	byok	byok-kms.md
Active Directory / Kerberos / domain join / self-managed AD / kinit / SPN / realm	ad-kerberos	ad-kerberos.md
audit / DB2_AUDIT / audit policy / audit to S3 / option group	db2-audit	db2-audit.md
minimum IAM / least privilege / IAM policy / trust policy / permissions	minimum-iam	minimum-iam.md
colocation / co-locate / EC2 app latency / ASG / ALB / failover routing	colocation	colocation.md

Constraints:

The agent MUST read only the reference files that match the user's question, to keep the context focused.
The agent MUST NOT invent RDSADMIN procedure signatures, because wrong parameter order will fail at runtime — always cite the signature from the reference file.
The agent MUST cite the source blog URL when an answer is blog-sourced, so the user can verify specifics.
If a question crosses two sub-skills (e.g. "migrate z/OS with near-zero downtime", or "BYOK plus cross-region standby"), the agent SHOULD load each matching reference and combine them.

Execute Workflow

Once routed, give the user a concrete, runnable answer grounded in the reference file.

Parameter acquisition:

All required parameters (region, instance identifier, source/target ARNs, S3 bucket, prefix, the
```
--master-username
```
value) MUST be collected upfront in a single message.
Parameter formats MUST be specified: region
```
us-east-1
```
-style; instance identifier
```
^[a-zA-Z][a-zA-Z0-9-]{0,62}$
```
; ARN
```
arn:aws:rds:<region>:<account>:db:<name>
```
; S3 bucket 3–63 chars lowercase.
The agent MUST accept parameters via direct input, a JSON/YAML file path, or a URL.

Tool use:

Use AWS CLI for RDS operations (example:

aws rds create-db-instance-read-replica --db-instance-identifier <name> --source-db-instance-identifier <arn> --replica-mode mounted --region <dr-region>

). Every operation is expressed in AWS CLI syntax so it runs whether or not the AWS MCP server is installed.

Use bundled scripts — db2-driver.sh, db2client-configure.sh, db2client-airgap.sh, functions.sh — instead of rewriting install steps.
Write migration plans, upgrade plans, validation reports to a local
```
artifacts/<app-name>/
```
directory created at runtime in the working directory (this is a run-time output location, not part of the shipped skill).

Constraints:

The agent MUST give exact CLI commands when behavior is deterministic, not descriptions like "enable Multi-AZ".
The agent MUST obtain AWS credentials through an IAM role or instance profile and MUST NOT prompt the user to paste credentials.
The agent MUST cite the source blog or documentation URL whenever the answer is sourced from published material, so the user can verify it.
The agent MUST write long-form artifacts to a local
```
artifacts/<app-name>/
```
directory (created at runtime in the working directory) so the workspace is inspectable.
When a requested action is unsupported on managed RDS for Db2, the agent MUST state the limitation plainly — no hedging like "limited support" or "with special config" — and offer a supported alternative (for example, unfenced C/COBOL stored procedures are not supported; rewrite them in Java via
```
sqlj.install_jar
```
, or in SQL PL).
The AWS MCP server is recommended but not required. When the MCP server is in use, prefer inline JSON strings over positional filesystem arguments with
```
call_aws
```
; this is guidance for the MCP path only, not a requirement. Never treat
```
call_aws
```
or
```
run_script
```
as the only way to perform an operation — the AWS CLI command always works on its own.

Resource tagging (always apply on resource creation)

When creating any RDS for Db2 resource (

create-db-instance

create-db-parameter-group

create-db-cluster

for Multi-AZ deployments,

create-db-instance-read-replica

for standby replicas), ALWAYS include these tags using the RDS list-of-records

--tags

syntax:

--tags Key=created_by,Value=rds-db2-skill Key=generation_model,Value={your-model-id}

Example:

--tags Key=created_by,Value=rds-db2-skill Key=generation_model,Value=claude-sonnet-4-20250514

The same convention applies to every resource this skill creates, including BYOK-encrypted instances (

create-db-instance --storage-encrypted --kms-key-id ...

), audit option groups (

create-option-group

), and customer-managed KMS keys (

kms create-key

, tagged with

--tags TagKey=created_by,TagValue=rds-db2-skill TagKey=generation_model,TagValue={your-model-id}

per the KMS tag syntax).

Include these tags even if the user does not mention tagging, so that they can identify the resources created via this skill. If the user provides additional tags, append these to their tags rather than replacing them. The same applies when tagging via

add-tags-to-resource

on existing resources.

RDS-managed facts the agent must always surface

These RDS-for-Db2-specific facts are what differentiates this skill from general IBM Db2 knowledge. General-Db2 answers typically omit the RDS-managed constraints (no unfenced C/COBOL, Secrets Manager rotation side effects,

rdsadmin.*

procedures) and the AWS-native migration tooling nuances (DMS z/OS limits, ADB2GEN vs SCT).

For "create cross-region standby replica for DR", you MUST tell the user ALL of the following six facts:

Use
aws rds create-db-instance-read-replica
with
```
--replica-mode mounted
```
and the cross-region source ARN — Db2 cross-region standby uses mounted replica mode, NOT transactional read-replica mode.
Source prerequisite: automated backups enabled on the source instance (backup retention period > 0).
Target-region prerequisite: custom parameter group created in the target region before the command runs.
Target-region prerequisite: KMS key available in the target region (multi-region KMS key or a target-region customer-managed KMS key).
State prerequisites: all databases in
active
state, no pending reboots, no license-model restrictions blocking cross-region replicas.
Explain the mounted-vs-transactional distinction — mounted replicas do not accept reads or SQL from applications; they exist purely as a DR standby that can be promoted. Do not suggest read offload use cases.

For "restore Db2 backup from S3 (multi-part, N files)", you MUST tell the user ALL of the following six facts — never omit any of the procedure names:

Attach IAM role with S3 access via
aws rds add-role-to-db-instance
using

--feature-name S3_INTEGRATION

Set restore performance parameters via
rdsadmin.set_configuration
— tune

USE_STREAMING_RESTORE

RESTORE_DATABASE_NUM_BUFFERS

, and

PARALLELISM

before starting the restore.

Call
rdsadmin.restore_database
with five parameters in this exact order: database name, restore mode (
```
OFFLINE
```
or
```
ONLINE
```
), S3 prefix, S3 bucket, and region. Multi-file (multi-part) backups are handled by the shared prefix — there is no separate multi-part flag parameter. (Signature:
```
rdsadmin.restore_database(dbname, type, prefix, bucket, region)
```
.)
For
ONLINE
restore mode, follow up with
rdsadmin.rollforward_database
to replay archive logs, then
```
rdsadmin.complete_rollforward
```
to finish.
```
OFFLINE
```
restores do NOT need rollforward.
Monitor progress with
rdsadmin.get_task_status
— every
```
rdsadmin
```
procedure returns a task ID you poll.
Warn about VPC endpoint for S3 if no internet egress from the private subnet, and warn about Db2 version compatibility between the source backup and the RDS instance engine version (forward-compatible, not backward).

For "C/COBOL unfenced external stored procedures — lift and shift to RDS for Db2?", you MUST tell the user ALL of the following four facts:

Unfenced external stored procedures in C and COBOL are NOT supported on RDS for Db2. State this as an unqualified "not supported" — do not hedge with "limited support" or "with special config."
All routines on RDS for Db2 MUST be fenced. This is a managed-service architectural constraint, not a flag.
Java stored procedures are supported — install via
```
sqlj.install_jar
```
. C/COBOL SPs should be rewritten in Java or SQL PL (Db2's procedural SQL, equivalent to Oracle's PL/SQL).
Offer to help identify which SPs are unfenced and prioritize the rewrite by call frequency (hot code path first).

For "migrate Db2 for z/OS to RDS for Db2 with near-zero downtime", you MUST tell the user ALL of the following five facts:

For near-zero-downtime from z/OS, use Q Replication (IBM IIDR), Qlik Replicate, or Precisely — these are the CDC tools that support Db2 for z/OS as a source streaming to RDS for Db2.
AWS DMS supports FULL LOAD ONLY from Db2 for z/OS. DMS does NOT support CDC from z/OS sources. Use DMS for a one-time bulk load, not for near-zero-downtime cutover.
Use ADB2GEN for schema conversion from z/OS. AWS SCT does NOT support Db2 for z/OS as a source — this is a common trap. Do not recommend SCT for z/OS sources.
Code-page conversion (EBCDIC → UTF-8) is the primary migration risk. Plan explicit collation and code page mapping before cutover — silent data corruption is the failure mode.
Plan explicit collation selection on the target RDS instance to match the semantic ordering of the z/OS source.

For "SQL30082N — USERNAME AND/OR PASSWORD INVALID" with RDS-managed master user (user didn't change it), you MUST tell the user ALL of the following four facts:

SQL30082N after a previously-working connection almost always means the master password rotated in Secrets Manager. RDS for Db2 rotates the master password on the Secrets Manager schedule — clients using a cached password will start failing with SQL30082N even though nothing on their side changed.
Fix: run
db2_use <instance-id>
(from
```
functions.sh
```
/ the bundled helpers). This fetches the current password from Secrets Manager and rewrites
```
~/.db2env
```
with the new value.
Alternative:
db2_test_connection
to verify the helper's fix worked end-to-end.
If
db2_use
isn't installed, the user needs to pull the current password with
```
aws secretsmanager get-secret-value
```
and update their local credential cache manually. Do not tell them to rotate the password — the password rotation is what caused the problem.

For "BYOK / customer-managed KMS key for RDS for Db2", you MUST tell the user ALL of the following six facts:

Use a multi-region KMS key with
--origin EXTERNAL
when importing your own key material, so the same key ID and material can replicate to a DR region.
The creating principal needs
kms:CreateGrant
and
kms:DescribeKey
on the key, or instance creation fails.
Encryption is set at instance creation with
```
--storage-encrypted --kms-key-id <alias|arn>
```
. You cannot encrypt an existing unencrypted instance in place — go snapshot →
```
copy-db-snapshot --kms-key-id
```
→
```
restore-db-instance-from-db-snapshot
```
.
For cross-region DR, replicate the multi-region key (
kms:ReplicateKey
) into the DR region first, then
```
copy-db-snapshot
```
across regions with the replica key.
Import tokens expire after 24 hours — if
```
import-key-material
```
fails on expiry, re-run
```
get-parameters-for-import
```
to get a fresh token and wrapping key.
Cite blog DBBLOG-5188 and byok-kms.md; do not invent KMS parameter names.

For "self-managed Active Directory with Kerberos on RDS for Db2", you MUST tell the user ALL of the following six facts:

RDS joins your AD via
--domain-fqdn
,
--domain-ou
,
--domain-auth-secret-arn
, and
--domain-dns-ips
— the self-managed AD path, with no AWS Managed Microsoft AD required.
The Secrets Manager secret uses keys
SELF_MANAGED_ACTIVE_DIRECTORY_USERNAME
(the sAMAccountName only — no
DOMAIN\
prefix, which fails creation) and
SELF_MANAGED_ACTIVE_DIRECTORY_PASSWORD
, encrypted by a dedicated KMS key, with a resource policy trusting
```
rds.amazonaws.com
```
guarded by
```
aws:SourceArn
```
and
```
aws:SourceAccount
```
(confused-deputy protection).
Delegate the nine AD permissions to a dedicated service account scoped to one OU; grant
```
servicePrincipalName
```
read/write on User objects using ADSI Edit, not the ADUC delegation wizard (which filters that attribute out) — this is the most common failure.
Open AD ports between RDS and the domain controllers: DNS 53, Kerberos 88 and 464, LDAP 389 and 3268, and the RPC range 49152–65535. Missing the RPC range is the top cause of intermittent join failures. Keep clock skew under 5 minutes.
The RDS master user is a local account that cannot get a Kerberos ticket. AD users need
```
kinit
```
plus a
```
GRANT CONNECT
```
. Kerberos JDBC uses
```
securityMechanism=11
```
and a region-specific PEM via
```
sslCertLocation
```
(never
```
global-bundle.pem
```
).
Cite the self-managed AD blog and ad-kerberos.md; verify with
```
describe-db-instances ... DomainMemberships
```
showing
```
Status: joined
```
.

Troubleshooting

Error	Cause	Fix
`SQL30082N`	Password rotated in Secrets Manager	Run `db2_use <instance-id>` — the helper re-fetches the current password and rewrites `~/.db2env` .
`SQL1531N`	DSN not yet in cache	`db2 terminate` to clear, then retry; if still failing, re-run db2client-configure.sh.
`SQL01013N` / TCP timeout	Security group blocks 50000/50443	Check SG inbound rules — add client's SG on TCP 50000 (plain) or 50443 (SSL).
GSKit / SSL certificate error	RDS cert bundle missing or RSA cert not first	Re-download `<region>-bundle.pem` from RDS truststore and re-run `db2client-configure.sh` .
Access denied on RDSADMIN call	IAM role missing `S3_INTEGRATION` feature	`aws rds add-role-to-db-instance --feature-name S3_INTEGRATION --role-arn <role-arn> --db-instance-identifier <id>` .
Restore fails with "database in rollforward pending"	ONLINE restore left DB in rollforward state	Call `rdsadmin.rollforward_database` for each archive log, then `rdsadmin.complete_rollforward` .
Standby replica creation fails	Missing prereqs	Verify: automated backups enabled, custom parameter group in DR region, KMS multi-region key, no pending `rdsadmin` tasks, all databases in active state.
AD domain join `Status` not `joined`	RPC port range blocked, wrong secret format, or SPN attribute missing	Open RPC 49152–65535 between RDS and the DCs, confirm the secret username is the sAMAccountName with no `DOMAIN\` prefix, and grant `servicePrincipalName` on User objects via ADSI Edit — see ad-kerberos.md.
`import-key-material` fails — token expired	Import token older than 24 hours	Re-run `get-parameters-for-import` for a fresh token and wrapping key, re-wrap the material with `openssl` , then retry the import — see byok-kms.md.
Throttling from RDS API	Exceeded API request rate	Exponential backoff with jitter; batch operations; check Service Quotas.

Security Considerations

Surface these controls when advising on any production RDS for Db2 deployment. They consolidate the security guidance that the sub-skill references cover in depth.

Encryption at rest and in transit — Always create instances with
```
--storage-encrypted
```
; for key ownership and compliance use a customer-managed KMS key (BYOK), and for DR use a multi-region key. Enforce TLS on every connection (port 50443,
```
<region>-bundle.pem
```
); never connect in plaintext for production. See byok-kms.md and connectivity-tls.md. (Guideline 1)
Least-privilege IAM — Use the scoped policy and trust policy in minimum-iam.md; never attach a
```
*FullAccess
```
managed policy. Scope
```
iam:PassRole
```
and ARN-pattern every mutating statement that supports resource-level permissions. (Guideline 5)
Network isolation — Keep instances in private subnets, restrict security groups to the application/source SG (never
```
0.0.0.0/0
```
), and use VPC endpoints for S3/SSM/Secrets Manager so traffic stays off the public internet. See colocation.md. (Guideline 5)
Audit logging and monitoring — Enable Db2 audit to S3 (db2-audit.md), RDS Enhanced Monitoring, and CloudTrail for RDS/KMS/Secrets Manager API calls. Alarm on failed logins and configuration changes. (Guideline 12)
Secret rotation — Provision with
```
--manage-master-user-password
```
so RDS stores and rotates the master password in Secrets Manager; never embed plaintext passwords. After rotation, refresh clients with
```
db2_use <instance-id>
```
. (Guideline 13)
Backup encryption and retention — Set a backup retention period, encrypt automated and manual snapshots with your KMS key, and apply S3 bucket encryption plus lifecycle/retention to any Db2 audit or backup buckets. (Guideline 13)

Additional Resources

In-scope documentation and blogs

AWS docs — RDS for Db2: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_RDSDb2.html
AWS docs — RDS for Db2 IAM permissions: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAM.html
AWS docs — Kerberos authentication for RDS for Db2: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/db2-kerberos.html
Blog — Connect to RDS for Db2 from CloudShell: https://aws.amazon.com/blogs/database/connect-to-amazon-rds-for-db2-using-aws-cloudshell/
Blog — Restore self-managed Db2 Linux into RDS for Db2: https://aws.amazon.com/blogs/database/restore-self-managed-db2-linux-databases-in-amazon-rds-for-db2/
Blog — Near-zero downtime from AIX/Windows to RDS for Db2 with Q Replication: https://aws.amazon.com/blogs/database/near-zero-downtime-migrations-from-self-managed-db2-on-aix-or-windows-to-amazon-rds-for-db2-using-ibm-q-replication/
Blog — Cross-region standby replicas: https://aws.amazon.com/blogs/database/configure-amazon-rds-for-db2-standby-replicas-for-high-availability-and-faster-disaster-recovery/
Blog — Mainframe DDL conversion (z/OS to RDS for Db2): https://aws.amazon.com/blogs/database/migrating-tables-from-ibm-db2-for-z-os-to-amazon-rds-for-db2/
Blog — Code page and collation for mainframe migration: https://aws.amazon.com/blogs/database/choosing-the-right-code-page-and-collation-for-migration-from-mainframe-db2-to-amazon-rds-for-db2/
Blog — Bring your own customer-managed KMS key for RDS for Db2 (DBBLOG-5188): https://aws.amazon.com/blogs/database/bring-your-own-key-to-amazon-rds-for-db2-with-a-customer-managed-kms-key/
Blog — Self-managed Active Directory with Kerberos for RDS for Db2: https://aws.amazon.com/blogs/database/use-kerberos-authentication-with-a-self-managed-active-directory-for-amazon-rds-for-db2/

Blog catalog

The authoritative list of published RDS for Db2 blogs and sample tools is maintained at https://github.com/aws-samples/sample-rds-db2-tools/tree/main — consult it for the current set of blog articles and companion code.

Related skill (migrating off Db2 LUW to PostgreSQL):
```
rds-postgres-migration
```
(if present in corpus).

Handoff from aws-database-selection

This skill can be invoked directly, or it can be entered from the

aws-database-selection

parent skill after that skill has run a requirements interview and produced a

requirements.json

artifact. When you see a backtick-wrapped path matching

aws_dbs_requirements/*/requirements.json

in recent conversation, follow the entry protocol in

aws-database-selection/references/handoff-contract.md

Read the artifact using
```
file_read
```
.
Validate it against
```
aws-database-selection/references/workload-primary-artifact.schema.json
```
. If malformed or unreadable, tell the user and proceed without it.
Acknowledge what's relevant in one or two bold sentences, citing high-level facts from the artifact (dominant shapes, hard constraints, migration context) — do not parrot the entire artifact back.
Scope-check: this skill is scoped to Amazon RDS for Db2 — migrations from Db2 z/OS or LUW, HADR, standby replicas, SQL PL routines, Q Replication cutovers. If the artifact's
```
workload_primaries.dominant_shapes
```
or
```
migration_context
```
don't match that scope, emit weak backpressure per the handoff contract: suggest
```
amazon-aurora
```
for refactor-to-PostgreSQL from Db2, or go back to
```
aws-database-selection
```
if Db2 isn't the source, then ask the user whether to go back or proceed anyway. Do not silently misuse the artifact.
Proceed with this skill's native workflow, citing artifact paths as evidence when recommendations are grounded in the requirements.

The curated RDS-for-Db2 selection facts that the parent

aws-database-selection

skill consumes live at

assets/selection-knowledge-input.json

(with a human-readable companion at

assets/selection-knowledge-input.md

). These capture the in-scope source-migration scenarios, hard constraints, HA/DR options, and security areas in a structured, reusable form — read them when you need the curated selection view rather than re-deriving it.

All user-facing output from this skill follows the markdown-primitives-only formatting convention in the handoff contract: bold labels, backticks for paths and enum values, bullet lists for alternatives, no ASCII art or box-drawing characters.

rds-db2

NPX Install

Tags

SKILL.md Content

Amazon RDS for Db2

Overview

Common Tasks

Verify Dependencies

Classify and Route

Execute Workflow

Resource tagging (always apply on resource creation)

RDS-managed facts the agent must always surface

Troubleshooting

Security Considerations

Additional Resources

In-scope documentation and blogs

Related topics (cited resources, not yet routed sub-skills)

Blog catalog

Handoff from aws-database-selection