Elastic Cloud Serverless now supports Azure Private Link, letting Azure customers reach their Serverless projects entirely through Azure's own private network backbone instead of the public internet.
Elastic made the capability generally available on August 4, 2026, about six months after AWS PrivateLink reached the same milestone for Elastic Cloud Serverless in February. According to Elastic, once a private connection policy is attached to an Elastic Cloud Serverless project, any request that doesn't arrive through a matching private endpoint or IP filter gets rejected with a 403 error, even though the project's public endpoint stays resolvable. On Azure, attaching that policy isn't optional, unlike the AWS integration, where the equivalent policy can be skipped and connections approved by hand.
Wiring it up means creating a private endpoint in Azure that points at Elastic's own Private Link service, updating DNS so Elastic's hostnames resolve to that private IP, then building a matching connection policy in Elastic Cloud Console using the endpoint's resource ID, the field Azure's own portal labels Resource ID. A single policy can list up to 128 private endpoints or IP ranges and attach to several projects at once, an organization can register as many as 1,024 such policies, and IP filters can run alongside private endpoints on the same project without conflict.
Private connectivity for Elastic Cloud Serverless ships at no extra charge, though the tier requirement varies by workload: Observability projects need the Observability Complete tier and Security projects need Security Analytics Complete, while other project types such as plain Elasticsearch Serverless get it with no tier requirement at all. Any project spun up before the cutoff date is grandfathered and can use both private connections and IP filtering regardless of tier for the life of the project, even if it isn't using either yet.
One regional gap remains: Azure's northeurope region doesn't yet support Private Link even though Elastic Cloud Serverless itself runs there, a limitation Elastic attributes to Azure's own infrastructure rather than to its own service.
