Compute, scaling, and load balancing

A machine is one part of an application

An EC2 instance is virtual compute. An Amazon Machine Image, or AMI, supplies its starting operating-system image and related launch information. An instance type selects a resource shape. You still decide how code is installed, which user runs it, where logs go, how configuration arrives, and how the service becomes ready.

A launch template records repeatable launch settings. User data can help bootstrap a machine, but a submitted script does not prove its commands succeeded. An instance role, delivered through an instance profile, gives software temporary AWS credentials without embedding a person's access keys. Use the supported metadata and SDK mechanisms, with IMDSv2 settings appropriate to the workload.

Separate replacement, scaling, and traffic selection

An Auto Scaling group manages a desired set of instances, using minimum, desired, and maximum capacity plus health and scaling policies. It can replace unhealthy instances and adjust capacity. A load balancer receives client connections and forwards traffic to registered targets. These are related services with different jobs: creating more machines does not automatically send useful traffic to them.

An Application Load Balancer works with HTTP/HTTPS requests and can route by properties such as host or path. A Network Load Balancer serves transport-level use cases such as TCP, UDP, and TLS. Choose based on the protocol and requirements, not a belief that one is universally better.

A listener accepts traffic on a configured port/protocol. A target group defines destinations and health checks. TLS termination at a load balancer needs a suitable certificate and domain setup; encryption from load balancer to application is a separate choice.

Work a failure scenario on paper

Suppose a proposed API has two instances across two zones, with an ALB health check at /ready. One process is running but cannot accept requests because its configuration is missing. Predict the result:

1. EC2 may still consider the machine running.
2. The application health check should report it unready if it checks the relevant condition.
3. The load balancer's target-health view determines whether it should receive traffic, subject to documented load-balancer behavior.
4. The Auto Scaling group's configured health sources and grace periods determine replacement behavior.
5. A replacement only helps if the launch process supplies the missing configuration correctly.

This is a design scenario, not an observed outage or a guarantee of uninterrupted service. Two zones reduce some shared risks but do not fix a bad image, a single database dependency, or incompatible application changes.

Compare other execution choices

ECS schedules containers using AWS's orchestration model; EKS provides managed Kubernetes control-plane capabilities. Fargate is a compute option for supported container workloads that removes direct instance management. Lambda runs event-driven functions under its execution model and limits. These choices move responsibilities; they do not remove configuration, permission, networking, observability, or cost decisions.

For the current path, run MicroBank locally first. No EC2 fleet, EKS cluster, or cloud load balancer is needed to learn these relationships. The later cloud and orchestration tracks can choose a target after the application behavior is understood.

Practice and answers

Extend your previous network drawing with a listener, target group, and two proposed API instances. Mark where TLS ends, where health is checked, and where the service's IAM role is used. Write a readiness condition more useful than “the machine exists.” For example: the API has loaded valid configuration and can accept the operation the check promises.

Would scaling a memory-leaking release always cure it? No; it may repeat the defect on more instances. Would a green health endpoint prove a money transfer? No; verify a representative transaction separately. Next, choose storage according to the application's data behavior.

References: EC2 concepts↗, Auto Scaling groups↗, load balancing↗, and EC2 instance metadata↗.