Match compute size and placement to the bottleneck

A bigger compute unit is not automatically faster. First identify whether CPU, memory, storage, network, accelerator, startup, or concurrency limits the completed work. Sizing starts with a workload profile: request or batch, duration, concurrency, CPU saturation, memory working set, network and EBS throughput, local scratch, accelerator need, startup latency, and geographic placement. Record p50 and p95 behavior, not one average.

For EC2, the measured bottleneck chooses the family: compute-, memory-, storage-, or accelerator-oriented. Size must also respect instance network and EBS ceilings. A larger general-purpose instance is not sound when memory pressure or GPU support decides. For Lambda, memory is also a performance control because AWS allocates CPU in proportion to memory.

Test settings against duration, timeout, and completed-work cost rather than assuming the smallest costs least. For Fargate containers, select a supported CPU-memory task shape and account for startup and ephemeral storage. Retain headroom for bursts and failure, then validate with load tests. Right-sizing is a loop: hypothesize the bottleneck, change one resource dimension, and confirm target latency or throughput.

Online requests, finite queued jobs, distributed frameworks, and local device loops are different work shapes. Choose the service after naming the shape. EC2 is control-rich for long-running services, specialized hardware, tightly coupled nodes, and OS requirements. Lambda suits bounded event or request work without host control. AWS Batch schedules finite queued jobs onto supported compute environments; it is not an online API tier.

EMR is purpose-built for distributed frameworks such as Spark and Hadoop, where partitions, executors, shuffle, and data locality determine performance. Fargate runs containers without host provisioning, but does not turn an algorithm into EMR or a queue into Batch. Distributed computing changes placement. Cluster placement groups support tightly coupled EC2 nodes needing low-latency, high-throughput communication, but must be weighed against failure isolation.

Global or edge placement helps only when compute near users or data reduces the measured path. Lambda@Edge is for supported CloudFront event code, not a disconnected plant controller. AWS Outposts extends AWS infrastructure, services, APIs, and tools to customer premises for workloads needing local processing or low latency; its capacity, supported services, parent-Region dependencies, installation, and operations must be evaluated.

AWS IoT Greengrass runs components on edge devices so they can collect and process data locally, communicate on local networks, and continue operating with intermittent cloud connectivity. That makes Greengrass a current candidate for device-oriented local logic, not a substitute for every Regional service.

A compute choice is incomplete until its dependencies, placement, security, failure headroom, and completed-work cost are tested together. More vCPU does not help a memory-bound API; more Lambda concurrency does not shorten one CPU-bound invocation; more executors do not cure a skewed Spark partition; faster instances do not overcome a database connection ceiling.

Compare throughput per unit, startup time, tail latency, queue age, failure headroom, and total cost under realistic data. Security and operations remain constraints: select architectures and images the organization can patch and observe; place sensitive compute in appropriate network boundaries; use roles and certificate-backed device identities rather than static credentials. Resilience requires enough capacity after an instance or AZ loss, not merely at average load.

Cost should use completed work at the SLO, including local hardware, installation, fleet support, software rollout, data transfer, and idle headroom. Edge placement is not one category. Lambda@Edge can remove a viewer-to-Region trip for bounded CloudFront request or response transformations, but it does not host arbitrary long-running work or preserve a local control loop during WAN loss.

AWS Snowball Edge is no longer available to new customers. Existing customers must still verify eligibility and supported behavior; a new architecture must not select it as generally orderable local compute.

Current choices start with the operating model: Outposts supplies AWS infrastructure on premises for compatible workloads that need local processing, while Greengrass deploys and manages software components on edge devices and supports local processing during intermittent connectivity. For disconnected execution, partition state deliberately.

Cache only the inputs and policy needed for the outage window, authenticate devices locally without embedding long-lived secrets, journal accepted work with stable operation identifiers, and synchronize through an encrypted channel after reconnection. Reconciliation must be idempotent because acknowledgments can be lost.

During a WAN-loss drill, confirm that local inspection continues, unauthorized software is rejected, queued results remain encrypted, and each operation reaches the Regional system of record once after reconnection.

Regional compute becomes preferable when continuous connectivity meets the deadline and centralized operations cost less; Outposts becomes preferable when a larger compatible AWS stack and on-premises infrastructure justify its operational commitment; Greengrass wins for compact device-local processing that must tolerate intermittent links.