Comparison route

Single service comparison

Back to main page

Caching

Azure Cache for Redis

Azure Cache for Redis is a fully managed, in-memory Redis-compatible caching service providing low-latency data access for application workloads. It is provisioned as a PaaS resource with built-in replication, persistence, scaling, and TLS, offered in Basic, Standard, and Premium tiers plus Enterprise tiers based on Redis Enterprise Software, accessed over Redis protocol with private endpoints and VNet injection.

Azure logo

Azure

Service information

Azure Cache for Redis iconAzure Cache for Redis

Shortname: Azure Redis

Huawei equivalent shortnames: DCS

Keywords: redis, cache, in-memory

Differences vs Huawei

Azure Cache for Redis exposes a single managed Redis instance abstraction with tiered SKUs (Basic, Standard, Premium, Enterprise/Enterprise Flash) that bundle HA, persistence, and clustering differently, while Huawei DCS for Redis offers five explicit instance types—single-node, master/standby, Proxy Cluster, Redis Cluster, and read/write splitting—so topology choices are surfaced directly rather than folded into a tier. DCS supports both Arm and x86 kernels, which Azure does not expose; Azure, conversely, offers Enterprise tiers with Redis on flash storage and Redis Enterprise modules (RediSearch, RedisJSON, RedisTimeSeries, RedisBloom) that DCS does not advertise as equivalent. Both back up to object storage (Azure Storage / Huawei OBS) and enforce VPC isolation, but module coverage and tier-to-type mapping must be validated feature by feature before assuming parity.

API and data-model compatibility is close but not identical: both speak RESP and accept standard Redis clients, yet command support varies by engine version and module availability—Azure specifies supported Redis versions and modules per tier, while DCS publishes its own supported version and command compatibility matrix that may disable or restrict certain commands (e.g., KEYS, FLUSHALL, CONFIG). HA behavior also differs: Azure Standard/Premium uses primary/replica with automatic failover and zone redundancy options, whereas DCS master/standby and cluster shards perform replica promotion without changing the instance IP. Authentication, TLS, and private networking differ in naming (Azure private endpoints and VNet injection vs. DCS VPC/subnet placement and password/token auth plus optional TLS), so connection strings and security configuration must be remapped during migration.

Operational responsibility differs around scaling, monitoring, and regional footprint. Azure provides horizontal scaling and geo-replication between paired regions for Premium/Enterprise tiers, while DCS supports scaling within a region across its 23 regions but does not document an equivalent cross-region active geo-replication feature; multi-region caching must be re-architected as independent DCS instances with application-level replication. DCS publishes 40+ metrics and Cloud Trace Service auditing comparable to Azure Monitor, but alert policies, diagnostic settings, and backup retention defaults differ. Azure integrates with Azure AD token auth and Key Vault, while DCS integrates with IAM and KMS, so secret management and identity flows must be redesigned rather than lifted directly.

Migration to Huawei

Begin with an assessment of the Azure Cache for Redis tier, engine version, instance size, cluster topology, persistence/RDB-AOF settings, modules in use, and commanded QPS. Select the closest DCS instance type—master/standby for Standard-like HA, Redis Cluster or Proxy Cluster for sharded Premium/Enterprise workloads, read/write splitting for read-heavy patterns—and confirm a supported DCS engine version on Huawei's compatibility matrix. Avoid assuming Enterprise-tier module parity (RediSearch, RedisJSON, etc.); if those are load-bearing, the workload may not be a clean fit for DCS and an alternative design or remaining on a Redis Enterprise offering should be evaluated before proceeding.

For data migration, use DCS's documented online migration tools, which support moving data from another cloud's Redis to DCS via replication (SYNC/PSYNC) over a reachable endpoint or via backup restore from RDB dumps in OBS. Validate that the Azure source allows outbound replication and network reachability to the DCS endpoint (peering, VPN, or public endpoint with allowlisted IPs), and pre-stage any required VPC, subnet, security group, and IAM/KMS configuration. Re-create configuration such as maxmemory policies, eviction rules, and client connection parameters against DCS equivalents, and update application connection strings, credentials, and TLS settings to point at the DCS instance.

Validate before cutover by running parallel or shadow traffic against DCS and comparing latency, hit rate, command behavior, and any version-restricted commands. Confirm backup/restore drills succeed in the target region, and verify monitoring, alarms, and audit logging are wired to Huawei Cloud Eye and Cloud Trace Service. Schedule cutover during a controlled window, switch application configuration to DCS, and keep the Azure source running in read-only or fallback mode until cache repopulation and stability are confirmed.

Recalculate total cost of ownership since billing models differ: Azure Cache for Redis prices by tier, cache size, and hours of run plus data transfer and optional persistence, while DCS bills by instance specification (Arm or x86), edition (basic/professional), memory size, and hours, plus OBS-backed backup storage and cross-region or egress traffic. Account for peak QPS, connection counts, persistence/backup retention, and inter-region traffic, and note that geo-replication or active-active multi-region caching available on Azure may require multiple DCS instances and application-level replication, which changes both architecture and cost on Huawei Cloud.

Huawei Cloud logo

Huawei Cloud

Huawei equivalent service

Distributed Cache Service (for Redis) iconDistributed Cache Service (for Redis)

Shortname: DCS

General function: Caching

Managed Redis-compatible cache service.

Keywords: redis, cache, in-memory