ElastiCache — Managed In-Memory Cache

AWS docs: https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.html

ElastiCache uses the AWS Query protocol (form-encoded POST, XML responses). Operations are identified by the Action parameter with API version 2015-02-02.

When Docker is available, CreateCacheCluster, CreateReplicationGroup, and CreateServerlessCache start real containers with automatic port allocation from ELASTICACHE_PORT_BASE (default 63790). A readiness check polls the engine’s own protocol before transitioning to “available” — PING for Redis and Valkey, version for Memcached. A dial is not enough: Docker’s published port accepts connections as soon as the port proxy is up, before the engine has bound anything. An engine that never answers is not left claiming progress. A cache cluster settles in incompatible-network and a replication group or serverless cache in create-failed, which are the terminal statuses AWS documents for each of those three shapes, with the reason recorded on the record. When Docker is unavailable, operations are metadata-only and status transitions immediately.

One Overcast does not manage another’s cache. A cache cluster ID, replication group ID and serverless cache name are all names you choose, so two Overcasts sharing a Docker daemon can each hold one called sessions, and the container labels that name — startup reconciliation and the Docker event stream match on the creating instance’s identity as well, rather than marking a cache stopped that the other one is still serving. The container name is derived from the resource name and Docker requires it to be unique per daemon, so the second Overcast to start a cache of that name fails it with a reason saying so instead of quietly sharing the first one’s. Give them different names, or a Docker daemon each.

Supported engines: redis (redis:6, redis:7), valkey (valkey/valkey:7, valkey/valkey:8), memcached (memcached:1.5, memcached:1.6).

[!NOTE] Replication groups start a single primary container only — no multi-node replication is wired up between replicas.

VPC placement

A cache cluster or replication group created with a CacheSubnetGroupName lands on that subnet group’s VPC network and nothing else, so a Lambda or ECS task outside the VPC cannot reach it — as on AWS, where ElastiCache is never publicly accessible and has no PubliclyAccessible escape hatch. Put the caller in the same VPC.

CreateCacheCluster, CreateReplicationGroup and the CloudFormation resources for both accept the field. A serverless cache carries subnet IDs directly instead, and resolves its VPC from the first one that names it.

Create either without a subnet group and it stays on the default plane, which is where AWS puts a cache that names no subnet group too — its default VPC. That is not “reachable from everywhere”: a caller that named a VPC of its own has given up the default plane, so it still cannot reach the cache. Put both in the same VPC, or leave both out of one.

CacheSubnetGroupName is a create-only parameter: AWS does not return it on the ReplicationGroup shape, so neither does Overcast.

See Networking § Lambda, ECS and VPCs for the full picture and for what a refused connection looks like.

CloudFormation

AWS::ElastiCache::CacheCluster names its cluster with ClusterName — the resource has no CacheClusterId property, whatever the API calls the parameter. Leave it out and CloudFormation generates the name from the stack, the logical ID and a random suffix, lowercased and capped at the 50 characters ElastiCache allows in a cluster ID.

A cache cluster’s endpoint reaches a template through Fn::GetAtt, under the attribute pair its engine has — RedisEndpoint.Address/.Port for Redis and Valkey, ConfigurationEndpoint.Address/.Port for Memcached, as AWS populates them. The pair the engine does not have resolves to the empty string, so a template that reads the wrong one for its engine gets the same nothing here that it would get on AWS, rather than a value that works only locally.

A replication group’s PrimaryEndPoint and ConfigurationEndPoint both carry the endpoint. AWS populates the first only for a cluster-mode-disabled group and the second only for a cluster-mode-enabled one; Overcast starts a single primary and models neither node groups nor replicas, so it cannot yet tell the two apart.

These are data-plane hostnames — the VPC placement above decides who can resolve one.

---

Summary

Category	✅ Supported	❌ Unsupported
General	22	2

---

Endpoints

General

Operation	Status	Notes	AWS Docs
AddTagsToResource	✅ Supported	ARN-scoped tag storage	docs
CreateCacheCluster	✅ Supported	Docker-backed (redis/valkey/memcached); async creating→available once the engine answers PING; a cache that never answers ends in incompatible-network; port auto-alloc; PreferredAvailabilityZone, CacheParameterGroupName and inline Tags round-trip; the CloudFormation resource’s Port, VpcSecurityGroupIds, AZMode, TransitEncryptionEnabled, SnapshotRetentionLimit, NotificationTopicArn, PreferredMaintenanceWindow, AutoMinorVersionUpgrade and LogDeliveryConfigurations are not modeled	docs
CreateCacheParameterGroup	✅ Supported	Stores name, family, description, and ARN	docs
CreateCacheSubnetGroup	✅ Supported	Stores name, description, and subnet IDs	docs
CreateReplicationGroup	✅ Supported	Docker-backed (single primary node); async creating→available once the primary answers PING; a group that never answers ends in create-failed; CacheSubnetGroupName places the group in that subnet group’s VPC; Engine/EngineVersion pick the container image (redis/valkey/memcached) — previously dropped on Create, defaulting every group to redis regardless of the template (#543); SnapshotRetentionLimit and PrimaryClusterId also round-trip from Create; the CloudFormation resource’s NumCacheClusters, NumNodeGroups, ReplicasPerNodeGroup, CacheParameterGroupName, AtRestEncryptionEnabled, TransitEncryptionEnabled, AuthToken, KmsKeyId, UserGroupIds, CacheSecurityGroupNames, LogDeliveryConfigurations, Tags, NotificationTopicArn, PreferredMaintenanceWindow, SnapshotWindow and SecurityGroupIds are not modeled	docs
CreateServerlessCache	✅ Supported	Docker-backed (redis/valkey/memcached); async creating→available once the engine answers PING; a cache that never answers ends in create-failed; CloudFormation ServerlessCache supported	docs
DeleteCacheCluster	✅ Supported	Sets status to “deleting”; stops and removes Docker container asynchronously	docs
DeleteCacheParameterGroup	✅ Supported	Removes stored parameter group	docs
DeleteCacheSubnetGroup	✅ Supported	Removes stored subnet group	docs
DeleteReplicationGroup	✅ Supported	Sets status to “deleting”; stops and removes Docker container asynchronously	docs
DeleteServerlessCache	✅ Supported	Sets status to “deleting”; stops and removes Docker container asynchronously	docs
DescribeCacheClusters	✅ Supported	List all or filter by CacheClusterId	docs
DescribeCacheEngineVersions	❌ Unsupported	stub; returns 501	docs
DescribeCacheParameterGroups	✅ Supported	List all or filter by name	docs
DescribeCacheParameters	✅ Supported	Returns curated static parameters for the group’s family; supports Source filter and MaxRecords/Marker pagination	docs
DescribeCacheSubnetGroups	✅ Supported	List all or filter by name	docs
DescribeReplicationGroups	✅ Supported	List all or filter by ReplicationGroupId	docs
DescribeServerlessCaches	✅ Supported	List all or filter by ServerlessCacheName	docs
ListTagsForResource	✅ Supported	Returns all tags for an ARN	docs
ModifyCacheCluster	✅ Supported	Metadata-only; updates nodeType, engineVersion, numNodes, parameterGroup; modifying→available	docs
ModifyReplicationGroup	✅ Supported	Metadata-only; updates description, nodeType, failover, multiAZ; modifying→available	docs
ModifyServerlessCache	✅ Supported	Metadata-only; updates description, engine/version, usage limits, security groups, snapshots, and user group; modifying→available	docs
RebootCacheCluster	❌ Unsupported	stub; returns 501	docs
RemoveTagsFromResource	✅ Supported	Removes specific tag keys	docs