rds-db2

Provisions, connects, migrates, and operates Amazon RDS for Db2. Applies when provisioning with IBM customer and site IDs (License Manager, BYOL, GovCloud), connecting over TLS, fixing SQL30082N after Secrets Manager rotation, migration from Db2 LUW (Linux, AIX, Windows, AS400) or z/OS mainframe (AD

By aws · 3,362 installs

npx skills add aws/agent-toolkit-for-aws --skill rds-db2

Source repository · Upstream listing

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](references/provisioning.md) connect / SQL30082N / SQL1531N / DSN / CLP / Python / Java / CloudShell / airgap connectivity [connectivity.md](references/connectivity.md) SSL / TLS / GSKit / certificate / truststore / bundle.pem connectivity tls [connectivity tls.md](references/connectivity tls.md) Python driver / JDBC / laptop / multi instance / db2 use connection drivers [connection drivers.md](references/connection drivers.md) migrate / DMS / Q Replication / IIDR / AIX / Windows / AS400 / precheck migration [migration.md](references/migration.md) z/OS / mainframe / ADB2GEN / schema conversion mainframe migration [mainframe migration.md](references/mainframe migration.md) code page / collation / CCSID / EBCDIC / UTF 8 / CODEUNITS32 / territory code page & collation [code page collation.md](references/code page collation.md) snapshot / backup / restore / rollforward / PiTR / S3 integration backup restore [backup restore.md](references/backup restore.md) Multi AZ / standby replica / read replica / HADR / cross region / failover ha dr [ha dr.md](references/ha dr.md) parameter group / RDSADMIN / scale / storage / CloudWatch / registry variable operations [operations.md](references/operations.md) BYOK / customer managed KMS / bring your own key / imported key material / multi region key byok [byok kms.md](references/byok kms.md) Active Directory / Kerberos / domain join / self managed AD / kinit / SPN / realm ad kerberos [ad kerberos.md](references/ad kerberos.md) audit / DB2 AUDIT / audit policy / audit to S3 / option group db2 audit [db2 audit.md](references/db2 audit.md) minimum IAM / least privilege / IAM policy / trust policy / permissions minimum iam [minimum iam.md](references/minimum iam.md) colocation / co locate / EC2 app latency / ASG / ALB / failover routing colocation [colocation.md](references/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](scripts/db2 driver.sh), [db2client configure.sh](scripts/db2client configure.sh), [db2client airgap.sh](scripts/db2client airgap.sh), [functions.sh](scripts/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: 1. 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. 2. Source prerequisite: automated backups enabled on the source instance (backup retention period 0). 3. Target region prerequisite: custom parameter group created in the target region before the command runs. 4. Target region prerequisite: KMS key available in the target region (multi region KMS key or a target region customer managed KMS key). 5. State prerequisites: all databases in active state, no pending reboots , no license model restrictions blocking cross region replicas. 6. 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: 1. Attach IAM role with S3 access via aws rds add role to db instance using feature name S3 INTEGRATION . 2. Set restore performance parameters via rdsadmin.set configuration — tune USE STREAMING RESTORE , RESTORE DATABASE NUM BUFFERS , and PARALLELISM before starting the restore. 3. 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) .) 4. 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. 5. Monitor progress with rdsadmin.get task status — every rdsadmin procedure returns a task ID you poll. 6. 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 s