skip to Main Content

In AWS account I created VPC1 using option “create vpc and more” so it creates the entire package with subnets route tables etc automatically. I used default 10.0.0.0/16 cidr block. I created simple RDS Postgres instance and attached security group that allowed all traffic both ways.

I can connect to the database with no problem.

Then I did the same for VPC2 but used non-overlapping cidr of 10.1.0.0/16 and created postgres RDS with security group that allows all traffic both ways. However, the connection times out when I want to access it.

Just to check, I created yet another VPC3 this time again with cidr 10.0.0.0/16 while VPC1 was still in place with its RDS postgres running. On VPC3 I created a postgres RDS with security group that allows all traffic both ways. I can connect to the database.

I repeated this scenario many times deleting and creating VPCs and RDS database instances back and forth so I do not think that there is a place for copy-pasting credentials wrong etc. Every time I make sure that the RDS instance has “publicly available” set to “yes”.

How is that possible? Am I not allowed to use 10.1.0.0 as my cidr for VPC2? How should I proceed?

2

Answers


  1. Chosen as BEST ANSWER

    Thank You for all the contributions! After an investigation it turned out that I was creating the vpc with default settings meaning that I had 2 public and 2 private subnets created. When I was creating and RDS instance subsequently I leaft automatic creation of subnet group leading to it including private subnets too. As a result the RDS was landing in the private subnet that is why I could not access it. For anyone having similar issue and reading this post in the future I suggest doing following: before creating RDS instance, manually create a subunet group in RDS menu (on the left panel there is a dedicated place where You can do it). In there create a subnet that consists only of public subnets. Only then proceed to creating the RDS instance and do not leave automatic subnet-group creation but choose the existing one that You just created.

    I know this is not following best practices as I learned that typically databases should be in private subnets but this is another topic.

    I consider my problem solved. Thank You to everyone that contributed to help me solve the issue and I hope this can be helpful for someone in the future.


  2. To reproduce your situation, I did the following:

    • Created a VPC in two AZs with public subnets and a CIDR of 10.1.0.0/16:

    AWS VPC

    The subnets are:

    VPC Subnets

    • Launched an Amazon RDS PostgreSQL database (Free Tier, t3.micro, gp2, new subnet group, new security group, public access = Yes)
    • Modified Security Group to permit access from 0.0.0.0/0 (instead of the default "My IP")
    • Waited for database to be available
    • Used DBeaver to connect to the database
    • Connection was successful

    DBeaver RDS

    So, it would appear that the problem is with your particular configuration of the Amazon RDS database.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search