Plan how the application will reach its PD AWS ElastiCache service before provisioning. This module creates node-based caches in an AWS VPC. The AWS management key used by the billing system is separate from the application’s private route, TLS connection and cache AUTH token.

Establish the application path

Use an application server in the cache’s VPC or an established private route into that network. The module does not create an application server, VPN or tunnel for you. AWS describes VPC access patterns for ElastiCache; have the administrator review the actual network path for the intended client.

The module attempts to create its own cache subnet group and firewall group using the selected region’s default VPC. Check VPC, subnets, routing, DNS and creation permissions before the first order. Confirm the resulting firewall assignment is dedicated before allowing customers to edit it. A successful replication-group read does not test those creation steps.

Check the connection layers

Review the intended package’s Module settings and region. For a created service, confirm the current primary endpoint and port, normally 6379. Use a TLS-capable application client: the module requests encrypted connections and sets an AUTH token. Keep certificate verification enabled, and keep AWS credentials out of the cache connection settings.

A timeout suggests a network-path or allowed-source check; an authentication refusal needs a private review of the current cache token and application configuration. Do not open all source addresses as a diagnostic shortcut. Compare the original requested network change with the actual AWS assignment and permitted source. If the result is uncertain, record both observations before attempting more changes; repeated changes can obscure the original result.

See the PD AWS ElastiCache Blesta guide for related tasks, or explore PD AWS ElastiCache.