AWS Aurora MySQL serverless: how to connect from MySQL Workbench

Question

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

Answer 1

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

Answer 2

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.

Answer 3

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>.

Answer 4

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.

Answer 5

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/

Answer 6

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:

1. Resolve the DNS of the serverless db and obtain its IP
2. Create an ALB in your VPC, with a target group to the IP that you found in #1
3. Create a new security group and attach that to your ALB
4. 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:

1. 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).
2. 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