Using Amazon RDS for SQL Server in a hybrid cloud environment

A common use case in an enterprise cloud database adoption strategy is to move your database workloads to the cloud first, while slowly moving the rest of your applications in batches. This post looks into the various possible scenarios and configurations you can use when accessing an Amazon Relational Database Service (Amazon RDS) for SQL Server database instance from your on-premises or hybrid environments.

Basic AWS infrastructure components

Before we dive into the hybrid data center discussion, let’s quickly familiarize ourselves with some of the components we refer to throughout this post:

• Amazon VPC – Amazon Virtual Private Cloud (Amazon VPC) lets you launch AWS resources in a logically isolated virtual network that you define. You have complete control over your virtual networking environment, including selecting your own IP address range, creating subnets, and configuring route tables and network gateways. You can use both IPv4 for most resources in your virtual private cloud, which helps ensure secure and easy access to resources and applications.
• Subnet – A subnet divides IP address space into logical subdivision. A VPC spans all the Availability Zones in the Region. After creating a VPC, you can add one or more subnets in each Availability Zone.
• VPN – A VPN, or virtual private network, is an encrypted connection over the internet between networks or devices.
• AWS Direct Connect – AWS Direct Connect is a network service that provides an alternative to using the internet to utilize AWS Cloud services. AWS Direct Connect enables you to have low latency, secure, and private connections to AWS for workloads that require higher speed or lower latency than the internet.

Use case 1: Using a site-to-site VPN

Let’s begin by discussing the simplest way of getting from your data center to AWS: by using a secure VPN connection between your data center and AWS, over the internet. In this setup, you create a VPC with a range of IP address in your AWS account and create subnets by further subdividing the VPC IP range. For this post, we create two subnets, private and public, and we place the RDS DB instance inside this private subnet. Private subnet resources don’t get a public routable IP address.

In this configuration, you use the Site-to-Site VPN connection to connect your data center to the VPC. In your data center, you have a physical device or a software application that works as a customer gateway device. You create and configure a customer gateway resource that represents the customer gateway device in your data center.

On the AWS side, you create and configure a virtual private gateway. For more information about individual component configuration, see How AWS Site-to-Site VPN works. The following diagram shows a simple setup where you have a single VPC.

For a more complete discussion on configuring a VPN with Amazon RDS, see Accessing an Amazon RDS instance remotely using AWS Client VPN.

What if you have more than one VPC? This is often the case in an enterprise environment. In this situation, you can use AWS Transit Gateway, which acts as a transit hub. You can use a transit gateway to interconnect your VPCs and on-premises networks. The following diagram shows a configuration that utilizes a transit gateway.

When creating these connections, be careful to not overlap IP address ranges between the VPCs and the on-premises IP address space.

If you have more than one data center that needs to communicate with AWS, you can route traffic from multiple remote locations to your AWS VPCs, while continuing to use a virtual private gateway or transit gateway. Another variation of this configuration is to use the AWS VPN CloudHub. If you have multiple AWS Site-to-Site VPN connections, you can provide secure communication between sites using the VPN CloudHub. This enables your remote sites to communicate with each other, and not just with the VPC. The VPN CloudHub operates on a simple hub-and-spoke model. This design is suitable if you have multiple branch offices and want to implement a convenient, potentially low-cost hub-and-spoke model for primary or backup connectivity between these remote offices.

Use case 2: Using AWS Direct Connect

Site-to-Site VPN connectivity is a simple and great way to get connected to AWS from your data center. However, as you start to use more and more resources in AWS from your remote location, the limited bandwidth of the VPN connection and its reliance over the public internet start to become a bottleneck. Maximum bandwidth per VPN tunnel is 1.25 Gbps and can’t be increased further.

To make higher bandwidth available between your DC and AWS, you can use AWS Direct Connect. With AWS Direct Connect, you can establish a secure and reliable high-bandwidth connection between your data center location and AWS. AWS Direct Connect lets you link your DC network to an AWS Direct Connect location over a standard Ethernet fiber-optic cable, thereby completely bypassing the internet and avoiding network congestion.

You can create two types of connections:

• Dedicated connection – A physical Ethernet connection associated with a single customer. You can provision either 1 Gbps or 10 Gbps port speeds with direct connections.
• Hosted connection – A physical Ethernet connection that an AWS Direct Connect Partner provisions on behalf of a customer. You can provision sub 1 Gbps connection speeds (50 Mbps up to 1 Gbps) and sub 10 Gbps speeds (1 Gbps up to 10Gbps) when using a hosted connection.

With AWS Direct Connect, you can create three types of virtual interfaces:

• Public virtual interface – A public VIF lets you interface directly to public AWS services (such as Amazon Simple Storage Service (Amazon S3)), bypassing public internet
• Private virtual interface – A private VIF enables access to your AWS VPC directly, bypassing internet service providers in your network path
• Transit virtual interface – A transit VIF lets you interface with multiple VPCs from your data center directly

The following diagram shows a setup with a private VIF connection between your data center and AWS VPC. After the AWS Direct Connect connection is established, the application in your data center can access RDS databases by using the RDS DB endpoints.

This is just an overview of AWS Direct Connect; a comprehensive discussion is beyond the scope of this article. For more information, see the AWS Direct Connect User Guide.

Use case 3: Other cloud providers and hosting providers

There may be situations where you need to establish connectivity between other cloud providers or hosting locations and AWS. This scenario can be treated similar to the VPN scenario discussed previously. The AWS side and the VPN stays identical, but instead of a customer gateway in the customer data center, you create it with the vendor cloud provider or in the hosting location.

Extending on-premises Microsoft Active Directory and Kerberos authentication to the cloud

A common use case is to extend Microsoft Active Directory (AD) authentication to cloud, so on-premises users can continue to authenticate with managed RDS DB instances using their AD credentials. To achieve this, you need to use AWS Directory Service for Microsoft Active Directory and create a trust relationship with the on-premises AD so authentication requests can be forwarded. When users authenticate with an RDS DB instance joined to the trusting domain, authentication requests are forwarded to the domain directory that you create with AWS Directory Service.

You can establish trust in one of the two directions; both are supported by AWS Managed Microsoft AD:

• One-way trust – A unidirectional authentication path created between two domains. In a one-way trust between Domain A and Domain B, when Domain B has configured to trust Domain A, users in Domain A can access resources in Domain B; however, users in Domain B can’t access resources in Domain A.
• Two-way trust – Domain A trusts Domain B, and Domain B trusts Domain A. This configuration means that authentication requests can be passed between the two domains in both directions.

In addition to the flow of the trust, you also have to choose the type of trust as a forest trust. When you configure a forest trust, you can allow any contiguous namespace domain in the trusting forest to be accessible to any security principal in the trusted forest. You most likely configure forest trusts if your organization has two or more AD forests. Forest trusts provide name suffix routing, which routes the Kerberos authentication requests to the correct domain.

After you make the appropriate choices and configure the AWS Managed Microsoft AD, your on-premises application can connect to the RDS database with their existing AD credentials. For more information about this configuration, see Preparing on-premises and AWS environments for external Kerberos authentication for Amazon RDS.

The following diagram shows an example setup between on-premises AD and AWS Managed Microsoft AD with a one-way forest trust relationship.

Conclusion

This post discussed various methods you can employ to efficiently extend your data center to the AWS Cloud and get the applications in the data center or other remote locations talking seamlessly to RDS DB instances.

This post is meant to give you an overview of the options available; for in-depth discussions and configurations, refer to the blog posts and AWS service user guides linked throughout the post.

We hope this was helpful to get you started on your cloud journey or accelerate an ongoing project. We welcome your thoughts on this topic, so please leave your feedback in the comments section. Happy cloud computing!

About the Author

Aditya Samant is a Solutions architect specializing in databases at AWS. His day job allows him to help AWS customers design scalable, secure and robust architectures utilizing the most cutting-edge cloud technologies. When not working Aditya enjoys retro PC tech, playing computer games and spending time with his family and friends.