Edge Computing

Edge computing is an architectural approach that performs selected computations close to where data is generated or consumed. The edge might be an industrial gateway, a retail server, a connected device, or a cloud provider's distributed infrastructure near users. Its defining characteristic is processing location relative to the workload, not a particular service, hardware platform, or deployment model.

In cloud architectures, edge and centralized resources usually complement each other. Local components handle time-sensitive decisions, filtering, aggregation, or inference, while regional cloud services provide durable storage, fleet management, model training, and analysis across many locations. A factory gateway, for example, can evaluate vibration readings locally and upload summaries and abnormal readings rather than continuously transmitting every sample.

For cost-optimized compute design, identify what work can be eliminated or reduced before it reaches centralized systems. Filtering duplicate sensor events can reduce downstream ingestion, storage, and processing. Running inference near a camera can avoid continuously uploading video when only event metadata is needed. However, reducing device-to-cloud traffic does not automatically produce an AWS data-transfer saving: internet data transfer into AWS is generally free, while connectivity charges, downstream service charges, and data transfer out depend on the architecture.

Another application is lightweight request processing near web users. Edge functions can normalize URLs, issue redirects, or modify request headers before requests reach an application origin. Combined with appropriate caching, this can reduce origin requests and associated compute demand. Caching itself is not equivalent to executing application logic, although both techniques can be part of an edge architecture. Incorrect cache keys or personalization rules can expose user-specific data or reduce cache effectiveness.

The economic comparison must include the entire distributed system. Edge hardware, idle capacity, software deployment, monitoring, connectivity, physical maintenance, and replacement can outweigh savings from reduced centralized processing. Provider-managed edge functions have execution charges and runtime restrictions; local gateways require capacity planning and lifecycle management. A centralized, elastically scaled workload can be cheaper when data volumes are small, latency requirements are loose, or sharing compute across customers produces better utilization.

Intermittent connectivity is another reason to process locally, but offline operation must be designed explicitly. Applications need durable buffering, storage limits, retry policies, and duplicate-safe synchronization. Local processing does not guarantee continued operation if authentication, configuration, or required data still depends on an unavailable cloud endpoint. Similarly, proximity reduces network travel time but does not guarantee a hard real-time response.

Security and governance remain essential. Distributed devices need individual identities, least-privilege permissions, encryption, signed updates, and protection against physical compromise. Keeping raw data local can support privacy objectives, but logs, backups, and derived outputs must also satisfy residency and retention requirements. In architecture exam scenarios, favor edge processing when requirements emphasize local decisions, constrained connectivity, or reducing high-volume upstream data, then verify that its total cost and operational complexity are justified.