Deploying ProxySQL in AWS for Aurora MySQL: a practical starter guide

If you are new to ProxySQL, it can feel like “one more component” between your app and the database. In practice, it is often what makes your database layer calmer, cheaper, and more predictable under real production load.

This post provides a practical overview of deploying ProxySQL on AWS and connecting it to an Aurora MySQL cluster, with sensible defaults for networking and security. If you want the full step-by-step lab, demos, and the “watch it happen” bits (failover, scaling, stats tables, and troubleshooting), I’ve packaged that into my course: Introduction to ProxySQL with AWS Aurora

👉 https://abd.training/introduction-to-proxysql

Why ProxySQL in front of Aurora?

Aurora is great, but your application layer can still cause pain:

• Apps often create too many database connections.
• MySQL has connection limits, and each connection consumes memory.
• Handling replicas and failover in application code is fiddly and error-prone.
• Read traffic can overload the writer if it is not routed cleanly to replicas.

ProxySQL sits between your app and Aurora, managing connections and routing queries more intelligently.

In plain English, it gives you a control plane for database traffic.

Architecture at a glance

A common pattern looks like this:

• App(s) connect to ProxySQL (client port typically 6033, but you can map it to 3306 if you want).
• ProxySQL connects to Aurora instances on 3306.
• ProxySQL admin is available on 6032 (lock this down hard).

If you are thinking in AWS terms, ProxySQL usually lives on EC2 (most common), or in containers (ECS/EKS), in the same VPC as the Aurora cluster, typically in private subnets.

Step 1: Choose a deployment model on AWS

You have a few reasonable options:

1. EC2 instances (most common) Simple, flexible, direct control. Easy to debug. Great place to start.
2. Containers (ECS/EKS) Scaling and CI/CD friendly, but you need to think about state and resilient config storage.
3. Embed with the application Fast local handshake, but operationally more complex.
4. Marketplace AMI Quick start, but less customisable.

For an intro deployment, EC2 is usually the best “get it working and understand it” route.

Step 2: Security basics you should not skip

Treat ProxySQL like you would treat a database server:

• Restrict the admin interface (6032) using security groups and network controls.
• Enable SSL/TLS where appropriate:
• client ↔ ProxySQL
• ProxySQL ↔ Aurora
• Store credentials securely (Secrets Manager or Parameter Store) and avoid hardcoding secrets into AMIs or user data.
• Enable logging to create an audit trail and support troubleshooting.

Also consider how you will do admin access in the real world. The built-in admin user is localhost-only, but you can create remote admin users. If you do, make that access very deliberate.

Step 3: Install ProxySQL on an EC2 instance (Amazon Linux 2023 example)

This is a minimal install path using the ProxySQL repo, then dnf:

# Add ProxySQL repo
sudo tee /etc/yum.repos.d/proxysql.repo > /dev/null << 'EOF'
[proxysql]
name=ProxySQL YUM repository
baseurl=https://repo.proxysql.com/ProxySQL/proxysql-3.0.x/centos/9
gpgcheck=1
gpgkey=https://repo.proxysql.com/ProxySQL/proxysql-3.0.x/repo_pub_key
EOF

# Install
sudo dnf install -y proxysql

# Enable and start
sudo systemctl enable proxysql
sudo systemctl start proxysql

Networking-wise, your security group typically needs:

• Inbound 6033 from your app tier (or your bastion for testing)
• Inbound 6032 only from your admin location (ideally a bastion or a tight CIDR)
• Outbound 3306 to your Aurora cluster

Step 4: Connect to the ProxySQL admin interface

ProxySQL configuration lives in tables, and you manage it through the admin interface (port 6032).

mysql -u admin -p -h 127.0.0.1 -P6032

From here, you configure users, backend servers, and (for Aurora specifically) the Aurora hostgroup mapping.

Step 5: Link ProxySQL to Aurora the “Aurora-aware” way

To take advantage of ProxySQL’s Aurora features (failover awareness, read/write split support, replica discovery), you define the Aurora cluster using the Aurora hostgroups table.

At a high level:

• Define Aurora hostgroups in ProxySQL
• Add one Aurora instance (ProxySQL can use auto-discovery to pull the rest)
• Make sure your writer and replicas land in the correct hostgroups

The key idea is that the writer and replicas must be in different hostgroups so that ProxySQL can route appropriately and load-balance reads safely.

Once configured, you can confirm what ProxySQL believes is active via runtime tables, for example:

SELECT * FROM runtime_mysql_servers;

Step 6: Validate traffic and behaviour

When testing, I like to validate in this order:

1. Can ProxySQL reach Aurora?
2. Can ProxySQL authenticate a client user and connect through?
3. Are reads and writes going where I expect?
4. Do stats tables show sensible pooling and routing?

In the full walkthrough, I run simple SELECT and INSERT queries through ProxySQL, then inspect stats tables to confirm what happened.

Step 7: Make ProxySQL highly available

A single ProxySQL instance is useful, but it is still a single point of failure. The common AWS pattern is:

• Auto Scaling Group across multiple AZs
• Network Load Balancer (NLB) and a target group
• Multiple ProxySQL instances behind the NLB

This gives you resilience at the service level, but it introduces a new question:

How do you keep configuration consistent across multiple ProxySQL nodes?

One approach is to rebuild nodes from automation (Ansible, images, pipelines). That works, but runtime events can change state, and you can end up chasing drift.

The alternative (and the approach I prefer) is ProxySQL’s built-in clustering for config distribution:

• Add all cluster node IPs to the proxysql_servers table on each node
• Load to runtime
• Changes made on one node propagate to others automatically

ProxySQL supports core and satellite node types, which lets you design cluster topologies that fit your environment.

What you get in the full course (the “meat and potatoes”)

This post is the overview.

The full course includes a complete lab walkthrough where you:

• Install ProxySQL on EC2
• Configure ports, admin, monitor, and user access
• Define Aurora hostgroups and add instances
• Connect through ProxySQL and run SELECT/INSERT queries
• Inspect stats tables to confirm routing and pooling
• Perform an Aurora cluster failover
• Perform Aurora scale-out and scale-in

👉 https://abd.training/introduction-to-proxysql

If you’re experienced with this stuff, I’d love your feedback

This is my first course, and it was built with the same mindset I use when mentoring junior engineers: explain the “why”, then show the “how”, then validate what happened.

If you read this and think:

• “You should include X”
• “This bit is confusing”
• “The next course should focus on Y”

…tell me. I genuinely want the constructive feedback.

ProxySQL, #AWS, #Aurora, #MySQL, #DevOps, #SRE, #Databases, #Cloud Architecture