database - Unable to connect to MSSQL server on Amazon RDS using NAT instance


Keywords:database 


Question: 

I am completely new to Amazon Web Services and I am trying to implement a Virtual Private Cloud with public and private subnets. A private subnet will host my database servers and public subnet will contain my application's web servers. I followed Amazon's own step-by-step tutorial to achieve this:

Scenario 2: VPC with Public and Private Subnets

I have configured all the VPC security groups as described in the tutorial and I successfully managed to get my web servers talking to my database servers. I also want to remotely connect to the database from MSSQL Management Studio on my local machine so I can create/drop schemas and generally see what's inside the database. However, I cannot connect to the database servers at all.

Part of the problem is that I am not sure exactly what I am meant to be connecting to. Prior to doing this tutorial I created a simple database and used its endpoint as the URL and I could remotely connect to it from my local machine. Now, since the database servers are on a private subnet and can only communicate with the outside world via a NAT instance, does this mean that I should use NAT's elastic IP as a database URL and add extra rules to NAT's security groups? My knowledge of networking is somewhat lacking so I am not too sure and the tutorial doesn't help here either.

My security groups contain the following entries:

NAT instance security group inbound:

Port   |   Source
22     |   my external ip
80     |   10.0.1.0/24 (private subnet)
443    |   10.0.1.0/24 (private subnet)
1433   |   my external ip

NAT instance security group outbound:

Port   |   Destination
80     |   0.0.0.0/0
443    |   0.0.0.0/0
1433   |   0.0.0.0/0

Database security group inbound:

Port   |   Source
1433   |   sg-d6ec33b9 (web servers security group)

Database security group outbound:

Port   |   Destination
80     |   0.0.0.0/0
443    |   0.0.0.0/0

Webservers security group inbound:

Port   |   Source
22     |   0.0.0.0/0
80     |   0.0.0.0/0
443    |   0.0.0.0/0
8080   |   0.0.0.0/0

Webservers security group outbound:

Port   |   Destination
80     |   0.0.0.0/0
443    |   0.0.0.0/0
1433   |   sg-b5ec33da (database security group id)

Main routing table is associated with a private subnet (10.0.1.0/24) and has following routes:

Destination | Target
10.0.0.0/16 | local
0.0.0.0/0   | i-cf8605ad (NAT instance id)

Custom route table is associated with a public subnet (10.0.0.0/24) and has following routes:

Destination | Target
10.0.0.0/16 | local
0.0.0.0/0   | igw-a4ed3aca (internet gateway id)

So given this setup, what would I need to do to gain an external access to the database servers that are on private subnet an are protected by a NAT instance? Do I need to add/alter the rules in the security groups?

Thanks in advance.


1 Answer: 

Your problem is a little bigger than security group changes. The main problem is that your private vpc is private as in 'not internet accessible'.

You have several options to connect from outside:

  1. Use a bastion machine as an intermediate hop (on the public net) and add relevant SG rules to hop form that machine into your precious DB. Your users will need to connect to that machine and then either run client tools on that machine to connect to the DB or setup a SSH tunnel to your DB (so your office machine could connect). This is not a great solution in term of users experience and in term of security (the bastion become a very big security risk) but it is simple to setup. (Note: since you are MS dude then please switch SSH for RDP [and cancel the tunneling thing])

  2. Setup a VPN - bring a big gun to shoot a fly. Setup a VPN (either use AWS VPN termination, or setup an OpenVPN or similar stuff). Define the routing, SG rules, Keys clients and update here if you managed to configure this within a reasonable effort. I would not go for a full site-to-site VPN (to your office network) since you do not want every malware running in your office to reach your 'private' data center.

  3. Create a little passthrough to your DB instance from your office. Ingredients: A custom route from your office IP to the private network, Proper SG rule to allow office IP to DB SG, Elastic IP to make the instance internet reachable.

You could improve solutions 1,3 security by utilizing Dome9's Access Leases. This will allow you to restrict access to the bastion/passthrough and to enable them on demand for authorized users (disclaimer - I'm a proud Dome9'er)

Enjoy