Getting Started on AWS RDS

I’m expanding my skill set into AWS in a big way. So, one of the things I do when I’m learning a technology is to write blog posts about that tech. So, prepare yourself for a bunch of info on AWS. I’ll be working with RDS, which will include SQL Server & PostgreSQL for certain. I’ll also be posting quite a bit on AWS DevOps as I get into it.

The usual stuff, including SQL Server, query tuning, Extended Events, Azure, Azure DevOps, and all the rest is not going away. I’m just adding another topic.

Today, we’re getting started on AWS RDS.

Creating an RDS Instance

The thing is, there’s a lot of documentation available on getting started on AWS RDS, directly from Amazon. It’s embedded neatly into the AWS Console. However, I did find a few hiccups and bumps along the way. Partly that’s in how I do things (poke first, read later) and partly in how the documentation was written.

I’m going to do the most bare bones of configurations this time. We can get into all the permutations as needed in other posts. I’m going to assume you can set up your own AWS account. They have a free tier, so you can do what I’m do, learn by doing. I’ll leave you to find your own way to the RDS page. It’s easy. However, when you get there, you’ll be presented with this:

However, we’re focused right here:

We’re looking at the “Create database” button. You may also see one at the top of the page. Clicking on this button opens the following:

I’m going to switch a bunch of stuff for our example here. First, we’re going with “Easy Create.” Then, we’ll pick “Microsoft SQL Server” and finally, we’re going for the free tier. Ultimately, our screen will look like this:

If you scroll down there are several other things you’ll need to fill in. The guidance through all this is excellent, so you won’t have a hard time:

It’s all straight forward. Give your instance a name. Set up a sql login to manage it. Generate a password or provide your own. I chose to set my own up. I have a single password I use for all test instances. Yeah, that means you can hack my test instance. Have fun with an empty database.

Scroll down a little further and we see the “Create database” button as shown here:

If you want to look at all the details you skipped, you can expand the section that says “View default settings for Easy create.”

However at this point, we’re done if you’re just setting up a quick database to work with.

After Creating the Instance

The create process will take a couple of minutes. Go grab a cup of coffee, check your email, or ping me on Twitter. You’ll see this page immediately, but your instance will still be creating. After it’s done, you’ll see the following:

You’ve got a SQL Server instance available. Have fun.

However, I want to get into the instance and control it externally, from my laptop. So I have a few more things I need to do. If you click on the instance you’ve created, you’ll see the following in the console:

First thing I’m going to do is make this instance publicly accessible. If you’re going to work strictly within AWS, you may not want to do this. However, since I have all my tools & such on my laptop, and this is strictly a test & dev machine, I feel perfectly comfortable doing this. To make it happen, I have to hit the Modify button.

This opens a new screen. I’m going to scroll down until I find the Security section:

I’m going to change the bottom setting, from “No” to “Yes”. That’s it. Keep scrolling. At the bottom of the screen is a button, “Continue.” Click that and you’ll be presented with this:

Again, I’m going to make one change. You’ll see that by default, it’s going to make the changes during the next maintenance window, in my case, next Wednesday. Normally, a good choice. However, for a test instance, I’m not waiting until Wednesday. So I’m going to hit “Apply immediately.” That will affect existing connections and processes, so, on a production instance, a bad choice. Once done, I hit “Modify DB Instance” and I’m done.

Poke A Hole in the Firewall

I’ve been saying it for years and years. The cloud is inherently secure. It’s on you to muck up the security. So, let’s do that. Now that my server will have a publicly available IP address, we still have to provide access to it because, by default, there is a locked down firewall in place. Back on the instance page, over on the right, you’ll see something like this:

You’ll have to wait for the modification to be complete for the “Public accessibility” to be set to “Yes”. However, the basics will be there. What we want is to click on the “VPC security group”. I prefer to right click on it and open it in a new tab (ctl-click, whatever). We’ll get a VPC listing, filtered on that VPC. Click on it again to get to the list of firewall rules like this:

Note at the bottom, I already have a rule for MSSQL, which is what we’re going to create. That’s because I already have some test instances in AWS and I’m using the same VPC to manage them. If you’re just getting started on AWS on RDS, you’ll only see the “All traffic” incoming rule.

Assuming you don’t have that in place, you’re going to do the following. First, click “Edit Inbound Rules” button over on the right. That’s going to open your rules. Then, click on the “Add Rule” button to get to here:

With that done, drop the box that says “Custom TCP”. Scroll down and select “MSSQL”. Then, go to the dropdown that says “Custom”. Select how you want to expose this. You can select Custom, in which case you supply the IP address range. You can select Everywhere, in which case you’ve opened yourself to the internet (probably not an ideal choice, even for a test instance). Finally, you can select My IP, which will show your current IP address. That’s usually what I pick, with the full knowledge that at some point in the future, dynamic IP allocation being what it is, I’ll have to update it.

Click on “Save Rules” and you’re done.

That’s it. If you want to connect remotely now, you can. The connection setting is right there on the instance window. You can see mine for this example here:

Just put that string that is under “Endpoint” into SSMS or ADS and you’re good to go. Since we accepted the default port, 1433, you shouldn’t need to worry about that, but if you do, add a comma & 1433 to the end of the connection string.

Conclusion

There’s not that much to doing this. It’s easy. Once you’re connected in, you’re just looking at, in this case, a SQL Server instance. Fire up T-SQL and run the command CREATE DATABASE and you’re off to the races. From there, largely, it’s just SQL Server and everything gets boring. Yeah, there are quite a few exceptions to that statement, but the overall message is accurate. I hope this helps you get started on AWS RDS.

Feel free to put in requests for specifics in and around the RDS platform. I think next time I may post on getting going with PostgreSQL in RDS.