6 AWS Compute Architecture and Practice

AWS compute options

Choosing compute is a workload-design decision, not a contest to use the newest service. Compare how work starts and runs, its runtime and resource needs, scaling behavior, operational control, and team expertise. One system can combine compute services when different parts of its workload have different needs.

Match the service to the workload

• Amazon EC2 fits applications needing operating-system access, specialized instance types, persistent processes, or compatibility with existing software. The trade-off is responsibility for instances, patching, capacity, and much of the scaling design.

• AWS Lambda fits short, event-driven work, such as handling an API request, processing an uploaded file, or reacting to a scheduled event. AWS manages the execution environment, but functions have service limits: a standard invocation can run for at most 15 minutes. Design state to live outside the function.

• Amazon ECS and Amazon EKS orchestrate applications packaged as containers. ECS provides AWS-native container orchestration; EKS is Kubernetes on AWS and fits workloads or teams that need Kubernetes compatibility and its ecosystem. Both need an underlying compute option.

• AWS Fargate runs containers without requiring the team to manage the EC2 hosts. Choose task or pod CPU and memory, and AWS manages the underlying compute. Fargate works with ECS and EKS.

• ECS or EKS on EC2 suits container workloads needing host-level control, specialized instance capacity, or a capacity model suited to sustained utilization. The team operates and scales both EC2 capacity and the container workload.

ECS and EKS are orchestrators; Fargate and EC2 provide the compute capacity on which containers run. Lambda runs functions in response to events. A container image can package a Lambda function, but that does not make Lambda a general-purpose, continuously running container service.

A method for choosing compute

Use the following questions in order to compare viable designs. They are guidelines, not rigid rules, and a workload can combine multiple compute types.

1. What starts the work? An event or request often suggests Lambda. A continuously available application or worker often suggests a container service or EC2.

2. How long does the work run, and what resources does it need? Check maximum execution duration, CPU, memory, storage, networking, and hardware or operating-system requirements before choosing.

3. Does the application need a container or host-level control? If it needs a container, compare ECS or EKS on Fargate with ECS or EKS on EC2. If it needs neither, Lambda may avoid unnecessary server and container management.

4. How does demand vary? For spiky or unpredictable event traffic, automatic scaling can reduce the need to keep servers running. For steady demand or specialized capacity, compare container and EC2 options along with operational effort.

5. What can the team operate well? Kubernetes capability, deployment processes, observability, and on-call experience matter. A technically possible service is not automatically the simplest choice for an organization.

Applying compute choices

Image resizing after upload

When a user uploads an image to Amazon S3 and resizing usually finishes quickly despite irregular traffic, a good starting design is to trigger a Lambda function from the S3 object-created event. The function resizes the image and writes the output back to S3. Keep durable state in storage rather than relying on a function instance to retain it. Confirm that execution time, dependencies, and resource use fit Lambda's limits; if processing later requires a long-running workload or resources outside those limits, reassess a container or batch-processing design.

An always-on containerized web application

For an application that serves HTTP requests continuously, is already packaged as a container, and does not require Kubernetes, a good starting design is an ECS service on Fargate. Put an Application Load Balancer in front if the application needs a load-balanced HTTP endpoint, and configure service scaling around an appropriate demand metric. Use ECS on EC2 instead if host control, specialized instances, or a different capacity model matters. Fargate supplies managed container compute, while ECS manages the service and its desired task count.

A legacy application requiring a specific operating system

For an application that runs continuously and needs a particular environment, host-level access, or software that does not fit a managed function or container deployment, a good starting design is EC2. For higher availability, use an Auto Scaling group across multiple Availability Zones and a load balancer that checks target health. Automate instance setup and deployment so replacement instances can be launched consistently. EC2 gives more virtual-server control than Lambda or Fargate, but the team takes on more infrastructure operations.

A web request that starts a long report

If report generation may take longer than a normal interactive request, the client should not have to keep a connection open until completion. Have the API accept the request and place a job on a queue. A container-service worker can process jobs independently: use Fargate when avoiding host management is a priority, or ECS on EC2 when host control or capacity economics justify it. Store job status and results outside the worker. Lambda may suit the work if each unit fits its limits, but a standard invocation cannot exceed 15 minutes. Separating acceptance from processing avoids tying the user's connection to job runtime and allows worker capacity to scale independently.

Deployment and reliability

Make compute replaceable by putting durable data and job state in managed storage or databases rather than depending on a particular instance, task, or function environment.

Use health checks that reflect application readiness. A process can be running while the application is unable to serve requests, so configure a health-check endpoint and ensure the load balancer can reach it.

Deploy incrementally, using staged traffic or rolling replacement where appropriate. Monitor error rates, latency, and health during rollout.

Scale the right unit: EC2 Auto Scaling adjusts instances, an ECS service adjusts tasks, and Lambda scales function invocations. Check whether downstream databases and other dependencies can handle the resulting concurrency.

Set permissions deliberately. Give each workload only the IAM permissions it needs, and ensure its execution role can access required services. Observe infrastructure and application behavior together by reviewing logs, service metrics, scaling activity, and deployment events when diagnosing failures.

Troubleshooting compute workloads

Timeouts and failed jobs

Compare actual runtime with service and request timeouts. For Lambda, check the configured timeout and the 15-minute standard invocation maximum, then inspect logs for the operation that is slow or stuck. If work exceeds the execution model, split it into smaller jobs or move it to a long-running worker.

Unreachable targets behind a load balancer

Check target health and the configured health-check path, protocol, and port. Verify that security groups permit traffic from the load balancer to the target, and that application readiness matches the health-check behavior.

EC2 Auto Scaling launch or attachment problems

Inspect scaling activities and their error messages. Confirm that the referenced load balancer and target group exist and are configured for the intended VPC.

ECS service scaling problems

Check the service's desired and running task counts, scaling policy, relevant CloudWatch metrics, and scaling activity. Then verify that the service has the permissions and available capacity needed to launch additional tasks.

A deployment seems healthy, but users see errors

Compare application logs and load-balancer target health with the deployment timeline. A passing process check does not prove that the application can complete real requests or reach its dependencies.

Putting the choices together

Use Lambda for suitable event-driven tasks, containers for applications that benefit from a packaged runtime and orchestrated lifecycle, and EC2 when virtual-machine control or compatibility is required. For containers, choose both an orchestrator—usually ECS or EKS—and a compute layer—Fargate or EC2. Validate limits, scaling behavior, dependencies, team skills, and failure modes before deployment. Combine services when different parts of a workload have different needs.