EC2 Advanced

Volume encryption uses EC2 host hardware to encrypt data at rest and in transit between EBS and EC2 instances. Encryption generates a data encryption key (DEK) from a customer master key (CMK) in each region. A unique DEK encrypts each volume. Snapshots of that volume are encrypted with the same DEK as are any volumes created from that snapshot.

Encrypted DEKs stored within volumes (EBS) are decrypted by KMS using a CMK and given to the EC2 host.

Plaintext DEKs are stored in EC2 memory and used to encrypt and decrypt data.

The EC2 instance and OS see plaintext data as normal - no performance impact.

To enable Volume encryption, Open EC2-->Account Attributes-->Settings-->Check Encryption-->Always encrypt new EBS volumes-->Save Settings.

Key Management Service (KMS) in AWS Console is a separate service.

Data is encrypted on EC2 instance and transferred to EBS for storage. Creating a snapshot of a volume is always encrypted by default.

Legacy non-EBS optimized instances used a shared networking path for data and storage communications. This Shared path resulted in lower performance for storage and normal networking.

EBS-optimized mode, which was historically optional and is now the default, adds optimizations and dedicated communication paths for storage and traditional data networking. This allows consistent utilization of both - and is a required feature to support higher performance storage.

Traditionally, virtual networking meant a virtual host (EC2 host) arranging access for n virtual machines to access one physical network card - this multitasking is done in software and is typically slow.

Enhanced networking uses SR-IOV (Single Route-Input Output Virtualization), which allows a single physical network card to appear as multiple physical devices. Each instance can be connected to one of these (fake) physical devices. This results in faster transfer rates, lower CPU usage and lower consistent latency. EC2 delivers this via the Elastic Network Adapter (ENA) or Intel 82599 Virtual Function (VF) interface.

Placement Groups. There are three types of PGs. These allow a level of visibility of where the EC2 instances run from. It allows to control or see the physical location.

Cluster PG: These are designed for performance. These are limited to one availability zone. All instances under a cluster will host on same physical hardware/host or a physically nearby host. Every instance can talk to every other instance at the same time at full speed. Works with enhanced networking for peak performance.

Partition PG: Instances deployed into a partition placement group (PPG) are separated into partitions (max of seven per AZ), each occupying isolated racks in AZs/regions. PPG can span multiple AZs in a region. PPGs minimize failure to a partition and give you visibility on placement.

Spread PG: SPGs are designed for a max of seven instances per AZ that need to be separated. Each instance occupies a partition and has an isolated fault domain. Great for email servers, domain controllers, file servers, and application HA pairs.

EC2 Billing Models

In contrast to On-Demand Instances, Spot instances allow consumption of spare AWS capacity for a given instance type and size in a specific AZ. Instances are provided for as long as our bid price is above the spot price and we only ever pay the spot price. If our bid price is exceeded, instances are terminated with a two minute warning.

Spot fleets are a container for "capacity needs". We can specify pools of instances of certain types / sizes aiming for a given capacity. A minimum percentage of on-demand can be set to ensure the fleet is always active. Sport instances are perfect for non-critical workloads, burst workloads or consistent non-critical jobs that can tolerate interruptions without impacting functionality.

Spot is not suitable for long-running workloads that require stability and cannot tolerate interruptions.

Reserved Instances lock in a reduced rate for one or three years. Zonal reserved instances include a capacity reservation. Our commitment incurs costs even if instances are not launched. Reserved purchased are used for long-running, understood and consistent workloads.

Key Facts:

  • Instance size/type have an AZ spot price.

  • Bid more, instance provisioned for spot price. Less = termination.

  • Spot fleets are containers, allowing capacity to be managed.

  • Reservations are zonal (AZ) or regional.

  • One or three years, no upfront, partial upfront, all upfront.

  • We pay regardless of EC2 instance using a reservation.

  • Regional is more flexible - but has no capacity reservation.

When to Use Reserved Purchases

  • Base/consistent load

  • Known and understood growth

  • Critical systems/components

When to use spot Instances/Fleets

  • Burst-y workloads

  • Cost-critical, which can cope with interruption

When to use On-Demand

  • Default or unknown demand

  • Anything in between reserved/spot

  • Short-term workloads that cannot tolerate interruption

Dedicated Host

Dedicated hosts are EC2 hosts for a given type and size that can be dedicated to you. The number of instances that can run on the host is fixed - depending on the type and size. An on-demand or reserved fee is charged for the dedicated host - there are no charges for instances running on the host. Dedicated hosts are generally used when software is licensed per core/CPU and not compatible with running within a shared cloud environment.

Next: Serverless Compute (Lambda)