Amazon RDS on AWS Outposts

You can use RDS on Outposts for managing databases that need to run on-premises for applications that need local access to the databases. This includes applications such as manufacturing equipment, IoT devices, etc. You can create and manage RDS databases running on Outposts using the same RDS console, APIs, and CLI.

Single-AZ instances support local data residency. You can configure Single-AZ instances to store all automated backups and logs directly on the AWS Outposts rack rather than in the AWS Region.

RDS on Outposts is available in all AWS Regions where AWS Outposts is supported.

Please refer to working with Amazon RDS on AWS Outposts documentation for all the supported database engines and most up-to-date list of supported versions.

Please see our working with Amazon RDS on AWS Outposts documentation for the latest list of supported instance types and sizes.

Yes, all database instances and snapshots are encrypted at rest on Outposts and in the AWS Region using the KMS key you provide.

Yes, RDS on AWS Outposts supports Multi-AZ across two Outposts each attached to a different AWS Availability Zone in the same Region.

Yes, RDS takes care of both OS and database engine patching with minimal downtime. Patching happens during a customer configurable maintenance window (30 min to 12 hours) or when you request an immediate patching action. When a patch becomes available, you may opt-in individual databases for immediate, next-window, or specified-date patching. You can also configure individual databases to automatically receive minor version upgrades as they become available.

Yes, RDS provides two different methods for backing up and restoring your DB instance(s): automated backups and database snapshots (DB Snapshots). RDS on Outposts supports storing your backups and logs either on your AWS Outposts or to the AWS Region. You will need networking connectivity between your Outposts and the AWS Region to back up or restore your database.

When automated backups are turned on for your DB instance, RDS automatically performs a full daily snapshot of your data (during your preferred backup window) and captures transaction logs (as updates to your DB instance are made). RDS retains backups of a DB instance for a limited, user-specified period of time called the retention period, which by default is 7 days but can be set to up to 35 days.

DB snapshots are user-initiated and can be initiated at any time from the console, via CreateDBSnapshot API, or create-db-snapshot command. Snapshots are kept until you explicitly delete them.

You can restore a DB instance from a DB snapshot either on an existing Outpost, another Outpost in the same Region and account, or in the AWS Region.

The physical Outpost rack must support the same EC2 instance family and generation that you intend to use for your corresponding RDS database. RDS on Outposts also requires a reliable network connection to the AWS Region from your Outposts.

Before you create an RDS on Outposts DB instance, you need to create a DB subnet group that includes one subnet that is associated with your Outpost. When you create a RDS on Outposts DB instance, specify this DB subnet group. An example is below:

create-db-subnet-group:

aws rds create-db-subnet-group 
--db-subnet-group-name outposts-rds-sg 
--db-subnet-group-description poc 
--subnet-ids <outpost-subnet>

create-db-instance:

aws rds create-db-instance 
--db-instance-identifier outpost-instance 
--engine mysql 
--engine-version 8.0.17 
--db-instance-class db.m5.large 
--master-username master 
--master-user-password password 
--allocated-storage 20 
--db-subnet-group-name outpost-rds-sg 
--storage-type gp2 
​​​​​​​--storage-encrypted

You can use AWS CLI command modify-db-instance to scale your database instances. RDS on Outposts will support this operation on the available capacity of the AWS Outpost.

When network connectivity to the AWS Region goes down, your database continues to run locally. You cannot create new databases or take new actions on the existing database. Automatic backups will also not trigger at that particular interval while connectivity is not available. In the case of database failures, the database will not be automatically replaced until the connectivity is restored. Once connectivity is restored Single-AZ instances will be rebooted. Depending on the circumstances, Multi-AZ instances may perform a failover. We recommend you restore network connectivity as soon as possible.