Amazon Relational Database Service
User Guide (API Version 2012-04-23)
Print this pageEmail this pageGo to the ForumsView the PDFShare this page on TwitterShare this page on FacebookBookmark this page on DeliciousSubmit this page to RedditSubmit this page to DiggDid this page help you?  Yes  No   Tell us about it...

Security and VPC

What is Amazon Virtual Private Cloud (VPC) and why would I want to use with Amazon RDS?

Amazon VPC lets you create a virtual networking environment in a private, isolated section of the Amazon Web Services (AWS) cloud, where you can exercise complete control over aspects such as private IP address ranges, subnets, routing tables and network gateways. With Amazon VPC, you can define a virtual network topology and customize the network configuration to closely resemble a traditional IP network that you might operate in your own datacenter.

One of the scenarios where you may want to use Amazon RDS in VPC is if you want to run a public-facing web application, while still maintaining non-publicly accessible backend servers in a private subnet. You can create a public-facing subnet for your webservers that has access to the Internet, and place your backend RDS DB Instances in a private-facing subnet with no Internet access. For more information about Amazon VPC, refer to the Amazon Virtual Private Cloud User Guide.

How is using Amazon RDS inside a VPC different from using it outside?

Only Amazon RDS for MySQL is currently supported in VPC. The basic functionality of Amazon RDS—backups, software patching, automatic failure detection, and data recovery—is the same inside or outside a VPC. Amazon RDS allows easy read-scaling (Read Replicas) and storage scaling for MySQL DB Instances inside and outside a VPC.

Amazon RDS DB Instances deployed outside a VPC are assigned an external IP address (to which the Endpoint/DNS Name resolves) that provides connectivity from EC2 or the Internet. In Amazon VPC, Amazon RDS DB instances have only a private IP address within a subnet that you define.

What is a DB Subnet Group and why do I need one?

A DB Subnet Group is a collection of subnets that you may want to designate for your RDS DB Instances in a VPC. Each DB Subnet Group should have at least one subnet for every Availability Zone in a given Region. When creating a DB Instance in VPC, you will need to select a DB Subnet Group. Amazon RDS then uses that DB Subnet Group and your preferred Availability Zone to select a subnet and an IP address within that subnet. Amazon RDS creates and associates an Elastic Network Interface to your DB Instance with that IP address.

[Important]Important

Since the underlying IP address can change (for example, during a failover), we strongly recommend you use the DNS Name to connect to your DB Instance s.

For Multi-AZ deployments, defining a subnet for all Availability Zones in a Region will allow Amazon RDS to create a new standby in another Availability Zone should the need arise. You need to do this even for Single-AZ deployments, just in case you want to convert them to Multi-AZ deployments at some point.

How do I create an Amazon RDS DB Instance in VPC?

For a walk-through example of creating a DB Instance in VPC, refer to the Amazon RDS User Guide.

The following are the pre-requisites necessary to create a DB Instances within a VPC:

  • You need to have a VPC set up with at least one subnet created in every Availability Zone in the Region you want to deploy your DB Instance. For information on creating Amazon VPC and subnets, go to the Getting Started Guide for Amazon VPC.

  • You need to have a DB Subnet Group defined for your VPC.

  • You need to have a DB Security Group defined for your VPC (or you can use the default provided).

  • In addition, you should allocate adequately large CIDR blocks to each of your subnets so that there are enough spare IP addresses for Amazon RDS to use during maintenance activities including scale compute and failover etc.

How do I control network access to my DB Instance(s)?

Amazon RDS allows you to control access to your DB Instances using database security groups (DB Security Groups). A DB Security Group acts like a firewall controlling network access to your DB Instance. By default, network access is turned off to your DB Instances. If you want your applications to access your DB Instance, you can set your DB Security Group to allow access from EC2 Instances with specific EC2 Security Group/VPC Security Group membership or IP ranges. This process is called ingress. Once ingress is configured for a DB Security Group, the same rules apply to all DB Instances associated with that DB Security Group. DB Security Groups can be configured with the "DB Security Groups" section of the AWS Management Console or using the Amazon RDS APIs.

[Note]Note

If you associate a VPC to a DB Security Group, all the access rules within that DB Security Group should be either from VPC Security Groups or IP ranges. EC2 Security Groups and VPC Security Groups are not interchangeable.

Whenever you create a DB Instance in VPC with a specific DB Security Group membership, Amazon RDS creates a corresponding VPC Security Group for that DB Instance for manageability. You can identify such VPC Security Groups via their description, which would be of the format “Security Group for RDS DB Instance ”. Please do not update them through the EC2/VPC console or the EC2/VPC APIs. Any changes you want to do for controlling access to your DB Instance should be done via the DB Security Groups.

How do I secure Amazon RDS DB Instances running within my VPC?

DB Security Groups can be used to help secure DB Instances within an Amazon VPC. In addition, network traffic entering and exiting each subnet can be allowed or denied via network Access Control Lists (ACLs). All network traffic entering or exiting your VPC via your IPsec VPN connection can be inspected by your on-premise security infrastructure, including network firewalls, intrusion detection and prevention systems.

How do I connect to an RDS DB Instance in VPC?

DB Instances deployed within a VPC can be accessed by EC2 Instances deployed in the same VPC. If these EC2 Instances are deployed in a public subnet with associated Elastic IPs, you can access the EC2 Instances via the internet.

DB Instances deployed within a VPC can be accessed from the Internet or from EC2 Instances outside the VPC via VPN or bastion hosts that you can launch in your public subnet. To use a bastion host, you will need to set up a public subnet with an EC2 instance that acts as a SSH Bastion. This public subnet must have an internet gateway and routing rules that allow traffic to be directed via the SSH host, which must then forward requests to the private IP address of your RDS DB instance.

[Important]Important

Since the underlying IP address can change (for example, during a failover), we strongly recommend you use the DNS Name to connect to your DB Instance s.

You can also set up a VPN Gateway that extends your corporate network into your VPC, and allows access to the RDS DB instance in that VPC. Refer to the Amazon VPC User Guide for more details.

Can I move my existing DB instances outside VPC into my VPC?

You can take a snapshot of your DB Instance outside VPC and restore it to VPC by specifying the DB Subnet Group you want to use. Alternatively, you can perform a "Restore to Point in Time" operation as well.

Can I move my existing DB instances from inside VPC to outside VPC?

Currently, direct migration of DB Instances from inside to outside VPC is not supported. For security reasons, a DB Snapshot of a DB Instance inside VPC cannot be restored to outside VPC. The same is true with “Restore to Point in Time” functionality. If you need to move your DB Instance from inside to outside VPC, you will need to export your data from your source DB Instance in your VPC to your target DB Instance deployed outside VPC.

What precautions should I take to ensure that my DB Instances in VPC are accessible by my application?

You are responsible for modifying routing tables and networking ACLs in your VPC to ensure that your DB instance is reachable from your client instances in the VPC.

For Multi-AZ deployments, after a failover, your client EC2 instance and RDS DB Instance may be in different Availability Zones. You should configure your networking ACLs to ensure that cross-AZ communication is possible.

Can I change the DB Subnet Group of my DB Instance?

An existing DB Subnet Group can be updated to add more subnets either for existing Availability Zones are for new Availability Zones added since the creation of the DB Instance. However, changing the DB Subnet Group of a deployed DB instance is not currently allowed.

What is an Amazon RDS master user account and how is it different from an AWS account?

To begin using Amazon RDS you will need an AWS developer account. If you do not have one prior to signing up for Amazon RDS, you will be prompted to create one when you begin the sign-up process. A master user account is different from an AWS developer account and used only within the context of Amazon RDS to control access to your DB Instance(s). The master user account is a native database user account which you can use to connect to your DB Instance. You can specify the master user name and password you want associated with each DB Instance when you create the DB Instance. Once you have created your DB Instance, you can connect to the database using the master user credentials. Subsequently, you may also want to create additional user accounts so that you can restrict who can access your DB Instance.

What privileges are granted to the master user for my DB Instance?

For MySQL, the default privileges for the master user include: create, drop, references, event, alter, delete, index, insert, select, update, create temporary tables, lock tables, trigger, create view, show view, alter routine, create routine, execute, trigger, create user, process, show databases, grant option.

For Oracle, the master user is granted the "dba" role. The master user inherits most of the privileges associated with the role. Please refer to the Amazon RDS User Guide for the list of restricted privileges and the corresponding alternatives to perform administrative tasks that may require these privileges.

Is there anything different about user management with Amazon RDS?

No, everything works the way you are familiar with when using a relational database you manage yourself.

Can programs running on servers in my own data center access Amazon RDS databases?

Yes. You have to intentionally turn on the ability to access your database over the Internet by granting permissions to your Amazon RDS DB Security Group(s) for access over the Internet. You can authorize access for only the specific IP’s, IP ranges, or subnets corresponding to servers in your own data center.

Can I encrypt connections between my application and my DB Instance using SSL?

Yes; however, this option is currently only supported for the MySQL engine.

Amazon RDS generates an SSL certificate for each DB Instance. The Amazon RDS User Guide includes instructions for establishing an encrypted connection using the default mysql client. Once an encrypted connection is established, data transferred between the DB Instance and your application will be encrypted during transfer. If you require your data to be encrypted while “at rest” in the database, your application must manage the encryption and decryption of data. Also note that SSL support within Amazon RDS is for encrypting the connection between your application and your DB Instance; it should not be relied on for authenticating the DB Instance itself.

While SSL offers security benefits, be aware that SSL encryption is a compute intensive operation and will increase the latency of your database connection. To learn more about how SSL works with MySQL, go to the to the MySQL documentation.

Can I require my DB instance to accept only encrypted connections?

For MySQL, after connecting to the DB Instance with the master username and password, you can use the GRANT statement to require SSL connections for specific users accounts. For example, you can use the following statement to require SSL connections on the user account encrypted_user:

GRANT USAGE ON *.* TO ‘encrypted_user’@’%’ REQUIRE SSL