Why Your On-Premises ARP Playbook Breaks Down the Moment You Move to the Cloud
For years, enterprise security teams have invested considerable effort in hardening Address Resolution Protocol behavior on physical networks. Dynamic ARP Inspection policies, static ARP entries for critical infrastructure, and VLAN segmentation have become standard components of a mature network security posture. Practitioners who have pursued formal credentials in protocol-level security understand these mechanisms well — and rightly so.
But a growing number of organizations are learning a costly lesson: the moment workloads migrate to a cloud provider, or when hybrid architectures begin bridging on-premises segments with virtualized environments, those carefully constructed ARP defenses stop functioning as intended. The issue is not a failure of policy or personnel. It is a fundamental mismatch between how ARP was designed to operate on physical Ethernet and how cloud providers have chosen to abstract, replace, or restrict that behavior entirely.
ARP Was Built for a World That Cloud Providers Have Largely Abandoned
At its core, ARP is a Layer 2 protocol. It assumes that devices sharing a network segment can broadcast to one another and that a response will come from the physical or virtual interface that legitimately owns a given IP address. Physical switches enforce these assumptions through hardware, and security overlays like port security and inspection policies reinforce them.
Cloud providers operate on an entirely different model. The underlying physical infrastructure is abstracted behind hypervisors, software-defined networking layers, and proprietary control planes. Tenants never interact with raw Layer 2 broadcasts in the same way. Instead, each provider has developed its own mechanism for resolving IP-to-MAC mappings — and those mechanisms vary significantly across AWS, Microsoft Azure, and Google Cloud Platform.
Understanding those differences is not optional for security professionals managing hybrid environments. It is a prerequisite for building any defense that will hold.
How AWS Handles ARP — and What That Means for Your Security Controls
Amazon Web Services does not permit traditional ARP broadcasts within a Virtual Private Cloud. When an EC2 instance needs to resolve an IP address, the AWS hypervisor intercepts the ARP request and responds directly from a centralized mapping table maintained by the VPC networking layer. The instance never actually communicates with another instance at Layer 2 in the conventional sense.
This design eliminates many classic ARP-based attack vectors. ARP spoofing, for instance, becomes significantly harder because there is no broadcast domain for a malicious actor to inject forged replies into. However, this also means that on-premises tools built to monitor ARP traffic — such as inspection logs from managed switches or SIEM rules tuned to detect anomalous ARP reply rates — produce no useful signal within a VPC. The traffic they are designed to observe simply does not exist in that form.
Security teams that assume their ARP monitoring coverage extends seamlessly into AWS will have a false sense of assurance. The relevant telemetry in AWS comes from VPC Flow Logs, CloudTrail, and network access control list audit records — not from ARP-layer inspection.
Azure's Approach Introduces a Different Set of Assumptions
Microsoft Azure uses a similar software-defined networking model, but the implementation details differ in ways that matter operationally. Azure's virtual network fabric also intercepts and responds to ARP requests at the platform level, preventing traditional broadcast-based resolution between tenant VMs. However, Azure's integration with on-premises environments through ExpressRoute and VPN Gateway creates boundary conditions where Layer 2 behavior can become inconsistent.
When organizations extend their on-premises VLANs into Azure using certain hybrid connectivity configurations, they may inadvertently create zones where ARP behavior is partially governed by on-premises rules and partially abstracted by Azure's control plane. Security controls that work reliably on either side of that boundary may fail at the seam — precisely the location where an attacker with access to the hybrid network would focus attention.
Azure Defender for Network and Microsoft Sentinel provide the monitoring primitives that replace ARP-level inspection in this environment, but they require deliberate configuration and an understanding of where the protocol abstraction boundaries lie. Practitioners without that knowledge will configure detection rules that miss the actual threat surface.
GCP Takes a Distinctly Different Architectural Stance
Google Cloud Platform's Virtual Private Cloud architecture diverges further still. GCP's networking model is not VLAN-based at all. VPCs in GCP are global constructs, and subnets within them can span multiple geographic regions. This means the concept of a broadcast domain — the foundational assumption underlying ARP — has no direct equivalent in GCP's architecture.
GCP resolves IP-to-MAC mappings entirely within its software-defined networking layer, and instances are isolated from one another at a level that makes traditional ARP attacks structurally impossible within the platform boundary. However, GCP's interconnect options, including Dedicated Interconnect and Partner Interconnect, can introduce on-premises Layer 2 segments into the picture, reintroducing the same boundary-condition risks that affect Azure hybrid deployments.
Additionally, container workloads running on Google Kubernetes Engine introduce a secondary resolution layer. Kubernetes networking relies on its own overlay network, where pod-to-pod communication may traverse multiple abstraction layers before reaching the underlying GCP network fabric. Each of those layers has its own address resolution logic, and a security practitioner who understands only traditional ARP will find GKE's network model largely opaque.
Mitigation Strategies That Account for the Real Threat Surface
Given these architectural realities, security teams managing hybrid or multi-cloud environments need a mitigation framework that does not assume ARP behavior is uniform across infrastructure boundaries.
First, map your abstraction boundaries explicitly. Before deploying any network security control, document precisely where traditional Layer 2 behavior ends and cloud provider abstraction begins. This is not a one-time exercise — it must be revisited whenever network topology changes, new interconnects are provisioned, or container orchestration platforms are introduced.
Second, replace ARP-specific monitoring with provider-native equivalents. AWS VPC Flow Logs, Azure Network Watcher, and GCP's VPC Flow Logs each capture the network telemetry that is relevant within their respective environments. SIEM integrations and detection rules must be tuned to these sources rather than to ARP packet inspection.
Third, treat hybrid connectivity as a high-risk boundary zone. ExpressRoute connections, AWS Direct Connect circuits, and GCP interconnects are the locations where on-premises ARP behavior meets cloud abstraction. These segments deserve dedicated monitoring, strict access controls, and regular review of routing and resolution configurations.
Fourth, address container networking as a distinct security domain. Kubernetes environments running on any major cloud provider introduce overlay networks — Flannel, Calico, Cilium, and others — each of which handles address resolution differently. Security professionals should develop specific competency in the overlay networking model in use within their environment rather than applying generic ARP security assumptions.
The Certification Imperative for Hybrid Network Security
The divergence between traditional ARP security and cloud-native network behavior represents exactly the kind of knowledge gap that formal training and credentialing programs are designed to address. Practitioners who hold protocol-level security credentials have a strong foundation — but that foundation must be extended with structured learning about how cloud providers abstract and replace Layer 2 behavior.
At ARP Certificate, we recognize that the networks our credential holders manage are increasingly hybrid in nature. The goal is not to abandon protocol fundamentals. Those fundamentals remain essential for understanding why cloud providers made the architectural choices they did, and for identifying the residual risks that exist at infrastructure boundaries. The goal is to build on that foundation with the specific, provider-aware knowledge that modern hybrid environments demand.
Security teams that treat on-premises ARP controls and cloud network security as separate disciplines — rather than as a unified body of knowledge — will continue to find gaps at the boundaries where their infrastructure connects. Closing those gaps begins with understanding precisely why the protocols behave differently, and what each environment requires in their place.
