Thanks — this is a clear set of questions. I’ll respond to each point you raised about LiveKit Cloud egress → Azure Blob uploads and highlight recommended approaches when your storage is locked down behind private networking. Quick summary of what I’m responding to: you asked about (1) outbound IP ranges to allow-list, (2) whether egress can use a custom proxy/endpoint, (3) SAS token support, and (4) recommended architectures when Azure Storage public access is disabled. 1) Outbound IP ranges • LiveKit Cloud egress does use fixed outbound IP addresses per region that can be allow‑listed in your Azure Storage firewall. • You should allow-list the static IP blocks for the region where your LiveKit Cloud egress runs. The regional static IP blocks are listed in our firewall/static IP reference (see the LiveKit firewall reference for the exact ranges for your region). 2) Proxy / custom endpoint support • Egress uploads using the

AzureBlobUpload

configuration do not support specifying a custom upload proxy URL or a custom endpoint. The egress component uploads directly to Azure Blob Storage using the account credentials and container you provide. • You cannot configure

AzureBlobUpload

to route uploads through an intermediary service (for example, an internal SAS-generation proxy) within the current egress implementation. 3) SAS token support • LiveKit Cloud egress does not support SAS tokens for Azure Blob uploads. Authentication requires the storage account name and account key; SAS tokens are not supported by the current egress implementation. 4) Recommended architecture for private storage (public network access disabled) • If your Azure Storage account has public network access disabled, LiveKit Cloud egress will not be able to upload directly because it runs in public cloud infrastructure and cannot reach private-only endpoints. • Common, recommended patterns customers use: ◦ Create a publicly accessible ingestion storage account (or enable public network access for a dedicated ingestion container) and allow-list LiveKit’s regional static IP ranges so egress can upload recordings. ◦ After ingestion, move or copy recordings from the public ingestion account to your private storage using internal Azure services you control (for example, Azure Functions, Logic Apps, Event Grid, or Storage replication/azcopy running from within your private network). ◦ Alternatively, ingest into a storage account in a cloud / region under your control that can accept public uploads and then replicate or transfer to the private-locked account via private networking routes. • If absolute private-only ingestion is required (no public access at all), the recommended options are: ◦ Self-host egress in your environment (so uploads originate inside your Azure VNet), or ◦ Run a relay/ingestion service inside your network that LiveKit egress can post to (but note LiveKit Cloud egress cannot be configured to post to a custom Azure endpoint directly — you would need to implement an intermediate public-facing ingest endpoint, or self-host). • The practical, commonly used approach is ingestion → secure automated transfer to private storage. This balances allowing LiveKit Cloud to perform uploads while preserving long-term private access and governance. If you’d like, I can help with next steps: • Tell me which LiveKit region/tenant you’ll use and I’ll point you to the exact static IP ranges for that region. • If you want architecture guidance, share whether you prefer (a) a public ingestion account + automated internal transfer, (b) self-hosting egress inside your Azure VNet, or (c) an ingestion relay—I can outline the pros/cons and a sample flow for the option you pick. I’m happy to walk through whichever option you prefer and provide links and a short architecture diagram for the chosen approach. Sources: Checklist for Regional Deployments | LiveKit