Skip to content

Configure AWS VPC peering

For the complete documentation index see: llms.txt

All documentation pages available in markdown.

With VPC peering, your app running in your AWS VPC can communicate privately with an Aerospike Cloud database in the Aerospike Cloud VPC without traversing the public internet. VPC peering reduces latency and exposure, ensuring a more secure connection for your applications.

Prerequisites

  • The AWS CLI is installed and configured.

  • An existing AWS VPC with an IPv4 CIDR block that does not overlap with Aerospike Cloud CIDR blocks:

    • The CIDR block you selected when provisioning your cluster: 10.128.0.0/19 by default

    • The CIDR block used for internal services in Aerospike Cloud: 10.129.0.0/24

  • Basic familiarity with AWS VPC peering.

  • DNS hostnames and DNS resolution are enabled in your VPC attributes.

Configure VPC peering

  1. Create or identify your AWS VPC

    • Create a new VPC in AWS or verify your existing VPC, ensuring that the CIDR block does not overlap with the Aerospike Cloud CIDR blocks listed above.
    • Take note of your VPC:
      • VPC ID (for example, vpc-0abcd1234efgh5678)
      • CIDR Block (for example, 10.0.0.0/16)
      • AWS Account ID (for example, 123456789012)
      • AWS Region (for example, us-east-1)

  2. Initiate VPC peering

    In the Aerospike Cloud Console:

    1. Navigate to your project and find the Networking or VPC Peering section for your database.
    2. Click Create VPC Peering.
    3. Fill in the details of your AWS VPC:
      • AWS Account ID: The 12-digit ID of your AWS account where your VPC resides.
      • AWS Region: The AWS region of your VPC.
      • VPC ID: The identifier of your VPC (for example, vpc-0abcd1234efgh5678).
      • VPC CIDR: Your VPC’s IPv4 CIDR block (for example, 10.0.0.0/16).
    4. Submit the peering request.

  3. Accept the peering request

    Since Aerospike Cloud initiated the peering request, you must accept it in your AWS account.

    In the AWS console:

    • Navigate to VPC → Peering Connections
    • Select the pending peering connection containing your peering connection ID
    • Select Actions → Accept Request.

  4. Update route tables

    To route traffic from your VPC to the Aerospike Cloud database VPC, add route table entries in your VPC route tables.

    You need to locate the route tables for each subnet that requires Aerospike access and add a route table entry to each one.

    Each route table entry should include the following:

    • Destination: The Aerospike Cloud database’s CIDR block, 10.128.0.0/19 by default
    • Target: The VPC peering connection, for example pcx-1410263943e464f4a
    • In VPC → Route Tables, locate the route tables for subnets that require Aerospike access.
    • Add a route to each required route table with:
      • Destination: The Aerospike Cloud database’s CIDR block, 10.128.0.0/19 by default
      • Target: The VPC peering connection, for example pcx-1410263943e464f4a

  5. Associate Private Hosted Zone (DNS)

    1. After the peering connection is accepted, get the Hosted Zone ID associated with your Aerospike Cloud database.

    The Hosted Zone ID, for example Z04089311NGVVH0FO3QGG, is shown in the Infrastructure section of the Details tab of your Aerospike Cloud database.

    1. Associate your VPC with Aerospike’s private hosted zone.

      Terminal window
      aws route53 associate-vpc-with-hosted-zone \
        --hosted-zone-id <HOSTED_ZONE_ID> \
        --vpc VPCRegion=<YOUR_AWS_REGION>,VPCId=<YOUR_VPC_ID>

    2. After a few minutes, DNS queries in your VPC, for example fcd8461a-49ee-42ea-ae08-7366a94e7654.aerospike.internal, will resolve to Aerospike’s private IP addresses.

  6. Configure security groups

    Follow these guidelines for configuring security groups in your VPC:

    • Outbound Rules
      • Allow outbound traffic on the following ports to Aerospike Cloud database’s CIDR block, 10.128.0.0/19 by default
    • Inbound Rules
      • Do not add an inbound rule that explicitly allows traffic from the Aerospike VPC block. Since security groups are stateful, if an instance in your VPC initiates a connection to the Aerospike VPC, the return traffic is automatically allowed back in.

  7. Test connectivity

    Run the following from a host in your peered AWS VPC (for example an EC2 instance or a pod). Commands do not work from your laptop unless it has network access to that VPC.

    1. In the Aerospike Cloud console, open Clusters, select your cluster, and open the Details tab. In the Connection section, copy Hostname.

      Use the full value (for example a1b2c3d4-e5f6-7890-abcd-ef1234567890.aerospike.internal) as <HOSTNAME> in the steps below. TLS port in the same section is 4000.

      For --tls-name, use the full Hostname value, not the bare Cluster ID from the General section.

    2. Test DNS resolution. The following commands should return a list of private IPs, one for each Aerospike node:

      Terminal window
      dig +short <HOSTNAME>

      Or:

      Terminal window
      getent hosts <HOSTNAME>

      Use one of the returned addresses as <NODE_IP> in the next step.

    3. Test TCP connectivity to the TLS port on a node IP from the previous step:

      Terminal window
      nc -zv <NODE_IP> 4000

      If nc is unavailable:

      Terminal window
      timeout 3 bash -c 'cat < /dev/null > /dev/tcp/<NODE_IP>/4000' \
        && echo "4000 open" || echo "4000 closed"

      If port 4000 is closed, double-check route tables, peering acceptance, and security group outbound rules from step 6.

    4. (Optional) Connect with Aerospike Quick Look (AQL).

      Before running AQL:

      Connect with TLS (port 4000). Use the same <HOSTNAME> for -h, --tls-name, and the host in the connection string:

      Terminal window
      aql --tls-enable \
        --tls-name <HOSTNAME> \
        --tls-cafile <PATH_TO_CA_PEM> \
        -h <HOSTNAME>:4000 \
        -U <DB_USERNAME> \
        -P

      Enter the database user password when prompted. For more command options, see Run Aerospike Quick Look.

VPC peering status definitions

Throughout the VPC peering process, Aerospike Cloud and AWS indicate the status of the peering connection. Following are common statuses and their meaning:

  • Pending Acceptance: The peering connection request has been created by Aerospike and is awaiting your acceptance in AWS. In this state, you need to take action to accept the request. (If not accepted within 7 days, the request will expire.)
  • Active: The peering connection is fully established. An active status on both sides means the link is ready for use (though routing/DNS may still need to be configured as described above).
  • Provisioning: (Transient state) The request was accepted and AWS is in the process of making it active. This status usually changes to Active within a short time without further action.
  • Failed: The peering request failed to establish. This can happen due to invalid parameters or network overlaps. A failed connection cannot be accepted or used. You may need to delete it and create a new request.
  • Rejected: The peering request was explicitly declined by the accepter (your side). No connection is made. You would need to create a new request if you rejected by mistake.
  • Expired: The request wasn’t accepted within the allowed time (7 days). The connection is not made and the request must be recreated if still needed.

In the Aerospike Cloud Console, these statuses might be labeled slightly differently (for example, Pending instead of Pending Acceptance) but the status is unchanged. Active is the desired end state. If your connection shows Active but you cannot connect to the database, double-check that routes and DNS are configured correctly as those steps are outside the raw peering status.

Troubleshooting

If a failure occurs during provisioning

If the VPC peering connection fails to provision or shows a Failed status, verify the following:

  • You entered the account ID for your VPC (Accepter) correctly.
  • You have selected the correct ID for your VPC (Accepter).
  • You entered the correct region for your VPC (Accepter).
  • None of the primary or secondary CIDR blocks in your VPC overlap those in the Aerospike Cloud VPC.

If any of these values are incorrect, delete the failed peering request and create a new one with the correct values.

If provisioning succeeded but you cannot connect

If the VPC peering status is Active, but you cannot connect to the database, check the following:

  • Routing: Your subnet uses the correct route table, with the Aerospike CIDR route pointing to the peering connection. Confirm that route entries exist in the route tables attached to your application subnets.
  • DNS: DNS resolution returns Aerospike private IPs. Verify that the hosted zone association completed successfully, and that enableDnsSupport and enableDnsHostnames are set to true in your VPC settings. These settings appear as DNS hostnames and DNS resolution in the VPC Console UI.
  • Ports: Client and AQL tests use TLS port 4000.
  • Security groups: Your security groups allow outbound TCP 4000 to the Aerospike VPC CIDR range. See AWS Security Group Rules documentation for more details.
  • Network ACLs: No network ACLs are blocking the traffic.
  • Propagation time: You waited at least 10 minutes after applying route changes for them to propagate.

The AWS Network Reachability Analyzer tool is helpful for debugging network connectivity issues.

Conclusion

After peering is active and routes are properly configured, your AWS resources (EC2, EKS, etc.) communicate privately with Aerospike Cloud. This approach eliminates internet exposure and generally yields lower latency. If you experience any issues connecting, see the Troubleshooting section.

What’s next
Feedback

Was this page helpful?

What type of feedback are you giving?

What would you like us to know?

+Capture screenshot

Can we reach out to you?