High-Level Architecture Overview

Our RDS VPC Endpoint Service enables secure, compliant, private cross-account access to your Amazon Aurora or RDS database – without exposing any database endpoints to the public internet. The solution creates a compliant, scalable networking layer around your database that you can safely share with Render services in other AWS accounts.

Below is an overview of the key components we put in place and how they work together.

1. Amazon RDS Proxy

RDS Proxy provides a stable, highly available connection endpoint for your Aurora cluster. Instead of connecting directly to the database, consumers connect to the Proxy. The proxy is the true upstream target for all inbound traffic. Everything else (NLB, VPC Endpoint Service, consumer VPC endpoints) ultimately routes to the RDS Proxy.

Why it matters:

• Protects your database from connection storms.

• Reduces failover times.

• Maintains stable connections even if the Aurora writer node changes.

• Manages authentication securely via AWS Secrets Manager.

2. Network Load Balancer

The Network Load Balancer exposes the RDS Proxy as a static, IP-address-based target that AWS VPC Endpoint Services require. Consumers connect privately to the NLB from their own VPC using an Interface VPC Endpoint. NLB is the AWS-required integration point for PrivateLink when serving TCP traffic such as PostgreSQL or MySQL.

How it fits into the solution:

• The NLB listens on your database port (e.g., 5432).

• The backend target group contains the current IP addresses of the RDS Proxy.

• Since an RDS Proxy endpoint resolves to multiple IPs that may change, the NLB target group is dynamically updated by a Lambda function (see below).

3. VPC Endpoint Service

This is the private service that you share with other AWS accounts. Authorized consumers can create Interface VPC Endpoints in their own VPCs, and those endpoints will route traffic privately to your NLB.

• No public exposure of your database.

• No need for VPC peering or transit gateways.

• Traffic stays on AWS’s secure, private network fabric.

• You fully control which AWS accounts can access your database.

How it fits into the solution:

• The service is automatically linked to your NLB.

• You explicitly allow one or multiple consumer AWS accounts to connect.

• Consumers see a stable, AWS-managed endpoint in their own VPC (“com.amazonaws.vpce-svc-xxxx”).

4. IP Auto-Update Lambda Function

Because RDS Proxy endpoints resolve to IP addresses that may change over time, the NLB target group must always reflect the correct set of upstream IPs.

This Lambda function automatically:

• Resolves the current IPs of the RDS Proxy endpoint.

• Compares them with the IPs currently registered in the NLB target group.

• Registers any new IPs.

• Deregisters any outdated IPs.

Without this automation, database connections could silently route to dead targets after RDS Proxy rotations, DNS changes, or failovers.
This ensures the backend stays healthy without requiring operators to manually update NLB targets.

The PrivateLink architecture is deployed directly into the customer’s AWS account and therefore uses the customer’s own Availability Zones. During implementation, Argorand deploys the Network Load Balancer and corresponding VPC Endpoint Service across at least two (2) AZs as required. A post-deployment report lists the actual AZ IDs (e.g., use1-az1, use1-az2) where the service is available.

Connecting from Render.com via Render PrivateLink

Applications running on Render can connect securely to the PrivateLink-enabled database access service using Render PrivateLink, which allows outbound connectivity from Render’s infrastructure into AWS VPC Endpoint Services.

With this approach:

1. Argorand deploys the RDS PrivateLink architecture (RDS Proxy → NLB → VPC Endpoint Service) inside the customer’s AWS account.

2. Render PrivateLink creates a managed network tunnel from Render’s environment into the AWS VPC Endpoint Service associated with the database.

3. Render provisions an Interface VPC Endpoint that maps directly to the VPC Endpoint Service ID we provide.

4. The Render application connects to the resulting private endpoint DNS name, ensuring all traffic stays on a private, encrypted path between Render and the customer’s VPC.

5. No public IPs, no VPN, and no exposed database ports are required.

This gives Render-hosted applications the same secure, private, compliant connectivity as workloads running inside AWS.