Managing IP address exhaustion for Amazon RDS Proxy

As your organization scales on Amazon Web Services (AWS), you need to effectively manage your network resources. You might experience IP address exhaustion when using Amazon Relational Database Service (Amazon RDS) Proxy, particularly as your database connection demands increases over time. While RDS Proxy excels at handling growing database connection requirement, it requires careful IP address capacity planning to maintain optimal performance as connectivity demands scale up.

For customers experiencing IP exhaustion with RDS Proxy, migrating to IPv6 address space can be an effective solution if your workload supports IPv6. This post focuses on workloads that cannot support IPv6 address space and provides an alternative approach using IPv4 subnet expansion.

You need to understand your IP capacity requirements to maintain operational stability. RDS Proxy dynamically adjusts its capacity based on several factors including database instance size, number of registered instances, scaling operations, and internal maintenance activities. Scarce IP addresses in your subnet can negatively impact database performance through increased query latency or connection failures and create critical security vulnerabilities and limit feature access for your proxy. When IP address space is constrained, the Amazon RDS team cannot apply essential OS security patches to RDS Proxy servers, potentially exposing your infrastructure to security threats. Additionally, this IP address shortage also prevents the RDS Proxy team from making new features available to customers. Amazon RDS proactively alerts you through RDS event ID RDS-EVENT-0243 when your subnets lack sufficient available IP addresses. For information about the reservation of minimum numbers of available IP addresses in your subnets for your proxy, based on database instance class sizes, see Planning for IP address capacity for RDS Proxy.

In this post, you will learn how to address IP address exhaustion challenges when working with Amazon RDS Proxy.

Solution overview

The solution focuses on expanding your Amazon Virtual Private Cloud (Amazon VPC) CIDR range, establishing new subnets, and executing a carefully planned switching of your proxy to a new subnet configuration.

For organizations experiencing current IP constraints or planning for future scaling needs, this solution provides a step-by-step approach that includes three main phases: VPC CIDR expansion, new subnet creation, and application traffic switching to a new RDS Proxy. Each phase is designed to minimize disruption to your existing database operations while establishing a more scalable network architecture.

The approach maintains application availability throughout the process by using parallel deployment techniques, so you can validate the new configuration before transitioning your production workload. This approach supports thorough testing and verification, helping to keep your database connections stable and performant during and after the traffic switching to new RDS Proxy.

This solution helps you scale your infrastructure whether you have immediate IP constraints or are planning for growth. It maintains the RDS Proxy benefits including connection pooling, automatic failover, secure credential management through AWS Secrets Manager, and end-to-end IAM authentication.

Prerequisites

For this walkthrough, you need to have access to the following resources:

• An AWS account.
• A supported RDS instance with RDS Proxy configured.
• AWS Command Line Interface (AWS CLI) installed
• AWS Identity and Access Management (IAM) permissions to manage RDS Proxy, Amazon VPC configurations, and subnet configurations.
• Planned Amazon VPC Route tables and network ACLs for the new subnets.

Amazon RDS Proxy network reconfiguration and transition process

To transition RDS Proxy to a new subnet configuration, this post guides you through a three-step process. This section outlines the AWS CLI commands required to accomplish this task. Alternatively, you can also make these changes using the AWS Management Console.

1. Amazon VPC CIDR expansion: Start by assessing your current IP address usage and projecting future needs. Using the AWS CLI or the console, you can expand your VPC by associating an additional CIDR block. If you don’t have enough available IP addresses to expand the VPC using RFC 1918 address space, you have the option to use the non-routable IP addresses from the Shared Address Space (RFC 6598: 100.64.0.0/10).

   aws ec2 associate-vpc-cidr-block \
    --vpc-id <your-vpc-id> \
    --cidr-block <new-cidr-block>

2. New subnet creation: Create new subnets within your expanded CIDR range across multiple Availability Zones to facilitate high availability. A minimum of two subnets in different Availability Zones is required for the proxy.

   aws ec2 create-subnet \
    --vpc-id <your-vpc-id> \
    --cidr-block <new-subnet-cidr-block> \
    --availability-zone <new-subnet-az>

3. Switch application traffic to the new proxy: Implement a parallel deployment strategy to minimize downtime. Switching application traffic from one proxy to another is best accomplished through a methodical, service-by-service approach that minimizes risk by moving only portions of traffic at a time. By using this strategy, teams can validate performance metrics for each service independently, limit potential disruption to small segments of the application environment and make data-driven decisions throughout the migration process.
   1. Create a new RDS Proxy instance in the newly configured subnets while maintaining the existing proxy.

      # Create new RDS Proxy in the new subnet 
      aws rds create-db-proxy \ 
       --db-proxy-name <new-proxy-name> \ 
       --engine-family <db-engine-family> \ 
       --role-arn <rds-proxy-role-arn> \ 
       --vpc-subnet-ids <subnet-new1> <subnet-new2> \ 
       --vpc-security-group-ids <sg-xxxxx> \ 
       --auth IAMAuth=DISABLED,AuthScheme=SECRETS,SecretArn=<secrets-manager-arn> 

   2. Register the target database instance with the newly created proxy.

      # Create target group for new proxy 
      aws rds register-db-proxy-targets \ 
       --db-proxy-name <new-proxy-name> \ 
       --target-group-name default \ 
       --db-instance-identifiers <database-1> <database-2>

   3. Gradually transition application traffic to the new proxy by updating connection strings in application configuration files, while adjusting the Connection pool maximum connections parameter on both proxies so that their combined total stays within the underlying database instance’s maximum connection limit.
   4. After successful traffic switching and validation with a confidence period (example: one week), remove the original proxy.

      aws rds delete-db-proxy \
       --db-proxy-name <old-proxy-name>

This phased approach facilitates minimal disruption to your applications while establishing a more scalable network architecture for your RDS Proxy implementation.

Best practices for IP address management for RDS Proxy

To facilitate smooth operation during and after switching to a new subnet configuration for RDS Proxy, consider the following best practices for IP address management:

• Subnet planning and organization: Use Amazon VPC IP Address Manager (IPAM) to strategically plan and manage the IP address space for your VPC’s subnets. Group subnets into IPAM pools based on factors such as application, Availability Zone, or other relevant criteria. This will simplify management and make it straightforward to allocate IP addresses as your infrastructure grows.
• IP address monitoring and alerting: Implement monitoring of subnet IP address utilization and RDS Proxy metrics using Amazon CloudWatch. Configure alarms to notify you when IP address usage approaches capacity thresholds, so you can take proactive action before exhausting the available IP addresses.

Conclusion

Addressing IP address exhaustion for Amazon RDS Proxy can be accomplished effectively using the approach outlined in this post. By implementing Amazon VPC CIDR expansion and transitioning to a new RDS proxy, you can effectively scale your database infrastructure while maintaining application availability.

Remember these key takeaways:

• Proactively monitor your IP address utilization to avoid potential connection issues.
• Follow the three-step process: Amazon VPC CIDR expansion, new subnet creation, and application traffic switching to new RDS Proxy.
• Implement application best practices like using DNS names and connection retries.
• Maintain both old and new proxies during the transition period to facilitate smooth cutover.
• Consider RDS Proxy limitations, such as the 20-proxy limit per AWS account and VPC requirements.

By understanding these considerations and following the outlined migration strategy, you can successfully manage IP address exhaustion while taking advantage of the RDS Proxy benefits of connection pooling, improved scalability, and enhanced database resilience.

For ongoing operations, continue monitoring your connection metrics and regularly assess your IP address needs as your workload grows. This proactive approach will help keep your database infrastructure robust and scalable for your business needs.

About the authors