PD AWS ElastiCache for Blesta

PD AWS ElastiCache lets a hosting company sell Amazon ElastiCache, the managed in-memory cache for Redis OSS or Valkey, as its own package in Blesta. Your customer orders and pays, a dedicated cache is built in your AWS account, and your customer runs it from the Blesta client portal: 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 package customers already ask for. Redis-protocol caches are a standard part of modern application stacks. Sell one beside your hosting packages, with your pricing and your brand on every page.

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

Every paid order sets itself up. Blesta adds a new order as pending and provisions it once the invoice is paid, through its Provision Paid Pending Services task. The cache is built in the region the customer chose, on the node size they picked, with no work in 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. Under Settings, Company, Modules, open PD AWS ElastiCache and add an account with its keys. The secret is stored encrypted. Test Connection in the PD Modules panel makes one read-only call; nothing is created.
2. Create your package. Choose PD AWS ElastiCache as the module and pick the account, region, node size, engine and engine version. The package form offers dropdowns of what is actually on offer.
3. Generate and price the options. One click in the Products panel attaches Region, Plan and Version as package options, trimmed to what AWS offers in that region, each at price zero. You set every price under Package Options. 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. Their endpoint and AUTH token appear on the service page as soon as AWS reports the cache available.

What you get in Blesta

Selling and pricing

• Region, Plan and Version as package options, with node sizes trimmed to what AWS offers in the package'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 package: 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 the 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 Blesta 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 package: turn one off and it disappears from the customer's menu and the server refuses it too. The pages follow the client portal's own theme and are fully translatable, with overrides that survive updates.

Security built in

• Your AWS key is stored encrypted on the module account 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 Blesta 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

• Blesta 6 or later on PHP 8.2 or later, with the ionCube Loader
• An AWS account and an IAM user with the policy we provide
• Blesta's cron running, so paid orders are provisioned
• PD Modules, the free control panel every PD module installs into