AWS Database Blog

Connect an on-premises application server to Amazon RDS on Outposts

AWS Outposts rack brings native AWS services to virtually any customer data center or on-premises facility. Outposts is a fully managed service that extends AWS infrastructure, services, APIs, and tools to customer premises.

In this post, we detail the connectivity required to connect on-premises applications to Amazon Relational Database Service (Amazon RDS) on Outposts. For more information on provisioning Amazon RDS on Outposts, see New – Create Amazon RDS DB Instances on AWS Outposts.

Introducing Amazon RDS on Outposts

Amazon RDS on Outposts allows you to deploy fully managed database instances in your on-premises environments. With Outposts rack, you can consume a service and not have to worry about the overhead of patching and upgrading the on-premises infrastructure.

In some use cases, you may need to remain on premises. The following are two main reasons for this:

  • Low-latency requirements – Some business-critical applications require real-time processing and are sensitive to latency. For example, applications that need to run on premises to respond to events with extremely small millisecond latencies.
  • Data locality – You may have data-intensive workloads that collect and process hundreds of TBs of data a day and in some cases must be processed locally. This allows you to process the data to respond to events in real time and to have better control analyzing, backing up, and restoring the data.

Databases are often integrated with on-premises applications, and moving these databases to the cloud can be more complex. Having a service that is interchangeable between Outposts rack and AWS Region in terms of how it works is really unique, especially for those customers in a hybrid model where teams need to standardize their skills. Now, with Outposts rack, you can run Amazon RDS on-premises for low-latency workloads that need to be run in close proximity to your database and applications. This provides the best experience for end-users.

With Amazon RDS on Outposts, you can run MySQL, Microsoft SQL Server, and PostgreSQL databases. For the latest supported database engines, see Amazon RDS on Outposts FAQs.

How does Amazon RDS on Outposts work?

Amazon RDS on Outposts makes it easy to provision and operate relational databases on premises, including for low-latency workloads that need to remain close to database and applications. The following diagram provides a high-level architectural view for the Region and Outposts rack. The diagram represents the VPC extension between the Region and Outposts rack, and the two subnets on Outposts rack for the database and applications. The elastic network interface (ENI) maps a path to the local gateway (LGW). This is where the RDS endpoint can be accessed by the on-premises servers.

The architecture shows how you can connect databases running in the Region and on-premises. For those instances running in a separate Region, you can configure VPC peering or AWS Transit Gateway to route that traffic.

Create an RDS database

You can manage RDS databases both in the cloud and on premises using the AWS Management Console, APIs, and AWS Command Line Interface (AWS CLI). For information on the additional provisioning steps (such as instance type, storage, and credentials) that you need to take, see New – Create Amazon RDS DB Instances on AWS Outposts.

To deploy an RDS database using the console, navigate to the Amazon RDS console and choose Create database. Select On-premises and RDS on Outposts.

To use the AWS CLI, run 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 internal-outposts-rds-sg
--storage-type gp2
--storage-encrypted 

Next, select the subnet from the available subnets associated with the VPC. You can choose the subnet associated with Outposts rack that the RDS instances are deployed to. The following screenshot shows this configuration using the console.

To use the AWS CLI, use the following command:

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 internal-outposts-rds-sg
--storage-type gp2
--storage-encrypted 

This is the same principle as within the Region today.

Connect to the RDS endpoint

Additional steps are needed when you create an RDS DB instance on Outposts rack compared to in the Region. When deploying Amazon RDS on Outposts, the create database process creates an ENI within the Outposts rack subnets, for example, subnets Internal-outpost-rds-sg, as shown in the previous examples.

The role of the ENI is to provide a logical networking component in a VPC that represents a virtual network card; this is very similar to having a physical network adapter in a physical server. The ENI is attached to the RDS instances. This allows the applications running on both the Outposts rack, Region, and on premises to connect to the ENI via the endpoint.

As discussed earlier, the ENI plays a key part in mapping a path to the local gateway. This is where the RDS endpoint can be accessed by the on-premises servers.

To find the DB instance endpoint and port number, navigate to upper-right corner of the Amazon RDS console and choose the Region of your DB instance. In the navigation pane, choose Databases to display a list of your DB instances. In the Connectivity & security section, copy the endpoint.

Outposts rack local gateway

As mentioned earlier, the key use cases for Outposts rack are low latency to on-premises workloads and local data processing. For workloads that are running on premises, these application servers connect from the Outposts rack to the local network running on-premises.

The following figure shows how to connect to the Outpost. The local gateway has been especially designed and runs on Outposts rack. The LGW operates in two modes: customer-owned IP (CoIP) or direct VPC routing. It provides a target in your VPC route tables for on-premises destined traffic, and it performs network address translation (NAT) for instances that have been assigned addresses from your CoIP pool.

Enable CoIP

During the preinstallation process, AWS creates an address pool, known as a customer-owned IP address pool. It’s created based on information that you provide about your on-premises network. Because the Outpost is an extension to the Region, this means that the VPC is extended from the associated Region to the Outpost, and the LGW attaches to the VPC in that Outpost to give you access to your on-premises resources.

When you enable a CoIP for an RDS on Outposts DB instance, you connect to the DB instance with the DB instance endpoint. Amazon RDS on Outposts 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

You can enable or disable a CoIP for an RDS on Outposts DB instance using the console, AWS CLI, or API.

To use the console, select Customer-owned IP address for Access type. Select one of the other settings to disable it.

With the AWS CLI, use the --enable-customer-owned-ip | --no-enable-customer-owned-ip option.

With the API, use the EnableCustomerOwnedIp parameter.

Enable direct VPC routing

When CoIP is enabled for a DB instance, the DB endpoint DNS only resolves to the CoIP and if connecting from within VPC, you need to update or configure the VPC subnet route table. An alternative solution is called direct VPC routing.

Direct VPC routing for Outposts rack uses the private IP address of the instances in your VPC to facilitate communication with your on-premises network. These VPC subnet addresses are advertised to your on-premises network with Border Gateway Protocol (BGP). Advertisement to BGP is only for the private IP addresses that belong to the subnets on your Outpost. This type of routing is the default mode for Outposts rack. In this mode, the local gateway does not perform NAT for instances, and you do not have to assign an Elastic IP address to your Amazon Elastic Compute Cloud (Amazon EC2) instance. You have the option to use your own address space instead of direct VPC routing mode. For more information, see the earlier section in this post regarding CoIPs.

The direct VPC routing mode is configured for an LGW route-table. The associated VPC CIDRs can route to your on-premises network. For the deployment of Amazon RDS on Outposts, you can use direct VPC routing, because this allows the VPC private IP of an instance to communicate with the on-premises networks. As shown earlier, the defined CIDRs for the local Outposts rack is propagated to the LGW and therefore the on-premises network.

Connecting in Region and on-premises

Applications that remain on-premises or within the Region can benefit from the same RDS database instances. For supported instances, see Working with Amazon RDS on AWS Outposts.

With direct VPC routing enabled, EC2 instances running on the same VPC, and in-Region or on the same Outpost, can now access the RDS endpoint. EC2 instances running on the same VPC but a different Outpost need more specific routes in the route table to direct traffic to local gateways. Similarly, EC2 instances running on a different VPC and on a different Outpost need a route table entry in each VPC to direct traffic to the local gateways.

With CoIP enabled, EC2 instances running on the same or different VPC, and on the same or different Outpost, can access the RDS endpoint, provided that each EC2 instance also has a CoIP address and routes in the route table to direct traffic to the local gateways, as shown in the following screenshot. However, EC2 instances in-Region can’t access the RDS endpoint.

You may need to update the VPC security groups to allow various ports to authorize the inbound and outbound connections permitting who has network access to your RDS database instances. The following screenshot shows the security group for allowing port 3306 (this example is for MySQL). By default, no inbound rules are configured.

Connect EC2 instances to the RDS endpoint

After performing all these steps, you can connect to the RDS database running on the Outpost by running the following commands for MySQL and PostgreSQL. In both examples, xxx relates to the database name.

To connect a running EC2 instance to a MySQL RDS database in the same VPC using the MySQL client, enter the following command at a command prompt:

mysql -h database-1.xxx.eu-west-2.rds.amazonaws.com -P 3306 -u mymasteruser -p

To connect a running EC2 instance to a PostgreSQL RDS database in the same VPC using the PSQL tool, enter the following command at a command prompt (in this example, the following command connects to a database called mypgdb on a PostgreSQL DB instance called database1):

psql --host=database-1.xxx.eu-west-2.rds.amazonaws.com --port=5432 --username=awsuser --password --dbname=mypgdb

Considerations

Before deploying Amazon RDS on Outposts, consider the following:

Conclusion

Outposts rack was designed to support two main requirements: low latency and data locality. With the database running within your on-premises environment, you can now have centralized databases in multiple locations around the world, whether these are accessed via on-premises resources or Regions.

AWS provides a database service that is interchangeable between Outposts rack and Region. This benefits those using hybrid models, especially if you want to standardize your teams’ skillsets. Now, with Outposts rack, you can run Amazon RDS on premises for low-latency workloads that need to be run in close proximity to your on-premises data and applications.

If you need more information, or access to the experts, visit AWS Outposts Partners.

For additional resources, check out the following:


About the author

Dean Lidstone is a Senior Partner Management Solutions Architect for AWS based in the UK. He helps AWS Partners across the UK & EMEA, by leveraging his experience to build their long term strategic plans and scalable solutions on AWS. He has extensive experience working with customers who are looking for hybrid solutions and specialises on AWS Outposts.