Skip to content

AWS Client VPN – Is there a limit on N number of devices connecting with individual certificates?

0

Hello AWS Community,

We have completed a Proof of Concept (PoC) on AWS Client VPN where we are connecting multiple medical stands to our AWS VPC using mutual certificate-based authentication (Mutual TLS). Each medical stand is assigned its own unique client certificate and private key for secure identification and individual revocation capability.

As we plan to scale this setup to production, we would like to understand the following

  1. Is there a hard or soft limit on the number of concurrent device connections (individual stands) that can connect to a single AWS Client VPN endpoint?

  2. Is there any limitation on the number of individual client certificates that can be used for mutual authentication on a single Client VPN endpoint?

  3. What is the maximum size of the Client Certificate Revocation List (CRL) supported per endpoint? Will this become a bottleneck as we scale to N number of stands?

  4. If default limits are hit, can they be increased via a Service Quota increase request?

  5. Are there any architectural best practices or alternative approaches recommended for connecting a large number of IoT-like devices or medical stands using individual certificates at scale?

Our Setup Details

  • Authentication method: Mutual TLS (certificate-based)
  • Each stand has a unique client certificate issued from a common CA
  • Certificates are managed individually per stand for granular revocation
  • We are evaluating how this scales to 1000 stands

Any guidance from AWS engineers or community experts on the scalability limits and best practices would be greatly appreciated.

Thank you!

1 Answer
1

Your use case sounds interesting!

Your setup (unique certificate per medical stand with mutual TLS) is a solid approach. Here are the answers to each of your questions, based on current AWS documentation.

1. Concurrent connection limit per endpoint

There is no fixed "hard limit" for concurrent connections — it scales based on how many subnets you associate with your Client VPN endpoint:

Subnet associationsMax concurrent connections
17,000
236,500
366,500
496,500
5126,000

For your target of 1,000 stands, even a single subnet association (7,000 connections) is more than enough. This quota is also adjustable via Service Quotas if you ever need more.

Make sure your Client CIDR range is large enough — AWS recommends allocating twice the number of IP addresses as your expected concurrent connections. For 1,000 stands, a /21 (2,048 IPs) would work, but a /16 gives you plenty of room to grow. You can't change the CIDR after creation.

2. Number of individual client certificates

There is no AWS-imposed limit on the number of unique client certificates you can use for mutual authentication. As long as each certificate is signed by the same CA (the one you uploaded as the server trust chain), the endpoint will accept it. You can issue thousands of unique certs — one per stand — without hitting a certificate count limit.

3. Certificate Revocation List (CRL) size

The CRL supports up to 20,000 entries per endpoint. This is a hard limit and is not adjustable. For 1,000 stands, this gives you plenty of headroom — even if you revoke every single certificate you've ever issued, you'd need to revoke 20,000 before this becomes a concern.

One thing to plan for: you need to manage CRL updates yourself. When you revoke a certificate, you regenerate the CRL and upload it to the endpoint via import-client-vpn-client-certificate-revocation-list. Consider automating this — the AWS blog post "Automate AWS Client VPN's CRL updates when using AWS Private Certificate Authority" walks through this.

4. Can limits be increased?

QuotaAdjustable?
Concurrent connections per endpointYes
Client VPN endpoints per RegionYes (default: 5)
Authorization rules per endpointYes (default: 200)
Routes per target network associationYes (default: 100)
CRL entries (20,000)No
Concurrent operations per endpoint (10)No

Request increases through the Service Quotas console.

5. Best practices for scaling to 1,000+ medical stands

  • Use AWS Private CA instead of self-managed OpenSSL/easy-rsa. It gives you programmatic certificate issuance, built-in revocation, and scales much better for fleet management. You can automate cert provisioning as part of your stand deployment pipeline.

  • Size your Client CIDR generously — use /16 or larger. You can't change it later, and it costs nothing to over-provision.

  • Associate at least 2 subnets (in different AZs) for high availability. Even though 1 subnet handles 7,000 connections, a second subnet gives you failover if an AZ goes down — critical for medical devices.

  • Automate CRL updates — don't rely on manual uploads. Use a Lambda function triggered when certificates are revoked to regenerate and upload the CRL automatically.

  • Monitor with CloudWatch — Client VPN publishes connection metrics. Set alarms on concurrent connection count so you know when you're approaching limits.

  • Consider split-tunnel if your stands only need to reach specific VPC resources (not all internet traffic). This reduces bandwidth load on the endpoint.

  • Alternative for very large scale (10,000+): If you eventually grow well beyond 1,000 devices and need IoT-style device management (certificate rotation, thing shadows, fleet provisioning), consider whether AWS IoT Core with its built-in mutual TLS and device management might be a better fit. But for 1,000 stands connecting to a VPC, Client VPN with mutual TLS is a well-suited and proven approach.

Summary

Your architecture is sound for 1,000 stands. The limits are generous (7,000+ connections, 20,000 CRL entries), and the key quotas are adjustable. Focus on automating certificate lifecycle management and CRL updates as you scale.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Sources: AWS Client VPN quotas, Client VPN scaling considerations, Rules and best practices

AWS
EXPERT
answered a month ago
EXPERT
reviewed a month ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.