Amazon Relational Database Service (Amazon RDS) Custom automates the setup, operation, monitoring, and scaling of relational databases in the cloud, while granting full access to the database and underlying operating system to configure settings, install drivers, and enable native features to meet the dependent application’s requirements.
Many organizations typically have different networking and database teams. Networking teams focus on designing, deploying, and managing the infrastructure and connectivity. They design the network to be highly secure, scalable, and reliable. Database teams focus on creating, configuring, and maintaining the database servers.
Customers often ask us how they can create an RDS Custom for SQL Server database in their existing networking infrastructure. They want to ensure that the database servers are created within the security perimeter designed by their networking teams. They also want to understand different components and services involved when creating an RDS Custom for SQL Server instance.
In this post, we demonstrate how to create an RDS Custom for SQL Server instance. We also show how to create the required prerequisites within an existing networking infrastructure. Amazon RDS Custom requires these prerequisites to create the necessary resources in your AWS account.
Solution overview
Before creating your first RDS Custom for SQL Server instance, you need to configure the following prerequisites:
An AWS Identity and Access Management (IAM) user or role with required permissions
A symmetric AWS Key Management Service (AWS KMS) key
An IAM role and instance profile
Endpoints for dependent AWS services
After you create these prerequisites, you can reuse these objects to create additional RDS Custom for SQL Server instances.
In this post, we show you how to configure the prerequisites and then perform the following actions:
Create an RDS Custom for SQL Server instance.
Validate the instance.
Prerequisites
The following sections describes the prerequisites in a greater detail. You can implement these steps either from the AWS Management Console or using the latest version of the AWS Command Line Interface (AWS CLI).
Create an IAM user or role with required permissions
IAM roles provide a way to access AWS resources. Each role has a set of permissions defined using policies that determine what it can and cannot do in AWS.
Before you proceed further, ensure you have the required permissions. The IAM user we create has the AdministrativeAccess policy attached to it. However, you may not need such elevated access. For example, to create a customer managed KMS key, you only need kms:CreateKey permissions.
To create the IAM user with required access, complete the following steps:
On the IAM console, choose Users in the navigation pane.
Choose Create user.
For User name, enter a name. For this post, we use awscliuser.
Select Provide user access to the AWS Management Console – optional if you want to configure prerequisites using the console.
Select I want to create an IAM user if you need to enable programmatic access through access keys, service-specific credentials for AWS CodeCommit or Amazon Keyspaces(for Apache Cassandra), or a backup credential for emergency account access.
For Console password, select Custom password and enter a strong password.
Choose Next.
For Permission options, select Attach policies directly.
Under Permissions policies, select the appropriate access policy. For our use case, we select AdministratorAccess.
Choose Next.
Review your choices and choose Create user.
In the Retrieve password section, choose Download .csv file.
This file contains user credentials and the console sign-in URL.
You have successfully created the IAM user with console access.
Grant AWS CLI access to the user
To grant AWS CLI access to the user you created, complete the following steps:
On the IAM console, choose Users in the navigation pane.
Choose the user name that you created (for this post, awsclisuer).
In the Summary section, for Access Key 1, choose Create access key.
For Access key best practices & alternatives, under Use case, choose Command Line Interface (CLI).
Under Confirmation, confirm that you understand the preceding recommendation.
Choose Next.
Choose Create access key.
For Retrieve access keys, choose Download .csv file.
You have successfully granted AWS CLI access to the awscliuser IAM user. You can now implement the prerequisites either from the console or using the latest version of the AWS CLI.
To verify access, use the following AWS CLI command to get the current user:
Use the following code to list all the managed policies that are attached to the specified IAM user:
Before you proceed further, ensure you have the required permissions.
Create a symmetric KMS key
A symmetric encryption KMS key is required for Amazon RDS Custom to encrypt and decrypt the data. Amazon RDS Custom supports only customer managed KMS keys. To check if you have an existing customer managed symmetric encryption KMS key in your account, complete the following steps:
On the AWS KMS console, choose Customer managed keys in the navigation pane.
Verify if the customer managed keys exist.
To create a new customer managed key, choose Create key.
For Key type, select Symmetric.
For Key usage, select Encrypt and decrypt.
Choose Next.
For Alias, enter an alias name for the KMS key. For this post, we enter rds-custom-key. The alias name cannot begin with aws/. The aws/ prefix is reserved by AWS to represent AWS managed keys in your account.
Choose Next.
Select the IAM users and roles that can administer the KMS key. For our use case, we select Admin. This key policy gives the AWS account full control of this KMS key. It allows account administrators to use IAM policies to give other principals permission to manage the KMS key. For details, see Default key policy.
Optionally, to prevent the selected IAM users and roles from deleting this KMS key, in the Key deletion section, deselect Allow key administrators to delete this key.
Choose Next.
Select the IAM users and roles that can use the key in cryptographic operations. For our use case, we select Admin.
Choose Next. As before, this key policy gives the AWS account full control of this KMS key, and allows account administrators to use IAM policies to give other principals permission to manage the KMS key.
Review the key settings that you chose. You can still go back and change all the settings.
Choose Finish to create the KMS key.
You can see the new KMS key on the Customer managed keys page.
You can also complete these steps using the AWS CLI.
To list all KMS keys in the account and Region using the AWS CLI, use the following command:
Create an IAM role and instance profile
Access in AWS is managed by creating policies and attaching them to IAM roles or AWS resources. Permissions in the policies determine what access the role has on the resource. Amazon Elastic Compute Cloud (Amazon EC2) is one of the core resources of Amazon RDS Custom. This policy must allow Amazon EC2 to perform various actions like send and receive messages to AWS Systems Manager. It must also allow Amazon EC2 to communicate to other Amazon services such Amazon Simple Storage Service (Amazon S3), Amazon CloudWatch, and Amazon Simple Queue Service (Amazon SQS). For this, you need to create an IAM role and add a policy to it. When you embed an inline policy in a role, it is used as part of the role’s access (permissions) policy.
An instance profile is a container for an IAM role that you can use to pass role information to an EC2 instance when the instance starts. Therefore, you need to create an instance profile and add the IAM role to it. The following diagram shows the typical flow when creating the IAM role and instance profile.
The steps are as follows:
Create the IAM role.
Attach the permissions to the IAM role with IAM policies.
Create the instance profile (AWS CLI only) and add the IAM role to the instance profile.
The prefix AWSRDSCustom is required for the IAM instance profile and its associated IAM role names. To create an IAM role and inline policy, follow these steps:
On the IAM console, choose Roles in the navigation pane.
Choose Create role.
For Trusted entity type, select AWS service.
For Common use cases, select EC2.
Choose Next.
On the Add permissions page, choose Next.
For Role name, enter AWSRDSCustomSQLServerInstanceRole.
Enter a description for the role and choose Create role.
The following example creates the AWSRDSCustomSQLServerInstanceRole role using the AWS CLI. The trust policy lets Amazon EC2 assume the role.
Next, we add an access policy to AWSRDSCustomSQLServerInstanceRole.
From the list of roles, choose AWSRDSCustomSQLServerInstanceRole.
In the Permissions policies section, choose Add permissions and Create inline policy.
For Create policy, choose JSON.
From the following code, copy the code within the –policy-document parameter and enter it in the JSON policy editor.
This example assumes that the ‘$REGION’, $ACCOUNT_ID, and ‘$CUSTOMER_KMS_KEY_ID’ variables have been set. ‘$CUSTOMER_KMS_KEY_ID’ is the ID, not the Amazon Resource Name (ARN), of the KMS key that you defined earlier.
The following code creates an access policy named AWSRDSCustomSQLServerIamRolePolicy and adds it to the AWSRDSCustomSQLServerInstanceRole role using the AWS CLI:
Choose Review policy.
For Name, enter AWSRDSCustomSQLServerIamRolePolicy.
Choose Create policy.
You can view the role ARN on the IAM console. An instance profile is also created for you when you use the console to create the role.
You can also create an instance profile and add the IAM role to it using the AWS CLI.
Use the following code to create an instance profile named AWSRDSCustomSQLServerInstanceProfile:
To add the AWSRDSCustomSQLServerInstanceRole role to the AWSRDSCustomSQLServerInstanceProfile instance profile, use the following command:
You have successfully created an IAM role and instance profile. Notice the role ARN and instance profile ARN created as well.
Configure endpoints for dependent AWS services
Amazon RDS Custom sends communication from your DB instance to other AWS services within your VPC. To ensure all RDS Custom automation works as expected, it validates network connectivity to the following AWS services:
Amazon CloudWatch
Amazon CloudWatch Logs
Amazon CloudWatch Events
Amazon EC2
Amazon EventBridge
Amazon S3
AWS Secrets Manager
AWS Systems Manager
Amazon SQS
We recommend that you add VPC endpoints for these services in your VPC. However, you can use any solution that lets your VPC communicate with AWS service endpoints. For example, you can use design patterns such as internet gateways, Network Address Translation (NAT) gateways with internet gateways, VPC peering, or transit gateways to direct your network to the required AWS service endpoints.
In this section, we explain how you can use VPC endpoints to connect to the AWS services in your VPC. The VPC endpoint enables resources in your VPC to privately connect to AWS services without leaving the Amazon network.
To configure VPC endpoints for AWS services that Amazon RDS Custom communicates with, complete the following steps using Amazon Virtual Private Cloud (Amazon VPC):
On the Amazon VPC console, choose your AWS Region.
Choose Endpoints in the navigation pane.
Choose Create endpoint.
For Service category, select AWS services.
For Service Name, enter an endpoint based on your service. For example, enter com.amazonaws.us-west-2.ssm.
We include a table with endpoint formats later in this section.
For VPC, choose your VPC.
For Subnets, choose a subnet from each Availability Zone to include.
The VPC endpoint can span multiple Availability Zones. AWS creates an elastic network interface for the VPC endpoint in each subnet that you choose.
For Security group, choose or create a security group.
Optionally, you can attach a policy to the VPC endpoint. Endpoint policies can control access to the AWS service to which you are connecting. The default policy allows all requests to pass through the endpoint. If you’re using a custom policy, make sure that requests from the DB instance are allowed in the policy.
Whether you choose an existing security group or create new, allow TCP port 443 inbound access from the RDS Custom DB instance.
For example, you can create a new security group for VPC endpoint named rds-custom-vpc-endpoint-sg. Next, allow TCP port 443 inbound access from the RDS Custom DB instance security group rds-custom-rds-custom-instance-sg. Refer to the following screenshot. You use the rds-custom-rds-custom-instance-sg security group when you create an RDS Custom DB instance.
Choose Create endpoint.
Repeat these steps for the remaining endpoints outlined in the following table, except for Amazon S3.
For Amazon S3, choose the service type as Gateway when creating a VPC endpoint.
The following table explains how to find the list of endpoints that your VPC needs for outbound communications.
Service
Endpoint format
Notes and links
AWS Systems Manager
Use the endpoint formats ssm.region.amazonaws.com or ssmmessages.region.amazonaws.com.
For the list of endpoints in each Region, see AWS Systems Manager endpoints and quotas.
AWS Secrets Manager
Use the endpoint format secretsmanager.region.amazonaws.com.
For the list of endpoints in each Region, see AWS Secrets Manager endpoints and quotas.
Amazon CloudWatch
For CloudWatch metrics, use monitoring.region.amazonaws.com.
For CloudWatch Events, use events.region.amazonaws.com.
For CloudWatch Logs, use logs.region.amazonaws.com.
For the list of endpoints in every Region, see Amazon CloudWatch endpoints and quotas, Amazon CloudWatch Logs endpoints and quotas, and Amazon CloudWatch Events endpoints and quotas.
Amazon EC2
Use the endpoint formats ec2.region.amazonaws.com or ec2messages.region.amazonaws.com.
For the list of endpoints in each Region, see Amazon Elastic Compute Cloud endpoints and quotas.
Amazon S3
Use the endpoint format s3.region.amazonaws.com.
To learn more about gateway endpoints for Amazon S3, see Endpoints for Amazon S3.
Amazon SQS
Use the endpoint format sqs.region.amazonaws.com.
For the list of endpoints in each Region, see Amazon Simple Queue Service endpoints and quotas.
Use the following commands in the AWS CLI to create VPC endpoints. Replace <vpc-id>, <subnet-ids>, <security-group-id>, and <route-table-id> with appropriate values from your networking infrastructure. <route-table-id> is a requirement for the Amazon S3 gateway endpoint only; it’s the route table associated with the subnet where you want to use the Amazon S3 VPC endpoint.
To verify the endpoints, navigate to the Endpoints page on the Amazon VPC console and check the Status column. All the Endpoint type values should show as Interface, except for S3, which should show as Gateway.
Use the following AWS CLI command to verify the endpoints:
Now that you have created the prerequisite components, you can create one or many RDS Custom for SQL Server instances.
Create an RDS Custom for SQL Server instance
To create an RDS Custom for SQL Server instance, perform the following steps:
On the Amazon RDS console, choose Create database.
Select Microsoft SQL Server for Engine type.
For Database management type, select Amazon RDS Custom.
Choose the appropriate edition of SQL Server. For our use case, we choose SQL Server Standard Edition.
Choose the latest engine version on the drop-down menu.
Under Settings, provide the DB instance identifier, primary user name, and primary password.
Under Instance configuration, choose an appropriate DB instance class (Standard classes or Memory optimized classes).
Under Storage, choose the desired storage class from gp2, gp3, or io1 and enter an appropriate storage amount.
Under Availability & durability, choose the appropriate setting for Multi-AZ deployment.
We recommend enabling Multi-AZ deployment for production workloads.
In the Connectivity section, choose your VPC, DB subnet group, and VPC security group.
Whether you configure a new VPC security group or choose existing one, make sure that the security group has the following permissions:
Allow TCP port 443 outbound access to the VPC endpoint security group
Allow TCP port 443 outbound access to the Amazon S3 gateway endpoint
For a Multi-AZ setup, ensure that TCP port 1433 and TCP port 1120 are allowed in both inbound and outbound rules from the RDS Custom for SQL Server security group
Add a rule in your private network Access Control List (ACL) that allows TCP ports 0-65535 for the source subnet of the DB instance
Under RDS Custom Security, choose AWSRDSCustomSQLServerInstanceRole for IAM instance profile.
For Encryption, choose the symmetric KMS key you created earlier.
Choose Create database.
Use the following command to create an RDS Custom for SQL Server instance with the AWS CLI:
Validate the instance
To validate that the RDS Custom for SQL Server instance is created successfully, perform the following steps:
Remote Desktop to the EC2 host created as a prerequisite.
Open SQL Server Management Studio and connect to the RDS Custom for SQL Server instance endpoint.
Run the following command and take note of the SQL Server version and EC2 host name for the RDS Custom for SQL Server instance:
Clean up
To avoid future charges and remove the components created while testing this use case, complete the following steps:
On the Amazon RDS console, choose Databases in the navigation pane.
Select the database you set up, and on the Actions menu, choose Delete.
Summary
In this post, we demonstrated how to set up the prerequisites to create an RDS Custom for SQL Server instance in your existing infrastructure. With this one-time configuration, you can reuse these objects to create RDS Custom for SQL Server instances within your networking infrastructure in the future.
If you have any comments or feedback, leave them in the comments section.
About the Author
Minesh Chande is Senior Database Specialist Solutions Architect at Amazon Web Services. He helps customers across different industry verticals design, migrate, and optimize their SQL Server workloads to a managed database platform like Amazon RDS and Amazon RDS Custom.
Read MoreAWS Database Blog
