Part 048 — Redis on AWS

AWS changes the Redis operating model.

You may still use Redis-compatible commands and Java clients, but the production responsibilities move into a managed-service boundary.

For enterprise Java/JAX-RS systems, the important question is not only:

Are we using Redis?

The better question is:

Which AWS Redis-compatible service, topology, security mode, failover behavior, network boundary, backup strategy, and observability model are we relying on?

This part focuses on Amazon ElastiCache for Valkey/Redis OSS as the common managed Redis-compatible service used for cache, session state, rate limiting, idempotency, coordination, lightweight queues, and operational acceleration.

Always verify current AWS documentation and internal platform standards because provider capabilities, version support, service names, and security options can change.

1. Mental Model: Managed Redis Is Still Redis

Managed Redis reduces operational burden.

It does not remove Redis design responsibility.

AWS may manage parts of:

• Node provisioning.
• Failover automation.
• Patch maintenance.
• Backups/snapshots.
• Monitoring integration.
• Encryption options.
• Network attachment.
• Replication group lifecycle.

Your engineering team still owns:

• Key design.
• TTL policy.
• Cache correctness.
• Invalidation design.
• Rate limiter behavior.
• Idempotency failure windows.
• Distributed lock correctness.
• Client timeout and retry settings.
• Java client topology awareness.
• Security of application payloads.
• Production readiness of Redis usage.

The managed service can keep Redis running.

It cannot make unsafe application semantics safe.

2. AWS Redis-Compatible Options

Common AWS options around Redis-compatible workloads include:

This series focuses on ElastiCache-style Redis-compatible usage, but the same application-level correctness concerns apply across all options.

3. Terminology Map

AWS terminology can hide Redis concepts.

Do not approve an AWS Redis design unless the team can translate AWS terminology back into Redis behavior.

4. Cluster Mode Disabled vs Enabled

AWS Redis-compatible deployments commonly distinguish cluster mode disabled and cluster mode enabled.

Cluster Mode Disabled

Mental model:

One primary shard
Optional read replicas
One keyspace
No hash slot sharding exposed to application

Useful when:

• Dataset fits one shard.
• Simpler client behavior is preferred.
• Multi-key operations are important.
• Operational simplicity matters more than horizontal keyspace scaling.

Risks:

• Single shard capacity limit.
• Hot key still affects the shard.
• Failover still requires client readiness.

Cluster Mode Enabled

Mental model:

Multiple shards
Each shard owns hash slots
Each shard has primary/replica nodes
Client must be cluster-aware

Useful when:

• Dataset or throughput exceeds one shard.
• Workload can be partitioned by key.
• Multi-key operations are designed around hash tags or avoided.

Risks:

• Cross-slot errors.
• Hot slot.
• More complex client topology refresh.
• Lua and transaction limitations across slots.
• Resharding behavior must be tested.

5. Replication Group Mental Model

A replication group gives high availability through primary/replica topology.

In cluster mode disabled:

Replication Group
  Primary node
  Replica node(s)

In cluster mode enabled:

Replication Group
  Shard 1: primary + replicas
  Shard 2: primary + replicas
  Shard N: primary + replicas

Application design implications:

• Writes go to primary role.
• Replicas may lag.
• Failover may promote a replica.
• Client must reconnect or refresh topology.
• Some acknowledged writes may be lost under asynchronous replication failure windows.

Managed failover does not create linearizable distributed storage.

6. Multi-AZ and Automatic Failover

Multi-AZ with automatic failover improves availability by allowing failover to a replica in another Availability Zone.

It does not mean zero impact.

Expected failure behavior may include:

• Short write unavailability during failover.
• Client reconnects.
• Command timeout spikes.
• READONLY errors on old primary connections.
• Possible write loss due to asynchronous replication window.
• Increased latency if clients and primary move across zones.

Java Client Requirements

• Timeout must be bounded.
• Retry must be safe and limited.
• Client must reconnect cleanly.
• Topology refresh must be enabled for cluster mode.
• Idempotent operations must tolerate retry ambiguity.
• Non-idempotent operations must not blindly retry.

7. Subnet Group and Placement

A subnet group defines which VPC subnets ElastiCache can use.

Placement decisions affect:

• Availability Zone resilience.
• Latency from EKS/ECS/EC2 clients.
• Cross-AZ data transfer cost.
• Blast radius of AZ failure.
• Routing through NAT/firewalls if misconfigured.

Review Questions

• Are Redis nodes spread across suitable AZs?
• Are application pods/instances in the same VPC/subnet architecture?
• Is traffic private, or does it cross unnecessary network boundaries?
• Are there cross-region or hybrid links in the path?
• Does the architecture tolerate AZ-local latency changes after failover?

8. Security Group Design

Security groups define network-level access.

For Redis, broad access is a serious risk.

Bad pattern:

Redis security group allows inbound from large CIDR ranges or entire VPC.
Many services can connect even if they do not own Redis usage.

Better pattern:

Redis security group allows inbound only from application security groups that need it.
Access is reviewed per service/use case.
Network boundary is paired with Redis ACL/RBAC where supported.

Internal Verification Checklist

• Which security groups can access Redis?
• Is access service-scoped or broadly VPC-scoped?
• Are admin/bastion paths controlled?
• Are test/stage/prod Redis networks separated?
• Are cross-account connections explicitly reviewed?

9. Parameter Group

A parameter group controls Redis engine settings.

Parameters may affect:

• Eviction behavior.
• Keyspace notifications.
• Slowlog threshold.
• Client output buffer limits.
• Cluster behavior.
• TLS/auth-related behavior depending on service/version.
• Memory and latency behavior.

A parameter group is production code.

It should be reviewed like code.

Review Questions

• Is parameter group managed by IaC?
• What differs from AWS default?
• Is eviction policy explicit?
• Is slowlog configured usefully?
• Are dangerous features restricted?
• Are changes promoted through environments?
• Is rollback defined?

10. Eviction Policy on AWS

Eviction policy defines what Redis does under memory pressure.

For cache-only data, eviction may be acceptable.

For sessions, idempotency, lock, stream, or security state, eviction may be dangerous.

Architecture Rule

If data loss from eviction breaks correctness, do not rely on ordinary cache eviction semantics for that data.

Review:

• maxmemory-policy.
• Memory headroom.
• Evicted key alarms.
• Keyspace split by use case.
• Whether correctness-sensitive data is mixed with disposable cache data.

Mixing disposable cache and correctness-sensitive state in the same Redis cluster can make eviction policy impossible to reason about.

11. Encryption in Transit

Encryption in transit protects data moving between clients and Redis and between nodes where supported by the service configuration.

Application impact:

• Java clients must support TLS.
• Truststore/certificate configuration must be correct.
• TLS handshake latency may appear during connection churn.
• Non-TLS clients cannot connect to TLS-required endpoints.
• Migration from non-TLS to TLS requires rollout planning.

Java Review Checklist

• Is Redis TLS enabled in production?
• Does the Java client use TLS endpoint/config?
• Is hostname verification configured as intended?
• Is trust material managed securely?
• Is certificate/provider rotation tested?
• Are TLS errors observable separately from command errors?

12. Encryption at Rest

Encryption at rest protects data stored on disk as part of persistence/sync/backup mechanisms, depending on service capability and configuration.

For Redis cache use cases, teams often forget that snapshots/backups can contain sensitive cached values.

Review:

• Is encryption at rest enabled where required?
• Are snapshots encrypted?
• Who can access snapshots?
• Are KMS keys customer-managed or provider-managed?
• Does key rotation affect operations?
• Do snapshots contain PII/token/session/idempotency data?

Security review must include Redis backups, not only live Redis traffic.

13. AUTH, ACL, RBAC, and IAM Awareness

AWS-managed Redis-compatible services may support several authentication/authorization models depending on engine, version, mode, and configuration.

Relevant concepts:

• Redis AUTH token/password.
• Redis ACL-style users and command/key permissions.
• AWS RBAC user groups where supported.
• IAM authentication where supported and enabled.
• Secret rotation and credential lifecycle.

Architecture Rule

Do not assume all authenticated clients should have full Redis access.

Prefer service-scoped access where available.

A rate limiter service should not need permission to read session tokens.

A cache invalidation worker should not need permission to run dangerous administrative commands.

Internal Verification Checklist

• Which auth model is used?
• Are users shared across services?
• Are key pattern permissions scoped?
• Are command categories restricted?
• How are credentials rotated?
• Does Java client support the selected auth model?
• Are IAM token refresh/re-auth constraints understood if IAM auth is used?

14. Backup and Snapshot Strategy

Backup strategy depends on Redis use case.

Snapshot Risks

• Sensitive data exposure.
• Restore to wrong environment.
• Restore old cache values causing stale behavior.
• Restored idempotency state causing unexpected duplicate suppression or replay.
• Restored queue/stream state causing reprocessing.

Do not treat Redis restore as a generic safe action.

It is use-case dependent.

15. Maintenance Window

Managed services have maintenance windows.

Maintenance can cause:

• Node replacement.
• Failover.
• Short connection interruption.
• TLS endpoint/config changes.
• Engine patch behavior changes.
• Latency spikes.

Application teams must know maintenance timing because Java services experience it as dependency disruption.

Review Questions

• What is the maintenance window?
• Does it overlap with high-traffic periods?
• Are Redis clients tested for failover?
• Are on-call teams aware of expected symptoms?
• Is maintenance visible in incident timelines?

16. Engine Version and Compatibility

Redis-compatible does not mean every feature is identical across versions and providers.

Verify:

• Redis OSS vs Valkey engine.
• Major/minor version.
• Cluster mode support.
• ACL/RBAC support.
• TLS migration support.
• Lua/Redis Functions support.
• Stream command support.
• Client library compatibility.
• Deprecated command behavior.

Java Dependency Review

• Does Lettuce/Jedis/Redisson support the engine/version?
• Does the client understand cluster redirections?
• Does it support TLS/auth mode?
• Does it handle topology refresh correctly?
• Are integration tests running against a compatible version?

17. CloudWatch Metrics

CloudWatch metrics are central for AWS-managed Redis operations.

Useful metric categories:

• CPU utilization.
• Engine CPU utilization.
• Memory usage.
• Freeable memory.
• Evictions.
• CurrConnections.
• NewConnections.
• Cache hits/misses.
• Replication lag.
• Network bytes in/out.
• Swap usage if exposed.
• Command latency where available.
• Throttling/limits depending on service mode.

CloudWatch tells you server-side behavior.

You still need Java client metrics for end-to-end diagnosis.

18. Dashboard Design

A production AWS Redis dashboard should combine:

AWS/Redis Metrics

• Node health.
• CPU/engine CPU.
• Memory usage and headroom.
• Evictions.
• Connections.
• Hit/miss ratio.
• Replication lag.
• Failover events.
• Cluster shard distribution.

Java Client Metrics

• Command latency.
• Command timeout count.
• Pool wait time.
• Connection failures.
• Retry count.
• Circuit breaker state.
• Cache hit/miss at application level.
• Redis fallback count.

Business/System Metrics

• HTTP latency.
• Error rate.
• Database QPS.
• Kafka/RabbitMQ consumer lag if cache invalidation depends on messaging.
• Rate limiter decisions.
• Idempotency duplicate/replay count.
• Session/auth failures.

Redis should be correlated with the system it accelerates.

19. Alerting Strategy

Do not alert only on node up/down.

Alert on symptoms that matter.

Recommended alert areas:

• High Redis latency.
• High client-side Redis timeout rate.
• Memory pressure.
• Evictions for correctness-sensitive Redis.
• Low cache hit ratio with DB load increase.
• Rejected connections or connection spike.
• Replication lag.
• Failover event.
• Cluster unhealthy/shard issue.
• Auth failures.
• Stream pending entries growing.
• Rate limiter script errors.
• Lock acquisition failure spike.

Alert design should identify both infrastructure and application semantic failures.

20. Global Datastore and Cross-Region Replication

AWS may provide cross-region replication models such as global datastore depending on service/version/configuration.

Use this carefully.

Cross-region Redis replication is usually asynchronous.

That means:

• Remote region may lag.
• Failover across regions may lose recent writes.
• Session/idempotency/lock semantics can break if assumed strongly consistent.
• Rate limiter global fairness may not hold.
• Cache invalidation may arrive late.

Architecture Rule

Cross-region Redis replication is not a substitute for a globally consistent transactional system.

Use it for latency/read locality or disaster recovery only after understanding staleness and conflict behavior.

21. Common AWS Redis Failure Modes

Failover Spike

Primary fails or is replaced.

Symptoms:

• Redis command timeouts.
• READONLY errors.
• Reconnect spikes.
• Increased p99 HTTP latency.
• Possible duplicate retries.

Mitigation:

• Bounded retries.
• Idempotency for side-effecting operations.
• Client topology refresh.
• Failover game day.

Memory Pressure

Redis approaches memory limit.

Symptoms:

• Evictions increase.
• Cache hit ratio drops.
• DB load increases.
• Latency rises.

Mitigation:

• Capacity planning.
• TTL discipline.
• Hot/big key remediation.
• Separate correctness-sensitive state.

Connection Spike

Application rollout or HPA creates too many connections.

Symptoms:

• NewConnections spike.
• CurrConnections high.
• Rejected clients.
• Java pool acquisition timeout.

Mitigation:

• Pool budget.
• Deployment surge control.
• Startup jitter.
• Connection reuse.

Auth or TLS Misconfiguration

Credential or certificate changes break clients.

Symptoms:

• AUTH failures.
• TLS handshake failures.
• Connection refused/timeouts.
• Pods fail readiness.

Mitigation:

• Rotation runbook.
• Overlap credentials.
• Canary rollout.
• Client-side error classification.

22. AWS Redis and Cache Correctness

Managed Redis does not solve cache correctness.

You still need:

• Clear source of truth.
• TTL policy.
• Invalidation trigger.
• Stale window definition.
• Versioned cache keys.
• Serialization compatibility.
• Cache stampede protection.
• Observability of hit/miss/fill/error.

AWS can provide availability tooling.

It cannot know whether a quote, catalog rule, tenant config, session, token, or order state is safe to cache.

23. AWS Redis and PostgreSQL Integration

For Java/JAX-RS services using PostgreSQL/MyBatis/JDBC, AWS Redis often sits above a relational source of truth.

Failure windows remain:

• DB commit succeeds, Redis invalidation fails.
• Redis cache update succeeds, DB commit fails.
• Migration changes schema, old cache values remain.
• Redis restore reintroduces stale data.
• Failover happens during idempotency update.

Review Questions

• Is Redis cache invalidated after DB commit?
• Is cache update inside or outside DB transaction boundary?
• Are stale values versioned away after schema changes?
• Is Redis restore allowed for this keyspace?
• Does DB fallback survive Redis miss spikes?

24. AWS Redis and Kafka/RabbitMQ Integration

Redis often receives updates from Kafka or RabbitMQ consumers.

Examples:

• Event-driven cache invalidation.
• Projection cache refresh.
• Tenant configuration update.
• Catalog/rule cache rebuild.
• Session/token revocation propagation.

AWS Redis failure interaction:

• Consumer receives event but Redis write fails.
• Redis write succeeds but consumer ack fails.
• Duplicate event updates cache twice.
• Out-of-order event writes stale value.
• Redis failover causes temporary projection lag.

Review Checklist

• Is Redis update idempotent?
• Does event carry version/timestamp?
• Is out-of-order handling defined?
• Can projection be rebuilt?
• Is cache invalidation lag monitored?

25. AWS Redis and Distributed Locking

Using managed Redis does not make Redis locks automatically correct.

The same lock concerns remain:

• Lease expiry.
• Process pause.
• Network partition.
• Failover write loss.
• Lock renewal.
• Safe unlock.
• Fencing token.

For AWS failover scenarios, ask:

• What happens to a lock written shortly before primary failure?
• Can another client acquire the same lock after failover?
• Is the protected resource fenced?
• Is the operation idempotent?
• Is a database constraint safer than Redis lock?

Managed Redis improves availability.

It does not remove distributed lock correctness boundaries.

26. AWS Redis and Rate Limiting

AWS Redis is common for distributed rate limiting.

Review:

• Are limiter keys scoped by tenant/user/IP/endpoint?
• Is limiter logic atomic?
• Is Lua used safely?
• What happens during Redis failover?
• Is fail-open or fail-closed policy explicit?
• Does rate limiter memory grow without cleanup?
• Are 429 responses and Retry-After headers correct?

A Redis failover can temporarily change limiter behavior.

That behavior must be acceptable, not accidental.

27. AWS Redis and Idempotency

Redis idempotency stores are sensitive to durability and failover semantics.

Review:

• Is the idempotency key stored before side effect?
• Is processing/completed state modeled explicitly?
• Is response replay stored safely?
• What happens if Redis fails after DB commit?
• What happens if DB commits but Redis state is lost during failover?
• Should PostgreSQL store the idempotency record instead?

For high-value order/payment/provisioning-like commands, Redis-only idempotency may be insufficient unless the failure window is accepted.

28. AWS Redis and Sessions/Tokens

Session and token data in Redis require explicit security and availability design.

Review:

• Is session data sensitive?
• Is TTL enforced?
• Is sliding expiration used?
• Is logout/revocation propagated?
• Does Redis failover log users out?
• Does Redis restore resurrect revoked sessions/tokens?
• Are snapshots/backups protected?
• Are token values stored raw or hashed?

Session stores are not just cache.

They are security state.

29. IaC and Environment Promotion

AWS Redis configuration should be managed through infrastructure as code where possible.

Artifacts:

• Replication group definition.
• Engine/version selection.
• Cluster mode setting.
• Node type/capacity.
• Subnet group.
• Security group.
• Parameter group.
• Auth/RBAC/IAM settings.
• Encryption settings.
• Snapshot settings.
• Maintenance window.
• CloudWatch alarms.

Promotion Rule

Redis infrastructure changes should move through environments like application code.

Avoid manual production-only configuration unless there is a documented break-glass process.

30. Cost and Capacity Awareness

Redis cost is driven by capacity and topology.

Drivers:

• Node size.
• Number of shards.
• Number of replicas.
• Multi-AZ placement.
• Backup retention.
• Cross-AZ traffic.
• Cross-region replication.
• Data transfer.
• Overprovisioning for memory headroom.

Engineering trade-off:

• Too small: eviction, latency, incidents.
• Too large: unnecessary cloud spend.
• Too few replicas: availability risk.
• Too many replicas: cost and complexity.

Capacity planning must be based on real key cardinality, payload size, TTL, command mix, and growth rate.

31. Production Readiness Checklist

Before using AWS Redis in production, verify:

Topology

• Service choice is documented.
• Cluster mode disabled/enabled is intentional.
• Shard and replica count match workload.
• Multi-AZ/automatic failover is configured if required.
• Java client mode matches topology.

Network

• Subnet group is correct.
• Security group access is minimal.
• Traffic is private.
• Cross-AZ/cross-region path is understood.
• EKS/ECS/EC2 clients can reach Redis reliably.

Security

• TLS is configured where required.
• Encryption at rest is configured where required.
• AUTH/ACL/RBAC/IAM model is explicit.
• Credentials are rotated safely.
• Snapshot access is controlled.

Operations

• CloudWatch metrics exist.
• Alerts exist.
• Maintenance window is documented.
• Backup/restore policy is documented.
• Failover has been tested.
• Runbook exists.

Application Semantics

• TTL policy exists.
• Invalidation policy exists.
• Cache miss fallback is safe.
• Rate limiter fail mode is explicit.
• Idempotency failure window is accepted.
• Lock correctness boundary is documented.
• Session/token outage behavior is defined.

32. Internal Verification Checklist for CSG/Team Context

Do not assume internal CSG architecture details.

Verify these with the actual team, repository, platform docs, and SRE/security owners.

Service Usage

• Which Java/JAX-RS services connect to AWS Redis?
• Which use cases exist: cache, session, limiter, idempotency, lock, stream, Pub/Sub, job queue, config cache?
• Which key prefixes are owned by which services?
• Which Redis data is disposable and which is correctness-sensitive?

AWS Configuration

• Is the service ElastiCache, MemoryDB, self-managed Redis, or another Redis-compatible system?
• Is the engine Redis OSS, Valkey, or another compatible engine?
• Is cluster mode enabled?
• How many shards and replicas exist?
• Is Multi-AZ automatic failover enabled?
• What subnet group/security groups are attached?
• What parameter group is used?
• What maintenance window is configured?

Security

• Is TLS required?
• Is encryption at rest enabled?
• What auth model is used?
• Are ACL/RBAC users service-scoped?
• How are credentials stored and rotated?
• Are snapshots/backups encrypted and access-controlled?

Java Client

• Which client is used: Lettuce, Jedis, Redisson, framework abstraction, or internal wrapper?
• Is the client cluster-aware if required?
• Are timeouts/retries/circuit breakers configured?
• Are client metrics emitted?
• Has failover behavior been tested?

Observability and Operations

• Which CloudWatch dashboard/alarms exist?
• Are Java-side Redis metrics available?
• Is there an incident runbook?
• Are failover events correlated with application incidents?
• Are memory/eviction/connection/latency alerts actionable?

33. Architecture Decision Questions

Before approving AWS Redis usage, ask:

1. Why AWS Redis instead of local cache, PostgreSQL, Kafka, RabbitMQ, or another store?
2. Is Redis cache-only or correctness-sensitive state?
3. What happens if Redis is unavailable for 5 minutes?
4. What happens if Redis loses recent writes during failover?
5. What happens if eviction occurs?
6. What data is stored in keys and values?
7. Is any PII, token, session, or customer-sensitive data stored?
8. Is TTL explicit for every ephemeral key?
9. Is cluster mode required?
10. Is the Java client compatible with cluster/failover/TLS/auth?
11. Is DB fallback safe during cache miss spike?
12. Is broker-driven invalidation idempotent and versioned?
13. Is backup/restore safe for this keyspace?
14. Are CloudWatch and Java client metrics sufficient?
15. Is there a tested failover runbook?

If these questions cannot be answered, the Redis design is not production-ready.

34. Senior Engineer Heuristics

AWS Redis is a strong fit when:

• Redis is used deliberately for low-latency access.
• Data loss tolerance is understood.
• TTL and eviction policy match the use case.
• Topology is matched by Java client configuration.
• Security groups and ACL/RBAC/IAM are scoped.
• CloudWatch and client-side observability are both present.
• Failover behavior is tested.
• Cache correctness is owned by application design.

AWS Redis is risky when:

• Teams assume managed equals correctness-safe.
• Cache and critical state share one eviction policy.
• Cluster mode is enabled without key design review.
• Java client is not topology-aware.
• Redis auth credentials are shared broadly.
• Snapshots may contain sensitive data but are not reviewed.
• Failover has never been tested.
• There is no fallback policy for Redis unavailable/slow.

35. Summary

AWS-managed Redis-compatible services reduce infrastructure burden, but they do not remove Redis engineering responsibility.

For Java/JAX-RS enterprise systems, the critical production questions are about topology, network, security, failover, observability, client behavior, and application-level correctness.

A senior engineer should treat AWS Redis as a managed runtime for Redis-like semantics, not as a magic consistency layer.

The most important discipline is to separate:

• What AWS manages.
• What Redis semantics guarantee.
• What the Java application must still design correctly.
• What the internal platform/SRE/security teams must verify.

Managed Redis can make Redis easier to operate.

It cannot make an unsafe cache, limiter, idempotency store, lock, queue, or session design safe by itself.