2

I've taken these steps:

  • Created an AWS account
  • Spun up an MS SQL Server Express instance
  • Added a security group for TCP 1433, my IP, prefix 32
  • Added forwarding for my home firewall, for port 1433, to my dev computer
  • Using SQL Management Studio on this machine, I attempt to connect to the server name shown in the AWS console, using the sa account name and password I specified earlier

I get "Cannot connect... network-related error... The parameter is incorrect".

On a LAN, my next thing to check would be that remote administration and TCP is enabled for the SQL instance. However, obviously any administration of a cloud machine will be remote, and the default parameter group has remote access turned on, so I presume this is set by default.

Connecting via RDP, the instance shows no SQL-related software installed. I suspect that the RDS instance needs to be associated with the Windows instance somehow, or perhaps if I want RDP access to the server underpinning an RDS, I need to install it on the server as an app, rather than using RDS.

These basic things have been surprisingly difficult to Google; it seems that the switch between EC2 and VDC has left conflicting sets of documentation floating out there.

  • Small update: based on docs.aws.amazon.com/AmazonRDS/latest/UserGuide/…, I tried connecting to the instance endpoint (mydbname.subdomain.region.rds.amazonaws.com) with the port separated by a comma instead of a colon. This gives "...network-related error...attempt failed because the connected party did not respond..." – user49214 Apr 9 '14 at 13:12
  • Leaving out the port from the server name in Mgt Studio (1433 is the default, after all), I get "...network-related error...network path was not found". My machine can resolve the instance path, so there's that, but pings are not returned. – user49214 Apr 9 '14 at 13:14
  • did you enable remote connections via Named Pipes in the SQL configuration manager? also have you considered using a different port? many ISPs block 1433 traffic. – Frank Thomas Apr 17 '14 at 2:02
  • I haven't been able to get RDP to work yet, with which to check that kind of detail, though AWS trumpets its convenient out-of-the-box configuration. I've spent hours going in circles through the AWS console trying to find ways to config this (and, per your suggestion, listening ports), without success. – user49214 Apr 17 '14 at 18:45
  • Attempting to connect using the IP address and creds of the RDP instance did not work either: "...server was not found...network path was not found." – user49214 Apr 18 '14 at 3:42
0

Make sure the database instance is publicly accessible. Go to your RDS dashboard, then view the instance details.

If it's not, then you'll have to recreate the instance. There doesn't seem to be a way to change this option.

0

I had a similar issue when using RDS. I solved it:

  • I had used private subnets (no NAT box) instead of public ones
  • There were 2 routes, not one.

After I changed to public subnets (created a new one to join the current one to form the new subnet group - I then destroyed the instance, subnet group and recreated them), I still couldnt connect and found that when I created the second public subnet, I had 2 different routes (and my SQL server had an IP from the newly created subnet. Changed the route to the one the first public subnet was using.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy