QuotaGuard gives your forwarder or HEC client two fixed egress IPs, so you can add them to the Splunk Cloud IP allow list and keep every other source out.
Splunk Cloud allowlists inbound data by source IP, per feature. Your forwarder is the client connecting in, and Splunk checks the address it arrives from. When that app runs on rotating cloud IPs, the allow list goes stale and your data gets rejected.
Set one environment variable, route your Splunk traffic through QuotaGuard, and add the two IPs to the allow list once. They stay fixed through deploys, restarts, and plan changes.
You satisfy a Splunk Cloud IP allow list with two fixed egress IPs, because Splunk checks the source address your forwarder or HEC client arrives from. The allow list is per feature, so each ingest path has its own list that you manage through the Admin Config Service (ACS) API or the IP allow list management page in Splunk Web.
Splunk's own guidance is that you must add the IP subnet that contains the forwarder's IP address to the correct allow list. A rotating cloud IP makes that subnet a moving target. Two QuotaGuard IPs make it a one-time entry.
Splunk Cloud scopes allow lists by feature type. The hec list gates the HTTP Event Collector, s2s gates forwarder-to-indexer traffic, and search-api gates programmatic search. You add your two QuotaGuard IPs to whichever features your integration actually uses.
The ACS API and the IP allow list management page in Splunk Web are the two supported ways to edit a list. IPv6 subnets are supported alongside IPv4. Splunk enforces a limit of 200 subnets per feature and 230 shared across the group, so a tight two-IP entry leaves headroom.
Many feature allow lists ship open at 0.0.0.0/0, so ingest works until you restrict it. The moment you tighten a list to real subnets, an app on a rotating AWS or Heroku IP starts getting rejected. Two static IPs are what keep it passing after lockdown.
On a Splunk Cloud compliance stack, allowlisting stops being optional and a stable egress IP becomes required infrastructure. QuotaGuard supplies that IP, and QuotaGuard Shield carries the regulated log data end to end without decrypting it.
On PCI and HIPAA compliance stacks, the search-api and search-ui allow lists are closed by default, so nothing reaches them until you add an approved subnet. Your two QuotaGuard IPs are the entries that let your tools connect while everything else stays blocked.
On FedRAMP High, ACS self-service allow list changes are not supported, and you contact Splunk Support to change a list. An egress IP that rarely changes turns that into a one-time request instead of a support ticket after every deploy.
Splunk logs can carry PHI, cardholder data, or other regulated PII. QuotaGuard Shield uses SSL passthrough and does not decrypt the payload in ordinary operation, which fits HIPAA, PCI-DSS, and SOC 2 review. Static satisfies the allow list for standard operational logs.
QuotaGuard runs your Splunk traffic through a load-balanced pair of static IPs, so a single-node issue never stops your data reaching the indexers. The IPs stay the same as your subscription changes, so the allow list you set once keeps working.
Each subscription runs a load-balanced pair with health checks and automatic failover. Add both to the Splunk allow list once, and traffic routes through whichever IP responds, so forwarder connections and HEC posts keep landing during a node event.
Proxies run in eleven AWS regions, selected at sign-up so your forwarder reaches your Splunk Cloud region with low latency. Pick the region nearest your stack to keep ingest round trips short.
Your two IPs do not change when you upgrade or downgrade your subscription. A Splunk allow list entry you set once keeps passing, so a plan change never turns into a data-loss incident on the ingest path.
Common questions about Splunk Cloud static IPs and QuotaGuard.
Does my Splunk Cloud integration need a static IP?
Only once you restrict a feature's IP allow list to real subnets, which most teams do to keep unknown sources out of ingest and search. Many Splunk Cloud allow lists default open at 0.0.0.0/0, so data flows until you lock a list down. The moment you do, a forwarder or HEC client on a rotating cloud IP starts getting rejected, because Splunk checks the source IP the connection arrives from. Two static IPs keep that entry valid after lockdown.
How fast can I set up QuotaGuard for Splunk Cloud?
About 2 minutes on the QuotaGuard side: add one environment variable and point your forwarder or HEC client at QuotaGuard as the proxy for outbound traffic to your Splunk Cloud stack. Then add your two static IPs to the correct feature allow list through the ACS API or the IP allow list management page in Splunk Web. The Splunk side is a config change, not a migration.
Which Splunk Cloud allow list do I add the IPs to?
The one that matches your ingest path. Splunk scopes allow lists by feature type: hec for the HTTP Event Collector, s2s for forwarder-to-indexer traffic, and search-api or search-ui for search, plus idm and hf. Add your two QuotaGuard IPs to each feature your integration uses. Splunk allows up to 200 subnets per feature and 230 shared across the group, so a two-IP entry stays well inside the limit.
Should I use QuotaGuard Static or Shield for Splunk Cloud?
Static satisfies the IP allow list and is right for standard operational logs. Use Shield when the data flowing to Splunk carries PHI, cardholder data, or other regulated PII, or when your stack is under SOC 2, PCI-DSS, or HIPAA review, because Shield uses SSL passthrough and does not decrypt the payload in ordinary operation. Some teams run Static for general logging and Shield for the flows that touch regulated data.
How does allowlisting work on a PCI or HIPAA compliance stack?
On PCI and HIPAA compliance stacks, the search-api and search-ui allow lists are closed by default, so nothing reaches them until you add an approved subnet. That makes a stable egress IP required, not optional. Your two QuotaGuard IPs are the subnets you add so approved tools connect while everything else stays blocked. Confirm the current defaults for your stack in Splunk's docs before you rely on them.
Does the Splunk Cloud allow list support CIDR ranges and IPv6?
Yes. You add subnets in CIDR notation, and ACS allow lists support IPv6 alongside IPv4. The format is never the problem. It is that PaaS hosts like Render, Railway, Heroku, and Fly.io do not publish narrow CIDR blocks, so allowlisting your platform's range would trust every other customer on it. Two specific QuotaGuard IPs keep the entry tight.
Can I get a dedicated IP for Splunk Cloud?
Yes. Dedicated IPs are included on QuotaGuard Enterprise plans, at $219/month for QuotaGuard Static and $269/month for QuotaGuard Shield on direct billing. A dedicated pair fits when your Splunk allow list must not share an origin with any other organization's traffic. Contact QuotaGuard support after signup with your username and preferred region.
What about traffic coming from Splunk Cloud, like search callbacks or alert webhooks?
Those flow in the opposite direction, from Splunk out to your endpoint, so the allow list you manage on the Splunk side does not apply to them. QuotaGuard handles the outbound path from your forwarder or app into Splunk Cloud. If you also need a fixed inbound endpoint for a receiver that Splunk alerts call, QuotaGuard Static includes inbound proxy capability on direct plans starting at $19/month.
For over a decade, QuotaGuard has provided reliable, high-performance static IP and proxy solutions for cloud environments like Heroku, Kubernetes, and AWS.
Get the fixed identity and security your application needs today.