In the last post we had a look at DB Parameter Groups when it comes to AWS RDS for PostgreSQL. This is one of the first things you should think about. But even before you think about PostgreSQL parameters you need to configure the networks your database instances shall be running in. In real life this is done by one of your network administrators and you will not have much to configure in this area. Anyway it is good to have a basic understanding about how that works and what you need for spinning up your instances. In AWS this all comes down to VPCs (Virtual private clouds) and Subnets, so lets briefly look at how this could be configured.
In our AWS test account I have configured my own VPC:
Inside this VPC I have configured three subnets (each of them in a separate availability zone):
To visualize that and to make easier to understand this is how it basically looks like:
Each of the subnets is attached to another availability zone and they are of course in different ranges. If you are not aware of this or do not configure that you will use the default VPC and default subnets that AWS created for your account. The same will happen for the subnet groups when it comes to RDS: You’ll get the default to make it easy to spin up your instances. In real life you should be aware what is happening in the background and why the various bits are required and this is why we will create the subnet group for our PostgreSQL RDS instances on our own and it the same reason why we had a brief look at the VPC and the subnets just above: Be aware of what the services are doing and what is required in the background. It is really easy to get started with a specific service by using the default, but at some point in the future you will need to look into more details and then it is getting much more complicated to get existing deployments right.
Coming back to the RDS subnet groups: When you deploy a new RDS instance you will be asked for the subnet group to put the new instance onto. Why do we need that? Well, on the one hand you want your new instance to be reachable somehow and for that you need IP addresses. The subnet group defines which IP addresses can be used for the new instance. On the other hand, if you want to make your instance high available you want to make sure, that the replicas are not running in the same availability zone. This is why all my three subnets are attached to a dedicated available zone. You can well go and create three subnets in the same availability zone, but this is not what you want when you want to make your deployment highly available (AWS RDS will not allow you to use subnets that are in the same AZ anyway).
Let’s go ahead and create our subnet group in the AWS RDS console:
As usual, we need a name, an optional description but we also need to select the VPC (which is the VPC described above):
As we’ve prepared the subnets already, we can just add all the subnets of the VPC:
That was the second building block when it comes to AWS RDS for PostgreSQL (actually it is the same for the other flavors of RDS). Now we have the DB Parameter Group and we have the Subnet group. In the next post we’ll be really bringing up a PostgreSQL RDS instance which uses the DB Parameter Group we’ve created and the subnet group we’ve configured in this post.