Building blocks
Design goal
Onboard on-premises or other-cloud servers to Azure Arc and Defender while limiting egress to approved connectivity paths and treating that path as shared platform infrastructure.
Success criteria
- Centralize Azure service connectivity
- Limit outbound destinations
- Apply consistent security posture
- Preserve auditable onboarding
Architecture
Each server runs the Azure Connected Machine agent and its local Arc proxy component. Outbound traffic can use Azure Arc gateway for supported Arc connectivity, while a customer-managed enterprise proxy—if required—remains a separate network service. Defender and monitoring may require additional documented service endpoints.
Architecture flow
- Servers reach approved Arc connectivity endpoint
- Azure Arc establishes resource identity
- Policy/management extensions are assigned
- Defender and monitoring data flow through approved service paths
Architecture decisions
Restricted egress, not zero connectivity
WhyAzure Arc management still requires connectivity to Azure services; the design focuses on controlled service access rather than fully offline operation.
Trade-offControlled egress reduces exposure, but Arc and Defender still depend on reachable Azure endpoints and healthy DNS/proxy infrastructure.
Separate Azure gateway and customer proxy responsibilities
WhyAzure Arc gateway is an Azure service; customer-managed proxies, DNS, firewall policy, TLS inspection, and local agent health are separate operational responsibilities. Do not describe the gateway itself as a customer-managed proxy appliance.
Trade-offCentralized connectivity simplifies egress policy, but enterprise proxies and network controls can become customer-managed dependencies. Validate service-specific endpoints for Defender and Azure Monitor in addition to Arc onboarding.
Networking
Make the traffic path explicit. Document DNS, the local Arc proxy component, Azure Arc gateway usage, any enterprise proxy, firewall/TLS inspection, and service-specific outbound requirements before onboarding production servers.
Security
Protect the control and data paths deliberately. Use least privilege, extension governance, policy, endpoint security, and central logging. Avoid opening inbound management ports from the internet.
Availability
Design for the failure domain that must be survived. Where customer-managed proxy or network infrastructure is operationally critical, design that path without a single point of failure and separately monitor Arc gateway/agent connectivity health.
Cost drivers
- Defender for Servers plan
- Log ingestion
- Gateway/proxy infrastructure
- Optional monitoring extensions
Design assumptions
- Servers can reach approved Azure endpoints through a controlled path
- Required certificates/DNS are available
Implementation plan
- Document the approved outbound connectivity model—direct, proxy, or Azure Arc gateway—and the DNS/firewall dependencies it introduces.
- Deploy the gateway or proxy path with redundancy appropriate to the number and criticality of connected servers.
- Onboard a small pilot group to Azure Arc and verify heartbeat, inventory, policy, and extension deployment through the restricted path.
- Assign the intended Defender for Servers plan, Azure Policy initiatives, and extensions only after the connectivity path is stable.
- Roll out in waves and monitor gateway capacity, agent health, certificate/proxy issues, and servers that stop reporting.
Validate the design
- Confirm Arc heartbeat and inventory continue through the approved Arc gateway or enterprise-proxy path without unrestricted internet access.
- Deploy a representative extension and verify installation succeeds through the restricted network.
- Confirm the expected Defender for Servers coverage and policy assignments appear for pilot servers.
- Interrupt the gateway/proxy path and verify monitoring identifies the loss and agents recover when connectivity returns.