通过CloudFormation新增ElastiCache分片时主副本节点被创建在错误AZ

问题描述 #

现有2分片的ElastiCache Redis集群CloudFormation配置，每个分片1个副本，已明确指定每个分片的主节点和副本节点所属可用区（AZ），初始创建时AZ分配完全符合配置：

"MyRedisCluster": {
        "Properties": {
            "Engine": "redis",
            "MultiAZEnabled": "true",
            "NodeGroupConfiguration": [
                {
                    "NodeGroupId": "0001",
                    "PrimaryAvailabilityZone": "eu-west-1b",
                    "ReplicaAvailabilityZones": [
                        "eu-west-1a"
                    ]
                },
                {
                    "NodeGroupId": "0002",
                    "PrimaryAvailabilityZone": "eu-west-1c",
                    "ReplicaAvailabilityZones": [
                        "eu-west-1b"
                    ]
                }
            ],
            "NumNodeGroups": 2,
            "ReplicasPerNodeGroup": 1
        },
        "Type": "AWS::ElastiCache::ReplicationGroup",
        "UpdatePolicy": {
            "UseOnlineResharding": "true"
        }
    }

更新栈新增第三个分片时，在NodeGroupConfiguration中添加如下配置，同时将NumNodeGroups修改为3：

{
    "NodeGroupId": "0003",
    "PrimaryAvailabilityZone": "eu-west-1a",
    "ReplicaAvailabilityZones": [
        "eu-west-1c"
    ]
}

更新成功后发现第三个分片的主副本AZ完全颠倒：配置要求主节点在eu-west-1a、副本在eu-west-1c，实际主节点在eu-west-1c、副本在eu-west-1a。直接通过AWS CLI调用modify-replication-group-shard-configuration执行相同操作时AZ分配符合预期。 #

解答 #

这是旧版本AWS::ElastiCache::ReplicationGroup CloudFormation资源的已知缺陷，核心原因是2023年之前发布的该资源类型Schema，在处理开启在线分片（UseOnlineResharding: true）的更新场景时，存在参数传递错误：底层调用ElastiCache API时将PrimaryAvailabilityZone和ReplicaAvailabilityZones的参数值颠倒传递，导致新增分片的主副本AZ反转。而CLI直接调用API时不存在该参数转换错误，因此运行结果符合预期。

对应解决方案如下：

• 临时修复：新增分片完成后，手动调用ElastiCache的主从切换接口，将主节点切换到预期AZ即可
• 根治方案：将CloudFormation中AWS::ElastiCache::ReplicationGroup资源升级到2023年10月之后发布的版本，该版本已修复参数传递错误问题
• 替代方案：取消在NodeGroupConfiguration中硬编码每个分片的AZ配置，改用全局PreferredAvailabilityZones参数指定AZ优先级，该参数的处理逻辑不受该缺陷影响

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