AWS RDS Proxy stuck with PENDING_PROXY_CAPACITY

The agent's answer covers good general troubleshooting (subnet IPs, security groups, RDS events). I'd like to add some targeted guidance based on the specific sequence of actions you described.

TLS configuration mismatch:

You created Proxy 2 with RequireTLS=true, and Proxy 1's issue started after toggling RequireTLS. When RequireTLS=true, the proxy must establish TLS connections to the Aurora backend. If your Aurora cluster doesn't accept TLS connections, the proxy will never successfully connect to its targets and they'll stay in PENDING_PROXY_CAPACITY indefinitely.

To verify:

1. Connect directly to your Aurora cluster with TLS enforced:

   mysql -h your-cluster-endpoint -u your_user -p --ssl-mode=REQUIRED

   If this fails, your Aurora cluster isn't configured for TLS and that's your root cause.

2. Check the cluster parameter group for require_secure_transport. Also verify the cluster has a valid CA certificate associated.

Secrets Manager credentials:

RDS Proxy authenticates to Aurora using credentials stored in Secrets Manager. If the secret contains stale or incorrect credentials, the proxy can't establish backend connections.

Verify:

1. Retrieve the secret value and confirm the username/password work by connecting directly to Aurora with those credentials.
2. Confirm the proxy's IAM role has secretsmanager:GetSecretValue permission on the secret's ARN.
3. If the secret was recently rotated, ensure the new credentials are valid.

Security group path from proxy to Aurora:

The proxy's ENIs need to reach Aurora on the database port. Confirm the Aurora cluster's security group allows inbound 3306 (MySQL) or 5432 (PostgreSQL) from the proxy's security group.

Quick isolation test:

Create a third proxy with RequireTLS=false and the simplest possible configuration (same VPC, same subnets, same secret). If targets become AVAILABLE, the issue is TLS configuration on Proxy 2 (and was the same problem on Proxy 1 after the toggle).

Regarding the missing CloudWatch log group:

Enhanced logging won't produce a log group until the proxy is fully provisioned and processing connections. Since the proxy is stuck in provisioning, the absence of logs is expected and not a separate problem.

References:

• Setting up TLS/SSL for RDS Proxy connections to Aurora (https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy-setup.html#rds-proxy-security.tls)
• RDS Proxy troubleshooting (https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.troubleshooting.html)
• Using Secrets Manager with RDS Proxy (https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy-setup.html#rds-proxy-iam-setup)

The PENDING_PROXY_CAPACITY state indicates that your RDS Proxy targets are waiting for the proxy to scale to its desired capacity. This is typically a temporary condition that should resolve automatically, but when it persists for 30+ minutes as you're experiencing, it suggests a capacity provisioning issue.

Here are some steps to help diagnose and resolve this:

Immediate troubleshooting:

1. Check your subnet configuration - Ensure the subnets associated with your proxy have sufficient available IP addresses. RDS Proxy requires multiple IP addresses to scale, and insufficient IPs in your subnets can prevent capacity provisioning. Review your VPC subnet CIDR blocks and current IP usage.

2. Verify connectivity requirements - Confirm that your proxy's security groups allow proper communication with the Aurora cluster. The proxy needs to reach the database instances on their designated ports.

3. Review RDS events - Check the RDS event log for your proxy in the AWS Console or via CLI. Look for events related to insufficient IP addresses, connection limits, or other capacity-related messages that might explain the scaling delay.

4. Monitor the TargetHealth details - Continue running describe-db-proxy-targets and examine the Description field within TargetHealth for additional context about why capacity provisioning is delayed.

Regarding your specific situation:

The fact that both an existing proxy (after RequireTLS changes) and a newly created proxy exhibit the same behavior suggests this may be an environmental constraint rather than a configuration issue with the proxies themselves. The RequireTLS toggle on Proxy 1 likely triggered a scaling operation that couldn't complete.

Additional actions to consider:

• If your subnets are constrained, consider adding additional subnets to the proxy configuration or using subnets with larger CIDR blocks
• Verify that you haven't hit any service limits for RDS Proxy in your region
• For the debug logging issue, note that enhanced logging can take some time to initialize, and the log group should appear once the proxy becomes operational

If the issue persists after checking these items, I recommend adding detailed correspondence about your subnet configuration and any RDS events you're seeing to your support case at https://console.aws.amazon.com/support/ for further investigation into potential capacity constraints in your environment.
Sources
Troubleshooting for RDS Proxy - Amazon Relational Database Service
Amazon RDS examples using AWS CLI - AWS SDK Code Examples
Troubleshooting for RDS Proxy - Amazon Aurora

My DB behind the Proxy is postgres. I did perform below mentioned tests and these were all ok "Connect directly to your Aurora cluster with TLS enforced: If this fails, your Aurora cluster isn't configured for TLS and that's your root cause. Check the cluster parameter group for require_secure_transport. Also verify the cluster has a valid CA certificate associated.Retrieve the secret value and confirm the username/password work by connecting directly to Aurora with those credentials. Confirm the proxy's IAM role has secretsmanager:GetSecretValue permission on the secret's ARN. If the secret was recently rotated, ensure the new credentials are valid."
I did create another Proxy with no TLS and still the same error. AI agent KIRO suggested to delete and create fresh Proxy. - Fresh RDS Proxy in us-east-1 stuck in PENDING_PROXY_CAPACITY indefinitely. Created multiple proxies (with and without TLS) — all exhibit same issue. No modifications made after creation. Aurora cluster is healthy and available.