I'm trying to connect to my new AWS RDS I just made.
I followed the "Setting up for RDS" (https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SettingUp.html), then the "Tutorial: Create an Amazon VPC for Use with a DB Instance" (https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Tutorials.WebServerDB.CreateVPC.html), then the "Creating a MySQL DB Instance and Connecting to a Database on a MySQL DB Instance" (https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_GettingStarted.CreatingConnecting.MySQL.html) but I'm not able to connect to my DB from my computer or my dedicated server on the web.
Following the previous docs, I have this config :
My DB instance
The VPC
The subnetworks
Example of subnetwork's details :
The first security group :
The second security group, calling the first one :
For the first security group, I put both my private IP and the IP of my dedicated server, and their ports.
I even tried to put 0.0.0.0/0 for SSH and TCP, it didn't work either.
For the DB instance, I tried to add the two security group instead of only the db-securitygroup, it didn't work.
I tried to use a different Port for the DB instance, it didn't work.
With MySQL Workbench or with PDO on my dedicated server, I'm unable to connect to the DB : "SQLSTATE[HY000] [2003] Can't connect to MySQL server on [...]"
I think your security groups are incorrect. If the RDS instance is the only thing you currently have running in the VPC, then you should only have one security group, which is assigned to the RDS server, and that security group should have a rule for port 3306 that allows ingress from your personal IP address, and your dedicated server's IP address.
Take a look to this instruction, pay attention to step 3, 4 and 5. It is for ElasticSearch but I think in your case steps are similar
Related
I am trying to migrate to use private IP:s for all our Cloud SQL instances. I have gotten it working for postgres, and am now trying to get access for our wordpress instances using MySQL.
The problem is I cant get the connection working from the running pods in our GKE cluster.
root#******:/var/www/app# mysql --host=10.**.**.* -u *_se -p
Enter password:
ERROR 2003 (HY000): Can't connect to MySQL server on '10.*.*.*' (110 "Connection timed out")
I have activated the private IP on the Cloud SQL instance, and added a private service connection to the VPC-network that is the same network that our cluster uses, but still cant connect in the same way as I did with postgres.
Does anyone know anything I could try to get this working?
There are specific network requirements Cloud SQL instances must
adhere to when communicating via a private connection. One of which
is that your Cloud SQL and GKE instances are located in the same
region and VPC network. Check this to configure private IP for MySQL.
The GKE cluster must be VPC-native and peered with the same VPC
network as the Cloud SQL instance. To connect MySQL from GKE, refer
to this Google documentation.
Note: If you are using shared VPC networks, you cannot assign a
private IP address in a shared VPC network to an existing Cloud SQL
instance. Also, VPC Network Peering uses private services access.
However, you do not create the VPC Network Peering explicitly, because
the peering is internal to Google Cloud.
Some possible causes of mentioned error are as follows:
Network failure especially if MySQL database server is running on a remote host.
No MYSQL server is running on the mentioned host.
Firewall blocking TCP-IP connection or other related reasons.
I would suggest you check the firewall setting and check if your MySQL server is listening on default port 3306. Also try to connect MySQL server on IP for which MySQL server is bound in 'my.cnf’. If it not so, run the following command to bind address if you are using Ubuntu:
1. Run the command vim /etc/mysql/my.cnf or vim /etc/mysql/mysqld.conf/mysqld.cnf
2. Comment bind-address = <Server IP> using the # symbol
3. Restart your MYSQL server once.
I was trying to use AWS Aurora Serverless for MySQL in my project, but I am impossible to connect to it, though I have the endpoint, username, password.
What I have done:
From AWS console managment, I select RDS > Instances > Aurora > Serverless
Leave the default settings
Create database
AWS will only create an AWS Cluster
I open MySQL Workbench, and use endpoint, username, password to connect the database
Ressult:
Your connection attempt failed for user 'admin' from your host to
server at xxxxx.cluster-abcdefg1234.eu-west-1.rds.amazonaws.com:3306:
Can't connect to MySQL server on
'xxxxx.cluster-abcdefg1234.eu-west-1.rds.amazonaws.com' (60)
Did I make any wrong steps ? Please advice me.
****EDIT****
I tried to create another Aurora database with capacity type: Provisioned. I can connect to the endpoint seamlessly with username and password by MySql workbench. It means that the port 3306 is opened for workbench.
About the security group:
From https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/aurora-serverless.html :
You can't give an Aurora Serverless DB cluster a public IP address.
You can access an Aurora Serverless DB cluster only from within a
virtual private cloud (VPC) based on the Amazon VPC service.
You can't access an Aurora Serverless DB cluster's endpoint through an
AWS VPN connection or an inter-region VPC peering connection. There
are limitations in accessing a cluster's endpoint through an
intra-region VPC peering connection; for more information, see
Interface VPC Endpoints (AWS PrivateLink) in the Amazon VPC User
Guide. However, you can access an Aurora Serverless cluster's
endpoint through an AWS Direct Connect connection.
So, aside from SSH-ing through an EC2 instance, you can also access your serverless cluster with mySQL Workbench with AWS Direct Connect.
You can also set up a mySQL Workbench through a RDP connection to a Windows EC2 and access the Serverless cluster. This instance only needs to be up when you need to access the Aurora.
If one of the setups here don't work, the usual suspects are the VPC Security group, firewall rules vs port number configured on the cluster or IAM configuration if connecting using IAM.
One way to connect to an Aurora Serverless DB cluster is by using an Amazon EC2 instance. You cannot
create publicly accessible Aurora Serverless DB clusters in the Preview. This task walks you through
creating a publicly accessible Amazon EC2 instance in your VPC. You can use this Amazon EC2 instance to
connect to an Aurora Serverless DB cluster.
This is directly from the docs provided upon preview signup. Please try creating an EC2 instance and using SSH Tunnel method in your MYSQL Workbench or SQL UI of choice. During the preview the Aurora Serverless is not allowed to be set to publicly accessible.
To connect to Aurora serverless or any database in private subnet you will need a 'jump host' which can be any EC2 instance in a public subnet.
Follow Below Steps:
Open the security group attached to the database, and add new rule as below:-
Type:MYSQL/Aurora, Protocol:TCP, PortRange:3306,
Source:securitygroupofEC2 (you can all security group by entering
'sg-')
Open the security group attached to the EC2, and make port 22 is open. If not, add a new rule as below:-
Type:SSH, Protocol:TCP, PortRange:22, Source:MY IP
Open Workbench, Click New connection
- Standard TCP/IP over SSH
- SSH Hostname : < your EC2 Public IP > #34.3.3.1
- SSH Username : < your username > #common ones are : ubuntu, ec2-user, admin
- SSH KeyFile: < attach your EC2 .pem file>
- MYSQL Hostname: <database endpoint name> #mydb.tbgvsblc6.eu-west-1.rds.amazonaws.com
- MYSQL Port: 3306
- Username : <database username>
- Password: <database password>
Click 'test connection' and boom done!!
A common pattern used by customers for connecting to VPC only services (like Aurora Serverless, Amazon Neptune, Amazon DocDB etc) is to have a middle layer (EC2 instance, or ALB etc) and making the middle layer accessible from outside the VPC. If your use case is just trying out some queries or connecting a workbench, then the easiest thing to do is:
Resolve the DNS of the serverless db and obtain its IP
Create an ALB in your VPC, with a target group to the IP that you found in #1
Create a new security group and attach that to your ALB
Update the SG to allow inbound from where ever you want. If you want public internet access, then allow inbound from all IPs, enable an internet gateway in your VPC, and use a public subnet for your ALB.
Once all of this is done, you would end up with a new DNS - that points to your ALB. Make sure that your ALB is set up correctly by:
Using telnet to connect to your ALB endpoint. telnet alb-endpoint alb-port. If it succeeds, then you have a full end to end connection (not jsut to your ALB, but all the way through).
Verify ALB metrics to make sure that all health checks are passing.
Once this is done, use the ALB endpoint in workbench, and you are good to go.
This pattern is recommended only for non production systems. The concerning step is the one where you resolve the DNS to an IP - that IP is ephemeral, it can change when scale compute or failover happens in the background.
Hope this helps, let me know if you need more details on any step. Here is a related answer for Neptune:
Connect to Neptune on AWS from local machine
We can't connect Aurora Serverless directly from MySQL Workbench as only private IPs assigned to Aurora Serverless, not public IP ones.
We can connect Aurora Serverless from EC2 but can't connect Aurora Serverless through the Mysql Workbench SSH tunnel.
We can't connect Aurora Serverless through ALB as ALB allow only HTTP and HTTPS traffic.
you can telnet ALB-RDS-DNS from local but can't connect to MySQL Workbench
Then what is a solution here;
We can connect Aurora Serverless through NLB as NLB allow traffic over TCP protocol;
Steps 1: Create NLB and add listener Load Balancer Protocol: TCP, and Load Balancer Port
:3306
Step 2: Select the VPC (It should be the same VPC of Aurora Serverless Cluster), and add subnets (public)
Step 3: Navigate to Configure Routing, select Target type: IP, and Protocol: TCP,Port:3306
Step 4: Use DNS Checker to get private IP of Aurora Serverless Cluster, and add those IPs with port 3306
Step 5: Create NLB
Now modify the Security group of Aurora Serverless Cluster, allow traffic from either 0.0.0.0 (not recommended) or VPC CIDR
Now, go to Mysql Workbench and use the NLB DNS name, and try to connect using the correct username and password of Aurora Serverless Cluster.
New AWS Feature: Aurora Serverless v2.0 Public IP Address Available
Like many of you I've been waiting and hoping for this for some time.
As of today April 27, 2022 RDS Aurora MySQL Serverless now has a Public option. You must create a separate security group for that option and set inbound rules.
Copy your endpoint, user, and password and you're good to go.
Look at the Comparison of Aurora Serverless v2 and Aurora Serverless v1 requirements
Worked like a charm for me.
Data API and Query Editor for connecting to Aurora Serverless are now available in some more regions.
https://aws.amazon.com/about-aws/whats-new/2020/05/amazon-rds-data-api-and-query-editor-available-additional-regions/
You should be using an EC2 instance that has access to your dbinstance.
This EC2 instance should have port 22 opened for ssh.
Now use port forwarding from local to EC2 to db instance.
Now in your work bench give hostname 127.0.0.1 and port <forwarded port>.
Aurora serverless does not have public endpoint to connect from any of the ide like MYSQL workbench,Sequel pro etc. But we can connect through cli by launching an instance in same vpc in which aurora serverless resides.
Besides you can checkout cloud9 an aws cloud ide. This is in turn ec2 only but will have UI also and can be shared with teams and bunch of other features.
Initially, I was got stuck in the same scenario
Points to be noted while connecting AWS RDS Aurora
Cant connect Public, you need an EC2 instance with the same region where Aurora is been created.
Aurora Public access should be checked No(it worked for me).
You need to create the security group, where you should add Inbound and Outbound rules(IpAddress of EC2 instances).
Ex: Type = MYSQL/AURORA, Protocol=TCP, PortRange=3306,Source=Custom and your IP Address Range,
modify instance and security group to the instance and apply the changes immediately.
While creating Aurora, u will create MasterName, Pwd, and default schema to connect.
After creating, go to cluster and take the cluster endpoint and log in with your EC2 Instance and with MySQL Workbench, Hostname as your cluster endpoint, username and pwd entered while creating aurora database.
This can be achieved using haproxy
Install Haproxy on Centos-> yum install haproxy
delete existing configuration in this file /etc/haproxy/haproxy.cfg and add the below lines(make sure you replace your RDS endpoint url in below configuration)
global
user haproxy
group haproxy
defaults
retries 2
timeout connect 3000
timeout server 5000
timeout client 5000
listen mysql-cluster
bind 0.0.0.0:3307
mode tcp
server mysql-1 test.cluster-crkxsds.us-west-2.rds.amazonaws.com:3306
After modifying the file,start the haproxy -> service haproxy start
You can connect Aurora RDS in MYSQL Workbench using Public IP with port no 3307
We have installed softether vpn in one of ec2 instance in vpc public subnet. We connected the softether vpn from linux / mac os / windows like regualr vpn. After then we were able to access all the private resources like aws aurora serverless as like regualr endpoints from mysql workbench, pgadmin, etc tools, even the django admin shell commands from local computer.
Hope this should help.
https://www.softether.org/4-docs/1-manual/2._SoftEther_VPN_Essential_Architecture/2.4_VPN_Server_Manager
My guess is your security group is not correctly setup for access. You need to explicitly allow remote access on that port to that instance.
From the official docs:
Two common causes of connection failures to a new DB instance are:
The DB instance was created using a security group that does not authorize connections from the device or Amazon EC2 instance where the
MySQL application or utility is running. If the DB instance was
created in a VPC, it must have a VPC security group that authorizes
the connections. If the DB instance was created outside of a VPC, it
must have a DB security group that authorizes the connections.
The DB instance was created using the default port of 3306, and your company has firewall rules blocking connections to that port from
devices in your company network. To fix this failure, recreate the
instance with a different port.
See here for more information:
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToInstance.html
I'm having difficulty to connect mysql Workbench to RDS. I contacted amazon support and they told me this
"I've looked at the configuration of the EB environment and the SG's and they're now in good order, the only item left, as I see its not possible to connect to the RDS DB remotely, the SG sg-882213c3 needs to have another rule added to allow connectivity from the computer with the mysql client. Perhaps, allow 0.0.0.0/0 to TCP port 3306 for temporary access or from the source IP of the computer."
so what I did is this
but the connection still failing
the pervious steps are
I created new new DB Instances called east-mysql2-instance1. For east-mysql2-instance1 Security group is set to rds-launch-wizard (sg-882213c3) and i did modify the inbound to Source sg-882213c3 (rds-launch-wizard). but it wont let me change the type to Mysql/Aurora it stays at custom TCP Rule.
for EC2 Instance I have 2 running instances and I changed both Security groups to
rds-launch-wizard and awseb-e-bdbjjgxvzd-stack-AWSEBSecurity
I terminate my old environment and created new one called Borroup-env-1, I changed the EC2 security groups for the environment to awseb-e-bdbjjgxvzd-stack-AWSEBSecurityGroup-1PTJG896MEOYR and rds-launch-wizard.
I changed Environment properties and added RDS_DB_NAME, RDS_HOSTNAME, RDS_PASSWORD, RDS_PORT, RDS_USERNAME
From your second screenshot, it looks like you are setting up a connection that is:
SSH from your mac desktop to an ec2 instance
connect form the ec2 instance to RDS
If this is the situation you are wanting to achieve I would not be leaving a rule allowing 3306 from 0.0.0.0/0. This is allowing any IP address in the world to connect on port 3306 - a well known port. Additionally, that advice seems to suggest putting that rule against the RDS instance? Overkill - only needs to allow access from your EC2 instance or its subnet.
The first step I would take is use SSH on terminal to verify you can SSH from your mac to the EC2 instance - if this is not working, no point looking at SGs and rules between EC2 and RDS. Once that is working, you can move forward to resolving the connectivity from the ec2 to the RDS. As John noted above, if both the RDS and the EC2 are in the same VPC, you can setup a SG allowing access to the RDS instance from the subnet that the EC2 is in.
As an alternative solution, you can also setup to allow access to the RDS instance directly, without going through the EC2. See Public Accessibility and also subnet requirements here: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html Depends on what kind of setup you want...
If the EC2 and RDS are not in the same VPC but are in the same region, you may want to look at setting up VPC peering: https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-peering.html If they EC2 are RDS are not in the same region or same VPC, you may want to setup Inter region VPC peering: https://aws.amazon.com/about-aws/whats-new/2017/11/announcing-support-for-inter-region-vpc-peering/
It sounds like you wish to connect from an Amazon EC2 instance to an Amazon RDS instance. Assuming that they are both in the same VPC, the easiest way to configure it is:
Create an App-SG security group and associate it with the EC2 instance. Grant whatever access you need to login/use the instance.
Create a RDS-SG security group and associate it with the RDS database. Permit inbound access from the App-SG security group on port 3306 (MySQL/Aurora).
This basically says that any resources associated with App-SG will be permitted to access any resource associated with RDS-SG.
If that doesn't work, then there's something else (aside from security groups) that needs to be configured.
From EC2 instance i-78a8df00, I'm trying to connect to RDS instance mysql.************.us-east-1.rds.amazonaws.com. They are both in the U.S. East region. I added the security group of EC2 instance (sg-********) to the RDS security group, but that didn't help. It appears to be a firewall/DNS issue as it is timing out when running this command:
ubuntu#ip-10-195-189-237:~$ mysql -h mysql.************.us-east-1.rds.amazonaws.com
ERROR 2003 (HY000): Can't connect to MySQL server on 'mysql.************.us-east-1.rds.amazonaws.com' (110)
I can connect to RDS instance fine from my local machine using the same line as above. I tried various forum solutions but those don't help.
I had similar problem, when I spun a new EC2 instance, but didn't change setting in RDS security group of inbound IP address allowed to connect to port 3306 of my RDS instance.
The confusing bit was an option in RDS dashboard, called Security Groups. You don't need it to solve the problem.
What you really need is:
Go to list of RDS instances
Click on the instance you are trying to connect
Click Security group rules section
This should open a new browser tab or window with details of security group.
Locate several tabs in bottom part, select Inbound rules tab and click Edit button.
Change value to the IP address of your EC2 instance or IPv4 CIDR blocks, e.g.
174.33.0.0/16
To get this value, you can either ssh into your instance and run ip addr or run EC2 Manager in browser and locate value of Private IPs in your instance details.
Additional information for people who might run into similar issues trying to connect to RDS or RedShift:
1) Check security groups
Verify the security group for the RDS instance allows access from the security group your source server belongs to (or its IP added directly if external to AWS). The security group you should be looking at is the one specified in the RDS instance attributes from the RDS console UI (named "security group").
NOTE: Database security groups might be different from AWS EC2 security groups. If your RDS instance is in classic/public EC2, you should check in the "database security group" section of the RDS UI. For VPC users, the security group will be an normal VPC security group (the name sg-xxx will be listed in the RDS instance's attributes).
2) Confirm DNS isn't an issue.
Amazon uses split DNS, so a DNS lookup external to AWS will return the public IP while a lookup internal to AWS will return a private IP. If you suspect it is a DNS issue, have you confirmed different IPs are returned from different availability zones? If different AZs get different IPs, you will need to contact AWS support.
3) Confirm network connectivity by establishing a socket connection.
Tools like tracepath and traceroute likely won't help since RDS currently drops ICMP traffic.
Test port connectivity by trying to establish a socket connection to the RDS instance on port 3306 (mysql, or 5432 for postgres). Start by finding the IP of the RDS instance and using either telnet or nc:
telnet x.x.x.x 3306
nc -vz x.x.x.x 3306
a) If your connection attempt isn't successful and immediately fails, the port is likely blocked or the remote host isn't running a service on that port. you may need to engage AWS support to troubleshoot further. If connecting from outside of AWS, try to connect from another instance inside AWS first (as your firewall might be blocking those connections).
b) If your connection isn't successful and you get a timeout, packets are probably being dropped/ignored by a firewall or packets are returning on a different network path. You can confirm this by running netstat -an | grep SYN (from a different CLI window/session while running and waiting for the telnet/nc command to timeout). Connections in the SYN state mean that you've sent a connection request, but haven't received anything back (SYN_ACK or reject/block). Usually this means a firewall or security group is ignoring or dropping packets.
Check to make sure you're not using iptables or a NAT gateway between your host and the RDS instance. If you're in a VPC, also make sure you allow egress/outbound traffic from the source host.
c) If your socket connection test was successful, but you can't connect with a mysql client (CLI, workbench, app, etc.), take a look at the output of netstat to see what state the connection is in (replace x.x.x.x with the actual IP address of the RDS instance):
netstat -an | grep x.x.x.x
If you were getting a connection established when using telnet or NC, but you see the 'SYN' state when using a mysql client, you might be running into an MTU issue.
RDS, at the time this is written, may not support ICMP packets used for PMTUD (https://en.wikipedia.org/wiki/Path_MTU_Discovery#Problems_with_PMTUD). This can be a problem if you're trying to access RDS or RedShift that's in a VPC from a classic ec2 instance via ClassicLink. Try lowering the MTU with the following, then testing again:
sudo ip link show
# take note of the current MTU (likely 1500 or 9001)
sudo ip link set dev eth0 mtu 1400
If the lower MTU worked, be sure to follow up with AWS customer support for help and mention that you are seeing an MTU issue while trying to connect to your RDS instance. This can happen if TCP packets are wrapped with encapsulation for tunneling, resulting in a lower usable MTU for packet data / payload. Lowering the MTU on the source server allows the wrapped packets to still fit under the limit.
If it didn't work, set your MTU back to it's default and engage AWS support for further troubleshooting.
While Mark's problem seemed to have something to do with multi-AZ routing & EC2 classic, I ran into this exact same problem today.
To fix it, I modified the Security Group that was created automatically with my RDS instance by adding the two private IP addresses from my EC2 instance.
This was a fairly obvious problem, but I'm new to AWS in general, so hopefully this is useful for others like myself.
Apparently, multi-AZ screws everything up. Since the default multi-AZ config placed my database in region us-east-1d, and my EC2 instance was in region us-east-1a, the DNS was not routing correctly. I re-created the RDS instance as non-multi-AZ, and made it live in us-east-1a, and all is happy.
If there are any super geniuses out there in regards to DNS routing on AWS with RDS, ELB, and multi-AZ capabilities, it would be pretty awesome to know how to do this, since this isn't documented anywhere in Amazon Web Service's documentation.
After struggling for 3 days I finally found why mine was not connecting ...
Add outbound rule on your EC2 instance for port 3306 and inbound rules on your RDS server on port 3306. The inbound value should be the security of the EC2 instance
Example:
Your EC2 security group is - sg.ec2
And RDS security group is - sg.rds
So go to edit outbound rules of sg.ec2 and add Custom TCP at port 3306 and destination to 0.0.0.0/0
Then, go to edit inbound rule of sg.rds and add an inbound rule at port 3306 and source as sg.ec2
I had the similar problem today when my EC2 instance suddenly lost access to RDS instance and Wordpress stopped working. The security groups were correct and I could even connect to MySQL from console on EC2 instance but not from PHP. For some reason restarting EC2 server helped me.
Looks like sometime between the last posting and this posting, Amazon fixed the DNS routing issue, because everything works fine now for multi-AZ rds...
Solution: I had to adjust the inbound rule of the RDS instance's security group to allow connections from the IP address of my EC2 instance.
Longer explanation: When creating an AWS RDS instance I selected the option to be able to connect to it via public IP address. In doing so I ASSUMED that I would then be able to connect to it from ANY IP Address, but that was not the case. Rather, when the instance got created/configured, it took the public IP address of my laptop and set the inbound rule of the RDS security group to only accept connections from that IP address. So I had to manually add a rule to allow incoming MYSQL/Aurora connections from IP address of the EC2 instance.
I ran into the same issue, I was not able to connect from EC2 instance to the RDS both resources in the same VPC and multi AZ setup.
The multi-AZ setup was not a problem for me.
I was missing only the OUTBOUND rule 3306 from my EC2 instance Security group, to my RDS Security group.
According to the Amazon doc, we should use:
PROMPT> mysql -h <endpoint> -P 3306 -u <mymasteruser> -p
where endpoint and mymasteruser(username) are from your RDS instance.
I solved that problem using IP public adress directly(of the endpoint) instead of the endpoint(****.us-east-1.rds.amazonaws.com).You can get the ip public address using "ping" command(ping ****.us-east-1.rds.amazonaws.com)
I keep running into this error while connecting to my newly built RDS MySQL instance
ERROR 2003 (HY000): Can't connect to MySQL server on
'****.ap-southeast-1.rds.amazonaws.com' (60)
I wouldn't say I am an expert, as I have several EC2 instances running and able to connect.
And I have all the security groups created and necessary permissions for inbound added accordingly. But i just quite connect to the RDS instance.
1. I have re-recreated with guide from AWS document, created new VPC group and dedicated DB security group.
2. Gone through most of the responses from similar questions, and applied the suggested resolutions (which is adding own public IP in the inbound rules) etc..
Any help?
1)
Make sure that the server is running
telnet ****.ap-southeast-1.rds.amazonaws.com 3306
2) Make sure that the server is not bind to specific address.
bind-address = 127.0.0.1
3) Make sure that the IP address that you have added to security group is correct. Don't forget the /32 for a single ip. You can get IP address from
/sbin/ifconfig
4) Make sure that there are no firewalls on outbound traffic on the host from which you are trying to connect
Does your RDS configured as publicly accessible? If not, you can only connect it within your VPC.
Thanks everybody. I was able to resolve the problem. The supported platform uses the EC2,VPC, so my AWS account is in the current region that does not use a default VPC. I dumped everything out, created VPC using wizard, then the security group. Then re-created the DB instance, assigned it the new VPC i re-created. Thanks for your efforts.