AWS Database Access with Twingate

AWS Database Access with Twingate

Securely accessing Amazon RDS, Aurora, and DynamoDB requires more than simply opening ports. This guide explains how to use Twingate to route traffic to your AWS databases and how to configure AWS so that only traffic from Twingate Connectors is permitted.

Prerequisites

Before beginning, make sure you have:

• A Remote Network defined in the Twingate Admin Console – this is the private network that your database sits in.
• At least one Twingate Connector deployed – the Connector routes traffic from users to the Remote Network. Where possible, use the private IP address of each Connector (e.g. the Connector’s address inside your VPC) when configuring security rules. Only use the public IP address when connecting to services that require it - see Public Database Access for more information.

Amazon RDS & Aurora – Configuring network access

Amazon RDS and Aurora run inside your VPC. To restrict connections to these databases you must configure Security Group rules that allow traffic only from your Connector’s IP addresses. Using Twingate reduces the attack surface because you do not expose your database to the internet - you only allow traffic from the Connector.

1. Create a Twingate Resource for your database endpoint

• In the Twingate Admin Console, create a Resource that points to your database endpoint (e.g. mydb.cluster-1234abcd.us-east-1.rds.amazonaws.com). Use the port appropriate for your database (3306 for MySQL/Aurora MySQL, 5432 for PostgreSQL/Aurora PostgreSQL).
• Note the private IP address of your Connector(s) (within the same VPC or network) on the Connectors page. This is the address you will allow in your Security Group rules. If your deployment spans networks where only a public IP address is exposed, you may need to use the public IP address instead - see Public Database Access for more information.

2. Update the Security Group on your RDS/Aurora instance

• In the AWS Management Console, navigate to RDS → Databases, choose your database, and locate its VPC Security Group.
• Edit the Inbound rules and add a rule that allows the Connector’s private IP addresses on the appropriate port (e.g. TCP port 3306 for MySQL or 5432 for PostgreSQL). If your Connector communicates with the database over the internet (e.g. when the database is in a different VPC or region), you may need to allow its public IP address - see SaaS App Gating for more information.
• Save the changes.

3. Connect to your database

Once the Security Group has been updated and the Resource is created in Twingate, you can connect to it from your local machine through the Twingate Client:

• MySQL (RDS or Aurora):

  Copy

  mysql -h mydb.cluster-1234abcd.us-east-1.rds.amazonaws.com -u <username> -p

• PostgreSQL (RDS or Aurora):

  Copy

  psql -h mydb.cluster-1234abcd.us-east-1.rds.amazonaws.com -U <username> -d <database>

• DBeaver or other Clients:

  • Connect to a database (select the type)
  • Set the Host to mydb.cluster-1234abcd.us-east-1.rds.amazonaws.com on the appropriate port
  • Authenticate and Connect!

For Aurora clusters, use the cluster endpoint rather than an individual instance endpoint to take advantage of failover and load balancing.

Amazon DynamoDB – Access considerations

Unlike RDS and Aurora, DynamoDB is a fully managed NoSQL service that is exposed over HTTPS using regional endpoints (e.g. dynamodb.us‑east‑1.amazonaws.com). There is no built‑in IP allow list for DynamoDB console or API access. AWS explains that DynamoDB is publicly accessible by default and recommends using a VPC endpoint to keep traffic within your VPC. You can also restrict access by writing IAM policies that only permit requests through a specific VPC endpoint using the aws:SourceVpce condition.

1. Create a Twingate resource for the DynamoDB API

• In the Twingate Admin Console, create a Resource that points to the regional DynamoDB endpoint you use (e.g. dynamodb.us‑east‑1.amazonaws.com). Because DynamoDB uses HTTPS on port 443, specify port 443 when creating the Resource. See Amazon DynamoDB endpoints and quotas for more information.
• Note the private IP address of your Connector(s). Use this address when configuring security rules for the VPC endpoint. Only use the public IP address if the endpoint must be accessed via the internet.

2. Use a VPC endpoint to restrict network traffic (recommended)

• In the AWS Console, create a VPC Gateway Endpoint for DynamoDB in your VPC. This endpoint provides direct, private connectivity to DynamoDB from instances within the same VPC and region.
• Update the Security Group attached to the VPC endpoint to allow inbound connections from your Twingate Connector’s private IP addresses. When using a VPC endpoint, you can write an IAM policy that permits DynamoDB actions only when the request comes from that endpoint using the aws:SourceVpce condition.

3. Connect to DynamoDB

You can now access DynamoDB through the Twingate Client using AWS SDKs or the AWS CLI. Client traffic to the regional API host will be tunneled to the Connector, and from there the Connector’s HTTPS traffic is automatically routed through the Gateway Endpoint. For example:

aws dynamodb list-tables \
  --region us-east-1 \
  --endpoint-url https://dynamodb.us-east-1.vpce-<endpoint-id>.vpce-svc-<service-id>.amazonaws.com

If you do not create a VPC endpoint, DynamoDB will still be reachable via its public endpoint. However, you cannot restrict access via an IP allow list - access control must be enforced via IAM policies.

Self‑hosted or non‑AWS databases

If you run MySQL, PostgreSQL, or other database engines yourself (on EC2, on‑premises, or another cloud), you can still use Twingate to secure access:

• Create a Twingate Resource that points to the fully qualified domain name (FQDN) or IP address of your database and specify the appropriate port.
• Add the Connector’s private IP address to any firewall or security group protecting the database. Only use the public IP address if the Connector communicates with the database over the internet.
• Connect using your preferred client through Twingate.

Troubleshooting Database Connections

If you’re having trouble connecting to your database via Twingate, check the following common issues:

• DynamoDB access issues: Using a VPC endpoint? Double‑check that your IAM policies permit DynamoDB actions only through that endpoint (aws:SourceVpce).

• Connection Refused: Ensure that your database’s IP access list includes the Connector’s IP addresses (use the private IP address for databases in your private network and the public IP address for SaaS services).

• Slow Connections: Check the health of your Connectors and make sure there are no firewall rules blocking access to the database.

• Timeouts: Verify your Connectors are online, reachable, and properly configured.

• Twingate Recent Activity: In the Admin Console, open Recent Activity for the Resource to see what’s happening:

  • DNS Failed: The Client sent traffic to the Connector, but the Connector couldn’t resolve the hostname. Ensure the DNS hosted zone is tied to the VPC, the DNS server is defined as a Twingate Resource (if self-hosting), or there’s a valid route from the Connector to the DNS server.

  • Connection Failed: The Client captured the traffic, sent it to the Connector, and the Connector tried but couldn’t reach the destination. Check that a route exists between the Connector and database, IP allow lists are correct, and firewall/security group rules allow the port on both ends.

  • No Activity: The Client didn’t send traffic to the Connector. Make sure the Client is running, you have access to the Resource, and no other VPN is hijacking the connection.

For more troubleshooting tips, refer to the Twingate Troubleshooting Guide.

Related Resources

• SaaS App Gating Guide
• Connector Best Practices
• Security Policies Guide