PD AWS ElastiCache for WHMCS

PD AWS ElastiCache lets a hosting company sell Amazon ElastiCache, the managed in-memory cache for Redis OSS or Valkey, as its own product. Your customer orders in your WHMCS cart, a dedicated cache is built in your AWS account, and your customer runs it from your client area: connection details, usage charts, snapshots, an allowed-address list and an AUTH token reset, with no AWS console and no mention of Amazon. You set the price, AWS bills you the cost, and the difference is your margin.

It is built for hosts whose customers need a fast cache or session store behind a web application: WordPress and WooCommerce sites, Laravel and Django apps, job queues and rate limiters. Those customers know Redis, ask for it by name, and would rather buy it from their host than set up AWS themselves.

Why hosts choose PD AWS ElastiCache

A product customers already ask for. Redis-protocol caches are a standard part of modern application stacks. Sell one as a line item beside your hosting, with your pricing and your brand on every page.

Redis or Valkey, your choice per product. Set the engine once on the product and every order of it gets that engine. A Valkey product is offered Valkey versions and a Redis product Redis versions, and the customer's page names which they have. Both use port 6379 and the same redis-cli and client libraries.

Every order sets itself up. A paid order creates a dedicated cache in the region the customer chose, on the node size they picked at checkout. No one on your team opens the AWS console.

Nothing is shared between customers. Each cache gets its own security group, named for the service. If the region has no default network, or your key cannot create a security group, the order is refused with the reason in your Activity log. The cache is never put on a shared firewall.

Suspension that really cuts access. A cache cannot be stopped, so suspending closes its firewall instead, saving the rules. Unsuspending restores exactly those rules. If the firewall could not be closed, the suspension is reported as failed, never as done.

Nothing left billing. Terminating a service removes the cache, its nodes, its own firewall, its subnet group and its manual snapshots, then confirms at AWS that they are gone.

How it works

1. Connect your AWS account. Create an IAM user with the policy in our guide and add its keys once on a WHMCS server record. Test Connection makes one read-only call; nothing is created.
2. Create your product. Choose the Other product type and switch automatic setup on, then pick a region, node size, engine and version. One click generates the Region, Plan and Version options for the cart from what AWS offers in that region, each at price zero.
3. Set your prices. You price every option on WHMCS's own Configurable Options screen. The module never changes a price after generation unless you press Rebuild, and the button warns you first.
4. Your customer orders. They choose their options and pay. The cache is built, and its endpoint and AUTH token appear on their service page as soon as AWS reports it available.

What you get in WHMCS

Selling and pricing

• Region, Plan and Version as cart options, with node sizes trimmed to what AWS offers in the product's region
• A default node size that is always one AWS currently offers
• A blank version means whatever AWS uses for new caches; a chosen version is the one provisioned
• A chosen option's price is what the invoice and every renewal charge, in the customer's currency
• A resource name prefix of your choice, so caches read as <prefix>-<service id> in AWS
• Switches for each customer feature, per product: snapshots, firewall, connection details and usage graphs

Provisioning you can trust

• If AWS refuses an order, you see AWS's reason in the Activity log and the customer is told it could not be set up, never left on "still provisioning"
• Creating a service again adopts the cache that already exists instead of building a second one
• Plan upgrades and downgrades change the node type in place, with no rebuild
• A cache deleted outside WHMCS is reported to you in the Activity log, never to the customer
• The module refuses to be deactivated while it still tracks caches, so no record is orphaned

Running it day to day

• Clients and Caches: every cache with its service, node size, region, endpoint and state
• Activity: recent provisioning and actions across all clients, with the outcome and AWS's reason for any failure
• A Report showing licence state, your configured AWS accounts and the cache count
• Read-only AI tools for service status, the list and recent activity; nothing can create, resize or delete through them

What your customers get

• Reboot and AUTH token reset. There is no Start or Stop, because ElastiCache cannot stop a cache, and the pages do not pretend otherwise. A reset takes effect within minutes and only the new token works
• Connection details with copy buttons: endpoint, port 6379, username, AUTH token and a ready-to-paste redis-cli command with TLS on. No certificate file is needed
• Usage graphs for CPU, connected clients, freeable memory and memory usage over the last 24 hours
• Snapshots they take in one click and delete when finished, each with its date. AWS also keeps one automatic daily backup for a day
• A firewall where they add and remove IPv4 addresses or ranges. A new cache allows nothing until they do, and an invalid entry is refused with a message
• Activity, the last 40 actions in plain words with when and how each ended

Each cache is a single node with no automatic failover. If the node fails, AWS replaces it after a short outage, and the pages say so. Restoring a snapshot is your job in AWS. Caches are private to your AWS network and never get a public address, so customers connect from an application server inside it. Every feature is a switch on the product: turn one off and it disappears from the customer's menu and the server refuses it too. The pages render natively on WHMCS's Six, Twenty-One and Nexus themes and are fully translatable, with overrides that survive updates.

Security built in

• Your AWS key lives on the WHMCS server record, stored encrypted, and never reaches a customer page.
• The AUTH token is stored encrypted on the service and shown only to its owner.
• All connections use TLS.
• A suspended, terminated, cancelled or fraud-held service cannot snapshot or reset anything.
• Only licence data reaches us. Customer data and credentials never do.

One product, every feature

PD AWS ElastiCache is one paid module with everything included: provisioning, reboot, snapshots, firewall, usage graphs and teardown. There are no tiers to compare. It installs into PD Modules in one click, updates itself, and uninstalls cleanly without modifying any WHMCS files.

If your subscription ever lapses, nothing the module built is touched. You get a 14-day grace period with everything working, then admin management locks while customers keep being served, and only after that do customer features pause, behind a neutral message that never mentions licensing. Renewing restores everything at once.

Requirements

• WHMCS 9 or later on PHP 8.2 or later, with the ionCube Loader
• An AWS account and an IAM user with the policy we provide
• PD Modules, the free control panel every PD module installs into