Verify container-group egress identity separately from its inbound address

Source facts

Microsoft documents that a container group’s external-facing address accepts inbound connections while the group uses a different outbound address. That default egress address is not exposed programmatically.

Its documented virtual-network design uses Azure Firewall, a user-defined route and firewall rules so ingress and egress use the firewall’s public address. Multiple groups in the subnet can share that egress identity. Microsoft Learn.

Applicability

Identify the container group, required destination and actual approved outbound design. This is an address-identity review, not a complete firewall deployment procedure.

DSE recommendation

DSE recommends recording inbound publishing and outbound source requirements as separate entries. If a stable shared egress path is needed, review the supported design with the network owner before requesting a destination-side allowlist change. Account for the other groups using that path when assigning ownership. Use an approved observation endpoint rather than sending application data to an arbitrary public address-checking service.

Verification

From a controlled container workload, make an authorized request and compare the destination’s observed source with the reviewed egress address. Test inbound access separately where required. Retain the route and rule context with both results. If the addresses differ from the plan, investigate the actual path before broadening the receiving service’s allowlist or claiming the container’s public address is sufficient evidence.

Official references

Microsoft Learn: Configure Static Outbound IP. Source retrieved September 9, 2026.