Exporting Rds To S3
Export RDS or Aurora snapshots to S3 as Parquet for analytics, archival, or migration with correct IAM and KMS setup.
Overview
Exporting RDS to S3 is an agent skill for the Operate phase that guides snapshot export from RDS or Aurora to S3 in Parquet format with IAM, KMS, and verification steps.
Install
npx skills add https://github.com/aws/agent-toolkit-for-aws --skill exporting-rds-to-s3What is this skill?
- End-to-end SOP: snapshot identify/create through verified Parquet objects in S3
- IAM role and KMS encryption configuration with explicit required parameters
- Supports RDS DB instances and Aurora cluster identifiers by region
- Progress monitoring and verification steps for export tasks
- Output suited for Athena, Redshift Spectrum, and AWS Glue analytics paths
Adoption & trust: 892 installs on skills.sh; 819 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need RDS or Aurora data in S3 for analytics or backup but the IAM, KMS, snapshot, and export-task steps are easy to get wrong in one sitting.
Who is it for?
Indie SaaS operators on AWS who periodically dump production or reporting snapshots to S3 for Athena/Glue or cold storage.
Skip if: Greenfield app builders still choosing a database, or teams wanting continuous CDC/replication instead of snapshot-based export.
When should I use this skill?
User needs to export RDS or Aurora snapshots to S3 for analytics, backup archival, long-term storage, or data migration with full AWS workflow.
What do I get? / Deliverables
A completed, verified Parquet export in your S3 bucket with roles and encryption configured per the workflow you confirmed.
- Configured export task and Parquet objects in the specified S3 prefix
- Documented IAM/KMS and verification checklist from the SOP run
Recommended Skills
Journey fit
Operate is the right shelf because the SOP governs live AWS databases, snapshot exports, and long-term data placement in production accounts. Infra subphase reflects RDS/Aurora, S3, IAM roles, KMS keys, and export task orchestration—not app feature code.
How it compares
Opinionated AWS snapshot-export SOP—not a generic "dump MySQL to CSV" script or application-level backup plugin.
Common Questions / FAQ
Who is exporting-rds-to-s3 for?
Builders and operators managing RDS or Aurora in AWS who want agent-guided exports to S3 without missing IAM, KMS, or export-task details.
When should I use exporting-rds-to-s3?
During Operate when setting up analytics lakes, archival, migration extracts, or recurring snapshot exports from existing RDS/Aurora databases.
Is exporting-rds-to-s3 safe to install?
It implies AWS API access and IAM changes; review Prism Security Audits for the skill package and restrict credentials to least-privilege roles you approve.
SKILL.md
READMESKILL.md - Exporting Rds To S3
# Export RDS/Aurora to S3 ## Overview This SOP guides you through exporting Amazon RDS database snapshots or Aurora cluster snapshots to Amazon S3 for analytics, backup archival, long-term storage, or data migration purposes. AWS provides a native snapshot export feature that converts database snapshots to Apache Parquet format in S3, making the data accessible for analytics tools like Amazon Athena, Amazon Redshift Spectrum, and AWS Glue. The SOP handles the complete workflow including snapshot identification or creation, IAM role setup with proper permissions, KMS key configuration for encryption, S3 bucket preparation, export task initiation, progress monitoring, and verification of exported data. ## Parameters Prompt the user in a single message to provide all required parameters at once. Clearly list the required parameters and their descriptions, and include any optional parameters with their default values. Do not proceed until you have received and confirmed all required parameters. If any required parameter is missing or unclear, you MUST explicitly request the missing information before moving forward. - **database_identifier** (required): The RDS DB instance identifier or Aurora cluster identifier to export (e.g., "production-mysql", "analytics-aurora-cluster") - **region** (required): The AWS region where the database exists (e.g., "us-east-1", "eu-west-1") - **s3_bucket_name** (required): The S3 bucket name where exported data will be stored (e.g., "my-rds-exports") - **s3_prefix** (optional, default: "rds-exports/"): S3 prefix/folder for exported data (e.g., "rds-exports/", "backups/mysql/") - **export_type** (optional, default: "latest-snapshot"): Export source type ("latest-snapshot", "specific-snapshot", "create-new-snapshot") - **snapshot_identifier** (optional): Specific snapshot ID to export (required if export_type is "specific-snapshot") - **export_only_tables** (optional): Comma-separated list of specific tables to export (e.g., "schema1.table1,schema2.table2", exports all if not specified) - **iam_role_arn** (optional): Existing IAM role ARN with S3 and export permissions (will create if not provided) - **kms_key_id** (optional): KMS key ID for encrypting exported data in S3 (will use default S3 encryption if not provided) - **export_task_identifier** (optional): Custom identifier for the export task (auto-generated if not provided) Only proceed to the steps below if you have all required information. ## Steps ### 1. Verify Dependencies Check for required tools and warn the user if any are missing. **Constraints:** - You MUST verify the following tools are available in your context: - call_aws - You MUST ONLY check for tool existence and MUST NOT attempt to run the tools because running tools during verification could cause unintended side effects, consume resources unnecessarily, or trigger actions before the user is ready - You MUST inform the user about any missing tools with a clear message - You MUST ask if the user wants to proceed anyway despite missing tools - You MUST respect the user's decision to proceed or abort ### 2. Identify Database and Engine Type Verify the database exists and determine whether it's RDS or Aurora. **Constraints:** - You MUST first attempt to describe the database as an RDS instance: `aws rds describe-db-instances --db-instance-identifier ${database_identifier} --region ${region}` - You MUST check if the database is actually an Aurora cluster if the instance query fails: `aws rds describe-db-clusters --db-cluster-identifier ${database_identifier} --region ${region}` - You MUST extract critical information from the response: - Database engine type (mysql, postgres, mariadb, aurora-mysql, aurora-postgresql) - Engine version - Database status (must be "available" for snapshot operations) - Storage encrypted status - KMS key ID if encrypted - DB instance class or cluster size - Availability zone(s) - You MUST verify the database engine support