Securing Amazon Aurora DSQL: Access control best practices

Amazon Aurora DSQL is the fastest serverless distributed SQL database for always available applications. With its innovative active-active distributed architecture, Aurora DSQL is designed for 99.99% availability in single-Region configuration and 99.999% in multi-Region configuration, making it ideal for building highly available applications.

You can access the Aurora DSQL cluster by using a public endpoint and AWS PrivateLink endpoints. In this post, we demonstrate how to control access to your Aurora DSQL cluster by using public endpoints and private VPC endpoints through PrivateLink, both from inside and outside AWS.

Controlling access by using Aurora DSQL public endpoints

Accessing Aurora DSQL through its public endpoint provides flexibility for external applications or on-premises systems to connect to the Aurora DSQL cluster without requiring a VPN or AWS Direct Connect setup. However, this convenience must be balanced with strong access control. Aurora DSQL integrates with AWS Identity and Access Management (IAM) to enforce identity-based permissions, so only authorized roles can initiate connections. You can define granular policies to allow or deny access based on user roles, IP address ranges, or virtual private cloud (VPC) identifiers. For example, if users attempt to connect without the necessary dsql:DbConnect or dsql:DbConnectAdmin permissions, they will receive an access denied error, even if the public endpoint is reachable.

By combining IAM policies with security groups and network access control lists (network ACLs), you can maintain tight control of Aurora DSQL cluster access while enabling secure access across environments. When accessing an Aurora DSQL cluster through a public endpoint, implementing the following access controls is essential for security:

• Principle of least privilege – Grant minimal IAM permissions required for each database role or user.
• IP-based access control – Allow connections from only specified IP addresses or ranges.

The following diagram illustrates the architecture of this setup.

Managing access control from on premises to Aurora DSQL by using a public endpoint

In this section, we walk through how to manage access securely from an on-premises network to an Aurora DSQL cluster by using a public endpoint.

Control database access with IAM permissions

Aurora DSQL doesn’t use traditional passwords for authentication. Instead, it relies on short-lived authentication tokens generated by the AWS SDK. When a user or application attempts to connect to the Aurora DSQL cluster, Aurora DSQL validates their token and evaluates the caller’s IAM policies to determine whether access should be granted. This approach enhances security by reducing the risks associated with long-lived passwords such as infrequent rotation and credential leaks.

Using IAM based token authentication makes sure that only explicitly authorized roles and users can connect to the database. It also allows centralized control and auditing of who can access the system.

To demonstrate this, we first attempt to connect to the Aurora DSQL cluster’s public endpoint without assigning any Aurora DSQL permissions (dsql:DbConnect or dsql:DbConnectAdmin) to the Amazon Elastic Compute Cloud (Amazon EC2) instance’s IAM role:

export PGSSLMODE=require
export PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --hostname $CLUSTER_ENDPOINT --region us-east-1)
[root@ip-10-0-0-40 ~]# psql --quiet --username admin --dbname postgres --host $CLUSTER_ENDPOINT
psql: error: connection to server at "xxxxxxxxxxxxxxxxxxxxxxxxxx.dsql.us-east-1.on.aws" (18.97.33.130), port 5432 failed: FATAL: unable to accept connection, access denied
DETAIL: Session Id: kvs6xpvbygqtwayg2o6pzp7lgi
HINT: User: arn:aws:sts::123456789012:assumed-role/EC2Role/i-b188560f is not authorized to perform: dsql:DbConnectAdmin on resource: arn:aws:dsql:us-east-1:123456789012:cluster/xxxxxxxxxxxxxxxxxxxxxxxxxx because no identity-based policy allows the dsql:DbConnectAdmin action

This demonstrates that your Aurora DSQL cluster is secured, even when accessed through the public endpoint, by enforcing IAM permissions. Connection attempts without the appropriate policies are denied, effectively preventing unauthorized access.Next, we attach the following IAM policy to the Amazon EC2 instance’s IAM role. This policy grants permissions to connect to the cluster by using both the administrator role (dsql:DbConnectAdmin) and a custom database role (dsql:DbConnect).

Note: Throughout this post, be sure to replace the <placeholder values> with your own information.

{
    "Version": "2012-10-17",
    "Statement": [
        
        {
            "Sid": "StatementAllow",
            "Effect": "Allow",
            "Action": [
                "dsql:DbConnect",
                "dsql:DbConnectAdmin"
            ],
            "Resource": [
                "arn:aws:dsql:<AWS-Region>:<account-id>:cluster/examplecluster"
            ]
        }
    ]
}

We then run the following command to set PostgreSQL’s SSL mode to require, which enforces secure connections. Aurora DSQL mandates SSL for all connections and will reject any attempt that doesn’t use it.

export PGSSLMODE=require

Next, we generate an authentication token and store it in the PGPASSWORD environment variable. By default, authentication tokens in Aurora DSQL expire after 15 minutes (900 seconds). However, for the purpose of this walkthrough, we generate a token with a longer lifespan that we set to expire after 1 hour (3,600 seconds):

export PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --hostname $CLUSTER_ENDPOINT --region us-east-1 --expires-in 3600)

Now that we’ve set the necessary connection parameters, let’s test the connectivity to the Aurora DSQL cluster:

[root@ip-10-0-0-40 ~]# psql --quiet --username admin --dbname postgres --host $CLUSTER_ENDPOINT

postgres=> select current_user;
current_user-----------------
admin
(1 row)

The preceding code and output demonstrate that Aurora DSQL is enforcing IAM based authentication effectively, even when accessed through a public endpoint. For secure and controlled access, always follow the principle of least privilege and grant only the necessary permissions (dsql:DbConnect or dsql:DbConnectAdmin) to roles and users that require database access. Regularly audit IAM policies and use short-lived authentication tokens instead of long-lived credentials to reduce exposure risk.

Control database access based on IP address or range

Now, we explore how to restrict access to your Aurora DSQL cluster based on the source IP address. This method adds a valuable layer of network-based security, making sure only connections originating from trusted IP addresses or CIDR blocks are allowed. By using IAM policies with the aws:SourceIp condition, you can define explicit allow or deny rules that complement your role-based access controls. This is especially useful when granting access to specific corporate offices, on-premises data centers, or known bastion hosts.

The following example code demonstrates how to create an identity-based IAM policy that denies access to the Aurora DSQL cluster if the connection request originates from an IP address outside the specified range. In this policy, the ”Effect”: "Deny" condition blocks any requests not coming from the trusted IP address (in this case, 203.0.113.1/32). This approach makes sure that only connections from approved IPs are permitted, even if the user or role has the required Aurora DSQL permissions.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "StatementDeny",
            "Effect": "Deny",
            "Action": [
                "dsql:DbConnect",
                "dsql:DbConnectAdmin"
            ],
            "Resource": [
                "arn:aws:dsql:<AWS-Region>:<account-id>:cluster/examplecluster"
            ],
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": "203.0.113.1/32"
                }
            }
        },
        {
            "Sid": "StatementAllow",
            "Effect": "Allow",
            "Action": [
                "dsql:DbConnect",
                "dsql:DbConnectAdmin"
            ],
            "Resource": [
                "arn:aws:dsql:<AWS-Region>:<account-id>:cluster/examplecluster"
            ]
        }
    ]
}

Connect to Aurora DSQL from an Amazon EC2 instance with a different source IP address

To validate the effectiveness of the IP-based restriction we discussed in the preceding subsection, let’s attempt to connect to the Aurora DSQL cluster from an Amazon EC2 instance with a different public IP address—one that falls outside the allowed range defined in the IAM policy. Because the policy explicitly denies access for any IP address not matching 203.0.113.1/32, the connection attempt from this Amazon EC2 instance should fail, even if all other IAM permissions are correctly configured.

Before testing the connection, we must confirm that the Amazon EC2 instance’s public IP address falls outside the allowed IP range defined in the IAM policy. Run the following commands to securely retrieve the instance’s public IPv4 address by using Amazon EC2 Instance Metadata Service Version 2 (IMDSv2) with an IMDSv2 token:

# Generate an IMDSv2 token
TOKEN=$(curl --silent -X PUT "http://169.254.169.254/latest/api/token" \
-H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Use the token to retrieve the public IP address
public_ipv4=$(curl --silent -H "X-aws-ec2-metadata-token: $TOKEN" \
http://169.254.169.254/latest/meta-data/public-ipv4)

# Display the IP
echo $public_ipv4
192.0.2.1

Because the IAM policy explicitly denies access to any source IP address outside 203.0.113.1/32, the connection attempt from this Amazon EC2 instance is correctly rejected because the public IP address is 192.0.2.1. This validates that IP-based restrictions are being enforced as intended.

[root@ip-10-0-0-40 ~]# psql --quiet --username admin --dbname postgres --host $CLUSTER_ENDPOINT
psql: error: connection to server at "examplecluster.dsql.us-east-1.on.aws" (18.97.33.130), port 5432 failed: FATAL: unable to accept connection, access denied

DETAIL: Session Id: abcdefghijaklmnop2ryunhve
HINT: User: arn:aws:sts:: 12345678910:assumed-role/EC2Role/i-b188560f is not authorized to perform: dsql:DbConnectAdmin on resource: arn:aws:dsql:us-east-1:12345678910:cluster/examplecluster with an explicit deny in an identity-based policy

The preceding code demonstrates that, even when the user or role has the correct permissions, Aurora DSQL honors IP-based deny rules and makes sure access is limited to trusted network boundaries.

Connect to Aurora DSQL from an Amazon EC2 instance with an allowed source IP address

To confirm that the IP-based access policy works as expected, we now connect to the Aurora DSQL cluster from an Amazon EC2 instance whose public IP address matches the allowed IP range (203.0.113.1/32) defined in the IAM policy.

Because the instance’s public IP address falls within the permitted range and the IAM role has the necessary dsql:DbConnect or dsql:DbConnectAdmin permissions, the connection should succeed without errors.

Before testing the connection, let’s confirm that the Amazon EC2 instance’s public IP address falls within the allowed IP range defined in the IAM policy (203.0.113.1/32). To do this, we securely retrieve the instance’s public IPv4 address by using the IMDSv2 token:

# Generate an IMDSv2 token
[root@ip-10-0-0-40 ~]# export PGSSLMODE=require
[root@ip-10-0-0-40 ~]# export PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --hostname $CLUSTER_ENDPOINT —region us-east-1)

# Use the token to retrieve the public IP address
[root@ip-10-0-0-40 ~]# TOKEN=$(curl --silent -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
[root@ip-10-0-0-40 ~]# public_ipv4=$(curl —silent -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/public-ipv4)

# Display the IP
[root@ip-10-0-0-40 ~]# echo $public_ipv4
203.0.113.1

With the IAM policy correctly configured to allow access from IP address 203.0.113.1 and all required connection parameters set (including the authentication token and SSL mode), we can now successfully connect to the Aurora DSQL cluster:

[root@ip-10-0-0-40 ~]# psql --quiet --username admin --dbname postgres --host $CLUSTER_ENDPOINT

postgres=> select current_user; 
current_user
--------------
admin

This confirms that the IP-based access control is functioning correctly, allowing connections only from explicitly permitted IP addresses.

Controlling access to Aurora DSQL by using PrivateLink and private DNS endpoints

In this section, we explore how to securely access Aurora DSQL by using PrivateLink and private DNS endpoints. This approach allows traffic between your VPC and Aurora DSQL to remain entirely within the AWS network, which alleviates the need for public IP addresses, internet gateways, or NAT devices.

Using PrivateLink, you can create interface VPC endpoints to connect to Aurora DSQL as if it were part of your own VPC. When combined with private DNS, these endpoints allow your applications to resolve and access the Aurora DSQL cluster by using standard host names, while traffic is routed privately and securely. This configuration is especially useful for internal workloads or hybrid environments where data privacy and low-latency, secure connectivity are key requirements.

The following diagram illustrates how you can control access to your Aurora DSQL cluster by using PrivateLink.

Prerequisites

Before you proceed with following subsections, make sure you have the following prerequisites:

• An Amazon VPC
• A compute resource within the VPC (such as an Amazon EC2 instance)
• An Aurora DSQL cluster in a single AWS Region
• IAM permissions to create interface VPC endpoints and access Aurora DSQL

Create the PrivateLink interface endpoint

With PrivateLink support for Aurora DSQL, you can provision interface VPC endpoints in your VPC. These endpoints allow your applications to privately connect to Aurora DSQL without requiring public IP addresses or internet-facing connectivity. Applications deployed within your Amazon VPC can securely access Aurora DSQL by using its private DNS host name through the interface endpoint. This keeps traffic entirely within the AWS network, enhancing both security and performance. For detailed steps to create a PrivateLink interface endpoint, see Managing and connecting to Amazon Aurora DSQL clusters using AWS PrivateLink.

With the PrivateLink interface endpoint in place, the next step is to explore mechanisms for controlling access to the Aurora DSQL cluster through fine-grained, identity-based controls.

Restrict database access by using a VPC endpoint policy

With VPC endpoint policies, you can define a robust data perimeter by granting access exclusively to trusted IAM principals and resources within your network. This approach minimizes the risk of unauthorized access and provides precise, policy-driven control over how your Aurora DSQL clusters are accessed.

The following example demonstrates how to create an identity-based IAM policy that denies access to the Aurora DSQL cluster if the connection request does not originate from a specific IAM role. In this policy, the ”Effect”: "Deny" condition blocks any requests not coming from the trusted IAM role EC2Role. At the same time, the policy grants the dsql:DbConnect and dsql:DbConnectAdmin actions on the examplecluster Aurora DSQL cluster. This approach makes sure only connections made using the approved IAM role are permitted.

{
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "*",
      "Resource": "arn:aws:dsql:<AWS-Region>:<account-id>:cluster/examplecluster",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalArn": "arn:aws:iam::<account-id>:role/EC2Role"
        }
      }
    },
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "dsql:DbConnect",
        "dsql:DbConnectAdmin"
      ],
      "Resource": "arn:aws:dsql:<AWS-Region>:<account-id>:cluster/examplecluster"
    }
  ]
}

Test Aurora DSQL connectivity with an unauthorized IAM role

To verify that the preceding VPC endpoint policy is working as intended, we attempt to connect to the Aurora DSQL cluster from an Amazon EC2 instance using an unauthorized IAM role. In this case, the instance is associated with the role (ec2-admin-role), which differs from the explicitly permitted role (ec2-role), which is defined in the VPC endpoint policy.

First, let’s view which IAM role associated with the instance:

[root@ip-10-0-0-34 ~]# TOKEN=$(curl --silent -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
[root@ip-10-0-0-34 ~]# curl --silent -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/

ec2-admin-role

Set the connection parameters as follows:

# Set environment variables
export CLUSTERID=your-cluster-id
export REGION=us-east-1
export SERVICE_IDENTIFIER=dsql-fnh4 # This should match the identifier in your service name
# Construct the hostname
export HOSTNAME="$CLUSTERID.$SERVICE_IDENTIFIER.$REGION.on.aws"

# Generate authentication token
export PGPASSWORD=$(aws dsql --region $REGION generate-db-connect-admin-auth-token --hostname $HOSTNAME)

Now let’s connect and review the results:

[root@ip-10-0-0-34 ~]# psql --d postgres --h $HOSTNAME --U admin
psql: error: connection to server at "examplecluster.dsql-fnh4.us-east-1.on.aws" (10.0.0.0), port 5432 failed: FATAL: unable to accept connection, access deniedDETAIL: Session Id: sfs65e33upgza5iywqh64wd7sq
HINT: User: arn:aws:sts::123456789012:assumed-role/ec2-admin-role/i-XXXXXXXXXXX is not authorized to perform: dsql:DbConnectAdmin on resource: arn:aws:dsql:us-east-1:123456789012:cluster/examplecluster with an explicit deny in a VPC endpoint policy

The VPC endpoint policy has correctly denied access to an unauthorized IAM role (ec2-admin-role).

Test Aurora DSQL connectivity with the allowed IAM role

To validate that the VPC endpoint policy permits access for the intended IAM identity, we initiate a connection from an Amazon EC2 instance configured with the authorized IAM role (ec2-role).

First, we confirm the IAM role associated with the instance:

[root@ip-10-0-0-40 ~]# TOKEN=$(curl --silent -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
[root@ip-10-0-0-40 ~]# curl --silent -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials

ec2-role

This confirms that the Amazon EC2 instance is using the allowed IAM role (ec2-role).

Next, we set the connection parameters and initiate a connection to the Aurora DSQL cluster:

export PGSSLMODE=require
export PGPASSWORD=$(aws dsql --region $REGION generate-db-connect-admin-auth-token —hostname $HOSTNAME)

psql --d postgres --h $HOSTNAME --U admin
psql (15.6, server 16.9)
WARNING: psql major version 15, server major version 16.
Some psql features might not work.
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_128_GCM_SHA256, compression: off)
Type "help" for help.

postgres=> select current_user;
current_user
----------------
admin
(1 row)

The connection succeeds as expected, demonstrating that the VPC endpoint policy correctly allows access when the request originates from the authorized IAM role.

Using security groups to restrict traffic to Aurora DSQL

Security groups act as virtual firewalls for your AWS resources, controlling both inbound and outbound traffic. When working with Aurora DSQL PrivateLink VPC endpoints (interface endpoints), security groups provide a powerful mechanism to restrict cluster access to specific compute resources, IP ranges, or subnets within your VPC.

In this section, we walk through an example of using security groups to control connectivity to an Aurora DSQL cluster and validate the configuration through a test scenario.

Identify security groups associated with the Amazon EC2 instance

We first retrieve the list of security groups associated with our Amazon EC2 instance that will attempt to connect to Aurora DSQL:

# Get EC2 metadata token
TOKEN=$(curl --silent -X PUT "http://169.254.169.254/latest/api/token" \ -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# List attached security groups
curl --silent -H "X-aws-ec2-metadata-token: $TOKEN" \ http://169.254.169.254/latest/meta-data/security-groups

#Example Output:
SecGroup-MySQL
SecGroup-PG
SecGroup-DSQL

Check security groups on the PrivateLink endpoint

Now, we inspect which security groups are currently associated with the Aurora DSQL PrivateLink endpoint:

aws ec2 describe-vpc-endpoints \
--vpc-endpoint-ids vpce-03ae184e1b904ecb5 \
--query "VpcEndpoints[0].Groups"

#Example Output:
[
	{
   "GroupId": "sg-0b457c8e654a695f5",
   "GroupName": " SecGroup-ec2"
   }
]

We can see that the Amazon EC2 instance and the PrivateLink endpoint don’t have a security group in common, so the connection is likely to fail unless it’s explicitly allowed.

Attempt a connection with mismatched security groups

We attempt to connect to the Aurora DSQL cluster from the Amazon EC2 instance, setting a timeout to confirm whether access is permitted. We have set the PGCONNECT_TIMEOUT variable so that the connection times out after 10 seconds:

export HOSTNAME="$CLUSTERID.$SERVICE_IDENTIFIER.$REGION.on.aws"
echo $HOSTNAME
examplecluster. dsql-fnh4.us-east-1.on.aws
export PGCONNECT_TIMEOUT=10
export PGPASSWORD=$(aws dsql --region $REGION generate-db-connect-admin-auth-token --hostname $HOSTNAME)

psql --quiet --username admin --dbname postgres --host $HOSTNAME

#Example Output:
psql: error: connection to server at " examplecluster. dsql-fnh4.us-east-1.on.aws" (10.0.0.0), port 5432 failed: timeout expired connection to server at " examplecluster. dsql-fnh4.us-east-1.on.aws (10.0.0.0), port 5432 failed: timeout expired

The preceding output confirms that the Amazon EC2 instance is unable to reach the Aurora DSQL endpoint because of restrictive security group settings on the VPC endpoint.

Attach the correct security group to the endpoint

To attach the correct security group to the endpoint, we identify the correct security group used by the Amazon EC2 instance:

aws ec2 describe-security-groups \
--filter Name=group-name,Values= SecGroup-DSQL \
--query "SecurityGroups[0].GroupId"

#Example Output:
"sg-078a098b3069c40de"

We then add the sg-078a098b3069c40de security group to the existing PrivateLink endpoint:

aws ec2 modify-vpc-endpoint \
--vpc-endpoint-id vpce-03ab184c1d904efg5 \
--add-security-group-ids sg-078a098b3069c40de

Now, we verify the updated group association:

aws ec2 describe-vpc-endpoints \
--vpc-endpoint-ids vpce-privatelink-id \
--query "VpcEndpoints[*].Groups"

# Example Output
[
	{
   "GroupId": " sg-078a098b3069c40de", 
   "GroupName": " SecGroup-DSQL"
   }
]

Retest the connection from the Amazon EC2 instance

With the correct security group now associated with the VPC endpoint, we retry the connection from the Amazon EC2 instance:

psql --quiet --username admin --dbname postgres --host $HOSTNAME

postgres=>postgres=> select current_user;
current_user
--------------
admin

The connection to the Aurora DSQL cluster now succeeds, confirming that security group alignment is critical for enabling access through PrivateLink.

Using security groups with Aurora DSQL PrivateLink endpoints provides essential, network-level access control that complements IAM and VPC endpoint policies. By carefully aligning the security groups attached to your Amazon EC2 instances and VPC interface endpoints, you can make sure only trusted resources within your VPC can establish connections to your Aurora DSQL clusters. This approach not only helps enforce a least-privilege access model, but it also strengthens your overall security posture by preventing unintended or unauthorized network traffic from reaching sensitive data endpoints.

Additional IAM-based access control policies for Aurora DSQL

Depending on your security and audit objectives, IAM provides flexible options to control who can connect to your Aurora DSQL cluster and from which VPCs those connection attempts originate. The following sample policies can serve as a starting point for applying VPC-based and identity-based access controls tailored to your environment.

Note that, IAM is a service accessed by computers in data centers worldwide and operates using a distributed computing model called eventual consistency. This means that any changes you make in IAM or related AWS services such as updates to attribute-based access control (ABAC) tags, may take some time to propagate and become visible across all endpoints. The delay occurs because data must be transmitted between servers, across replication zones, and between AWS Regions. Additionally, IAM employs caching to boost performance, which can sometimes introduce further delay. As a result, changes might not be immediately visible until cached data expires. For more information, see: Changes that I make are not always immediately visible

Blocking Aurora DSQL cluster public access using IAM conditions

To tightly control access to your Aurora DSQL public endpoint, you can block all traffic that does not originate from an approved VPC or PrivateLink endpoint. The following IAM policy uses conditional keys to deny access when the connection request is not coming from a VPC or interface endpoint. In this example, if the request does not include a valid VPC source IP (aws:VpcSourceIp), source VPC identifier (aws:SourceVpc), or VPC endpoint identifier (aws:SourceVpce), the connection attempt is denied effectively preventing all public internet–based access, even if the user or role has the required Aurora DSQL permissions.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Resource": "arn:aws:dsql:<AWS-Region>:<account-id>:cluster/examplecluster",
            "Effect": "Deny",
            "Action": [
                "dsql:DbConnect",
                "dsql:DbConnectAdmin"
            ],
            "Condition": {
                "Null": {
                    "aws:VpcSourceIp": "true",
                    "aws:SourceVpc": "true",
                    "aws:SourceVpce": "true"
                }
            }
        }
    ]
}

This policy acts as a strong safeguard by ensuring only connections originating from trusted private networks or explicitly configured VPC interface endpoints are allowed, thereby preventing any unintended exposure of your Aurora DSQL clusters to the public internet.

Limiting Aurora DSQL PrivateLink access to trusted VPCs

In environments where Aurora DSQL must be accessed only from a predefined set of VPCs (for example, approved production or staging networks), you can deny connection attempts unless the request originates from one of those trusted VPC IDs. In the following example, the policy denies both dsql:DbConnect and dsql:DbConnectAdmin if the connection does not come from either vpc-abc or vpc-xyz.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RestrictDSQLDBConnectToSpecificVPCs",
            "Effect": "Deny",
            "Action": [
                "dsql:DbConnect",
                "dsql:DbConnectAdmin"
            ],
            "Resource": "*",
            "Condition": {
                "ForAnyValue:StringNotEquals": {
                    "aws:SourceVpc": [
                        "vpc-abc",
                        "vpc-xyz"
                    ]
                }
            }
        }
    ]
}

With this policy in place, connection attempts from any other VPC are denied even if the caller has the necessary IAM permissions.

Restrict Aurora DSQL PrivateLink connectivity from a designated VPC

In highly controlled environments, you may require that Aurora DSQL be accessed only from a single VPC. The policy below denies all connection attempts unless they originate from VPC vpc-xyz.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RestrictDSQLDBConnectToVPC",
            "Effect": "Deny",
            "Action": [
                "dsql:DBConnect"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:SourceVpc": "vpc-xyz"
                }
            }
        }
    ]
}

This is useful when your Aurora DSQL cluster must be accessed exclusively from a tightly controlled VPC, such as a central data services VPC used by internal applications.

Enforce VPC and IAM-based access control for Aurora DSQL PrivateLink

For the highest level of control, you can combine both network-based restrictions and identity-based restrictions in the same policy. The following example only allows dsql:DbConnect if the request originates from vpc-xyz and uses either the IAM role ApprovedRole or user ApprovedUser.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RestrictDSQLDBConnectByVPCAndPrincipal",
            "Effect": "Allow",
            "Action": [
                "dsql:DBConnect"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceVpc": "vpc-xyz",
                    "aws:PrincipalArn": [
                        "arn:aws:iam::444455556666:role/ApprovedRole",
                        "arn:aws:iam::444455556666:user/ApprovedUser"
                    ]
                }
            }
        }
    ]
}

With this approach, even if a request originates from your approved VPC, it must also be made by one of your trusted IAM principals. This offers strong defense-in-depth by combining identity and network provenance before allowing access to Aurora DSQL.

Security best practices

When configuring PrivateLink for Aurora DSQL, it’s important to implement multiple layers of access control to protect your data and infrastructure. Consider the following security best practices to enhance your overall posture:

• Security groups – Attach tightly scoped security groups to your VPC interface endpoints. These should allow traffic only from specific, trusted resources within your VPC, such as approved Amazon EC2 instances or application subnets, and limit access to required ports, typically TCP 5432 for PostgreSQL.
• IAM policies – Enforce least-privilege access by defining IAM policies that control who can create, modify, or delete VPC endpoints. This makes sure only authorized end users and services can manage network access to your Aurora DSQL clusters.
• Network ACLs – Use network ACLs to provide stateless, subnet-level traffic filtering. To add an additional layer of protection alongside security groups, configure network ACLs to allow only the necessary inbound and outbound traffic for the subnets that host your VPC endpoint network interfaces.

By combining these best practices, you can create a robust, defense-in-depth strategy that secures Aurora DSQL connectivity within your AWS environment.

Deployment planning considerations

When planning your Aurora DSQL deployment with PrivateLink, keep the following considerations in mind:

• Shared endpoints – Multiple Aurora DSQL clusters can share a single PrivateLink interface endpoint, as long as they use the same service name. This can simplify connectivity and reduce operational overhead.
• Region scope – PrivateLink endpoints are Region-specific. They can be used only to access Aurora DSQL clusters within the same Region. Cross-Region access is not supported through PrivateLink.
• Cost implications – Standard PrivateLink pricing applies, including charges for interface endpoints and data processing. PrivateLink usage is billed separately from Aurora DSQL usage, and it should be factored into your cost planning.
• Connection limits – The number of simultaneous connections that can pass through a PrivateLink endpoint is bound by Aurora DSQL connection limits. Make sure your workload design aligns with these limits to avoid throttling or connection errors.

Understanding these considerations early can help you design a secure, scalable, and cost-effective architecture around Aurora DSQL and PrivateLink.

Conclusion

In this post, we explored how to securely connect to and control access to your Aurora DSQL cluster by using both public and PrivateLink endpoints. Whether you’re accessing Aurora DSQL from within your VPC or from an on-premises data center, the approaches we’ve covered can help you keep traffic private, enforce fine-grained access controls, and adhere to security best practices.

By using VPC interface endpoints, security groups, IAM policies, and VPC endpoint policies, you can build a robust security perimeter that limits access to only trusted resources and identities. Use this post’s insights to help guide your architecture decisions as you design secure, scalable solutions around Aurora DSQL connectivity.

About the authors