Single service comparison

DCS is the Huawei equivalent for the Redis OSS workload only; Huawei has no managed Memcached offering, so Memcached-backed ElastiCache clusters cannot map to DCS and must be re-platformed to Redis or run on self-managed ECS. DCS exposes single-node, master/standby, Proxy Cluster, Redis Cluster, and read/write-splitting instance types, which differs from ElastiCache's cluster-mode sharding plus per-shard replica count and its separate Memcached node-group model. Both use the Redis OSS wire protocol, but DCS's Proxy Cluster front end and Arm/x86 kernel choices mean client routing, command compatibility, and module/CMD support (e.g. Streams, Lua, modules) need per-command validation rather than assumed parity.

High availability and scaling differ operationally. ElastiCache supports Multi-AZ automatic failover with primary relocation, online horizontal/vertical scaling, and Global Datastore for cross-region read replication; DCS provides master/replica per shard with in-IP failover and instance reconfiguration, but its cross-region behavior, scaling granularity, replica count options, and max instance size (128 MB to ~1 TB) must be checked against the source workload. Backups on DCS are taken to OBS and restored within the service, whereas AWS couples ElastiCache backups to S3 and the ElastiCache API; the control-plane APIs, CloudFormation/Terraform equivalents (Huawei RMS/RESS), and CLI surface are separate, so IaC reservations are not portable.

Integration and operational responsibility diverge: ElastiCache integrates with IAM, KMS, CloudWatch, Secrets Manager, and VPC security groups, while DCS integrates with Huawei IAM, KMS, VPC/subnets, Cloud Trace Service (CTS), and Cloud Eye. Pricing also differs materially—ElastiCache bills node hours for cache.m*/r* instance classes (or serverless vCPU-memory-usage on cache.serverless), while DCS bills by instance edition (basic/professional), memory specification, and backup/OBS egress. There is no one-click ElastiCache-to-DCS import; the operator owns cutover and data consistency.

Start with assessment: map each ElastiCache cluster's engine (Redis OSS version, Memcached), node type, shard/replica count, max memory, eviction policy, TLS/auth, persistence/snapshot cadence, and consumed Redis commands and modules. Convert Memcached clusters to a Redis-based design on DCS (no managed Memcached target) or run on ECS. Pick a DCS instance edition and topology (basic single-node for dev, master/standby for HA, Redis Cluster or Proxy Cluster for sharded) sized to peak QPS and working set, and confirm the Redis version DCS supports matches the source within minor compatibility.

For data migration use DCS's documented migration tooling for the Redis path: DCS online migration (full + incremental via the Redis SYNC/replication stream) and offline backup-restore to OBS. The DCS user guide provides explicit 'Migration from Another Cloud' and 'Migrating Data from Self-Hosted Redis to DCS' procedures; both expect the source Redis to be reachable from the DCS instance's VPC (private peering, VPN, or public endpoint secured with auth/TLS). For Memcached caches, re-platform and reload warm data from the upstream database on cutover, since DCS migration tooling targets Redis-compatible sources only.

Application and config migration: update connection strings, TLS, and AUTH/Redis ACL handling to the DCS endpoint, and replace AWS SDK/Terraform resource blocks (aws_elasticache_*) with Huawei RMS/ROS templates (huaweicloud_dcs_*). Audit command-set parity—DCS Proxy Cluster may reject certain keyspace-distribution-sensitive commands or multi-key operations—and adjust client logic. Reconfigure monitoring from CloudWatch to Cloud Eye and alarms, and re-establish backup windows to DCS's OBS-based backup schedule, noting DCS replica counts and failover behavior may differ from Multi-AZ semantics.

Validation and cutover: run parallel reads, measure latency and hit-rate under realistic load, verify eviction/persistence behavior, and rehearse failover within a single AZ/shard rather than assuming ElastiCache Multi-AZ equivalence. Cost model changes apply—DCS bills by instance edition, memory size, professional-edition QPS tier, backup storage on OBS, and cross-region/cross-AZ traffic, with no ElastiCache serverless equivalent; rebuild TCO against peak QPS, working set, snapshot retention, and egress, and confirm region availability (DCS lists ~23 regions, narrower than AWS) before committing production.