EC2 AMI

As we saw, AWS comes with base images such as:

- ubuntu, fedora, redhat, windows, ets..

 

These images can be customised at runtime using EC2 User data

But what if we could create our own image?

That's an AMI- an image to use to create our instances

AMI can be built for Linux or Windows machines

 

then whay would you use a custom AMI?

- Using a custom built AMI can provide for the following advantages:

a) Pre-installed packages needed

b) Faster boot time(no need for ec2 user data at boot time)

c) Machine comes configured with monitoring / enterprise software

d) Security concerns - control over the machines in the network

e) Control of maintenance and update of AMIs over time

f) Active Directory Integration out of the box

g) Installing your app ahead of time (for faster deploys when auto-scaling)

h) Using someone else's AMI that is optimised for running an app, DB, etc...

 

Using Public AMIs

You can leverage AMIs from other people 

You can also pay for other people's AMI by the hour

a) these people have optimised the software

b) the machine is easy to run and configure

c) you basically rent "expertise" from the AMI creator

 

AMI storage

Your AMI take space and they live in Amazon S3

Amazon S3 is a durable, cheap and resilient storage where most of your backups will live(but you won't see them in the S3 console)

By default, your AMIs are private, and locked for your account / region

You can also make your AMIs public and share them with other AWS accounts or sell them on the AMI Marketplace

 

AMI Pricing

AMI live in Amazon S3, so you get charged for the actual space in takes in Amazon S3

Amazon S3 pricing in US-EAST-1:

 a) First 50TB/ month:$0.023 per GB

 b) Next 450TB / month:$0.022 per GB

Overall it is quite inexpensive to store private AMIs.

Make sure to remove the AMIs you don't use

 

Cross Account AMI Copy (FAQ + Exam Tip)

You can share an AMI with another AWS account

Sharing an AMI does not affect the ownership of the AMI

If you copy an AMI that has been shared with your account, you are the owner of the target AMI in your account

To copy an AMI that was shared with you from another, the owner of the source AMI must grant you read permissions for the storage that backs the AMI, either the associated EBS snapshot (for an Amazon EBS-backed AMI) or an associated S3 bucket (for an instance store-backed-AMI)

Limits:

You can't copy an encrypted AMI that was shared with you from another account. Instead, if the underlying snapshot and encryption key were shared with you, you can copy the snapshot while re-encrypting it with a key of your own. You own the copied snapshot, and can register it as a new AMI

You can't copy an AMI with an associated billingProduct code that was shared with you from another account. This includes Windows AMIs and AMIs from the AWS Marketplace. To copy a shared AMI with a billingProduct code, launch an EC2 instance in your account using the shared AMI and then create an AMI from the instance 

 

Placement Groups

Sometimes you want control over the EC2 Instance placement strategy

That strategy can be defined using placement groups

When you create a placement group, you specify one of the following strategies for the group:

a) Cluster - cluster's instances into a low-latency group in a single Availability Zone

b) Spread - spreads instances across underlying hardware (max 7 instances per group per AZ) - critical applications

c) Partition- spreads instances across many different partitions (which rely on different sets of racks) within an AZ Scales to 100s of EC2 instances per group (Hadoop, Cassandra, Kafka)

 

Cluster 

Pros: Great network (10 Gbps bandwidth between instances)

Cons: If the rack fails, all instances fails at the same time

Use case:

 a) Big Data job that needs to complete fast

 b) Application that needs extremely low latency and high network throughput

 

Spread

Pros:

a) Can span accross Availability Zones(AZ)

b) Reduced risk is stimultaneous failure

c) EC2 Instances are on different physical hardware

 

Cons:

a) Limited to 7 instances per AZ per placement group

 

Use case:

a) Application that needs to maximize high availability

b) Critical Applications where each instance must be isolated from failure from each other

 

Placements Groups Partition

 

a) Up to 7 partitions per AZ

b) Up to 100s of EC2 instances

c) The instances in a partition do not share racks with the instances in the other partitions

d) A partition failure can affect many EC2 but won't affect other partitions

e) EC2 instances get across to the partition information as metadata

 

Use cases: HDFS, HBase, Cassandra, Kafka 

create placement group

 

do creating placement group more.

Configure Instance Details

going to launch as a cluster

 

you can create many instances within placement group