Skip to article
Databases Cache and in-memory data

Redis firewall rule

A Redis firewall rule in Azure Cache for Redis allows specific public IP address ranges to connect to a cache instance. Firewall rules use start and end IP values, apply to Basic, Standard, and Premium tiers, and are not available for Enterprise or Enterprise Flash.

Source: Microsoft Learn - Azure Cache for Redis network isolation options Reviewed 2026-05-21

Exam trap
Adding private VNet addresses to a public firewall rule instead of the client’s actual outbound public IP.
Production check
Run az redis firewall-rules list and confirm every range has an owner and current business reason.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
None listed
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-21
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

A Redis firewall rule is an allow list for public network access to an Azure Cache for Redis instance. You define a start IP and end IP range, and only clients from those addresses can connect through the public endpoint. It is not the same as a private endpoint, virtual network injection, or Redis authentication. A firewall rule narrows where traffic may come from, but clients still need valid credentials or identity support to use the cache.

Why it matters

Redis firewall rules matter because Redis is usually close to application state, sessions, counters, tokens, and high-value cache data. A public endpoint with broad access increases exposure even when TLS and keys are enabled. A tight allow list reduces accidental access from unknown networks and helps auditors understand which clients should connect. The rule also prevents common migration mistakes, such as moving an app behind a new NAT gateway without updating Redis access. Poor firewall hygiene causes outages when legitimate clients are blocked, and risk when old office, vendor, or developer IP ranges stay open forever. That visibility supports both uptime and audit readiness.

Technical context

In Azure architecture, a Redis firewall rule is a child configuration under Microsoft.Cache/redis for Basic, Standard, and Premium Azure Cache for Redis. It belongs to the network boundary around the public endpoint. Operators often manage it with portal settings, ARM, Bicep, Terraform, or az redis firewall-rules commands. The rule interacts with publicNetworkAccess, private endpoints, VNet design, client hosting locations, NAT gateways, App Service outbound IPs, monitoring access, and Redis authentication settings. Enterprise tiers use different networking patterns.

Exam context

Compare with

Private Endpoint Virtual network

Where it is used

Where you see it

  1. The Azure Cache for Redis Firewall page lists rule names with start and end IP ranges that are allowed through the public endpoint for clients.
  2. Bicep templates expose Microsoft.Cache/redis/firewallRules child resources with required startIP and endIP properties under the parent cache resource for code review. safely for review
  3. CLI output from az redis firewall-rules list shows current allowed ranges, making stale office, vendor, or temporary access easy to review during audits. quarterly for review

Common situations

  • Allow a known NAT Gateway public IP to reach Redis while blocking other public internet clients.
  • Support a short migration window where an old application host and new host both need Redis access.
  • Remove stale developer, vendor, or office IP ranges that no longer have a business reason to connect.
  • Prove during audit which public source ranges can reach production Redis endpoints.
  • Diagnose application connection failures after App Service, AKS, or network egress addresses changed.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Payroll processor narrows Redis access after office-network audit Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A payroll processor allowed several office and vendor IP ranges to reach its production Redis cache. An audit found that two ranges belonged to retired contractors and one covered more addresses than necessary.

Goals
  • Reduce public Redis exposure without disrupting payroll batch windows.
  • Tie every allowed IP range to a named owner and change record.
  • Replace broad office ranges with controlled application egress addresses.
  • Create repeatable evidence for quarterly access reviews.
Approach using Redis firewall rule

The security and platform teams exported existing Redis firewall rules with Azure CLI and matched each range against NAT Gateway, App Service, vendor, and office-network records. They removed retired vendor ranges, replaced broad office access with a narrow jump-host egress IP, and kept the payroll application range tied to a named NAT Gateway. Bicep was updated with Microsoft.Cache/redis/firewallRules resources so future changes went through code review. Operators validated payroll batch connectivity from the real application host after each removal, then archived CLI JSON output and Activity Log references for the audit file.

Potential outcomes
  • Allowed public ranges dropped from nine to three without missing a payroll batch.
  • Audit evidence preparation time fell from two days to four hours.
  • Stale third-party access was removed from production before contract renewal review.
  • Firewall-rule drift checks became part of the quarterly platform control process.
What to learn

Redis firewall rules are useful only when every allowed range is narrow, owned, and regularly revalidated.

Scenario 02 Media ingest pipeline restores connectivity after NAT migration Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A video-streaming company moved ingest workers behind a new NAT Gateway. Redis-backed transcoding queues stopped connecting because the old firewall rule allowed the previous outbound IP only.

Goals
  • Restore Redis connectivity without opening the cache to broad public access.
  • Identify the new worker egress IP with confidence.
  • Avoid changing Redis authentication or application connection strings unnecessarily.
  • Add a rollback path for future egress migrations.
Approach using Redis firewall rule

Operators first confirmed that Redis itself was healthy and that authentication had not changed. They listed the existing Redis firewall rules and compared them with the new NAT Gateway public IP assigned to the ingest subnet. A narrow firewall rule was created for the new address while the old range remained temporarily during validation. The team tested transcoding workers from both old and new pools, then removed the retired range after queues drained. The runbook now includes a pre-migration CLI step that captures Redis rule JSON, NAT public IPs, publicNetworkAccess, and application connectivity tests.

Potential outcomes
  • Transcoding queue connectivity recovered in 14 minutes without broadening exposure.
  • No connection-string or Redis key rotation was needed because the root cause was network allow-list drift.
  • Future NAT migrations gained a documented precheck and rollback command.
  • Ingest job backlog cleared within 35 minutes after workers reconnected.
What to learn

Firewall-rule troubleshooting keeps teams from blaming Redis credentials when the real failure is an changed client egress path.

Scenario 03 Legal research SaaS controls build-agent access to Redis test data Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A legal research SaaS used external build agents to run integration tests against a staging Redis cache. The team needed temporary access for test windows without leaving CI infrastructure permanently trusted.

Goals
  • Allow CI agents to reach staging Redis only during approved test periods.
  • Prevent staging firewall exceptions from being copied to production.
  • Record all rule creation and deletion for compliance review.
  • Keep test failures from encouraging broad emergency ranges.
Approach using Redis firewall rule

The DevOps team created a pipeline step that resolved the CI agent pool’s current outbound IP and applied a Redis firewall rule to the staging cache through Azure CLI. The rule name included the pipeline run ID and expiration timestamp. After integration tests finished, the pipeline deleted the rule and exported the list output as evidence. Production templates explicitly rejected CI-agent firewall ranges. The team also configured alerts for firewall-rule updates outside the pipeline identity, catching manual portal changes. Redis authentication remained separate through managed secrets and did not depend on the firewall rule alone.

Potential outcomes
  • Temporary staging rules were removed automatically in 99 percent of test runs.
  • No CI-agent ranges appeared in production Redis access reviews after policy enforcement.
  • Failed cleanup jobs produced alerts within five minutes for manual review.
  • Integration-test setup time dropped from 30 minutes of manual work to under 3 minutes.
What to learn

Automation can make Redis firewall rules safer when temporary access is created narrowly, named clearly, and deleted reliably.

Azure CLI

Azure CLI is useful for Redis firewall rules because network access needs clean evidence and fast rollback. I use CLI to list rules, create narrow ranges, update stale entries, and export the result for a change record. The portal is fine for one rule, but it is slow when comparing dozens of caches or removing expired exceptions. CLI also makes it obvious which resource group, cache, rule name, start IP, and end IP are being touched. After ten years in Azure, I do not rely on memory for firewall changes; I rely on repeatable commands and JSON output.

Useful for

  • List every firewall rule on a Redis cache before approving public client access.
  • Create a narrow rule for a NAT Gateway, build agent, or temporary migration host.
  • Update an existing range after application egress moves to a new public IP.
  • Delete stale vendor, office, or developer rules after an access review.
  • Export firewall rule JSON as audit evidence for production Redis exposure.

Before you run a command

  • Confirm tenant, subscription, resource group, cache name, rule name, and whether the cache tier supports firewall rules.
  • Verify the client’s actual outbound public IP, not the private address shown inside the virtual network or application host.
  • Check publicNetworkAccess and private endpoint design because firewall rules only control the public endpoint path.
  • Use read-only list and show commands first, then apply create, update, or delete only during an approved change window.
  • Consider destructive risk carefully: deleting or narrowing a rule can immediately break application connectivity.

What the output tells you

  • Rule names identify the access exception and should map to an owner, application, vendor, or change ticket.
  • Start and end IP fields show the exact public range that can reach the Redis endpoint.
  • The cache resource ID, location, and tags tell you which environment and business owner are affected.
  • Provisioning or command status confirms whether a create, update, or delete operation completed before testing connectivity.
  • Absence of rules can mean public access is unrestricted or controlled by another network setting, so check publicNetworkAccess too.

Mapped commands

Redis firewall rule CLI Commands

direct 
az redis firewall-rules list --name <cache-name> --resource-group <resource-group>
az redis firewall-rulesdiscoverDatabases
read-only Microsoft Learn 
az redis firewall-rules create --name <cache-name> --resource-group <resource-group> --rule-name <rule-name> --start-ip <start-ip> --end-ip <end-ip>
az redis firewall-rulesprovisionDatabases
mutating Microsoft Learn 
az redis firewall-rules update --name <cache-name> --resource-group <resource-group> --rule-name <rule-name> --start-ip <start-ip> --end-ip <end-ip>
az redis firewall-rulesconfigureDatabases
mutating Microsoft Learn 
az redis firewall-rules delete --name <cache-name> --resource-group <resource-group> --rule-name <rule-name>
az redis firewall-rulesremoveDatabases
mutating Microsoft Learn 
az redis show --name <cache-name> --resource-group <resource-group> --query "{publicNetworkAccess:publicNetworkAccess,hostName:hostName,sslPort:sslPort}"
az redisdiscoverDatabases
read-only Microsoft Learn

Architecture context

A practical Azure architect treats Redis firewall rules as a transitional or constrained public-access control, not the strongest network-isolation pattern. For production, I usually prefer private endpoint designs when the client estate can support them. When public access is required, the architecture should list every allowed source, explain why it needs Redis, and identify the NAT or outbound IP that owns the connection. The design must also cover publicNetworkAccess, TLS, access keys or Entra authentication, rotation, diagnostics, and change ownership. Firewall rules should be represented in infrastructure as code so access does not drift through emergency portal edits. Exceptions need expiration dates and owners.

Security
Security impact is direct. A Redis firewall rule reduces network exposure by limiting which public IP ranges can reach the cache endpoint. It does not replace authentication, TLS, access-key rotation, Entra authentication where available, or Redis ACL controls. Rules should be narrow, named clearly, and tied to known application egress points such as NAT Gateway or App Service outbound addresses. Avoid broad ranges, personal home IPs, and temporary vendor access that never expires. Review activity logs for rule creation, update, and deletion. If private endpoints are enabled, verify public access behavior so firewall assumptions stay true. Treat every rule as production exposure until proven otherwise.
Cost
The rule itself is not a separate billing meter, but it affects cost through architecture choices and operations. Public firewall rules may be cheaper than private networking in simple scenarios, but they can create incident labor, audit effort, and security-review overhead. Moving to private endpoints, NAT Gateway, or centralized egress has its own cost profile, but often gives better control for production. Stale firewall rules increase compliance work and breach exposure. FinOps and platform teams should weigh the low direct cost of rules against operational risk, change frequency, and the price of blocked applications during deployment windows. Access design should be reviewed with security.
Reliability
Reliability impact is direct because a wrong firewall rule can block healthy applications instantly. Cloud clients often change outbound addresses during hosting moves, regional failover, NAT updates, or App Service scale changes. If Redis allows only old ranges, the application sees connection failures that look like Redis downtime. Reliable designs document expected client egress IPs, test connectivity after network changes, and keep rollback commands ready. Monitoring systems may still connect even with firewall rules, so green platform metrics do not prove the application can connect. Failover plans must include updated Redis access for backup regions. Include access checks in every regional recovery rehearsal.
Performance
Runtime performance is usually not directly improved by a firewall rule. The performance value is operational: a clear allow list makes connectivity failures faster to diagnose and reduces time wasted testing unrelated Redis settings. However, the network design behind the allowed IPs still matters. NAT gateways, cross-region clients, public internet routing, private endpoints, and DNS decisions can affect latency and connection stability. After changing rules, test application connection time, Redis command latency, and retry behavior from the actual client host. Do not assume portal reachability means the application path is fast or working. Connectivity tests should include realistic retry settings.
Operations
Operators manage Redis firewall rules by listing allowed ranges, confirming ownership, comparing live settings to infrastructure code, and checking activity logs before and after changes. A safe workflow starts with read-only inventory, identifies the client’s current outbound IP, applies a narrow range, and validates application connectivity. During incidents, operators distinguish DNS, TLS, authentication, private endpoint, and firewall failures. They also remove stale ranges, document vendor exceptions, and watch for emergency portal edits. Every rule should have a reason, owner, creation date, and review cadence because network exceptions silently become permanent risk. They should also compare rules against IaC so manual exceptions do not linger.

Common mistakes

  • Adding private VNet addresses to a public firewall rule instead of the client’s actual outbound public IP.
  • Creating broad ranges such as an entire ISP block because the exact NAT or App Service egress IP was not identified.
  • Assuming firewall rules are available on Enterprise tiers when that tier uses different networking patterns.
  • Leaving temporary vendor or developer access in production after a migration or troubleshooting session ends.
  • Removing a rule during cleanup without confirming backup-region, monitoring, or deployment-agent connectivity.