MCP Server ElastiCache Redis — VPC placement, parameter groups, eviction policy, ioredis

VPC and networking architecture

ElastiCache Redis clusters have no public internet endpoint. Every connection must originate from inside the VPC. The access path for an MCP server depends on where it runs:

• ECS Fargate in the same VPC — connect directly to the ElastiCache primary endpoint over the internal network. No NAT Gateway or VPC endpoint needed.
• Lambda in the same VPC — Lambda must be placed inside VPC subnets (set vpcConfig in the Lambda function configuration or CDK). The Lambda adds ~10ms cold start latency due to ENI attachment, but this is now much lower than in early Lambda generations.
• Lambda without VPC config — Lambda functions without VPC config cannot reach ElastiCache. You must add VPC configuration or use an intermediary (e.g., an API Gateway route backed by a VPC-connected Lambda).

Create a subnet group that covers the private subnets in each Availability Zone where your MCP server runs. The ElastiCache replication group will place a primary node in one AZ and replica nodes in others. The subnet group controls which AZs are available for node placement.

Security group configuration:

• Create a dedicated ElastiCache security group (elasticache-sg) with no inbound rules from the internet.
• Add an inbound rule: TCP port 6379 from the MCP server's security group (mcp-server-sg).
• Never add inbound rules from 0.0.0.0/0 — ElastiCache should only be reachable from your application tier.

// CDK: ElastiCache replication group in private subnets
import * as elasticache from "aws-cdk-lib/aws-elasticache";
import * as ec2 from "aws-cdk-lib/aws-ec2";

const elasticacheSg = new ec2.SecurityGroup(this, "ElastiCacheSg", {
  vpc,
  description: "ElastiCache Redis — allow access from MCP server only",
  allowAllOutbound: false,
});

const mcpServerSg = new ec2.SecurityGroup(this, "McpServerSg", {
  vpc,
  description: "MCP server security group",
});

// Allow MCP server to reach Redis on port 6379
elasticacheSg.addIngressRule(
  ec2.Peer.securityGroupId(mcpServerSg.securityGroupId),
  ec2.Port.tcp(6379),
  "Allow Redis from MCP server"
);

const subnetGroup = new elasticache.CfnSubnetGroup(this, "RedisSubnetGroup", {
  description: "ElastiCache private subnet group",
  subnetIds: vpc.privateSubnets.map((s) => s.subnetId),
  cacheSubnetGroupName: "mcp-redis-subnet-group",
});

const paramGroup = new elasticache.CfnParameterGroup(this, "RedisParamGroup", {
  cacheParameterGroupFamily: "redis7",
  description: "MCP server Redis parameters",
  properties: {
    "maxmemory-policy": "volatile-lru",
    "hz": "20",
    "lazyfree-lazy-eviction": "yes",
    "lazyfree-lazy-expire": "yes",
    "activerehashing": "yes",
  },
});

const redis = new elasticache.CfnReplicationGroup(this, "McpRedis", {
  replicationGroupDescription: "MCP server session cache",
  numCacheClusters: 2,              // 1 primary + 1 replica
  cacheNodeType: "cache.t4g.small",
  engine: "redis",
  engineVersion: "7.1",
  cacheParameterGroupName: paramGroup.ref,
  cacheSubnetGroupName: subnetGroup.ref,
  securityGroupIds: [elasticacheSg.securityGroupId],
  authToken: process.env.REDIS_AUTH_TOKEN,   // set before creation
  transitEncryptionEnabled: true,
  atRestEncryptionEnabled: true,
  automaticFailoverEnabled: true,
  multiAzEnabled: true,
});

The primaryEndPoint.address attribute of the replication group gives you the primary endpoint; readerEndPoint.address gives the reader endpoint that load-balances across replicas.

Parameter group configuration

ElastiCache does not allow CONFIG SET at runtime — any attempt is rejected with ERR unknown command 'config' or ERR command not allowed from scripts depending on the ElastiCache version. All parameters must be set in a custom parameter group before the cluster is created.

Connecting with ioredis

Use the primary endpoint for writes (session creation, updates) and the reader endpoint for reads (status checks, session reads that can tolerate a few milliseconds of replication lag).

import Redis from "ioredis";

// Primary endpoint — all writes
const redisWriter = new Redis({
  host: process.env.ELASTICACHE_PRIMARY_ENDPOINT,
  port: 6379,
  password: process.env.REDIS_AUTH_TOKEN,
  tls: {}, // required when transit encryption is enabled
  // ElastiCache uses AWS-managed TLS certificate;
  // the CA is trusted by Node's default bundle since Node 18+
  connectTimeout: 5000,
  maxRetriesPerRequest: 3,
  retryStrategy: (times: number) => Math.min(times * 100, 3000),
  lazyConnect: false,
});

// Reader endpoint — read-only operations
const redisReader = new Redis({
  host: process.env.ELASTICACHE_READER_ENDPOINT,
  port: 6379,
  password: process.env.REDIS_AUTH_TOKEN,
  tls: {},
  connectTimeout: 5000,
  maxRetriesPerRequest: 3,
  retryStrategy: (times: number) => Math.min(times * 100, 3000),
  lazyConnect: false,
});

// Store a session with TTL
export async function setSession(
  sessionId: string,
  data: Record,
  ttlSeconds: number
): Promise {
  // SET with EX ensures the key has a TTL — required for volatile-lru to protect it
  await redisWriter.set(
    `session:${sessionId}`,
    JSON.stringify(data),
    "EX",
    ttlSeconds
  );
}

// Read a session (can use reader replica)
export async function getSession(
  sessionId: string
): Promise | null> {
  const raw = await redisReader.get(`session:${sessionId}`);
  if (!raw) return null;
  return JSON.parse(raw) as Record;
}

Always set a TTL when storing session data. Without a TTL, the key does not qualify for volatile-lru eviction and will remain in memory indefinitely, eventually causing out-of-memory errors.

Eviction policy selection

The maxmemory-policy parameter controls what Redis does when it reaches the memory limit. For MCP session state, volatile-lru is almost always the correct choice.

Set TTL on every session key with EX in the SET command or EXPIRE. If you store a session key without a TTL, it will never be evicted under volatile-lru, accumulating until memory is exhausted.

Common failure modes