AWS compute options - virtual machines (VMs)

One way of deploying our workload is to use virtual machines. To do this in AWS, we can use Amazon Elastic Compute Cloud. Amazon EC2 (Elastic Compute Cloud) is a service that provides virtual servers to run applications on the AWS cloud. It allows you to quickly scale your computing capacity as needed, paying only for what you use. This article will explain how EC2 works and how you can use it.

Amazon EC2 (Amazon Elastic Compute Cloud):

web service providing compute capacity through virtual servers called EC2 instances
emulates a physical server
allows installing an HTTP server to run your applications
to run virtual machines, you install a hypervisor (software to share physical resource across VMs) on a host machine
you can launch/stop/shutdown multiple EC2 instances
you pay by the hour or second for each instance type (min 60s)
to manage EC2 instances you can use:
- AWS Management Console,
- AWS CLI,
- AWS SDKs,
- automation tools,
- infrastructure orchestration services
to create EC2 instance you need to specify:
- hardware (CPU, memory, network, storage)
- logical configuration (networking location, firewall rules, authentication, operating system)
to start instance you need to specify:
- AMI (Amazon Machine Image)
- Instance type
- Network placement and addressing
- Assumed IAM role
- User data (e.g some scripts to customize an instance, that runs when instance starts)
- storage (for root and boot volume)
- security group
- key pair (to connect to instance via ssh or rdp)

Storage types for EC2 instance

you can have couple types of storage attached to EC2 instance:
- instance storage (ephemeral storage, attached physically to host)
- Amazon EBS (persistent storage volumes, used for boot disk)
- EBS-optimized instance (faster access to EBS volumes by minimizing I/O contention between the volume and other traffic from the instance)
- Amazon Elastic File System (EFS)
- Amazon FSx for Windows File system

Storage types for root volume:

root volume can only be in instance store or EBS volume which is on SSD disks

Using the same storage for multiple instances

instance store and EBS can only be used by one instance at a time, and additionally, the instance store can only be used by the instance to which it is added
if we want to share data volume between instances at the same time, we need EFS for Linux instances and FSx for Windows instances or EBS with multi-attach feature

Amazon EBS-optimized instances

some EC2 instances are EBS-optimised, which allows them to use dedicated connections to EBS and greater I/O performance
for such instances optimization is enabled by default, for other instance types it must be enabled manually
additional performance boost can be achieved by using EC2 Nitro System-based instance

Amazon Machine Image – AMI:

base software configuration
AMI includes:
- template dla root volume (with operating system and additional preinstalled applications)
- launch permissions
- block device mapping
AMI is how you model your instances and EC2 is the entity of the given AMI (like class and objects)
AMI is reusable – you can create AMI from running EC2 instance and use it to start new EC2 instance with identical configuration
AMI has, unique to each Region, AMI ID, which is prefixed by ami-, followed by a random hash of numbers and letters
selected AMI is copied to the root device volume, which contains the image that is used to boot the volume.

Where you can find AMI to use:

Quick Start AMIs – common AMIs provided by AWS
AWS Marketplace AMIs – open-source and commercial software from third-party vendors
My AMIs – AMI created from your EC2 instances
Community AMIs – from AWS community
EC2 Image Builder – you can build your own AMI using EC2 Image Builder.

How to choose right AMI?

we choose AMI based on:
- region – each ami exists on region level, so we need to choose ami from the region we want to run our instance
- operating system (windows/linux)
- storage for root device (EBS-backed or store-backed instance)
- architecture (32b, 64b, x86, ARM)
- virtualization type (paravirtual (PV) or Hardware Virtual Machine (HVM). The second one offer better performance, because it can use hardware improvements)

EC2 Image Builder

service that allows you to create, maintain, validate, share, and deploy AMIs
graphical interface for creating AMIs and generating VM images for on-premise use
you can have version control
the output image can be in the following formats: AMI, VHDX, VMDK, OVF

AMi vs user data

when building an instance, we need to choose how many things we want to put into the AMI, and how many we want to configure in the user data
if we have a fully baked AMI, it will take a long time to build it, plus we will have to watch out for vulnerabilities in all used libraries
if we have an AMI with only the basic OS, and the rest is loaded into user data, then booting the instance will take a long time
therefore we have 3 approaches:
- full AMI – all dependencies pre-installed, long build, short boot and short lifespan, possible problems with rollbacks
- hybrid AMI – only prerequisites are preinstalled, extending lifespan, easier rollbacks
- OS-only AMI – slow boot

EBS-backed instance vs store-backed instance

EBS-backed instance boots faster comparing to store-backed instance
EBS-backed instance can have up to 16 TiB of root device, while store-backed only 10 GiB
EBS-backed instance can be stopped, while store-backed can be only reboot or terminated
EBS-backed instance can change instance type after stopping, while store-backed cannto change type
while using EBS-backed instance you are charged for instance usage, EBS volume usage, storing AMI as an EBS snapshot. Using store-backed instance you will be charged only for instance usgae and storing your AMI in S3.

Amazon EC2 instance types:

combination of virtual processors (vCPUs), memory, network, and, sometimes, instance storage and graphics processing units (GPUs)
instance types consist of a prefix identifying the type of workloads they’re optimized for, followed by a size
- e.g. c5n.xlarge:
- c – instance family (compute optimized family), each instance family is optimized to fit different use cases
- 5 – generation of the instance
- n – additional attributes (local NVMe storage)
- xlarge – instance size.

EC2 instance families:

general purpose – balanced CPU/memory/network.
- for applications that use these resources in equal proportions (web servers, code repositories)
- e.g. m7g.medium, m7gd.medium, m7gd.metal
compute optimized – high-performance processors, ideal for compute bound applications:
- batch processing,
- media transcoding,
- high performance web servers,
- HPC – high performance computing,
- scientific modeling,
- gaming and ad servers engines,
- machine learning
- e.g. C7g.medium, c7gd.4xlarge, c7gd.metal
memory optimized – for processing large data sets in memory,
- distributed web-scale in-memory caches,
- mid-size in-memory databases,
- real-time big-data analytics
- e.g. R8g, R4, U7i, X2iedn, z1d
accelerated computing – have hardware accelerators/co-processors to better perform operations, such as:
- graphics processing,
- data pattern matching
- ML,
- HPC
- e.g P5,G6, Trn1, Inf2, DL1, F1, VT1
storage optimized – for high sequential read and write access to large datasets on local storage. They are optimized for I/O operations
- NoSQL databases (Cassandra, MongoDB and Redis),
- in-memory databases,
- scale-out transactional databases,
- data warehousing,
- Elasticsearch, and analytics
- e.g. I4g, I4i, D3en, H1
HPC optimized – offers the best price performance for running HPC workloads at scale on AWS.
- large, complex simulations and deep learning workloads
- e.g. Hpc7g, Hpc6a

AWS Compute Optimizer

analyzes your workload on the instance and makes recommendations: under-provisioned, over-provisioned, optimized, none
recommends instance type and auto scaling group configuration

EC2 instance locations:

by default placed in VPC (Virtual Private Cloud)
resources put in default VPC are public (accessible by the internet), so don’t place customer data or private info there
it is better to use custom VPC.

Architecting for high availability:

it is generally better to have many smaller instances rather than few large ones in case of failure
use at least 2 EC2 instances in separate AZ

EC2 instance lifecycle:

pending
- when launching instance enters pending state
- billing is not started
- AWS perform actions needed to set up instance (copying AMI content to root device, allocating networking components)
running
- ready to use,
- billing begins
reboot
- equivalent to rebooting operating system,
- different from start/stop,
- instance stays on the same host, keeps public DNS name, IPv4/v6 public and private addresses, if it has an instance store volume, we don’t lose this data
stopping, stopped
- you can stop instance if it has Amazon EBS (Elastic Block Store) volume as its root device
- after stop/start instance can be placed on different physical server
- instance retains private IPv4/v6 addresses
- when you put instance into stop-hibernate it enters stopped state and saves the last information into memory to speed up start process
terminated
- instance stores are erased,
- loses public and private ip
- as soon as the status changes to shutting down/terminated you stop paying for that instance

stop vs stop-hibernate

stop:
- AWS does not charge usage/data transfer fees for stopped instances, but Amazon EBS volumes are still charged
- in stopped state you can modify some attributes (e.g. instance type)
- when you stop instance you loose data from instance RAM
stop-hibernate:
- EC2 signals OS to perform hibernation (suspend-to-disk) – it saves content from RAM to EBS root volume
- you can hibernate an instance only if hibernation is turned on and the instance meets the hibernation prerequisites
- you can hibernate only EBS-backed instance
- private ip and elastic ip are saved in memory and remain the same after start

Amazon EC2 pricing models:

on-demand instances:
- you pay for compute capacity per hour/per second
- no long-term commitments or upfront payments required
- you can change your compute capacity to meet the demands of your application
- use cases:
  - applications with short-term, spiky, or unpredictable workloads that cannot be interrupted or for apps tested on Amazon EC2 for the first time
spot instances:
- we request currently unused instances, to use this our workload must be able to stop and restart with 2 minutes notification
- you can request spare Amazon EC2 computing capacity for up to 90 percent off the On-Demand price
- for applications that are profitable only at very low compute prices and have fault-tolerant or stateless workloads
- the instance is started as resources are available, and the maximum price per hour for our request will exceed the spot price
saving plans:
- offers low usage prices for a 1-year or 3-year term commitment to a consistent amount of usage
- applies to Amazon EC2, AWS Lambda, and AWS Fargate usage and provides up to 72 percent savings on AWS compute usage
- for workloads with a consistent and steady-state usage
- for customers who want to use different instance types and compute solutions across different locations
reserved instances:
- steady state usage that might require reserved capacity
- You can choose between three payment options:
  - All Upfront
  - Partial Upfront
  - No Upfront
- You can select either a 1-year or 3-year term for each of these options.
  - Standard Reserved Instances: most significant discount (up to 72 percent off On-Demand pricing), best for steady-state usage.
  - Convertible Reserved Instances: discount up to 54 percent off On-Demand pricing, capability to change the attributes of the Reserved Instance if as a result we create instances of equal or greater value, best suited for steady-state usage.
  - Scheduled Reserved Instances: available to launch within the time windows that you reserve, thanks to that you can match adapt to a predictable recurring schedule that only requires a fraction of a day/week/month
dedicated hosts:
- physical Amazon EC2 server that is dedicated for your use
- you can use your existing server-bound software licenses (e.g. Windows Server, Oracle licenses) – cost reduction
- help you meet compliance requirements
- integrated with AWS License Manager (service that manages software licenses)
- dedicated hosts can be purchased on demand (hourly) or as a reservation for up to 70 percent off the On-Demand price

Amazon EC2 cost optimization

to optimized costs you should combine available purchase options, e.g:
- use reserved instances or saving plans for steady-state workloads
- use on-demand instances for stateful spiky workloads
- use spot instances for fault-tolerant, stateless workloads

Placement group

allow you to control where in the availability zone the instance is launched
possible strategies:
- cluster – instances packed close together in the availability zone, low latency and high packet-per-second network performance (best practice – start all instances with one request)
- partition – instances spread across logical partitions, so that they do not share the underlying hardware, each partition has its own set of racks, partitions can be in different AZs, recommended for large distributed replicated workloads
- spread – directly placing small groups of instances on different hardware, groups can span multiple AZs, recommended for applications with a few critical instances that need to be kept separate

Amazon EC2 use cases:

we need to have full control over computing resources – choice of OS, x86/ARM processor architectures
we want to optimize costs – on-demand instances, savings plans, reserved instances, spot instances
we need to handle different types of workload

In conclusion, AWS provides a variety of compute options through Amazon EC2, enabling flexible and scalable deployment of virtual machines. By understanding AMIs, storage types, pricing models, and instance configurations, you can tailor your EC2 instances to meet specific workload requirements efficiently. With these tools, you can optimize performance and cost- effectiveness for your applications in the cloud.