2 Amazon EC2 Instances and Scaling

Select an instance type

Amazon EC2 provides virtual servers whose capacity, operating system, storage, and network settings you choose. You can launch a single instance for a small task or manage a fleet that adjusts to changing demand.

An instance type defines the virtual hardware available to an instance, including its CPU, memory, storage, and networking capacity. First choose a family suited to the workload, then select a size that provides enough capacity:

• General purpose balances compute, memory, and networking, for example, for a web server.

• Compute optimized suits processor-intensive work such as batch processing.

• Memory optimized suits workloads that process large datasets in memory.

• Storage optimized suits workloads that need high storage throughput or I/O performance.

• Accelerated computing uses hardware accelerators for tasks such as graphics processing or machine learning.

For a typical application server, begin by evaluating a general-purpose type. If testing shows that the application is CPU-bound, compare a compute-optimized type; if it frequently runs out of memory, compare memory-optimized types. Availability and specifications vary by instance type and Region, so check the current EC2 instance-type catalog before choosing.

Prepare and launch an instance

An Amazon Machine Image (AMI) is the bootable template for an instance. It specifies the operating system and software and includes the block-device mapping for attached storage. AMIs are Region-specific and must be compatible with the chosen instance type. You can use an AWS-provided or Marketplace image, or create an AMI to reproduce a customized server.

A typical launch involves configuring the following:

1. AMI and instance type to choose the software and hardware.

2. Key pair or another supported access method for administration. Protect private credentials; do not place them in images or source code.

3. VPC and subnet to determine network placement.

4. Security groups to control allowed traffic.

5. Storage and instance count, along with tags such as Name or Environment for identification and organization.

6. An IAM instance profile, when applications on the instance need permission to access AWS services. Grant only the permissions they require.

A launch template can save reusable launch settings and serve as the configuration for an Auto Scaling group. Instances pass through states such as pending and running. Once an instance is running, connect using an approved method and verify that its operating system and application are healthy.

Choose storage carefully

Amazon EBS provides persistent block storage that can be attached to an instance and managed separately from it. EBS volumes can be backed up with snapshots. Check a volume’s encryption, size, performance settings, and delete-on-termination behavior, and preserve required data before deleting resources.

Instance store is temporary local storage available on some instance types. Its data does not survive stopping, hibernating, or terminating the instance. Use it for disposable data such as caches or temporary processing files, not as the only copy of valuable data.

Configure network access

An instance launches in a subnet in an Amazon VPC and receives a private IP address. Whether it can be reached from the internet depends on its network configuration, including subnet routes and public addressing. An automatically assigned public IP may change after a stop and start; use an Elastic IP when a persistent public IPv4 address is needed.

A security group acts as a stateful virtual firewall. Inbound rules permit specified protocols, ports, and sources; outbound rules govern traffic leaving the instance. For example, a public web server might allow inbound HTTPS from clients while restricting administrative access to a trusted source. Avoid broad access to management ports such as SSH or RDP.

Rules apply to all associated instances, so grouping instances by role can simplify access control.

Manage instance state

You can stop and restart an EBS-backed instance when you need to pause its compute use, or terminate it when it is no longer needed. Stopping is reversible; termination is permanent. Stopping does not remove charges for resources that remain, such as EBS volumes. Instance-store data is lost when an instance is stopped.

Scale and monitor capacity

For horizontal scaling, place instances in an EC2 Auto Scaling group and set its minimum, desired, and maximum capacity. The group maintains desired capacity and can replace unhealthy instances. If configured across Availability Zones, it can distribute instances among them.

Scaling can be manual, scheduled for predictable demand, or dynamic in response to metrics. For example, a target-tracking policy can adjust capacity to maintain a chosen average CPU utilization or request rate. Set sensible capacity limits and use health checks that reflect whether instances can actually serve the application.

Amazon CloudWatch receives basic EC2 metrics, including CPU and network measurements, at five-minute intervals by default. Detailed monitoring provides one-minute intervals. CloudWatch alarms can notify you or trigger actions when a metric crosses a threshold, and the CloudWatch agent can collect guest operating-system metrics and logs. Monitor both infrastructure health and application-level signals: low CPU alone does not prove that an application is healthy.

Control costs

Match instance capacity to measured demand, scale in when demand falls, and stop or terminate unused instances. On-Demand pricing is flexible. Spot Instances use spare capacity but can be interrupted, so use them only for workloads that can tolerate interruption. Savings Plans can reduce eligible usage costs in exchange for a usage commitment. Choose commitment-based discounts only after understanding steady usage and flexibility needs.

The instance is not the only possible cost. Attached EBS volumes and snapshots can continue to incur charges, and network usage or monitoring features may also affect the bill. Tag resources consistently, review usage in billing tools, and set AWS Budgets alerts to catch unexpected spending. Budget alerts are monitoring aids, not necessarily immediate spending caps.