Definition
Edge Location (edge node) refers to access nodes deployed close to users or devices to provide proximity access, reduce cross-border connection latency, and improve response speed. Together with Multi-Region and CDN content distribution, it forms the infrastructure capability of ICMP to provide low-latency services to global customers.
Use Cases
Typical applications of Edge Location in ICMP include: API access — when a client system calls a RESTful API, the request can be routed to the nearest edge node, reducing transoceanic latency; Portal and console — accelerating the loading of static resources and pages through CDN or edge nodes; Device access — when IoT devices report data or receive commands, they can connect to the nearest gateway to reduce end-to-end latency. In cross-border scenarios, customers in Asia-Pacific, Europe, and the Americas accessing the same platform can experience significant improvement through edge nodes.
Relationship with Multi-Region
Edge Location is an extension of the Multi-Region architecture: core services are deployed across multiple regions, while edge nodes provide nearby access and caching. Edge nodes can handle traffic entry, SSL offloading, simple routing, etc., while complex business logic still returns to the regional center. Combined with Region Failover, edges can be configured with multiple origin sources to achieve high availability.
Compliance considerations
Edge nodes may cache or temporarily store data, so Data Residency and Data Localization should be taken into account: sensitive data should not be cached to overseas edges; some countries require data not to leave the country, so edge node deployment must comply with local regulations. The platform must clearly define the data storage policy of edge nodes to meet compliance requirements.
Access and offload work an edge node takes on
An edge node is an access point placed near the visitor, to shorten the first hop. It is suited to terminating encrypted connections, forwarding a request to the correct region by rule, and returning static files that are already allowed to be cached. It is not a complete billing and SIM-management region. The authoritative write of SIM state, invoice calculation, and storage of detail records should still return to the regional service that customer belongs to. Treating the edge as a second primary database means two places can change the same SIM at once.
After a device or a customer system connects to the nearest node, the node forwards the business request to the primary region according to the tenant configuration. Forwarding should keep the original identity and request ID. The edge must not issue a new internal identity that cannot be traced. If a node fails, the request should move to the next node or enter the region directly, not queue at the edge until a write times out and is dropped. Being nearby optimizes the path. It does not change where the data belongs.
Business conditions under which a request may end at the edge
What may finish at the edge is a request that does not read a customer’s private data: public scripts, the certificate handshake, health checks, and help pages that are explicitly cacheable and contain no personal data. A business read or write may skip the origin only when three conditions hold: the result is the same for everyone who hits it, the time it may stay on the node is written down, and the node’s location is accepted by the residency rules. If any of the three is missing, go back to the primary region in the multi-region deployment.
Long-lived connections and stateful operations should not be forwarded at random from the edge. If two requests in the same session land in different regions, a suspension and a query read states that have not caught up with each other. When stickiness is required, the sticky key should be the tenant or the session, not an egress address that changes. The split with content delivery is this: a delivery network stores copies that may be public, while an edge node can also do access and routing. Neither is responsible for producing a new billing result. If edge logs contain SIM identifiers, the place those logs are stored counts toward residency. They are not sent to a global roll-up merely because they are “only access logs.”
Edge storage that violates residency
Writing invoices, detail records, or diagnostic results to an edge disk so they can be retried makes those files a copy outside the primary region. If the node is outside the region the customer agreed, residency has already changed at the moment of that temporary store. Encryption does not replace location. Ciphertext is still a copy of that data. If a debug switch writes the full request body into the edge log, personal data and tokens remain on the node, and they are harder to clean up than the primary database.
Another error is promoting primary storage temporarily onto an edge node during failover, then neither moving the data back nor deleting the edge copy when the failover ends. A cache key that is too broad lets different tenants hit the same diagnostic result. The rule is: the edge keeps only short-lived connection state by default, and business payloads go back to the origin. If something must be stored temporarily, it may land only inside a region that tenant is allowed to use, and it needs an explicit deletion time. A launch check should list each node’s geographic location and the data classes it is allowed to keep. If storage has crossed a region, stop writes to that node first, clear the copies, and only then restore access.
A node’s geographic location should be managed as configuration, not only drawn on a network diagram. When a new access point is added, check whether it may receive traffic for customers of that region, and whether its disk, log, and cache policy may store business payloads. If not, it only forwards. A backup node used after a failed health check must pass the same check. Do not send traffic to an unreviewed site just to recover faster. During a drill, record which region the request finally landed in, and confirm that “nearby” was not rewritten into a cross-region write. If access logs are to be searched centrally, strip SIM identifiers and tokens before they leave the node.