# Amazon RDS on AWS Outposts Amazon RDS on AWS Outposts extends RDS for SQL Server, RDS for MySQL, RDS for PostgreSQL, and RDS for Oracle databases to AWS Outposts Rack Gen1 and Gen2 environments. AWS Outposts uses the same hardware as in public AWS Regions to bring AWS services, infrastructure, and operation models on-premises. With RDS on Outposts, you can provision managed DB instances close to the business applications that must run on-premises. For more information about AWS Outposts, see the [AWS Outposts documentation](https://docs.aws.amazon.com/outposts/) and the [AWS Outposts product page](https://aws.amazon.com/outposts/). You use the same AWS Management Console, AWS CLI, and RDS API to provision and manage on-premises RDS on Outposts DB instances as you do for RDS DB instances running in the AWS Cloud. RDS on Outposts automates tasks, such as database provisioning, operating system and database patching, backup, and long-term archival in Amazon S3. RDS on Outposts supports automated backups of DB instances. Network connectivity between your Outpost and your AWS Region is required to back up and restore DB instances. All DB snapshots and transaction logs from an Outpost are stored in your AWS Region. From your AWS Region, you can restore a DB instance from a DB snapshot to a different Outpost. For more information, see [Introduction to backups](USER_WorkingWithAutomatedBackups.md). RDS on Outposts supports automated maintenance and upgrades of DB instances. For more information, see [Maintaining a DB instance](USER_UpgradeDBInstance.Maintenance.md). RDS on Outposts uses encryption at rest for DB instances and DB snapshots using your AWS KMS key. For more information about encryption at rest, see [Encrypting Amazon RDS resources](Overview.Encryption.md). By default, EC2 instances in Outposts subnets can use the Amazon Route 53 DNS Service to resolve domain names to IP addresses. You might encounter longer DNS resolution times with Route 53, depending on the path latency between your Outpost and the AWS Region. In such cases, you can use the DNS servers installed locally in your on-premises environment. For more information, see [DNS](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-networking-components.html#dns) in the *AWS Outposts User Guide*. When network connectivity to the AWS Region isn't available, your DB instance continues to run locally. You can continue to access DB instances using DNS name resolution by configuring a local DNS server as a secondary server. However, you can't create new DB instances or modify existing DB instances. Automatic backups don't occur when there is no connectivity. If there is a DB instance failure, the DB instance isn't automatically replaced until connectivity is restored. We recommend restoring network connectivity as soon as possible. **Topics** + [ ## Prerequisites for Amazon RDS on AWS Outposts ](#rds-on-outposts.prerequisites) + [ # Amazon RDS on AWS Outposts support for Amazon RDS features ](rds-on-outposts.features.md) + [ # Supported DB instance classes for Amazon RDS on AWS Outposts ](rds-on-outposts.db-instance-classes.md) + [ # Customer-owned IP addresses for Amazon RDS on AWS Outposts ](rds-on-outposts.coip.md) + [ # Working with Multi-AZ deployments for Amazon RDS on AWS Outposts ](rds-on-outposts.maz.md) + [ # Creating DB instances for Amazon RDS on AWS Outposts ](rds-on-outposts.creating.md) + [ # Creating read replicas for Amazon RDS on AWS Outposts ](rds-on-outposts.rr.md) + [ # Considerations for restoring DB instances on Amazon RDS on AWS Outposts ](rds-on-outposts.restoring.md) ## Prerequisites for Amazon RDS on AWS Outposts The following are prerequisites for using Amazon RDS on AWS Outposts: + Install AWS Outposts in your on-premises data center. For more information, see [Installing an AWS Outposts server](https://docs.aws.amazon.com/outposts/latest/install-server/install-server.html) in the *AWS Outposts Server installation guide*. + Make sure that you have at least one subnet available for RDS on Outposts. You can use the same subnet for other workloads. + Make sure that you have a reliable network connection between your Outpost and an AWS Region. # Amazon RDS on AWS Outposts support for Amazon RDS features The following table describes the Amazon RDS features supported by Amazon RDS on AWS Outposts. | Feature | Supported | Notes | More information | | --- | --- | --- | --- | | DB instance provisioning | Yes | You can only create DB instances for RDS for SQL Server, RDS for MySQL, RDS for PostgreSQL, or RDS for Oracle DB engines. The following versions are supported: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-on-outposts.features.html) | [Creating DB instances for Amazon RDS on AWS Outposts](rds-on-outposts.creating.md) | | Connect to a Microsoft SQL Server DB instance with Microsoft SQL Server Management Studio | Yes | Some TLS versions and encryption ciphers might not be secure. To turn them off, follow the instructions in [Configuring SQL Server security protocols and ciphers](SQLServer.Ciphers.md). | [Connecting to your Microsoft SQL Server DB instance](USER_ConnectToMicrosoftSQLServerInstance.md) | | Modifying the master user password | Yes | None | [Modifying an Amazon RDS DB instance](Overview.DBInstance.Modifying.md) | | Renaming a DB instance | Yes | None | [Modifying an Amazon RDS DB instance](Overview.DBInstance.Modifying.md) | | Rebooting a DB instance | Yes | None | [Rebooting a DB instance](USER_RebootInstance.md) | | Stopping a DB instance | Yes | None | [Stopping an Amazon RDS DB instance temporarily](USER_StopInstance.md) | | Starting a DB instance | Yes | None | [Starting an Amazon RDS DB instance that was previously stopped](USER_StartInstance.md) | | Multi-AZ deployments | Yes | Multi-AZ deployments are supported on MySQL, PostgreSQL, and Oracle DB instances. Multi-AZ deployments do not support Direct VPC Routing (DVR). | [Creating DB instances for Amazon RDS on AWS Outposts](rds-on-outposts.creating.md) [Configuring and managing a Multi-AZ deployment for Amazon RDS](Concepts.MultiAZ.md) | | DB parameter groups | Yes | None | [Parameter groups for Amazon RDS](USER_WorkingWithParamGroups.md) | | Read replicas | Yes | Read replicas are supported for MySQL, PostgreSQL, and Oracle DB instances. Read replicas do not support Direct VPC Routing (DVR). | [Creating read replicas for Amazon RDS on AWS Outposts](rds-on-outposts.rr.md) | | Encryption at rest | Yes | RDS on Outposts doesn't support unencrypted DB instances. | [Encrypting Amazon RDS resources](Overview.Encryption.md) | | AWS Identity and Access Management (IAM) database authentication | No | None | [IAM database authentication for MariaDB, MySQL, and PostgreSQL](UsingWithRDS.IAMDBAuth.md) | | Associating an IAM role with a DB instance | No | None | [add-role-to-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/add-role-to-db-instance.html) AWS CLI command [AddRoleToDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_AddRoleToDBInstance.html) RDS API operation | | Kerberos authentication | No | None | [Kerberos authentication](database-authentication.md#kerberos-authentication) | | Tagging Amazon RDS resources | Yes | None | [Tagging Amazon RDS resources](USER_Tagging.md) | | Option groups | Yes | The following RDS for Oracle options are not supported: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-on-outposts.features.html) | [Working with option groups](USER_WorkingWithOptionGroups.md) | | Modifying the maintenance window | Yes | None | [Maintaining a DB instance](USER_UpgradeDBInstance.Maintenance.md) | | Automatic minor version upgrade | Yes | None | [Automatically upgrading the minor engine version](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.AutoMinorVersionUpgrades) | | Modifying the backup window | Yes | None | [Introduction to backups](USER_WorkingWithAutomatedBackups.md) [Modifying an Amazon RDS DB instance](Overview.DBInstance.Modifying.md) | | Changing the DB instance class | Yes | None | [Modifying an Amazon RDS DB instance](Overview.DBInstance.Modifying.md) | | Changing the allocated storage | Yes | None | [Modifying an Amazon RDS DB instance](Overview.DBInstance.Modifying.md) | | Storage autoscaling | Yes | None | [Managing capacity automatically with Amazon RDS storage autoscaling](USER_PIOPS.Autoscaling.md) | | Manual and automatic DB instance snapshots | Yes | You can store automated backups and manual snapshots in your AWS Region. Or you can store them locally on your Outpost. Local backups are supported on MySQL, PostgreSQL, and Oracle DB instances. To store backups on your Outpost, make sure that you have Amazon S3 on Outposts configured. Local backups are not supported for Multi-AZ instance deployments. | [Creating DB instances for Amazon RDS on AWS Outposts](rds-on-outposts.creating.md) [Amazon S3 on Outposts](https://aws.amazon.com/s3/outposts/) [Creating a DB snapshot for a Single-AZ DB instance for Amazon RDS](USER_CreateSnapshot.md) | | Restoring from a DB snapshot | Yes | You can store automated backups and manual snapshots for the restored DB instance in the parent AWS Region or locally on your Outpost. | [Considerations for restoring DB instances on Amazon RDS on AWS Outposts](rds-on-outposts.restoring.md) [Restoring to a DB instance](USER_RestoreFromSnapshot.md) | | Restoring a DB instance from Amazon S3 | No | None | [Restoring a backup into an Amazon RDS for MySQL DB instance](MySQL.Procedural.Importing.md) | | Exporting snapshot data to Amazon S3 | No | None | [Exporting DB snapshot data to Amazon S3 for Amazon RDS](USER_ExportSnapshot.md) | | Point-in-time recovery | Yes | You can store automated backups and manual snapshots for the restored DB instance in the parent AWS Region or locally on your Outpost, with one exception. | [Considerations for restoring DB instances on Amazon RDS on AWS Outposts](rds-on-outposts.restoring.md) [Restoring a DB instance to a specified time for Amazon RDS](USER_PIT.md) | | Enhanced monitoring | No | None | [Monitoring OS metrics with Enhanced Monitoring](USER_Monitoring.OS.md) | | Amazon CloudWatch monitoring | Yes | You can view the same set of metrics that are available for your databases in the AWS Region. | [Monitoring Amazon RDS metrics with Amazon CloudWatch](monitoring-cloudwatch.md) | | Publishing database engine logs to CloudWatch Logs | Yes | None | [Publishing database logs to Amazon CloudWatch Logs](USER_LogAccess.Procedural.UploadtoCloudWatch.md) | | Event notification | Yes | None | [Working with Amazon RDS event notification](USER_Events.md) | | Amazon RDS Performance Insights | No | None | [Monitoring DB load with Performance Insights on Amazon RDS](USER_PerfInsights.md) | | Viewing or downloading database logs | No | RDS on Outposts doesn't support viewing database logs using the console or describing database logs using the AWS CLI or RDS API. RDS on Outposts doesn't support downloading database logs using the console or downloading database logs using the AWS CLI or RDS API. | [Monitoring Amazon RDS log files](USER_LogAccess.md) | | Amazon RDS Proxy | No | None | [Amazon RDS Proxy](rds-proxy.md) | | Stored procedures for Amazon RDS for MySQL | Yes | None | [RDS for MySQL stored procedure reference](Appendix.MySQL.SQLRef.md) | | Replication with external databases for RDS for MySQL | No | None | [Configuring binary log file position replication with an external source instance](MySQL.Procedural.Importing.External.Repl.md) | | Native backup and restore for Amazon RDS for Microsoft SQL Server | Yes | None | [Importing and exporting SQL Server databases using native backup and restore](SQLServer.Procedural.Importing.md) | # Supported DB instance classes for Amazon RDS on AWS Outposts Amazon RDS on AWS Outposts supports the following DB instance classes: + General purpose DB instance classes + db.m7i.48xlarge + db.m7i.24xlarge + db.m7i.16xlarge + db.m7i.12xlarge + db.m7i.8xlarge + db.m7i.4xlarge + db.m7i.2xlarge + db.m7i.xlarge + db.m7i.large + db.m5.24xlarge + db.m5.16xlarge + db.m5.12xlarge + db.m5.8xlarge + db.m5.4xlarge + db.m5.2xlarge + db.m5.xlarge + db.m5.large + Memory optimized DB instance classes + db.r7i.48xlarge + db.r7i.24xlarge + db.r7i.16xlarge + db.r7i.12xlarge + db.r7i.8xlarge + db.r7i.4xlarge + db.r7i.2xlarge + db.r7i.xlarge + db.r7i.large + db.r5.24xlarge + db.r5.16xlarge + db.r5.12xlarge + db.r5.8xlarge + db.r5.4xlarge + db.r5.2xlarge + db.r5.xlarge + db.r5.large Depending on how you've configured your Outpost, you might not have all of these classes available. For example, if you haven't purchased the db.r5 classes for your Outpost, you can't use them with RDS on Outposts. Only general purpose SSD storage is supported for RDS on Outposts DB instances. For more information about DB instance classes, see [DB instance classes](Concepts.DBInstanceClass.md). Amazon RDS manages maintenance and recovery for your DB instances and requires active capacity on the Outpost to do so. We recommend that you configure N\$11 EC2 instances for each DB instance class in your production environments. RDS on Outposts can use the extra capacity of these EC2 instances for maintenance and repair operations. For example, if your production environments have 3 db.m5.large and 5 db.r5.xlarge DB instance classes, then we recommend that they have at least 4 m5.large EC2 instances and 6 r5.xlarge EC2 instances. For more information, see [Resilience in AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/disaster-recovery-resiliency.html) in the *AWS Outposts User Guide*. # Customer-owned IP addresses for Amazon RDS on AWS Outposts Amazon RDS on AWS Outposts uses information that you provide about your on-premises network to create an address pool. This pool is known as a *customer-owned IP address pool* (CoIP pool). *Customer-owned IP addresses* (CoIPs) provide local or external connectivity to resources in your Outpost subnets through your on-premises network. For more information about CoIPs, see [Customer-owned IP addresses](https://docs.aws.amazon.com/outposts/latest/userguide/routing.html#ip-addressing) in the *AWS Outposts User Guide*. Each RDS on Outposts DB instance has a private IP address for traffic inside its virtual private cloud (VPC). This private IP address isn't publicly accessible. You can use the **Public** option to set whether the DB instance also has a public IP address in addition to the private IP address. Using the public IP address for connections routes them through the internet and can result in high latencies in some cases. Instead of using these private and public IP addresses, RDS on Outposts supports using CoIPs for DB instances through their subnets. When you use a CoIP for an RDS on Outposts DB instance, you connect to the DB instance with the DB instance endpoint. RDS on Outposts then automatically uses the CoIP for all connections from both inside and outside of the VPC. CoIPs can provide the following benefits for RDS on Outposts DB instances: + Lower connection latency + Enhanced security ## Using CoIPs You can turn CoIPs on or off for an RDS on Outposts DB instance using the AWS Management Console, the AWS CLI, or the RDS API: + With the AWS Management Console, choose the **Customer-owned IP address (CoIP)** setting in **Access type** to use CoIPs. Choose one of the other settings to turn them off. ![\[The Customer-owned IP address (CoIP) setting in the AWS Management Console.\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/outpost-coip.png) + With the AWS CLI, use the `--enable-customer-owned-ip | --no-enable-customer-owned-ip` option. + With the RDS API, use the `EnableCustomerOwnedIp` parameter. You can turn CoIPs on or off when you perform any of the following actions: + Create a DB instance For more information, see [Creating DB instances for Amazon RDS on AWS Outposts](rds-on-outposts.creating.md). + Modify a DB instance For more information, see [Modifying an Amazon RDS DB instance](Overview.DBInstance.Modifying.md). + Create a read replica For more information, see [Creating read replicas for Amazon RDS on AWS Outposts](rds-on-outposts.rr.md). + Restore a DB instance from a snapshot For more information, see [Restoring to a DB instance](USER_RestoreFromSnapshot.md). + Restore a DB instance to a specified time For more information, see [Restoring a DB instance to a specified time for Amazon RDS](USER_PIT.md). **Note** In some cases, you might turn on CoIPs for a DB instance but Amazon RDS isn't able to allocate a CoIP for the DB instance. In such cases, the DB instance status is changed to **incompatible-network**. For more information about the DB instance status, see [Viewing Amazon RDSDB instance status](accessing-monitoring.md#Overview.DBInstance.Status). ## Limitations The following limitations apply to CoIP support for RDS on Outposts DB instances: + When using a CoIP for a DB instance, make sure that public accessibility is turned off for that DB instance. + Make sure that the inbound rules for your VPC security groups include the CoIP address range (CIDR block). For more information about setting up security groups, see [Provide access to your DB instance in your VPC by creating a security group](CHAP_SettingUp.md#CHAP_SettingUp.SecurityGroup). + You can't assign a CoIP from a CoIP pool to a DB instance. When you use a CoIP for a DB instance, Amazon RDS automatically assigns a CoIP from a CoIP pool to the DB instance. + You must use the AWS account that owns the Outpost resources (owner) or share the following resources with other AWS accounts (consumers) in the same organization: + The Outpost + The local gateway (LGW) route table for the DB instance's VPC + The CoIP pool or pools for the LGW route table For more information, see [ Working with shared AWS Outposts resources](https://docs.aws.amazon.com/outposts/latest/userguide/sharing-outposts.html) in the *AWS Outposts User Guide*. # Working with Multi-AZ deployments for Amazon RDS on AWS Outposts For Multi-AZ deployments, Amazon RDS creates a primary DB instance on one AWS Outpost. RDS synchronously replicates the data to a standby DB instance on a different Outpost. Multi-AZ deployments on AWS Outposts operate like Multi-AZ deployments in AWS Regions, but with the following differences: + They require a local connection between two or more Outposts. + They require customer-owned IP (CoIP) pools. For more information, see [Customer-owned IP addresses for Amazon RDS on AWS Outposts](rds-on-outposts.coip.md). + Replication runs on your local network. Multi-AZ on AWS Outposts is available for all supported versions of MySQL, PostgreSQL, and Oracle on RDS on Outposts. Local backups aren't supported for Multi-AZ deployments. For more information, see [Creating DB instances for Amazon RDS on AWS Outposts](rds-on-outposts.creating.md). ## Working with the shared responsibility model Although AWS uses commercially reasonable efforts to provide DB instances configured for high availability, the availability uses a shared responsibility model. The ability of RDS on Outposts to fail over and repair DB instances requires each of your Outposts to be connected to its AWS Region. RDS on Outposts also requires connectivity between the Outpost that is hosting the primary DB instance and the Outpost that is hosting the standby DB instance for synchronous replication. Any impact to this connection can prevent RDS on Outposts from performing a failover. You might see elevated latencies for a standard DB instance deployment as a result of the synchronous data replication. The bandwidth and latency of the connection between the Outpost hosting the primary DB instance and the Outpost hosting the standby DB instance directly affect latencies. For more information, see [Prerequisites](#rds-on-outposts.maz.prereqs). ## Improving availability We recommend the following actions to improve availability: + Allocate enough additional capacity for your mission-critical applications to allow recovery and failover if there is an underlying host issue. This applies to all Outposts that contain subnets in your DB subnet group. For more information, see [Resilience in AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/disaster-recovery-resiliency.html). + Provide redundant network connectivity for your Outposts. + Use more than two Outposts. Having more than two Outposts allows Amazon RDS to recover a DB instance. RDS does this recovery by moving the DB instance to another Outpost if the current Outpost experiences a failure. + Provide dual power sources and redundant network connectivity for your Outpost. We recommend the following for your local networks: + The round trip time (RTT) latency between the Outpost hosting your primary DB instance and the Outpost hosting your standby DB instance directly affects write latency. Keep the RTT latency between the AWS Outposts in the low single-digit milliseconds. We recommend not more than 5 milliseconds, but your requirements might vary. You can find the net impact to network latency in the Amazon CloudWatch metrics for `WriteLatency`. For more information, see [Amazon CloudWatch metrics for Amazon RDS](rds-metrics.md). + The availability of the connection between the Outposts affects the overall availability of your DB instances. Have redundant network connectivity between the Outposts. ## Prerequisites Multi-AZ deployments on RDS on Outposts have the following prerequisites: + Have at least two Outposts, connected over local connections and attached to different Availability Zones in an AWS Region. + Make sure that your DB subnet groups contain the following: + At least two subnets in at least two Availability Zones in a given AWS Region. + Subnets only in Outposts. + At least two subnets in at least two Outposts within the same virtual private cloud (VPC). + Associate your DB instance's VPC with all of your local gateway route tables. This association is necessary because replication runs over your local network using your Outposts' local gateways. For example, suppose that your VPC contains subnet-A in Outpost-A and subnet-B in Outpost-B. Outpost-A uses LocalGateway-A (LGW-A), and Outpost-B uses LocalGateway-B (LGW-B). LGW-A has RouteTable-A, and LGW-B has RouteTable-B. You want to use both RouteTable-A and RouteTable-B for replication traffic. To do this, associate your VPC with both RouteTable-A and RouteTable-B. For more information about how to create an association, see the Amazon EC2 [create-local-gateway-route-table-vpc-association](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-local-gateway-route-table-vpc-association.html) AWS CLI command. + Make sure that your Outposts use customer-owned IP (CoIP) routing. Each route table must also each have at least one address pool. Amazon RDS allocates an additional IP address each for the primary and standby DB instances for data synchronization. + Make sure that the AWS account that owns the RDS DB instances owns the local gateway route tables and CoIP pools. Or make sure it's part of a Resource Access Manager share with access to the local gateway route tables and CoIP pools. + Make sure that the IP addresses in your CoIP pools can be routed from one Outpost local gateway to the others. + Make sure that the VPC's CIDR blocks (for example, 10.0.0.0/4) and your CoIP pool CIDR blocks don't contain IP addresses from Class E (240.0.0.0/4). RDS uses these IP addresses internally. + Make sure that you correctly set up outbound and related inbound traffic. RDS on Outposts establishes a virtual private network (VPN) connection between the primary and standby DB instances. For this to work correctly, your local network must allow outbound and related inbound traffic for Internet Security Association and Key Management Protocol (ISAKMP). It does so using User Datagram Protocol (UDP) port 500 and IP Security (IPsec) Network Address Translation Traversal (NAT-T) using UDP port 4500. For more information on CoIPs, see [Customer-owned IP addresses for Amazon RDS on AWS Outposts](rds-on-outposts.coip.md) in this guide, and [Customer-owned IP addresses](https://docs.aws.amazon.com/outposts/latest/userguide/how-racks-work.html#ip-addressing) in the *AWS Outposts User Guide*. ## Working with API operations for Amazon EC2 permissions Regardless of whether you use CoIPs for your DB instance on AWS Outposts, RDS requires access to your CoIP pool resources. RDS can call the following EC2 permissions API operations for CoIPs on your behalf for Multi-AZ deployments: + `CreateCoipPoolPermission` – When you create a Multi-AZ DB instance on RDS on Outposts + `DeleteCoipPoolPermission` – When you delete a Multi-AZ DB instance on RDS on Outposts These API operations grant to, or remove from, internal RDS accounts the permission to allocate elastic IP addresses from the CoIP pool specified by the permission. You can view these IP addresses using the `DescribeCoipPoolUsage` API operation. For more information on CoIPs, see [Customer-owned IP addresses for Amazon RDS on AWS Outposts](rds-on-outposts.coip.md) and [Customer-owned IP addresses](https://docs.aws.amazon.com/outposts/latest/userguide/how-racks-work.html#ip-addressing) in the *AWS Outposts User Guide*. RDS can also call the following EC2 permission API operations for local gateway route tables on your behalf for Multi-AZ deployments: + `CreateLocalGatewayRouteTablePermission` – When you create a Multi-AZ DB instance on RDS on Outposts + `DeleteLocalGatewayRouteTablePermission` – When you delete a Multi-AZ DB instance on RDS on Outposts These API operations grant to, or remove from, internal RDS accounts the permission to associate internal RDS VPCs with your local gateway route tables. You can view these route table–VPC associations using the `DescribeLocalGatewayRouteTableVpcAssociations` API operations. # Creating DB instances for Amazon RDS on AWS Outposts Creating an Amazon RDS on AWS Outposts DB instance is similar to creating an Amazon RDS DB instance in the AWS Cloud. However, make sure that you specify a DB subnet group that is associated with your Outpost. A virtual private cloud (VPC) based on the Amazon VPC service can span all of the Availability Zones in an AWS Region. You can extend any VPC in the AWS Region to your Outpost by adding an Outpost subnet. To add an Outpost subnet to a VPC, specify the Amazon Resource Name (ARN) of the Outpost when you create the subnet. Before you create an RDS on Outposts DB instance, you can create a DB subnet group that includes one subnet that is associated with your Outpost. When you create an RDS on Outposts DB instance, specify this DB subnet group. You can also choose to create a new DB subnet group when you create your DB instance. For information about configuring AWS Outposts, see the [AWS Outposts User Guide](https://docs.aws.amazon.com/outposts/latest/userguide/). ## Console ### Creating a DB subnet group Create a DB subnet group with one subnet that is associated with your Outpost. You can also create a new DB subnet group for the Outpost when you create your DB instance. If you want to do so, then skip this procedure. **Note** To create a DB subnet group for the AWS Cloud, specify at least two subnets. **To create a DB subnet group for your Outpost** 1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. In the upper-right corner of the Amazon RDS console, choose the AWS Region where you want to create the DB subnet group. 1. Choose **Subnet groups**, and then choose **Create DB Subnet Group**. The **Create DB subnet group** page appears. ![\[Create DB subnet group page.\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/create-db-subnet-group.png) 1. For **Name**, choose the name of the DB subnet group. 1. For **Description**, choose a description for the DB subnet group. 1. For **VPC**, choose the VPC that you're creating the DB subnet group for. 1. For **Availability Zones**, choose the Availability Zone for your Outpost. 1. For **Subnets**, choose the subnet for use by RDS on Outposts. 1. Choose **Create** to create the DB subnet group. ### Creating the RDS on Outposts DB instance Create the DB instance, and choose the Outpost for your DB instance. **To create an RDS on Outposts DB instance using the console** 1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. In the upper-right corner of the Amazon RDS console, choose the AWS Region where the Outpost on which you want to create the DB instance is attached. 1. In the navigation pane, choose **Databases**. 1. Choose **Create database**. The AWS Management Console detects available Outposts that you have configured and presents the **On-premises** option in the **Database location** section. **Note** If you haven't configured any Outposts, either the **Database location** section doesn't appear or the **RDS on Outposts** option isn't available in the **Choose an on-premises creation method** section. 1. For **Database location**, choose **On-premises**. 1. For **On-premises creation method**, choose **RDS on Outposts**. 1. Specify your settings for **Outposts Connectivity**. These settings are for the Outpost that uses the VPC that has the DB subnet group for your DB instance. Your VPC must be based on the Amazon VPC service. 1. For **Virtual Private Cloud (VPC)**, choose the VPC that contains the DB subnet group for your DB instance. 1. For **VPC security group**, choose the Amazon VPC security group for your DB instance. 1. For **DB subnet group**, choose the DB subnet group for your DB instance. You can choose an existing DB subnet group that's associated with the Outpost—for example, if you performed the procedure in [Creating a DB subnet group](#rds-on-outposts.creating.console.subnet). You can also create a new DB subnet group for the Outpost. 1. For **Multi-AZ deployment**, choose **Create a standby instance (recommended for production usage)** to create a standby DB instance in another Outpost. **Note** This option isn't available for Microsoft SQL Server. If you choose to create a Multi-AZ deployment, you can't store backups on your Outpost. 1. Under **Backup**, do the following: 1. For **Backup target**, choose one of the following: + **AWS Cloud** to store automated backups and manual snapshots in the parent AWS Region. + **Outposts (on-premises)** to create local backups. **Note** To store backups on your Outpost, your Outpost must have Amazon S3 capability. For more information, see [Amazon S3 on Outposts](https://aws.amazon.com/s3/outposts/). Local backups aren't supported for Multi-AZ deployments or read replicas. 1. Choose **Enable automated backups** to create point-in-time snapshots of your DB instance. If you turn on automated backups, then you can choose values for **Backup retention period** and **Backup window**, or leave the default values. 1. Specify other DB instance settings as needed. For information about each setting when creating a DB instance, see [Settings for DB instances](USER_CreateDBInstance.Settings.md). 1. Choose **Create database**. The **Databases** page appears. A banner tells you that your DB instance is being created, and displays the **View credential details** button. ### Viewing DB instance details After you create your DB instance, you can view credentials and other details for it. **To view DB instance details** 1. To view the master user name and password for the DB instance, choose **View credential details** on the **Databases** page. You can connect to the DB instance as the master user by using these credentials. **Important** You can't view the master user password again. If you don't record it, you might have to change it. To change the master user password after the DB instance is available, modify the DB instance. For more information about modifying a DB instance, see [Modifying an Amazon RDS DB instance](Overview.DBInstance.Modifying.md). 1. Choose the name of the new DB instance on the **Databases** page. On the RDS console, the details for the new DB instance appear. The DB instance has a status of **Creating** until the DB instance is created and ready for use. When the state changes to **Available**, you can connect to the DB instance. Depending on the DB instance class and storage allocated, it can take several minutes for the new DB instance to be available. ![\[My DB instances details\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/create-outpost-launch.png) After the DB instance is available, you can manage it the same way that you manage RDS DB instances in the AWS Cloud. ## AWS CLI Before you create a new DB instance in an Outpost with the AWS CLI, first create a DB subnet group for use by RDS on Outposts. **To create a DB subnet group for your Outpost** + Use the [create-db-subnet-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-subnet-group.html) command. For `--subnet-ids`, specify the subnet group in the Outpost for use by RDS on Outposts. For Linux, macOS, or Unix: ``` 1. aws rds create-db-subnet-group \ 2. --db-subnet-group-name myoutpostdbsubnetgr \ 3. --db-subnet-group-description "DB subnet group for RDS on Outposts" \ 4. --subnet-ids subnet-abc123 ``` For Windows: ``` 1. aws rds create-db-subnet-group ^ 2. --db-subnet-group-name myoutpostdbsubnetgr ^ 3. --db-subnet-group-description "DB subnet group for RDS on Outposts" ^ 4. --subnet-ids subnet-abc123 ``` **To create an RDS on Outposts DB instance using the AWS CLI** + Use the [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) command. Specify an Availability Zone for the Outpost, an Amazon VPC security group associated with the Outpost, and the DB subnet group you created for the Outpost. You can include the following options: + `--db-instance-identifier` + `--db-instance-class` + `--engine` – The database engine. Use one of the following values: + MySQL – Specify `mysql`. + PostgreSQL – Specify `postgres`. + Microsoft SQL Server – Specify `sqlserver-ee`, `sqlserver-se`, or `sqlserver-web`. + Oracle – Specify `oracle-se2`, `oracle-se2-cdb`, `oracle-ee`, or `oracle-ee-cdb`. + `--availability-zone` + `--vpc-security-group-ids` + `--db-subnet-group-name` + `--allocated-storage` + `--max-allocated-storage` + `--master-username` + `--master-user-password` + `--multi-az | --no-multi-az` – (Optional) Whether to create a standby DB instance in a different Availability Zone. The default is `--no-multi-az`. The `--multi-az` option isn't available for SQL Server. + `--backup-retention-period` + `--backup-target` – (Optional) Where to store automated backups and manual snapshots. Use one of the following values: + `outposts` – Store them locally on your Outpost. + `region` – Store them in the parent AWS Region. This is the default value. If you use the `--multi-az` option, you can't use `outposts` for `--backup-target`. In addition, the DB instance can't have read replicas if you use `outposts` for `--backup-target`. + `--storage-encrypted` + `--kms-key-id` **Example** The following example creates a MySQL DB instance named `myoutpostdbinstance` with backups stored on your Outpost. For Linux, macOS, or Unix: ``` 1. aws rds create-db-instance \ 2. --db-instance-identifier myoutpostdbinstance \ 3. --engine-version 8.0.17 \ 4. --db-instance-class db.m5.large \ 5. --engine mysql \ 6. --availability-zone us-east-1d \ 7. --vpc-security-group-ids outpost-sg \ 8. --db-subnet-group-name myoutpostdbsubnetgr \ 9. --allocated-storage 100 \ 10. --max-allocated-storage 1000 \ 11. --master-username masterawsuser \ 12. --manage-master-user-password \ 13. --backup-retention-period 3 \ 14. --backup-target outposts \ 15. --storage-encrypted \ 16. --kms-key-id mykey ``` For Windows: ``` 1. aws rds create-db-instance ^ 2. --db-instance-identifier myoutpostdbinstance ^ 3. --engine-version 8.0.17 ^ 4. --db-instance-class db.m5.large ^ 5. --engine mysql ^ 6. --availability-zone us-east-1d ^ 7. --vpc-security-group-ids outpost-sg ^ 8. --db-subnet-group-name myoutpostdbsubnetgr ^ 9. --allocated-storage 100 ^ 10. --max-allocated-storage 1000 ^ 11. --master-username masterawsuser ^ 12. --manage-master-user-password ^ 13. --backup-retention-period 3 ^ 14. --backup-target outposts ^ 15. --storage-encrypted ^ 16. --kms-key-id mykey ``` For information about each setting when creating a DB instance, see [Settings for DB instances](USER_CreateDBInstance.Settings.md). ## RDS API To create a new DB instance in an Outpost with the RDS API, first create a DB subnet group for use by RDS on Outposts by calling the [CreateDBSubnetGroup](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBSubnetGroup.html) operation. For `SubnetIds`, specify the subnet group in the Outpost for use by RDS on Outposts. Next, call the [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) operation with the following parameters. Specify an Availability Zone for the Outpost, an Amazon VPC security group associated with the Outpost, and the DB subnet group you created for the Outpost. + `AllocatedStorage` + `AvailabilityZone` + `BackupRetentionPeriod` + `BackupTarget` If you are creating a Multi-AZ DB instance deployment, you can't use `outposts` for `BackupTarget`. In addition, the DB instance can't have read replicas if you use `outposts` for `BackupTarget`. + `DBInstanceClass` + `DBInstanceIdentifier` + `VpcSecurityGroupIds` + `DBSubnetGroupName` + `Engine` + `EngineVersion` + `MasterUsername` + `MasterUserPassword` + `MaxAllocatedStorage` (optional) + `MultiAZ` (optional) + `StorageEncrypted` + `KmsKeyID` For information about each setting when creating a DB instance, see [Settings for DB instances](USER_CreateDBInstance.Settings.md). # Creating read replicas for Amazon RDS on AWS Outposts Amazon RDS on AWS Outposts uses the DB engines' built-in replication functionality to create a read replica from a source DB instance. The source DB instance becomes the primary DB instance. Updates made to the primary DB instance are asynchronously copied to the read replica. You can reduce the load on your primary DB instance by routing read queries from your applications to the read replica. Using read replicas, you can elastically scale out beyond the capacity constraints of a single DB instance for read-heavy database workloads. When you create a read replica from an RDS on Outposts DB instance, the read replica uses a customer-owned IP address (CoIP). For more information, see [Customer-owned IP addresses for Amazon RDS on AWS Outposts](rds-on-outposts.coip.md). Read replicas on RDS on Outposts have the following limitations: + You can't create read replicas for RDS for SQL Server on RDS on Outposts DB instances. + Cross-Region read replicas aren't supported on RDS on Outposts. + Cascading read replicas aren't supported on RDS on Outposts. + The source RDS on Outposts DB instance can't have local backups. The backup target for the source DB instance must be your AWS Region. + Read replicas require customer-owned IP (CoIP) pools. For more information, see [Customer-owned IP addresses for Amazon RDS on AWS Outposts](rds-on-outposts.coip.md). + Read replicas on RDS on Outposts can only be created in the same virtual private cloud (VPC) as the source DB instance. + Read replicas on RDS on Outposts can be located on the same Outpost or another Outpost in the same VPC as the source DB instance. + You can't create read replicas for DB instances encrypted with AWS KMS External Key Store (XKS). You can create a read replica from an RDS on Outposts DB instance using the AWS Management Console, AWS CLI, or RDS API. For more information on read replicas, see [Working with DB instance read replicas](USER_ReadRepl.md). ## Console **To create a read replica from a source DB instance** 1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. In the navigation pane, choose **Databases**. 1. Choose the DB instance that you want to use as the source for a read replica. 1. For **Actions**, choose **Create read replica**. 1. For **DB instance identifier**, enter a name for the read replica. 1. Specify your settings for **Outposts Connectivity**. These settings are for the Outpost that uses the virtual private cloud (VPC) that has the DB subnet group for your DB instance. Your VPC must be based on the Amazon VPC service. 1. Choose your **DB instance class**. We recommend that you use the same or larger DB instance class and storage type as the source DB instance for the read replica. 1. For **Multi-AZ deployment**, choose **Create a standby instance (recommended for production usage)** to create a standby DB instance in a different Availability Zone. Creating your read replica as a Multi-AZ DB instance is independent of whether the source database is a Multi-AZ DB instance. 1. (Optional) Under **Connectivity**, set values for **Subnet Group** and **Availability Zone**. If you specify values for both **Subnet Group** and **Availability Zone**, the read replica is created on an Outpost that is associated with the Availability Zone in the DB subnet group. If you specify a value for **Subnet Group** and **No preference** for **Availability Zone**, the read replica is created on a random Outpost in the DB subnet group. 1. For **AWS KMS key**, choose the AWS KMS key identifier of the KMS key. The read replica must be encrypted. 1. Choose other options as needed. 1. Choose **Create read replica**. After the read replica is created, you can see it on the **Databases** page in the RDS console. It shows **Replica** in the **Role** column. ## AWS CLI To create a read replica from a source MySQL, PostgreSQL, or Oracle DB instance, use the AWS CLI command [create-db-instance-read-replica](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance-read-replica.html). You can control where the read replica is created by specifying the `--db-subnet-group-name` and `--availability-zone` options: + If you specify both the `--db-subnet-group-name` and `--availability-zone` options, the read replica is created on an Outpost that is associated with the Availability Zone in the DB subnet group. + If you specify the `--db-subnet-group-name` option and don't specify the `--availability-zone` option, the read replica is created on a random Outpost in the DB subnet group. + If you don't specify either option, the read replica is created on the same Outpost as the source RDS on Outposts DB instance. The following example creates a replica and specifies the location of the read replica by including `--db-subnet-group-name` and `--availability-zone` options. **Example** For Linux, macOS, or Unix: ``` aws rds create-db-instance-read-replica \ --db-instance-identifier myreadreplica \ --source-db-instance-identifier mydbinstance \ --availability-zone us-west-2a ``` For Windows: ``` aws rds create-db-instance-read-replica ^ --db-instance-identifier myreadreplica ^ --source-db-instance-identifier mydbinstance ^ --availability-zone us-west-2a ``` ## RDS API To create a read replica from a source MySQL, PostgreSQL, or Oracle DB instance, call the Amazon RDS API [CreateDBInstanceReadReplica](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstanceReadReplica.html) operation with the following required parameters: + `DBInstanceIdentifier` + `SourceDBInstanceIdentifier` You can control where the read replica is created by specifying the `DBSubnetGroupName` and `AvailabilityZone` parameters: + If you specify both the `DBSubnetGroupName` and `AvailabilityZone` parameters, the read replica is created on an Outpost that is associated with the Availability Zone in the DB subnet group. + If you specify the `DBSubnetGroupName` parameter and don't specify the `AvailabilityZone` parameter, the read replica is created on a random Outpost in the DB subnet group. + If you don't specify either parameter, the read replica is created on the same Outpost as the source RDS on Outposts DB instance. # Considerations for restoring DB instances on Amazon RDS on AWS Outposts When you restore a DB instance in Amazon RDS on AWS Outposts, you can generally choose the storage location for automated backups and manual snapshots of the restored DB instance. + When restoring from a manual DB snapshot, you can store backups either in the parent AWS Region or locally on your Outpost. + When restoring from an automated backup (point-in-time recovery), you have fewer choices: + If restoring from the parent AWS Region, you can store backups either in the AWS Region or on your Outpost. + If restoring from your Outpost, you can store backups only on your Outpost.