Cannot connect to Amazon RDS database - amazon-web-services

I've been trying to create and connect to a new DB on AWS for days. I made it publicly accessible.
I've done this but it can't connect:
HOST: vepo-qa-database.xxxxxxx.ap-southeast-2.rds.amazonaws.com
URL: jdbc:postgresql://vepo-qa-database.xxxxxxx.ap-southeast-2.rds.amazonaws.com:5432/
Why will it not connect?

Your Security Group inbound rule configuration is:
Allow Inbound traffic on any port as long as it comes from sg-1fefe550 (itself!)
This means that only resources associated with that same security group can communicate with the database. Therefore, it is blocking access from your own computer on the Internet.
To enable access to the database, you should add another Inbound rule that permits inbound access on port 5432 (PostgreSQL) from your own IP address.
(I'm also not sure why you have configured the security group to permit access from 'itself'. This is not a normal way to configure security groups.)

There is not enough information in your question to be certain, but here are two suggestions:
1 - verify that the subnets for the database actually are public and that there is a route to the IGW
2 - add a rule to the inbound security group rules to allow you to connect to port 5431. Generally you'd want to restrict this to just your IP address for a public instance.
Also, I'm not sure why you have 192.31.0.0 as part of your VPC range - that is a public IP range.

Related

Connecting to an RDS Instance that is on VPC

I am trying to connect to my AWS RDS Mariadb instance that I am hosting on us-east/ohio from my local machine. I am trying to avoid making the instance publicly available but I am struggling to get this connection to work. Right now I am trying to connect from my local machine but eventually, I hope to host a nodejs server to talk to it on a static ip.
The setup I have now is the following:
A single VPC that my RDS is connected to which includes a CIDR that contains my public ip x.y.z.0/24
A route table which includes my public ip to connect to local
Network ACL inbound and outbound rule number 1 is to allow All TCP from 0.0.0.0/0
The Default security group which also allows all inbound and outbound traffic
A VPC endpoint attached to the RDS service
With all of this set up I figured it should allow anyone that has the DNS name of my VPC endpoint to talk to my RDS instance but I can not get a connection to my instance. I have used every DNS name associated with my endpoint and every single one of them times out when I try to sign into the database. I have been fumbling with this for days and would like to get past this point of initial setup.
Things possibly to note:
The Network ACL comes with a default rule of "*" deny all traffic. I do not know what order that rule is evaluated. I chose 1 for my rule of allowing all but I have also tried rule 100. Neither seems to work.
I know my RDS instance is on us-east-2a and I have made sure to add the us-east-2a subnet to my VPC endpoint. Using the DNS name that includes that at one point was giving me network unreachable for a little bit before I realized the subnet ID I chose was not the default which just gave me a timeout again.
I am trying to use DBeaver to connect to the VPC endpoint but I have also used the console command mysql -h vpce-<random characters>-<VPC ID>-us-east-2a.rsa.us-east-2.vpce.amazonaws.com -u admin -p and gotten the same timeout

AWS Security group for RDS - Inbound rules

I created a MySQL instance in AWS RDS and selected the create new security group option which created a new security group as below
Inbound rule created with a specific allowed ip
This allows traffic from only the specified ip. In the public accessibility option I have selected yes.
Now, I am able to connect to this database on my local computer. I am not able to understand the point of this security group inbound rule and where this ip in inbound rule is coming from?
This is your public IP (at least for now). /32 is from CIDR, means that this is only one ip in this network (SG work with CIDT, not just IP).
So, RDS could be accessed only from you IP

Cannot access EC2 via HTTP/HTTPS

I recently had to completely rebuild my AWS EC2 environment, because I accidentally deleted the SSH key, thinking it was something else. Unfortunately, I cannot access my Tomcat instance which I have confirmed is running on that EC2 instance.
I have added the following security groups for inbound HTTP traffic:
Type. Protocol Port Range Source
HTTP TCP 80 0.0.0.0/0
HTTP TCP 80 ::/0
Custom TCP Rule TCP 8080 0.0.0.0/0
Custom TCP Rule TCP 8080 ::/0
SSH TCP 22 (my IP address)
I have three security groups, and the above rules were added to the group named default:
rds-launch-wizard
launch-wizard-1
**default
I purchased a domain via AWS which I have pointed to this EC2 instance using Route 53. Previously, the DNS was available, but now it is not. However, there is a bigger fundamental problem here because I can't even ping the public IP of my EC2 instance.
I am in fact able to access my EC2 instance via SSH on port 22, which is why I was able to setup Java and Tomcat (both of which I have confirmed are running).
I suspect that some state from my previous configuration is responsible for this problem, but I don't even know where to begin looking for something.
Any help would be appreciated.
To have inbound/outbound internet access to your EC2, you need to look for three things:
Are you able to SSH from outside or inside AWS via an internet gateway (IGW)? If you can SSH from outside then you already have IGW setup properly. Otherwise, make sure your subnet's route table points to IGW by having a route like below:
0.0.0.0/0 igw-efxxxxxxx Active No
Network ACL: Go to your EC2's subnet and find its associated NACL
Create both inbound and outbound rules to ALLOW traffic to the above NACL by adding a rule like below:
100 ALL Traffic ALL ALL 0.0.0.0/0 ALLOW
Security Groups: Your security groups look good. No changes required there. However, based on the comments you made below it appears that, while you did define a security group with the proper inbound rules, for whatever reason you did not associate that security group with your EC2 instance. As a result, the inbound rules you defined were not being applied. To fix this, from the EC2 instance tag access the following:
Actions -> Networking -> Change Security Groups
Then, associate your security group with your instance by checking the appropriate box. After making these changes, your inbound rules should take effect, and you should be able to hit your Tomcat instance running on EC2.

Amazon Security Group - Cannot Connect from within Other Security Group

My security group inbound rules are as follows:
WebAccess
HTTP TCP 80 0.0.0.0/0
SSH TCP 22 0.0.0.0/0
and
DB
MYSQL/Aurora TCP 3306 sg-0252186b (WebAccess)
My instances are setup like this:
Instance 1, web server - security group WebAccess
Instance 2, web server - security group WebAccess
Instance 3, DB server - security
group DB
If my understanding is correct, anyone should be able to access HTTP and SSH on my web servers, and only a member instance of WebAccess group should be able to access the DB server. However, the DB server is not accessible from the web servers.
When I change the 3306 rule to be open to allow inbound from anyone, I can access it fine (also from my local computer, as expected).
Please could somebody help me understand where I'm going wrong?
Thanks,
Chris
When you change the security-group to 0.0.0.0/0 and you are able to access the DB later on from your desktop that means your instance has been enabled for public access (i.e. having a public IP). When you connect to such a instance traffic leaves the subnet to the internet and comes back in. Because of that, the traffic no longer originates on your web instance but from the internet. You would need to use the web instances public IPs in that case.
Also please note, the way you have worded your question/comments, suggest you use the IP of the RDS instead of the hostname. This works if you use a single AZ RDS deployment. It won't work if you use multi-AZ or convert this RDS instance to multi-AZ (HA setup). The reason is, that during a failover AWS updates the DNS name to point to the new master. If your application is using an IP no fail over will occur.
Even worse: if you use an IP and single-AZ now but later decide to upgrade to a multi-AZ your application will continue to work until the first failover (most likely due to maintenance)

Amazon EC2 Security Group with Host / Dynamic IP / DNS

I am seeking some guidance on the best approach to take with EC2 security groups and services with dynamic IP's. I want to make use of services such as SendGrid, Elastic Cloud etc which all use dyanmic IP's over port 80/443. However access to Port 80/443 is closed with the exception of whitelisted IPs. So far the solutions I have found are:
CRON Job to ping the service, take IP's and update EC2 Security Group via EC2 API.
Create a new EC2 to act as a proxy with port 80/443 open. New server communicates with Sendgrid/ElasticCloud, inspects responses and returns parts to main server.
Are there any other better solutions?
Firstly, please bear in mind that security groups in AWS are stateful, meaning that, for example, if you open ports 80 and 443 to all destinations (0.0.0.0/0) in your outbound rules, your EC2 machines will be able to connect to remote hosts and get the response back even if there are no inbound rules for a given IP.
However, this approach works only if the connection is always initiated by your EC2 instance and remote services are just responding. If you require the connections to your EC2 instances to be initiated from the outside, you do need to specify inbound rules in security group(s). If you know a CIDR block of their public IP addresses, that can solve the problem as you can specify it as a destination in security group rule. If you don't know IP range of the hosts that are going to reach your machines, then access restriction at network level is not feasible and you need to implement some form of authorisation of the requester.
P.S. Please also bear in mind that there is a soft default limit of 50 inbound or outbound rules per security group.