AWS ElastiCache节点间通信能否被ACL/安全组中断？副本延迟测试可行吗？

Hey there! Let's tackle your two key questions about ElastiCache replica lag testing and whether security groups/ACLs can interfere with node communication.

Can ElastiCache node-to-node communication be blocked by security groups or ACLs? #

Short answer: No, you can't block internal ElastiCache node communication with user-configured security groups or network ACLs.

ElastiCache handles replication and internal node traffic over AWS's private, managed network infrastructure. This traffic doesn't traverse the subnet's network ACLs or the node security groups you configure—those rules only control external client traffic connecting to your ElastiCache nodes. AWS manages the internal routing and security for node-to-node replication, so your custom rules won't affect this flow. That's why your attempt to add a deny rule to the primary node's subnet inbound rules didn't create the replica lag you wanted.

How to intentionally introduce replica lag for testing? #

Since security groups don't work here, here are a few reliable methods to simulate replica lag in your ElastiCache cluster:

• Adjust Redis replication parameters (for Redis clusters):

  • Run CONFIG SET repl-disable-tcp-nodelay yes on the primary node. This disables TCP_NODELAY, causing Redis to batch replication packets instead of sending them immediately, which introduces intentional lag. Don't forget to revert this setting after testing!
  • Tweak replication backlog size (CONFIG SET repl-backlog-size <larger-value>) or other replication-related configs to force delays in syncing.

• Use AWS Fault Injection Simulator (FIS)：

  • FIS is AWS's official chaos engineering tool. You can create targeted experiments to introduce replica lag in ElastiCache clusters, mimicking real-world network delays in a controlled, production-safe way. This is the most recommended method for structured testing.

• Simulate heavy primary node load:

  • Generate high-volume write traffic to the primary node (using tools like redis-benchmark or your application's load test suite). If the primary is overwhelmed with writes, the replica won't be able to keep up, naturally creating observable replica lag for your tests.

内容的提问来源于stack exchange，提问作者xywz