Elastic Compute Cloud (EC2) provides scalable computing capacity (VMs) in the Amazon Web Services (AWS) cloud.
Virtual computing environments, known as Ec2 instances.
An instance is a virtual server in the cloud.
Preconfigured templates for your instances, known as Amazon Machine Images (AMIs), that package the bits you need for your server (including the operating system and additional software).
After you create an AMI, you can keep it private so that only you can use it, or you can share it with a specified list of AWS accounts.
An instance type essentially determines the hardware of the host computer used for your instance. Various configurations of CPU, memory, storage, and networking .
The root device for your instance contains the image used to boot the instance.
Each Region is a separate geographic area.
Availability Zone is an Isolated location inside of a region.
A Local Zone is an extension of an AWS Region in geographic proximity to your users.
A network border group is a unique set of Availability Zones or Local Zones from where AWS advertises IP addresses.
An Availability Zone is represented by a Region code followed by a letter identifier; for example, us-east-1a.
When an instance is terminated, the instance performs a normal shutdown. The root device volume is deleted by default.
You can add and map instance store volumes for temporary data.
Secure login information for your instances using key pairs (AWS stores the public key, and you store the private key in a secure place)
Storage volumes for temporary data that’s deleted when you stop or terminate your instance, known as Instance store volumes.
Persistent storage volumes for your data using Amazon Elastic Block Store (Amazon EBS), known as Amazon EBS volumes.
A firewall that enables you to specify the protocols, ports, and source IP ranges that can reach your instances using security groups.
Static IP addresses for dynamic cloud computing, known as Elastic IP addresses.
Metadata, known as tags, can be created and assigned to EC2 resources.
Security groups act as a firewall for associated instances, controlling both inbound and outbound traffic at the instance level.
Accessing using: Amazon EC2 console, AWS Command line Interface (CLI), Amazon EC2 Command Line Interface (CLI) tools, AWS Tools for Windows Powershell, AWS Query API (Query API allows for requests are HTTP or HTTPS requests that use the HTTP verbs GET or POST and a Query parameter named Action), AWS SDK libraries.
Spot Instances are available at up to a 90% discount compared to On-Demand prices.
Note that if you plan to launch instances in multiple Regions, you'll need to create a security group in each Region. Disadvantage.
Key pairs are specific to a region. Disadvantage
You can launch your instance(s) into an Auto Scaling Group and set up policies to automatically scale the number of instances in the group.
The root storage device of the instance determines the process you follow to create an AMI.
Each AMI has a launchPermission property that controls which AWS accounts, besides the owner's, are allowed to use that AMI to launch instances.
The AWS Marketplace is an online store where you can buy software that runs on AWS,
AMIs that are backed by Amazon EBS snapshots can take advantage of Amazon EBS encryption.
Like EBS volumes, snapshots in AMIs can be encrypted by either your default AWS Key Management Service customer master key (CMK)
You can launch with Launch with no encryption parameters , Instance launch behaviors with Encrypted set but no KmsKeyId specified , Instance with both Encrypted and KmsKeyId set.
You need to think if you have an encrypted snapshot or not.
You can also copy an AMI and simultaneously apply a new encryption state to its associated EBS snapshots by supplying encryption parameters.
You can determine the platform details and billing information associated with an Amazon Machine Image (AMI) before you launch an On-Demand Instance or Spot Instance, or purchase a Reserved Instance.
For Spot Instances, you can use the platform details to confirm that the AMI is supported for Spot Instances. When purchasing a Reserved Instance, you can make sure that, for Platform, you select the correct value that maps to Platform details on the AMI.
External users will be unable to access a instance in private subnets directly. To provide such access, we need to deploy Bastion hosts in public subnets.
The recommendations from AWS when migrating a legacy application which is hosted on a virtual machine in an on-premises location to an AWS VPC :
Use Amazon Route53 resolver.
Use the VM Import provided by AWS.
To hard-coded IP addresses fo a VM, when we need to allow the application to failover to new instances (with the same IP) without much reconfiguration, you have 2 options:
Create a secondary ENI that can be moved to the failover instance. Use
Assign a secondary private IP address to the primary ENI of the failover instance.
Once an Instance has been launched with instance store storage, you can not attach additional instance store volumes after the instance is launched, only EBS volumes
You can encrypt both the boot and data volumes of an EC2 instance.
You can create an IAM role and attach it to an instance during or after launch.
To replace the IAM role on an instance that already has an attached IAM role, the instance must be in the running state.
Provides the information required to launch an instance, which is a virtual server in the cloud.
Includes the following: A template for the root volume for the instance for e.g. an operating system, an application server, and applications, permissions that control which AWS accounts can use the AMI to launch instances, a block device mapping that specifies the volumes to attach.
AMIs can be either: AWS managed, Third party or Community provided public custom AMIs, Private AMIs created by other AWS accounts and shared with you or Private and Custom AMIs created by you.
AMIs are specific to a region, and you can copy an AMI to the same region or to different regions.
Architecture (32-bit or 64-bit)
Permission: Public – Accessible to all AWS account, Explicit – Shared with specific AWS accounts, and Private – Owned and available for AMI creator AWS account only.
Storage: AMIs can have EBS or Instance store as the root device storage .
EBS volume; are independent of the EC2 instance lifecycle and can persist independently. Instances can be stopped or terminated (if the Delete On Termination flag is disabled) without losing the volumes. EBS backed instances boot up much faster than the Instance store, and AMI creation is much easier.
Instance Store: is an ephemeral storage and is dependent on the lifecycle of the Instance. Instance store is deleted if the instance is terminated or if the EBS backed instance, with attached instance store volumes, is stopped.
Instance store volumes cannot be stopped.
We can't use instance store volumes to create AMIs & Snapshots.
Instance store volumes have their AMI in S3 and have higher boot times compared to EBS backed instances. The AWS CLI tools can be used to create a bundle for the volume and upload it to S3. Then register the AMI to the file in the S3 bucket.
To create Linux AMIs backed by instance store, you must create an AMI from your instance on the instance itself using the Amazon EC2 AMI tools.
AMIs, with EBS backed snapshots, can be attached with both an encrypted root and data volume.
AMIs copy image can be used to create AMIs with encrypted snapshots from AMIs with unencrypted snapshots. By default, copy image preserves the encryption status of the snapshots.
AMI copy image can’t be used to create an unencrypted an AMI from an encrypted AMI.
Snapshots can be encrypted with either your default AWS Key Management Service customer master key (CMK), or with a custom key that you specify.
Amazon EBS-backed AMIs and instance store-backed AMIs can be copied. The copy has its own unique identifier, for EBS Backed AMI an identical but distinct root and data snapshots are created, encryption status of the snapshots are preserved, however the launch user-defined tags, or Amazon S3 bucket permissions are not copied.
Instances launched from an Amazon EBS-backed AMI launch faster than instances launched from an instance store-backed AMI.
Linux Amazon Machine Images use one of two types of virtualization: paravirtual (PV) or hardware virtual machine (HVM).
To make an AMI available in a different region, copy the AMI to the region and then share it.
Amazon Linux does not allow remote root SSH by default.
Password authentication is disabled to prevent brute-force password attacks.
Must be provided with a key pair at launch to enable SSH logins.
Inbound security group must allow SSH access.
By default, the only account that can log in remotely using SSH is ec2-user; this account also has sudo privileges.
They are configured to download and install security updates at launch time.
Updated on a regular basis to include the latest components.
Includes pre-installed packages to enable easy integration with AWS services, such as the AWS CLI, Amazon EC2 API and AMI tools, the Boto library for Python, and the Elastic Load Balancing tools.
Two types of virtualization: paravirtual (PV) or hardware virtual machine (HVM).
AMIs are a regional resource.
AMIs with encrypted volumes cannot be made public.
HVM virtualization type provides the ability to run an operating system directly on top of a virtual machine without any modification, as if it were run on the bare-metal hardware.
HVM AMIs are required to take advantage of enhanced networking and GPU processing.
All current generation instance types support HVM AMIs.The CC2, CR1, HI1, and HS1 previous generation instance types support HVM AMIs.
PV AMIs boot with a special boot loader called PV-GRUB, which starts the boot cycle and then chain loads the kernel specified in the menu.lst file on your image.
Paravirtual guests can run on host hardware that does not have explicit support for virtualization, but they cannot take advantage of special hardware extensions such as enhanced networking or GPU processing.
C3 and M3 current generation instance types support PV AMIs. The C1, HI1, HS1, M1, M2, and T1 previous generation instance types support PV AMIs.
Shared AMI is an AMI that can be created and shared with others for use.
Can be risky as Amazon does not perform an detailed checks and vouch for the integrity and security of these AMIs.
Before using a Shared AMI, check for any pre-installed credentials that would allow unwanted access to the instance by a third party and no pre-configured remote logging that could transmit sensitive data to a third party .
Amazon allows you to share an AMI, by defining launch permissions, to all (making it public) or only to a specific AWS accounts.
Launch permissions work at the AWS account level only; and can’t be used to restrict specific users within an AWS account.
Update the AMI tools or any software during startup, and take into account the software updates not break any software.
Fixed root passwords can be a security risk and needs to be disabled.
Disable direct root logins.
Remove the existing SSH host key pairs located in /etc/ssh, which forces SSH to generate new unique SSH key pairs when someone launches an instance using your AMI.
Disabling sshd DNS checks slightly weakens your sshd security. However, if DNS resolution fails, SSH logins still work. If you do not disable sshd checks, DNS resolution failures prevent all logins.
Provide more information to help describe the AMI.
Don’t store any sensitive data or software on the AMI.
Amazon EBS Multi-Attach enables you to attach a single Provisioned IOPS SSD (io1 or io2) volume to multiple instances that are in the same Availability Zone.
You can attach multiple Multi-Attach enabled volumes to an instance or set of instances.
Each instance to which the volume is attached has full read and write permission to the shared volume.
Multi-Attach makes it easier for you to achieve higher application availability in clustered Linux applications that manage concurrent write operations.
Multi-Attach enabled volumes can be attached to up to 16 Linux instances built on the Nitro System that are in the same Availability Zone.
Multi-Attach is supported exclusively on Provisioned IOPS SSD volumes.
Multi-Attach for io2 volumes is available in all Regions that support io2 volumes.
Multi-Attach for io1 volumes is available in the following Regions only: us-east-1, us-west-2, eu-west-1, and ap-northeast-2.
Multi-Attach enabled volumes can't be attached to R5b instances.
Standard file systems, such as XFS and EXT4, are not designed to be accessed simultaneously by multiple servers, such as EC2 instances.
Multi-Attach enabled volumes do not support I/O fencing. I/O fencing protocols control write access in a shared storage environment to maintain data consistency. Your applications must provide write ordering for the attached instances to maintain data consistency.
Multi-Attach enabled volumes can't be created as boot volumes.
Multi-Attach enabled volumes can be attached to one block device mapping per instance.
Multi-Attach can't be enabled during instance launch using either the Amazon EC2 console or RunInstances API.
Multi-Attach enabled volumes that have an issue at the Amazon EBS infrastructure layer are unavailable to all attached instances.
Issues at the Amazon EC2 or networking layer might impact only some attached instances.
For io2 you can't enable or disable Multi-Attach while the volume is attached to an instance.
Elastic Volumes are supported on the following instances: All current-generation instances, and The following previous-generation instances: C1, C3, CC2, CR1, G2, I2, M1, M3, and R3.
Linux AMIs require a GUID partition table (GPT) and GRUB 2 for boot volumes that are 2 TiB (2,048 GiB) or larger.
There are limits to the maximum aggregated storage that can be requested across volume modifications. For more information, see Amazon EBS service quotas.
The new volume size cannot exceed the supported volume capacity. For more information, see Constraints on the size and configuration of an EBS volume.
You can't use Elastic Volume operations to modify the volume type of Multi-Attach enabled io2 volumes.
You can't use Elastic Volume operations to change the volume type, size, or Provisioned IOPS of Multi-Attach enabled io1 volumes.
If the volume was attached before November 3, 2016 23:40 UTC, you must initialize Elastic Volumes support.
A gp2 volume that is attached to an instance as a root volume cannot be modified to an st1 or sc1 volume. If detached and modified to st1 or sc1, it cannot be attached to an instance as the root volume.
A gp2 volume cannot be modified to an st1 or sc1 volume if the requested volume size is below the minimum size for st1 and sc1 volumes.
In some cases, you must detach the volume or stop the instance for modification to proceed. If you encounter an error message while attempting to modify an EBS volume, or if you are modifying an EBS volume attached to a previous-generation instance type, take one of the following steps:
For a non-root volume, detach the volume from the instance, apply the modifications, and then re-attach the volume.
For a root (boot) volume, stop the instance, apply the modifications, and then restart the instance.
After provisioning over 32,000 IOPS on an existing io1 or io2 volume, you may need to do one of the following to see the full performance improvements:
Detach and attach the volume.
Restart the instance.
Decreasing the size of an EBS volume is not supported. However, you can create a smaller volume and then migrate your data to it using an application-level tool such as rsync.
Modification time is increased if you modify a volume that has not been fully initialized.
After modifying a volume, wait at least six hours and ensure that the volume is in the in-use or available state before making additional modifications to the same volume
While m3.medium instances fully support volume modification, m3.large, m3.xlarge, and m3.2xlarge instances might not support all volume modification features.
A gp2 root volume can be modified to an EBS Provisioned IOPS SSD (io1) after stopping the instance.
GP2 volume attached to an instance as a non-root volume can be modified to a Throughput Optimized HDD (st1) volume without stopping the instance or detaching the volume.
EBS-Backed Linux AMI can be created from the instance directly or from the EBS snapshot.
By default, EC2 shuts down the instance, takes snapshots of any attached volumes, creates and registers the AMI, and then reboots the instance.
A snapshot is constrained to the region where it was created, and you can use it to create new volumes in the same region.
You can also copy snapshots across regions, making it possible to use multiple regions for geographical expansion, data center migration, and disaster recovery.
Shut down & Reboot of the Instance can be prevented using the No reboot option, however the file system integrity of the created image can’t be guaranteed.
EC2 creates snapshots of the instance’s root volume and any other EBS volumes attached to your instance.
If any volumes attached to the instance are encrypted, the new AMI only launches successfully on instances that support Amazon EBS encryption.
While data on EBS volumes persists, the Instance-store volumes specified in the block device mapping for the new instance are new and don’t contain any data from the instance store volumes of the instance you used to create the AMI.
Its more efficient to create an EBS-backed AMI with EBS snapshots already taken as the snapshot created during AMI creation is just an incremental one.
You are charged for the storage of both the AMI and the snapshots.
AMIs that are backed by Amazon EBS snapshots can take advantage of Amazon EBS encryption.
Snapshots of both data and root volumes can be encrypted and attached to an AMI.
An unencrypted snapshot is restored to an unencrypted volume, unless encryption by default is enabled, in which case all the newly created volumes will be encrypted.
An encrypted snapshot that you own is restored to a volume that is encrypted to the same CMK.
Snapshot launch with no encryption parameters; An unencrypted snapshot is restored to an unencrypted volume, unless encryption by default is enabled, in which case all the newly created volumes will be encrypted.
An encrypted snapshot that you do not own (i.e., the AMI is shared with you) is restored to a volume that is encrypted by your AWS account's default CMK .
Instance launch behaviors with Encrypted set, but no KmsKeyId specified. An unencrypted snapshot is restored to an EBS volume that is encrypted by your AWS account's default CMK. An encrypted snapshot that you own is restored to an EBS volume encrypted by the same CMK.
By default, without explicit encryption parameters, a RunInstances action maintains the existing encryption state of an AMI's source snapshots while restoring EBS volumes from them.
To maintain the lowest cost for Amazon Elastic Block Store snapshots while giving you the ability to restore data fully, you need maintain a single snapshot: the latest snapshot is both Incremental and complete.
When you create an encrypted EBS volume and attach it to a supported instance type, the following types of data are encrypted:
Data at rest inside the volume
All data moving between the volume and the instance
All snapshots created from the volume
All volumes created from those snapshots
You need to dowload your instance and upload in S3 to create the AMI.
First you need to select an AMI #1 similar to what you want to have your new AMI #2, create an instance, and after that create a bundle.
The process to create the files to upload in S3 is "Bundle the Instance". Which consists of an image manifest (image.manifest.xml) and files (image.part.xx) that contain a template for the root volume.
Upload the bundle to your Amazon S3 bucket and register the Instance Store-backed AMI.
Charges are incurred for rhe storage space used by the bundle in Amazon S3 until deleted.
Charges are incurred on the AMI created and they can be deregistered, if not needed.
Deregistering an AMI does not delete the EBS snapshots or the bundles in the S3 buckets and have to be removed separately.
Once deregistered, new instances cannot be launched from the AMI. However, it does not impact already created instances from the AMI.
EC2 Instance types determines the hardware of the host computer used for the instance.
Each instance type offers different compute, memory, and storage capabilities and are grouped in instance families based on these capabilities.
EC2 shares other resources of the host computer, such as the network and the disk subsystem, among instances.
Some Instance types support only HVM virtualization type while others support both the PV and HVM virtualization types. AWS, recommends using HVM for taking advantage of the underlying hardware
All the instances are available in a VPC, however, few instance types are not available in an EC2-classic. AWS recommends VPC to take advantage of enhanced networking, multiple IP addresses, finer security control etc.
Some Instances types support only EBS volumes, while others support both EBS and Instance store volumes. Some instances that support instance store volumes use solid state drives (SSD) to deliver very high random I/O performance.
Some instances can be launched as EBS optimized instances with a dedicated capacity for Amazon EBS I/O.
Some instances can be launched in placement group for to optimize instances for High Performance Computing .
Some instance support Enhanced Networking, to get significantly higher packet per second (PPS) performance, lower network jitter, and lower latencies.
Some Instances allow EBS volumes to be encrypted.
EBS-optimized instance uses an optimized configuration stack and provides additional, dedicated capacity for EBS I/O.
EBS-optimized instances enable you to get consistently high performance for the EBS volumes by eliminating contention between EBS I/O and other network traffic from the instance.
With options between 500 Mbps and 4,000 Mbps, depending on the instance type you use.
When attached to an EBS–optimized instance, General Purpose (SSD) volumes are designed to deliver within 10 percent of their baseline and burst performance 99.9 percent of the time in a given year, and Provisioned IOPS (SSD) volumes are designed to deliver within 10 percent of their provisioned performance 99.9 percent of the time in a given year.
EBS optimization can be enabled for an instance that is not EBS–optimized, by default.
General-purpose instances with burstable performance
T2 instances are designed to provide moderate baseline performance and the capability to burst to significantly higher performance as required by your workload.
Mainly intended for workloads that don’t use the full CPU often or consistently, but occasionally need to burst.
For general purpose workloads, such as web servers, developer environments, remote desktops and small databases.
Websites, web applications, build servers, code repos, microservices, test, staging, and dev environments, business applications
Requirements can be launched only with HVM AMI, into a VPC only, as EBS-backed instances only, are available as On-Demand or Reserved instances, but do not allow spot instances, by default 20 (soft limit) T2 instances can run simultaneously, cannot be launched as a Dedicated instance.
CPU Credits (Similar to I/O Credits in case of the EBS general purpose storage) provides the performance of a full CPU core for one minute.
One CPU credit is equal to one vCPU running at 100% utilization for one minute. for e.g. you can have One vCPU running at 100% for One minute OR One vCPU running @ 50% for 2 minutes OR Two vCPU running @ 25% for 2 minutes.
T2 instances provide a baseline level of CPU performance, while CPU governs the ability to burst above the baseline level.
Each T2 instance receives a healthy initial credit balance for startup performance
Initial CPU credits do not expire, but they are used first when an instance uses CPU credits.
Each T2 instance then continuously (at a millisecond-level resolution) receives a set rate of CPU credits per hour, depending on instance size for e.g. t2.nano earns 3/hour while a t2.large earns 36/hour
Each T2 instance accumulates the CPU credit when it uses fewer CPU resources than its allowed baseline performance levels.
Maximum earned credit balance for an instance is equal to the number of CPU credits received per hour times 24 hours for e.g. t2.nano can earn max 72 (24 * 3) credits.
CPU credit balance is available for a period of 24 hours and it expires 24 hours after they were earned. Expired credits are removed from the balance before new ones are added.
CPU credit cease to persist between an instance stop – start.
However, after the start, the instance receives the initial CPU credits again.
When credit balance is completely exhausted, the instance will perform at its baseline performance.
General-purpose instances
Small and mid-size databases, data processing tasks that require additional memory, caching fleets, backend SAP servers, Microsoft SharePoint, cluster computing, other enterprise applications
Compute-optimized instances.
C4 instances are ideal for compute-bound applications that benefit from high performance processors.
Well suited for Batch processing workloads, Media transcoding, High-traffic web servers, massively multiplayer online (MMO) gaming servers, and ad serving engines.
High-performance web servers, high-performance computing, scientific modeling, distributed analytics, machine/deep learning inference, ad serving, highly scalable multiplayer gaming, video encoding.
Features are EBS-optimized by default, can be enabled for Enhanced Networking capabilities, can be in a placement group.
Requires 64-bit HVM AMI, VPC only.
GPU instances provide high parallel processing capability.
Instances optimized for graphics-intensive applications
Well suited for to accelerate many scientific, engineering, and rendering applications by leveraging the Compute Unified Device Architecture (CUDA) or OpenCL parallel computing frameworks, graphics applications, including game streaming, 3-D application streaming, and other graphics workloads.
3D visualizations, graphics-intensive remote workstations,, video encoding, other server-side graphics workloads.
Requires HVM AMI, can’t access GPU unless NVIDIA drivers installed.
Features; can be in a placement group.
I2 instances are optimized to deliver tens of thousands of low-latency, random I/O operations per second (IOPS) to applications.
Instances backed with Non-Volatile Memory Express (NVMe) SSDs, optimized for low-latency, very high random I/O performance, and high sequential read throughput.
For applications NoSQL databases (for example, Cassandra and MongoDB), Clustered databases, Online transaction processing (OLTP) systems.
In-memory databases (e.g. Aerospike), scale-out transactional databases, data warehousing, Elasticsearch, and analytics workloads.
Features; Primary data storage is SSD-based instance storage, can be enabled for Enhanced Networking, can be in a placement group, can enable EBS–optimization.
Requires HVM AMI, HI1 is the equivalent previous generation instance (PV and HVM).
D2 instances are designed for workloads with very high storage density and that require high sequential read and write access to very large data sets on local storage.
Lowest price-per-disk throughput performance on Amazon EC2.
Instances are backed by HDD-based local storage.
For applications massive parallel processing (MPP) data warehouse, MapReduce and Hadoop distributed computing, Log or data processing applications.
Features; primary data storage is HDD-based instance storage, are EBS-optimized by default, can be enabled for Enhanced Networking, can be in a placement group.
Requires 64-bit HVM AMI, HS1 is the equivalent previous generation instance (supports both EBS and Instance store, PV and HVM)
Instances with high-performance memory.
R4 instances are optimized for memory-intensive applications and offer better price per GiB of RAM than R3.
Large in-memory databases, including production deployments of SAP HANA, in the cloud.
High-performance databases, data mining and analytics, distributed web scale in-memory caches, applications performing real-time processing of unstructured big data, Hadoop/Spark clusters, and other enterprise data applications
Features:
High Frequency Intel Xeon E5-2686 v4 (Broadwell) processors
DDR4 Memory
Support for Enhanced Networking
Instances with extremely large amounts (up to almost 4 TB) of high-performance memory
In-memory databases (SAP HANA), big data processing engines (Apache Spark or Presto)
General-purpose GPU compute instances
Machine learning, deep learning, high-performance computing, computational fluid dynamics, computational finance, seismic analysis, speech recognition, autonomous vehicles, pharmaceutical discovery.
Instances with customize-able hardware acceleration with field-programmable gate arrays (FPGAs).
Genomics research, financial analytics, real-time video processing, big data search and analysis, and security analytics.
Instances with high disk throughput.
Applications that require low cost, high disk throughput and high sequential disk I/O access to very large data sets.
Applications requiring sequential access to large amounts of data on direct-attached instance storage .
Applications that require high-throughput access to large quantities of data
Amazon EMR-based workloads, distributed file systems such as HDFS and MapR-FS, network file systems, log or data processing applications such as Apache Kafka, big data workload clusters
Ways to pay for the EC2 instances Dedicated, On-Demand Instances, Reserved Instances, Spot Instances, and Saving Plans
EC2 Dedicated Instances; run in a VPC on hardware that’s dedicated to a single customer isolated from instances that belong to other AWS accounts.
Provide an extra level of hardware isolation compared to normal instances.
Instance-level isolation from other AWS accounts
Per-instance billing
No visibility of sockets, cores, and host ID.
Host and instance affinity not supported.
Targeted instance placement not supported
Automatic instance recovery supported
Bring Your Own License (BYOL) not supported
Each VPC has a related instance tenancy attribute, and can’t be changed after the VPC has been created. Default is shared
Each instance launched into a VPC has a tenancy attribute, can’t be changed after the instance is launched. Default tenancy depends on the VPC tenancy.
Dedicated Instances "can be launched"; using create the VPC with the instance tenancy set to dedicated, all instances launched into this VPC are Dedicated Instances even though if you mark the tenancy as shared, "or" create the VPC with the instance tenancy set to default, and specify dedicated tenancy for any instances that should be Dedicated Instances when you launch them.
Provide an extra level of hardware isolation compared to normal instances.
Physical server (host)-level isolation from other AWS accounts
Per-host billing
Visibility of sockets, cores and host ID
Allows you to consistently deploy your instances to the same physical server over time
Provides additional visibility and control over how instances are placed on a physical server
Automatic instance recovery not supported
Bring Your Own License (BYOL) supported
Dedicated Instances (left) give you instance-level isolation, but Dedicated Hosts (right) give you host-level isolation.
Pay for compute capacity per second or by the hour, depending on OS , with no long-term commitments or up-front payments.
No long-term commitments
No upfront payments
Instances can be scaled accordingly as per the demand.
There might be instances during peak demand where the instance cannot be launched.
Well suited for; save cost and have flexibility of Amazon EC2 without any up-front payment or long-term commitment, Applications with short term, spiky, or unpredictable workloads that cannot be interrupted. Applications being developed or tested on Amazon EC2 for the first time.
Savings Plans is a flexible pricing model that helps you save up to 72 percent on Amazon EC2, AWS Fargate, and AWS Lambda usage.
Savings Plans provides you lower prices for your Amazon EC2 usage, Fargate, and Lambda in exchange for a commitment to a consistent usage amount (measured in $/hour) for a one or three year term.
You can purchase Savings Plans from any account, management account or member account. The Savings Plans will first apply to usage in the account that owns the plan, and then apply to usage in other accounts in the AWS Organization.
Every type of compute usage has an On-Demand rate and a Savings Plans rate. For example, if you commit to $10/hour of compute usage, your usage is charged at your Savings Plans rate up to $10. Any usage beyond your Savings Plans commitment is charged at your regular On-Demand rates.
You can pay for your commitment using All Upfront, Partial upfront, or No upfront payment options.
Compute Savings Plans provide the most flexibility and prices that are up to 66 percent off of On-Demand rates. These plans automatically apply to your EC2 instance usage, regardless of instance family (for example, M5, C5, etc.), instance sizes (for example, c5.large, c5.xlarge, etc.), Region (for example, us-east-1, us-east-2, etc.), operating system (for example, Windows, Linux, etc.), or tenancy (for example, Dedicated, default, dedicated host). They also apply to your Fargate and Lambda usage.
EC2 Instance Savings Plans provide savings up to 72 percent off On-Demand, in exchange for a commitment to a specific instance family in a chosen AWS Region (for example, M5 in Virginia). These plans automatically apply to usage regardless of size (for example, m5.xlarge, m5.2xlarge, etc.), OS (for example, Windows, Linux, etc.), and tenancy (Host, Dedicated, Default) within the specified family in a region.
Pre-pay for capacity
Can be shared between multiple accounts
Provides lower hourly running costs by providing a billing discount as well as capacity reservation that is applied to instances and there would never be a case of insufficient capacity from AWS.
Best suited if consistent, heavy, use is expected and they can provide savings over owning your own hardware or running only On-Demand instances.
Well Suited for Applications with steady state, predictable usage, reserved capacity. Users able to make upfront payments to reduce their total computing costs even further.
Reserved instance is not a physical instance that is launched
Reserved Instances do not renew automatically, and the EC2 instances can be continued to be used but charged On-Demand rates.
Pay upfront with three different methods
Standard Reserved Instances (RIs): Provide the most significant discount; best suited for ready state usage; least flexible type of RI.
Convertible RIs: Moderate discount; able to change the attributes of the RI.
Schedule RIs: RIs that launch in a time window of your choice, allowing you to match your capacity needs
Auto Scaling or other AWS services can be used to launch the On-Demand instances that use the Reserved Instance benefits
You pay for the entire term, regardless of the usage, and once purchased, the reservation cannot be cancelled but can be sold in the Reserved Instance Marketplace.
Reserved Instance pricing tier discounts only apply to purchases made from AWS, and not to the third party Reserved instances.
Payment options: No Upfront (No upfront payment is required and the account is charged on a discounted hourly rate for every hour, regardless of the usage, and only available as 1-year reservation), Partial Upfront (A portion of the cost is paid upfront and the remaining hours in the term are charged at an hourly discounted rate, regardless of the usage), and Full Upfront (Full payment is made at the start of the term, with no costs for the remainder of the term, regardless of the usage).
Reservations and discounted rates only apply to one instance-hour per hour. Example: "If the instance restarts during one hour and again the next hour before running the remainder of the reservation, one instance-hour is charged at the On-Demand rate but the discounted rate is applied to previous and subsequent instance-hours".
Pricing benefits of Reserved Instances are shared when the purchasing account is part of a set of accounts billed under one consolidated billing payer account .
Consolidated billing account aggregates the list value of member accounts within a region.
When the list value of all active Reserved Instances for the consolidated billing account reaches a discount pricing tier, any Reserved Instances purchased after this point by any member of the consolidated billing account are charged at the discounted rate.
Buying Reserved Instances need selection of Platform, Instance Type, Availability Zone, Term (time period), Tenancy (dedicated or shared), and Offering (No Upfront, Partial Upfront, All Upfront) .
Reserved Instances can be modified and continue to benefit from your capacity reservation, when the computing needs change.
Modification does not change the remaining term of your Reserved Instances; their end dates remain the same.
Complete reservation or a subset of it can be modified in one or more of the following ways:
Switch Availability Zones within the same region
Change between EC2-VPC and EC2-Classic
Change the instance size within the same instance type, given the instance size footprint remains the same for e.g. four m1.medium instances (4 x 2), you can turn it into a reservation for eight m1.small instances (8 x 1) and vice versa. However, you cannot convert a reservation for a single m1.small instance (1 x 1) into a reservation for an m1.large instance (1 x 4)
Enable you to purchase capacity reservations that recur on a daily, weekly, or monthly basis, with a specified start time and duration, for a one-year term.
Scheduled Instances are a good choice for workloads that do not run continuously, but do run on a regular schedule . Terminates them 3 minutes before the time period ends, and cannot be stopped of rebooted, however they can be terminated and relaunched.
Scheduled Reserved instances limits or restrictions; after purchase cannot be modified, canceled or resold, only supported instance types: C3, C4, M4, and R3, required term is 365 days (one year), minimum utilization is 1,200 hours per year, and purchase up to three months in advance.
Enables bidding on unused EC2 instances, and are launched whenever the bid price exceeds the current market spot price.
EC2 sets up the hourly price which fluctuates depending upon the demand and supply of spot instances.
Spot instances are a cost-effective choice and can bring the EC2 costs down significantly.
Spot instances can be used for applications flexible in the timing when they can run and also able to handle interruption by storing the state externally for e.g. they are well-suited for data analysis, batch jobs, background processing, and optional tasks.
Well Suited for; Applications with flexible start and end times, applications that are only feasible at very low compute prices, users with urgent computing needs for large amounts of additional capacity.
Spot instances they are not launched immediately,they can be terminated anytime, prices vary as per the demand and supply of spot instances.
Usual strategy involves using Spot instances with On-Demand or Reserved instances.
Spot instances can also be launched with a required duration (also known as Spot blocks), which are not interrupted due to changes in the Spot price.
EC2 provides a data feed, sent to an S3 bucket specified during subscription, that describes the Spot instance usage and pricing.
T2 and HS1 instance class types are not supported for Spot instances.
Spot pool – Pool of EC2 instances with the same instance type, availability zone, operating system and network platform.
Spot price – Current market price of a spot instance per hour as set by Amazon EC2 based on the last fulfilled bid.
Spot bid – is the maximum bid price the bidder is willing to pay for the spot instance
Spot fleet – is the set of instances launched based on the criteria the bidder.
Spot instance interruption – EC2 terminates the spot instances whenever the bid price is lower than the current market price or the supply has reduced.
Bid status – provides the current state of the spot bid.
If the bid price exceeds the current market spot price, the request is fulfilled by Amazon till either the spot instance is terminated or the spot price increases beyond the bid price.
Everyone pays the same market price for the period irrespective of the bid price given the bid price is more than the spot price for e.g. if the spot price is $0.20 and there are 2 bids from Customers with bid price $0.25 and $0.30, both customers would still pay $0.20 only.
If the Spot instance is terminated by Amazon, you are not billed for the partial hour. However, if the spot instance are terminated by you, you will be charged for the partial hour.
Spot instances with a predefined duration use a fixed hourly price that remains in effect for the Spot instance while it runs.
EC2 can interrupt the Spot instance when the Spot price rises above your bid price, when the demand for Spot instances rises, or when the supply of Spot instances decreases.
When EC2 marks a Spot instance for termination, it provides a Spot instance termination notice, which gives the instance a two-minute warning before it terminates.
Termination notice warning is made available to the applications on the Spot instance using an item in the instance metadata termination-time attribute http://169.254.169.254/latest/meta-data/spot/termination-time and includes the time when the shutdown signal will be sent to the instance’s operating system.
Relevant applications on Spot Instances should poll for the termination notice at 5 second intervals, giving it almost the entire two minutes to complete any needed processing before the instance is terminated and taken back by AWS.
EBS-backed instance if it is a Spot instance cannot be stopped and started, but only rebooted or terminated.
Best Practice: Choose a reasonable bid price, which is low enough to suit your budget and high enough for the request to be fulfilled.
Best Practice: Ensure the instances are up and ready as soon as the request is fulfilled, by provisioning an AMI with all the required softwares and load application data from user data.
Best Practice: Store important data regularly and externally in a place that won’t be affected by Spot instance termination for e.g., use S3, EBS, or DynamoDB.
Best Practice: Divide the work into smaller finer tasks so that they can be completely and state saved more frequently.
Best Practice: Use Spot termination notice warning to monitor instance status regularly.
Best Practice: Test applications using On-Demand instances and terminating them to ensure that it handles unexpected termination gracefully.
"Pending": When the instance is first launched.
"Running": After Pending and the charges are incurred every hour.
"Start" (EBS-backed instances only): Receive a new host. Any data on an instance store volume (not root volume) would be lost while data on the EBS volume persists. EC2 instance retains its private IP address as well as the Elastic IP address. Public IP address would be released. Charges for full hour are incurred for every transition from stopped to running.
"Stop" (EBS-backed instances only): Charges are only for the EBS storage and not for the instance hourly charge or data transfer. You can treat its root volume like any other volume, and modify it. Volume can be detached from the stopped instance, and attached to a running instance, modified, detached from the running instance.
"Rebooted": EBS and Instance store instances can be rebooted. An instance retains it public DNS, public and private IP address during the reboot. Data on the EBS and Instance store volume is also retained. Amazon recommends to use Amazon EC2 to reboot the instance instead of running the operating system reboot command.
"Instance retirement": An instance is scheduled to be retired when AWS detects irreparable failure of the underlying hardware hosting the instance. It is stopped or terminated by AWS. If the root device is an Amazon EBS volume, can be started the instance again at any time.
"Instance Termination": Enters into the shutting-down. After an instance is terminated, it can’t be connected and no charges are incurred. Data on Instance store volume data does not persist.
EBS-backed instance supports "InstanceInitiatedShutdownBehavior" attribute which determines whether the instance would be stopped or terminated when a shutdown command from the instance itself for e.g. shutdown, halt or poweroff. Default behaviour for the the instance to be stopped.
A shutdown command for an Instance store-backed instance will always terminate the instance.
Termination protection ("DisableApiTermination" attribute) prevent instance from being accidently terminated. Instance can be terminated through Amazon EC2 CLI. Does not work for instances when: part of an Autoscaling group, Spot instances, initiating shutdown from the instance.
EBS volume have a DeleteOnTermination attribute to persist or delete the volume when an instance is terminated. Root volume has "true" (delete the volume) by default, additional EBS volumes attached has "false" (no delete the volume) by default.
Instance metadata and user data can be used for Self Configuration allowing EC2 instance answer the question Who am I ? What should I do ?
Data is not protected by cryptographic method.
Data is available from the IP address 169.254.169.254 and has the latest as well as previous versions available.
Can be retrieved using simple curl or GET command and these requests are not billed
Answer the What should I do?
Tt's supplied when launching a EC2 instance and executed at boot time.
User data can be in the form of parameters or user defined script executed when the instance is launched .
User data can be used to build more generic AMIs which can then be configured at launch time dynamically.
Can be retrieved from http://169.254.169.254/latest/user-data.
Executed only at the launch of the instance.
If you stop an instance, modify the user data, and start the instance, the new user data is not executed automatically.
Treated as opaque data and returned as is.
User data is limited to 16 KB. This limit applies to the data in raw form, not base64-encoded form.
User data must be base64-encoded before being submitted to the API. The EC2 command line tools perform the base64 encoding for you.
Cloud-Init and EC2Config provides the ability to parse the user-data script on the instance and run the instructions.
Cloud-Init; Amazon Linux (Linux, Ubuntu, RHEL) AMI supports Cloud-Init, built by Canonical. User data is executed on first boot using Cloud-Init if the user data begins with #!.
EC2Config; installed on Windows Server AMIs, User data is executed on first boot using Cloud-Init (technically EC2Config parses the instructions) if the user data begins with <script> or <powershell>. It performs tasks during initial instance startup (once) and each time you stop and start the instance. It can also perform tasks on demand.
EC2Config; uses settings files (EC2ConfigService\Settings) to control its operation, and runs Sysprep, a Microsoft tool that enables you to create a customized Windows AMI that can be reused.
Placement group determines how instances are placed on underlying hardware
AWS provides three types of placement groups:
Cluster – clusters instances into a low-latency group in a single AZ
Partition – spreads instances across logical partitions, ensuring that instances in one partition do not share underlying hardware with instances in other partitions.
Spread – spreads instances across underlying hardware
Ensure unique Placement group name within AWS account for the region.
Placement groups cannot be merged
An instance can be launched in one placement group at a time.
Instances with a tenancy of host cannot be launched in placement groups.
is a logical grouping of instances within a single Availability Zone
Amazon tries to put the instances in the same rack o closer between them.
Recommended for applications that benefits from low network latency (10 Gbps network), high network throughput, or both.
Choose an instance type that supports enhanced networking, to ensure enough capacity.
Instances can be added later, but there are chances of encountering an insufficient capacity error.
Stopping and starting the instance still runs in the same placement group.
In case of an capacity error, stop and start all of the instances in the placement group, and try the launch again. Restarting the instances may migrate them to hardware that has capacity for all requested instances.
Supported by Specific instance types (General Purpose, GPU, Compute, Memory, Storage Optimized – c4.8xlarge, c3.8xlarge, g2.8xlarge, i2.8xlarge, r3.8xlarge, m4.10xlarge, d2.8xlarge) which support 10 Gigabyte network.
Maximum network throughput speed of traffic between two instances is limited by the slower of the two instances.
Traffic to and from S3 buckets within the same region over the public IP address space or through a VPC endpoint can use all available instance aggregate bandwidth.
Recommended to use the same instance type.
Network traffic to the internet and over an AWS Direct Connect connection to on-premises resources is limited to 5 Gbps.
Itis a group of instances spread across partitions.
Partitions are logical groupings of instances, where contained instances do not share the same underlying hardware across different partitions.
To spread deployment of large distributed and replicated workloads, such as HDFS, HBase, and Cassandra, across distinct hardware to reduce the likelihood of correlated failures.
Can have a maximum of seven partitions per Availability Zone (with Dedicated Instances can have a maximum of two partitions). and can span multiple Availability Zones in the same Region.
They are not supported for Dedicated Hosts, are currently only available through the API or AWS CLI.
Tt's a group of instances that are each placed on distinct underlying hardware.
Recommended for applications that have a small number of critical instances that should be kept separate from each other.
Reduces the risk of simultaneous failures when instances share the same underlying hardware.
Can span multiple AZs, and can have a maximum of seven running instances per AZ per group.
If the start fails , the request can be tried later as EC2 makes more distinct hardware available over time.
They are not supported for Dedicated Instances or Dedicated Hosts.
Enables migration of VMs to EC2, or create a repository of VM images for backup and disaster recovery.
You can import a VM from a virtualization environment to EC2 as an Amazon Machine Image (AMI), EC2 instance (Stopped), disks as Amazon EBS snapshots .
The supported file formats are: VMware ESX VMDK images, Citrix Xen VHD images, Microsoft Hyper-V VHD images, and RAW images.
For VMware vSphere, AWS Connector for vCenter can be used to export a VM from VMware and import it into Amazon EC2.
For Microsoft Systems Center, AWS Systems Manager for Microsoft SCVMM can be used to import Windows VMs from SCVMM to EC2.
Enhanced networking results in higher bandwidth, higher packet per second (PPS) performance, lower latency, consistency, scalability and lower jitter.
Use single root I/O virtualization (SR-IOV) only on supported instance types.
SR-IOV is a method of device virtualization which provides higher I/O performance and lower CPU utilization.
Amazon Linux AMIs and Windows Server 2012 R2 AMI already have the module installed with the attributes set and does not require any additional configurations.
It can be enabled for other OS distributions by installing the module with the correct attributes configured.
VPC, as enhanced networking can’t be enabled for instance in EC2-Classic.
We need an HVM virtualization type AMI
We must to have Linux kernel version of 2.6.32+, Windows: Server 2008 R2+.
Appropriate Virtual Function (VF) driver; Linux – should have the ixgbevf module (for best performance version 2.14.2 or higher) installed and that sriovNetSupport attribute set for the instance. Windows- Intel 82599 Virtual Function driver.
Supported instance types i.e. C3, C4, D2, I2, M4 and R3.
All the EC2 instance types can be launched in a VPC
Instance types C4, M4 & T2 are available in VPC only.
Assign static private IP addresses to instances that persist across starts and stops.
Assign multiple IP addresses to your instances.
Define and attach one or more network interfaces to the instances.
Change security group for the instances while they’re running.
Control the outbound traffic from the instances (egress filtering) in addition to controlling the inbound traffic to them (ingress filtering)
Add an additional layer of access control to your instances in the form of network access control lists (ACL).
You can run the instances on single-tenant dedicated hardware.
Private IP address is the IP address that’s not reachable over the internet, and will be assigned from the address range of the subnet. Remains associated with the Instance when it is stopped or rebooted.
When an instance is launched, the default network interface eth0 is assigned a private IP address and an internal DNS hostname.
An additional private IP addresses, known as secondary private IP addresses can also be assigned. can be reassigned from one instance to another.
A public IP address is reachable from the Internet
Each instance assigned a public IP address is also given an External DNS hostname.
Public IP address is associated with the primary Private IP address through NAT.
An instance may or may not be assigned a public IP address depending upon the subnet Assign Public IP attribute.
Public IP address assigned to the pool is from the public IP address pool and is assigned to the instance. It's not assigned if there are more than one network interface attached to the instance.
Public IP cannot be manually associated or disassociated with an instance, and is released when an instance is stopped, terminated, is assigned an Elastic IP address.
Stopped instance when started receives a new public IP address
In EC2-VPC, multiple private IP addresses can be specified to the instances. Useful to host multiple websites on a single server, using multiple SSL certificates, operate network appliances with multiple private IP's, redirect internal traffic to a standby instance in case the instance fails.
Secondary IP address can be assigned to any network interface, which can be attached or detached from an instance.
Secondary IP address must be assigned from the CIDR block range of the subnet for the network interface.
Security groups apply to network interfaces and not to IP addresses.
Secondary private IP addresses can be assigned and unassigned to ENIs attached to running or stopped instances.
Secondary private IP addresses that are assigned to a network interface can be reassigned to another one if you explicitly allow it.
Primary private IP addresses, secondary private IP addresses, and any associated Elastic IP addresses remain with the network interface when it is detached from an instance or attached to another instance.
Although primary network interface cannot be moved from an instance, the secondary private IP address of the primary network interface can be reassigned to another network interface.
When an instance is launched in the default vpc, it is assigned 2 IP address, a private and a public IP address, which is mapped to the private IP address through NAT.
An instance launched in a non default vpc is assigned only a private IP address unless a public address is specifically requested or the subnet public ip attribute is enabled.
To get the private and public IP addresses, you can run the following commands on the running instance.
http://169.254.169.254/latest/meta-data/local-ipv4
http://169.254.169.254/latest/meta-data/public-ipv4
The changes when EC2 instances move from Running state to Hibernate and back to Running state: Only Public IPv4 is allocated with new IP while Private IPv4 and any IPv6 are retained.
Maximum Transmission Unit (MTU) of a network connection is the size, in bytes, of the largest permissible packet that can be transferred over the connection.
Largest ethernet packet size supported over most of the internet is 1500 MTU.
All Amazon EC2 instance types support 1500 MTU, and many current instance sizes support 9001 MTU, or Jumbo frames.
Compute optimized: C3, C4, CC2
General purpose: M3, M4, T2
GPU: CG1, G2
Memory optimized: CR1, R3
Storage optimized: D2, HI1, HS1, I2
Jumbo frames are Ethernet frames that allow more than 1500 bytes of data by increasing the payload size per packet, and thus increasing the percentage of the packet that is not packet overhead.
Jumbo frames should be used with caution for Internet-bound traffic or any traffic that leaves a VPC. Packets are fragmented by intermediate systems, which slows down this traffic.
For instances that are collocated inside a placement group, jumbo frames help to achieve the maximum network throughput possible, and they are recommended in this case.
An Elastic Fabric Adapter (EFA) is a network device that you can attach to your Amazon EC2 instance to accelerate High Performance Computing (HPC) and machine learning applications.
EFA enables you to achieve the application performance of an on-premises HPC cluster, with the scalability, flexibility, and elasticity provided by the AWS Cloud.
It is optimized to work on the existing AWS network infrastructure and it can scale depending on application requirements.
EFA integrates with Libfabric 1.11.1 and it supports Open MPI 4.0.5 and Intel MPI 2019 Update 7 for HPC applications, and Nvidia Collective Communications Library (NCCL) for machine learning applications.
It provides all of the functionality of an ENA, with an additional OS-bypass functionality.
OS-bypass is an access model that allows HPC and machine learning applications to communicate directly with the network interface hardware to provide low-latency, reliable transport functionality.
p4d.24xlarge instances support up to four EFAs. All other supported instance types support only one EFA per instance.
EFA OS-bypass traffic is limited to a single subnet. In other words, EFA traffic cannot be sent from one subnet to another. Normal IP traffic from the EFA can be sent from one subnet to another.
EFA OS-bypass traffic is not routable. Normal IP traffic from the EFA remains routable.
The EFA must be a member of a security group that allows all inbound and outbound traffic to and from the security group itself.
EFA traffic between C6gn instances and other EFA-enabled instances is not supported.
EFA must be a member of a security group that allows both inbound and outbound traffic.
Amazon cloud watch metrics are required to monitor EFA in Real-Time.
To log in to an EC2 instance, a key pair needs to be created and specified when the instance is launched, and the private key can be used to connect to the instance.
Linux instances have no password, and the key pair is used for ssh log in.
For Windows instances, the key pair can be used to obtain the administrator password and then log in using RDP.
EC2 stores the public key only, and the private key resides with the user. EC2 doesn’t keep a copy of your private key.
Keys can be downloaded in pem to save the private key in a format that is used with OpenSSH.
Keys can be downloaded in ppk to save the private key in a format that is used with PuTTY.
Set chmod 400 for set read access to the keys.
Public key content (on Linux instances) is placed in an entry within ~/.ssh/authorized_keys at boot time and enables the user to securely access the instance without passwords.
Public key specified for an instance when launched is also available through its instance metadata http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key.
Best Practice: Store the private keys in a secure place as anyone who possesses the private key can decrypt the login information.
If the private key is lost, there is no way to recover the same.
For instance store, you cannot access the instance.
For EBS-backed Linux instances, access can be regained.
EBS-backed instance can be stopped, its root volume detached and attached to another instance as a data volume
Modify the authorized_keys file, move the volume back to the original instance, and restart the instance
Key pair associated can be: Generated by Amazon EC2 ( Keys that Amazon EC2 uses are 2048-bit SSH-2 RSA keys), Created separately (using third-party tools) and Imported into EC2 ( EC2 only accepts RSA keys and does not accept DSA keys, with supported lengths: 1024, 2048, and 4096s)
You can have up to five thousand key pairs per region.
Deleting a key pair only deletes the public key and does not impact the servers already launched with the key
An EC2 instance, when launched, can be associated with one or more security groups with the instance, which acts as a virtual firewall that controls the traffic to that instance.
Security groups are associated with network interfaces. Changing an instance’s security groups changes the security groups associated with the primary network interface (eth0).
An Network interface can be associated with 5 security groups and with 50 rules per security group.
Rules for a security group can be modified at any time; the new rules are automatically applied to all instances associated with the security group.
Also, If your instance (host A) initiates traffic to host B and uses a protocol other than TCP, UDP, or ICMP, your instance’s firewall only tracks the IP address and protocol number for the purpose of allowing response traffic from host B. If host B initiates traffic to your instance in a separate request within 600 seconds of the original request or response, your instance accepts it regardless of inbound security group rules, because it’s regarded as response traffic.
EC2 partially supports resource-level permissions. For some EC2 API actions, you cannot specify which resource a user is allowed to work with for that action; instead, you have to allow users to work with all resources for that action
IAM allows to control only what actions a user can perform on the EC2 resources but cannot be used to grant access for users to be able to access or login to the instances.
EC2 instances can be launched with IAM roles so that the applications can securely make API requests from your instances.
IAM roles prevents the need to share as well as manage, rotate the security credentials that the applications use.
As per the latest enhancement from AWS, IAM role can be added to an existing running EC2 instance.
EC2 uses an instance profile as a container for an IAM role.
To launch an instance with an IAM role, the name of its instance profile needs to be specified.
An application on the instance can retrieve the security credentials provided by the role from the instance metadata item http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name.
Security credentials are temporary and are rotated automatically and new credentials are made available at least five minutes prior to the expiration of the old credentials.
Best Practice: Always launch EC2 instance with IAM role instead of hardcoded credentials.
Status monitoring help quickly determine whether EC2 has detected any problems that might prevent instances from running applications.
EC2 performs automated checks on every running EC2 instance to identify hardware and software issues.
Status checks are performed every minute and each returns a pass or a fail status.
If all checks pass, the overall status of the instance is OK, and If one or more checks fail, the overall status is Impaired.
Status checks are built into EC2, so they cannot be disabled or deleted.
Alarms can be created, or deleted, that are triggered based on the result of the status checks. for e.g., an alarm can be created to warn if status checks fail on a specific instance.
System Status Checks; monitor the AWS systems required to use your instance to ensure they are working properly, and detect problems with the instance that require AWS involvement to repair.
When a system status check fails, one can either ; wait for AWS to fix the issue "or" resolve it by by stopping and restarting or terminating and replacing an instance
System status checks failure might be cause of
Loss of network connectivity
Loss of system power
Software issues on the physical host
Hardware issues on the physical host
Instance Status Checks: monitor the software and network configuration of the individual instance, and checks detect problems that requires involvement to repair.
When an instance status check fails, it can be resolved by either rebooting the instance "or" by making modifications in the operating system
Instance status checks failure might be cause of
Failed system status checks
Misconfigured networking or startup configuration
Exhausted memory
Corrupted file system
Incompatible kernel
CloudWatch, helps monitor EC2 instances, which collects and processes raw data from EC2 into readable, near real-time metrics.
Statistics are recorded for a period of two weeks, so that historical information can be accessed and used to gain a better perspective on how the application or service is performing.
By default Basic monitoring is enabled and EC2 metric data is sent to CloudWatch in 5-minute periods automatically.
Detailed monitoring can be enabled on EC2 instance, which sends data to CloudWatch in 1-minute periods.
Aggregating Statistics Across Instances/ASG/AMI ID are available with detailed monitoring (at an additional charge) enable, which provides data in 1-minute periods.
CloudWatch does not aggregate data across Regions.
CloudWatch returns statistics for all dimensions in the AWS/EC2 namespace, if no dimension is specified. Does not work for custom namespaces published to CloudWatch, in this case you need to specify the dimension information.
Statistics include Sum, Average, Minimum, Maximum, Data Samples.
CloudWatch alarms; can be created to monitor any one of the EC2 instance’s metrics.
can be configured to automatically send you a notification when the metric reaches a specified threshold.
can automatically recover an EC2 instance when the instance becomes impaired due to an underlying hardware failure a problem that requires AWS involvement to repair.
can automatically stop or terminate the instances to save costs (EC2 instances that use an EBS volume as the root device can be stopped or terminated, whereas instances that use the instance store as the root device can only be terminated)
can use EC2ActionsAccess IAM role, which enables AWS to perform stop, terminate, or reboot actions on EC2 instances
If you have read/write permissions for CloudWatch but not for EC2, alarms can still be created but the stop or terminate actions won’t be performed on the EC2 instance.
EC2 Metrics
CPUCreditUsage: (Only valid for T2 instances) The number of CPU credits consumed during the specified period. CPU Credit metrics are available at a 5 minute frequency.
CPUCreditBalance: (Only valid for T2 instances) The number of CPU credits that an instance has accumulated. Used to determine how long an instance can burst beyond its baseline performance level at a given rate. Available at a 5 minute frequency.
CPUUtilization; % of allocated EC2 compute units that are currently in use on the instance.
DiskReadOps; Completed read operations from all instance store volumes available to the instance in a specified period of time.
DiskWriteOps; Completed write operations to all instance store volumes available to the instance in a specified period of time.
DiskReadBytes; Bytes read from all instance store volumes available to the instance. This can be used to determine the speed of the application.
DiskWriteBytes; Bytes written to all instance store volumes available to the instance. This can be used to determine the speed of the application.
NetworkIn; The number of bytes received on all network interfaces by the instance.
NetworkOut; The number of bytes sent out on all network interfaces by the instance.
NetworkPacketsIn; The number of packets received on all network interfaces by the instance. This metric is available for basic monitoring only
NetworkPacketsOut; The number of packets sent out on all network interfaces by the instance. This metric is available for basic monitoring only.
StatusCheckFailed; Reports if either of the status checks, StatusCheckFailed_Instance and StatusCheckFailed_System, that has failed. Values for this metric are either 0 (zero -pass) or 1 (one - failure). Status check metrics are available at 1 minute frequency.
StatusCheckFailed_Instance; Reports whether the instance has passed the Amazon EC2 instance status check in the last minute. Values for this metric are either 0 (zero -pass) or 1 (one - failure). Status check metrics are available at 1 minute frequency.
StatusCheckFailed_System; Reports whether the instance has passed the EC2 system status check in the last minute. Values for this metric are either 0 (zero -pass) or 1 (one - failure). Status check metrics are available at 1 minute frequency.
You can use Amazon Data Lifecycle Manager to automate the creation, retention, and deletion of EBS snapshots and EBS-backed AMIs. When you automate snapshot and AMI management, it helps you to:
Protect valuable data by enforcing a regular backup schedule.
Create standardized AMIs that can be refreshed at regular intervals.
Retain backups as required by auditors or internal compliance.
Reduce storage costs by deleting outdated backups.
Create disaster recovery backup policies that back up data to isolated accounts.
One thing to note is that the DLM policy has used Tags to choose EBS volumes.
You can create up to 100 lifecycle policies per Region.
Copying a snapshot to a new Region is commonly used for geographic expansion, migration, disaster recovery, etc.
EBS snapshots' lifecycle policies contain some rules. One of the rules is that when you copy a policy's snapshot, the new copy is not influenced by the retention schedule.
Verify the Security groups are properly configured to allow ssh access from the ip to the EC2 instance. For Security groups, Inbound traffic from the public ip address should be enabled.
Verify the NACLs are properly configured to allow ssh access from the ip to the EC2 instance. For NACLs, Inbound traffic from the public ip address should be enabled as well as the Outbound traffic for the response should be enabled.
Verify you are using the private key file that corresponds to the key pair that you selected when you launched the instance.
Verify you are connecting with the appropriate user name for your AMI.
Private User key file is not recognized by the Server.
Implement the least permissive rules for your security group.
Regularly patch, update, and secure the operating system and applications on your instance.
Launch your instances into a VPC instead of EC2-Classic.
Manage access to AWS resources and APIs using identity federation, IAM users, and IAM roles.
Establish credential management policies and procedures for creating, distributing, rotating, and revoking AWS access credentials.
EC2 supports Instance store and EBS volumes, so its best to understand the implications of the root device type for data persistence, backup, and recovery.
Use separate Amazon EBS volumes for the operating system (root device) versus your data.
Ensure that the data volume (with your data) persists after instance termination.
Use the instance store available for your instance to only store temporary data.
If you use instance store for database storage, ensure that you have a cluster with a replication factor that ensures fault tolerance.
Use instance metadata and custom resource tags to track and identify your AWS resources.
View your current limits for Amazon EC2. Plan to request any limit increases in advance of the time that you’ll need them.
Regularly back up your instance using Amazon EBS snapshots (not done automatically) or a backup tool.
Data Lifecycle Manager (DLM) to automate the creation, retention, and deletion of snapshots taken to back up the EBS volumes.
Implement High Availability by deploying critical components of the application across multiple Availability Zones, and replicate the data appropriately.
Monitor and respond to events.
Design your applications to handle dynamic IP addressing when your instance restarts.
Implement failover. For a basic solution, you can manually attach a network interface or Elastic IP address to a replacement instance.
Regularly test the process of recovering your instances and Amazon EBS volumes if they fail.
Disable root access to AMI; modify sshd_config
Disable unauthorized public ssh keys.
sudo find / -name "authorized_keys" -print -exec cat {} \;