When I made the jump from Frontend Developer to Full Stack Engineer the go-to solution was for many reason Serverless.
I loved it. Everything was... so simple! Need a REST API? ApiGateway + Lambda, there you have it immediately working for your React frontend.
Docker, Instances, Servers, Networks and Subnets on the other end, felt so cumbersome, and being a self taught dev, imposter syndrome immediately kicked in, and all this put me off for quite a while.
After evaluating both serverless and EC2 and having some experience with both worlds, I can still say I prefer Serverless, but I am not so scared by Compute Cloud anymore.
Don't let you be put off, hopefully these write-up help breaking the initial barrier and learning curve!
So, What is Cloud Computing?
Cloud Computing is the on-demand delivery of IT resources over the Internet with pay-as-you-go pricing. Instead of buying, owning, and maintaining physical data centers and servers, you can access technology services, such as computing power, storage, and databases, on an as-needed basis from a cloud provider like Amazon Web Services (AWS).
What is EC2?
EC2 (Elastic Cloud Compute) allows you to launch as many or as few virtual servers as you need, configure security and networking, and manage storage. Amazon EC2 enables you to scale up or down to handle changes in requirements or spikes in popularity, reducing your need to forecast traffic.
Concepts and terms
The EC2 service can be broken down into the following components:
- AMIs,
- Instance types,
- tenancy,
- user data,
- storage options
- security,
- instance purchasing options.
AMI
Amazon Machine Images are essentially templates of preconfigured EC2 instances.
They provide the necessary configuration to launch an Instance such as:
- Launch permissions
- Elastic Block Stores snapshots or a template for the root volume ( like OS, and applications)
- a block device mapping specifying the volumes to attach when instance is launched
AMI are regional but can be copied to other regions.
(more here)
AWS provides lots of different AMIs (Linux, Redhat, Windows but you can also launch an instance from an existing AMI, customise the instance (for example, installing software on it), and then save this updated configuration as a custom AMI.
Instance Type
Once you have chosen what type of AMI you need, the next step is specifying the instance type.
Instance type defines the hardware profile and costs based on (among others) the following characteristics:
- EC2 Computer Units
- Virtual CPUs
- Physical processor
- Memory
- Storage
- Network performance
- Processor Architecture
Instance types are grouped into family types that offer distinct performance benefits.
Purchasing Options
On Demand Instances
standard rate, no-commitment, no discount
good for short-term or unpredictable workloads which can't be interrupted.Reserved Instances
1 or 3 year commitment --> up to 75% discount (depending if All/Partial/No Upfront)
Reserved Instances can be Standard or Convertible (which can change Family, OS , tenancy and payment option, on top of AZ, instance size, networking type)Scheduled Reserved Instances
You can reserve instances that can be used on a recurring schedules. Min 1200 hours per year, can be used for reporting apps, running at regular intervals ( like min 6h-a day 4 days a week) - They are currently deprecatedSpot Instances
Bid for unused capacity, up to 90% discount BUT they can be terminated at any time.
Useful for workloads with flexible start and end times, for Cost-sensitive workloads that can afford to be interrupted.Dedicated Instances
Physical isolation at the host hardware level from instances of other AWS customers!
Pay per instanceDedicated Hosts
Physical server dedicated for you.
Full visibility of sockets and cores and targeted instance placement.
Pay per host.
Useful for workloads with server bound software licenses (like applications that use per-socket licensing).Saving Plans
Commitment to a consistent amount of usage
Pay by $/h - Require a commitment of 1-3 years Fargate, Lambda and EC2 and in case of EC2 only within selected region and Instance Family.
Within these purchasing options there are differences also in the way they are billed:
- Amazon Linux and Ubuntu in OnDemand, Reserved and Spot-Instances are billed per second (min 1 minute)
- Windows and Commercial Linus are billed per hour ( min 1 hour)
- EBS Volumes are billed per second ( min 1 minute)
Some more info about purchasing and billing worth mention is that you could create fleet of instances that are Spot/OnDemand :
- Spot fleet - launches and maintains Spot/OnDemand instances at a specified capacity 2.EC2 Fleet - launches and maintains Spot/OnDemand instances at a specified capacity in a single API call
With Spot Instances your instance can be terminated at any time and you just get a warning just 2 minutes before via Cloudwatch Events; even though savings are less ( 30-45% less than on-demand instead of up to 90% ) you could use SpotBlock to request for uninterrupted period of times.
The main point is that you can mix and match based on your Requirements (and budget):
For example if your application has bursts of traffic and needs to scale for a short period you could use Reserved Instances for the minimum required workload and get Spot instances for the bursts ( remember these are cheaper and can be terminated by AWS at any time)
Storage Options
Storage can be Persistent or Ephemeral.
Persistent storage is achieved by attaching EBS ( Elastic Block Store ) volumes to the instance.
In case of Ephemeral storage, local storage of the instance is used, therefore when the instance is stopped data saved on disk is lost.
User Data
User Data is basically a script (Limited to 16KB) that is run when instance is launched.
You normally use it to install stuff on your instance and start.
It is available at http://169.254.169.254/latest/user-data
Instance Metadata
returns information about your instance.
at http://169.254.169.254/latest/meta-data you can get a list of available properties that can be can queried (like public-ipv4 or ami-id etc)
Security
Security Groups
During the creation of an instance you will be asked to select a Security Group which is nothing else than a virtual firewall that controls incoming and outgoing traffic.
Inbound and Outbound rules control the flow of traffic to and from your instance.
It determines the protocols that we can use to connect to our instance.
For example SSH on port 22 with a Source 0.0.0.0/0 means any address
HTTP on port 80 will allow connection from a Browser or any HTTP client.
Network ACLs
A network access control list (NACL) is an additional way to control traffic in and out of one or more subnets.
They will be probably covered in other posts.
Key Pairs
You can securely connect to EC2 Instances (via SSH on Linux AMIs for example) using a key pair ( a public key stored by AWES and a private key file stored by you).
Key Pairs are not the AccessKey and SecretKey that you use to programmatically access AWS services!
To connect to an instance you have 3 options:
- UI Console (not much to say, here, besides logging in AWS Console, going to your instance and click connect)
- SSH Client
- EC2 Instance Connect
UI Console is useful to get the pre-populated commands to connect to our instance via SSH Client.
Public IPv4 address and Public IPv4 DNS are used (as the name suggest) to connect to the instance from outside, from the internet. While the 2 private addresses are only for internal use.
You will need the PEM file that was created when the instance was launched.
For remote administration of course the SSH Client connection is the way to go.
Accessing Services
If you need your Instance to be able to interact with other AWS Services ( like a Dynamo Table or an S3 Bucket you need to grant permissions to your instance.
This can happen through Access Keys or Instance Profile.
Access Keys
Access Keys are key-value pairs that are configured on the instance (very similar as you save yours on your computer ) and they are associated with an IAM account which has a policy that defines the permissions o
Access Keys will pick up those permissions and EC2 will use them.
Since they are stored on the instance it is not a very secure way to grant your instance access to other services (in case the instance is compromised, anyone can then use those access keys (it is as simple as typing cat ~/.aws/credentials)
Do not store Access Keys on your instances!
Instance Profile
The instance has a IAM Role attached to it, by assuming the Role EC2 can get access to any service and action specified by the policy attached to that role, without anything being stored on the instance.
(you can have a look at my previous post about IAM to understand better the concepts of Users Roles and Policies)
Placement Groups
Placement groups are the way that you can control how AWS deploys your EC2 instances and places them within or across Availability Zones.
Cluster
Instances are packet close together inside an availability zone. this enables workload to achieve low-latency network performance necessary for tightly-coupled node-to-node communication typical of HPC application (High Performance Computing).
Partition
Instances are spread across logical partitions.
Instances in different partitions do not share the same underlying hardware. this approach is used by large distributed and replicated workloads ( like Hadoop, Cassamdra and Kafka)
Each partition is located on a separate AWS Rack, and there can be up to 7 partition per AZ.
Spread
Similar to Partition but instances are strictly placed in small groups across distinct underlying hardware. Each Instance is located on a separate AWS Rack.
Network Interfaces and Adapters
An elastic network interface is a logical networking component in a VPC that represents a virtual network card.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html
Each instance has a default network interface, called the primary network interface. You cannot detach a primary network interface from an instance. You can create and attach additional network interfaces.
Each network interface is attached to a network card.
Instances with multiple network cards provide higher network performance, including bandwidth capabilities above 100 Gbps and improved packet rate performance.
ENI - Elastic Network Interface
A basic adapter for when you don't any high-performance requirements.
It can be used with all instance types
ENA Elastic Network Adapter
has enhanced networking performance
Higher bandwidth and lower inter-instance latency.
It can be used only with supported instance types.
EFA Elastic Fabric Adapter
More advanced, good for HPC (Hight Performance Computing) , MPI and ML use cases.
Useful for applications that are tightly coupled, have a lot of interconnectivity between components of the application, that require very low latency, and are therefore also close to each other (see above)
It can be used with all instance types.
ENI and EIP (Elastic IP Address) can be remapped to a different instance within the same Subnet.
Public, Private and Elastic IPs
Private IPs are static and can be used in private and public subnets.
Public addresses can be used on Public Subnets only and are dynamic addresses, this means they
change every time you stop and restart your instance. (if instance is simply rebooted - public address is preserved)
If you need to reference in your application code the public address, then you need an Elastic IP address which is static and will always stay the same.
Elastic IPs are static public addresses and do not change when instance is stopped.
They are, as the public address, associated with a private IP address on the instance but can be moved between instances and ENAs.
Elastic IP Addresses can be remapped across Zones.
One thing to remember is that they are charged once created, even if they are not mapped to an instance and being used. aws docs
Bastion Hosts
Public Subnets have public IP and can communicate with the outside world through Internet gateway.
Private subnets cannot, that's why they are private in the end, they have no route and no public IP address.
But we can somehow make possible that an instance in a private subnet communicates with the outside world via so-called Bastion Hosts.
Basically we have one instance in the Public Subnet which has a route table association with the Internet Gateway (which allows bidirectional communication with outside world). That will act as a Jump Server to then establish the connection (via SSH or RDP) with the instances in the Private Subnet.
Since we don't want to store ssh keys on the instance in the public subnet we will need SSH Agent forwarding so that our PEM certificate on our machine is used when we ssh into the instance in the Public subnet, and forwarded it to connect to the instance in the private subnet.
NAT for Private Addresses and Outbound communication
We use NAT ( Network Access Translation) adapter to allow private instances to have outbound communication with the outside world ( we don't have inbound communication - otherwise we would as well have public subnets).
If you run ipconfig on the instance, you can only see the private address, because the public address is associated to the adapter.
The internet gateway - see graph above - performs NAT.
NAT Instances
NAT instances are simply EC2 instances with a specific configuration ( they were used before NAT Gateways).
NAT instances uses a special AMI (`amzn-ami-wpc-nat" and must have source/destination checks disabled.
They are managed by you (A NAT instance does not provide high availability or scale automatically) can be used as Bastion Hosts.
NAT Gateway
is a more modern way of doing things.
It's fully managed by AWS and you get scalability up to 45 Gbps, and provides higher availability.
They do not support port forwarding and cannot be used as bastion hosts.
You cannot attach an Internet gateway to a private subnet. Internet Gateways are attached to VPCs and entries are added to route table in public subnets.
A NAT Gateway provides high availability and automatic scaling. You attach a NAT Gateway to a public subnet and then add a route to it in the private subnet. By doing this the private instances can have internet connectivity.
EC2 Lifecycle
Rebooting - Data on Instance Store Volume is preserved but RAM is erased. There are no changes in billing by the hour.
IP addresses (Private, Elastic and Public) are all retained.
Stopping and Hybernating are only possible on EBS Backed instances
When stopping instances we are not charged for the stopped instances - but we are charged for the EBS volumes.
Data is erased from Instance Store Volume, as well from RAM.
Private IP address (and Elastic ones) are retained, while public IP is released.
Hybernating, similar behaviour to Stopping but contents of RAM are saved to EBS volume. Apply to on-demand or reserved Linux instances.
When restarted after hybernation RAM content is reloaded, EBS volume is restored and processes are resumed.
Terminating means deleting an instance, Data is erased, RAM is erased, Volume is deleted. No more charges whatsoever. Instance can't be recovered.
For more details about differences check here
Nitro System
AWS Nitro System is the underlying platform for the next generation of EC2 Instances.
It improves performance, security and innovation.
Performance are close to bare metal.
Its benefits are
- Higher network performance
- High Performance Computing optimizations
- Dense Storage instance options but it does not make an instance have higher availability.
Its key features are:
- Nitro Security Chip
- Nitro Card
- Nitro Hypervisor
- Nitro TPM (rusted Platform Module)
- Nitro Enclaves provide isolated compute environments, it runs on isolated and hardened virtual machines.
Nitro Enclaves have No persistent storage, interactive access or external networking.
They use cryptographic attestation to ensure only authorised code is running and integrates KMS.
For these reasons they are useful to protect and process securely highly sensitive data like PII ( Personally identifiable information), health-care, financial or intellectual property data).
Not all instance types run on Nitro system, so this is something to be taken into account when choosing on what type of instance we want our application to run, based on the requirements.
Monitoring and Health Checks
By default, every EC2 Instance is enabled for basic monitoring which has no charge and runs every 5 minutes.
You can although enable Detailed Monitoring (for extra granularity every 1 minute, and to get aggregated data across groups of similar instances), this will than come with a charge.
Health Checks
Status checks are performed every minute, returning a pass or a fail status.
System Status Checks
System status checks monitor the AWS systems on which your instance runs. Therefore, if the status check fails, it is likely we have not much control of:
- Loss of network connectivity
- Loss of system power
- Software issues on the physical host
- Hardware issues on the physical host that impact network reachability.
We can decide to wait for AWS to resolve the issue, but usually a stop and restart (not simple reboot ) solves the problem because possibly instance is launched on a different physical server.
Instance Status Check
Instance status checks monitor the software and network configuration of our instance, so a failure is something that definitely requires our intervention:
- Misconfigured networking or startup configuration
- Exhausted memory
- Corrupted file system
Ok there is already a massive amount of information here.
More will come in the next posts about Autoscaling groups, Load Balancing and VPCs.
Top comments (3)
Hello Davide, just a quick fix in the EC2 Lifecycle part:
When an instance is rebooted, the public and private IP stay the same.
You are doing a great job with these posts.
Thank you in advance.
thanks for the tip. i need to go through the docs once again then. :-)
will update the post asap
fixed! thanks for noticing and pointing that out!