AMI, EC2 Image Builder, Local EC2 Instance Store, EFS, Shared Responsibility, FSx
AMI
- AMI = Amazon Machine Image
- AMI are a customization of an EC2 instance
- You add your own software, configuration, operating system, monitoring...
- Faster boot/ configuration time because all your software is pre-packaged
- AMI are built for a specific region ( and can be copied across regions)
- You can launch EC2 instances from:
- A public AMI: AWS provided
- Your own AMI: you make and maintain them yourself
- An AWS Marketplace AMI: an AMI someone else made (and potentially sells)
AMI Process (from an EC2 instance)
- Start an EC2 instance and customize it
- Stop the instance (for data integrity)
- Build an AMI - this will also create EBS snapshots
- Launch instances from other AMIs
EC2 Image Builder
- Used to automate the creation of Virtual Machines or container images
- Automate the creation, maintain, validate and test EC2 AMIs
- Can be run on a schedule (weekly, whenever packages are updated, etc....)
- Free service (only pay for the underlying resources)
EC2 Instance Store
- EBS volumes are network drives with good but "limited" performance
- If you need a high-performance hardware disk, use EC2 Instance Store
- Better I/O performance
- EC2 Instance Store lose their storage if they're stopped (ephermeral)
- Good for buffer/ cache/ scratch data/ temporary content
- Risk of data loss if hardware fails
- Backups and Replication are your responsibility
Local EC2 Instance Store
EFS - Elastic File System
- Managed NFS (network file system) that can be mounted on 100s of EC2
- EFS works with Linux EC2 instances in multi-AZ
- Highly available, scalable, expensive (3x gp2), pay per use, no capacity planning
EBS vs EFS
EFS Infrequent Access (EFS-IA)
- Storage class that is cost-optimized for files not accessed every day
- Up to 92% lower cost compared to EFS Standard
- EFS will automatically move your files to EFS-IA based on the last time they were accessed
- Enable EFS-IA with a Lifecycle Policy
- Example: move files that are not accessed for 60 days to EFS-IA
- Transparent to the applications accessing EFS
Shared Responsibility Model for EC2 Storage
- AWS responsibility
- Infrastructure
- Replication for data for EBS volumes & EFS drives
- Replacing faulty hardware
- Ensuring their employees cannot access your data
- User responsibility
- Setting up backup/ snapshot procedures
- Setting up data encryption
- Responsibility of any data on the drives
- Understanding the risk of using EC2 Instance Store
Amazon FSx:
- Launch 3rd party high-performance file systems on AWS
- Fully managed service
- FSx for Lustre
- FSx for Windows File Server
- FSx for NetApp ONTAP
Amazon FSx for Windows File Server
- A fully managed, highly reliable and scalable Windows native shared file system
- Built on Windows File Server
- Supports SMB protocol & Windows NTFS
- Integrated with Microsoft Active Directory
- Can be accessed from AWS or your on-premise infrastructure
Amazon FSx for Lustre
EC2 Instance Storage - Summary
- EBS volumes:
- network drives attached to one EC2 instance at a time
- Mapped to an Availability Zones
- Can use EBS Snapshots for backups / transferring EBS volumes across AZ
- AMI: create ready-to-use EC2 instances with out customizations
- EC2 Image Builder: automatically build, test and distribute AMIs
- EC2 Instance Store:
- High Performance hardware disk attached to our EC2 instance
- Lost if our instance is stopped / terminated
- EFS: network file system, can be attached to 100s of instances in a region
- EFS-IA: cost-optimization storage class for infrequent accessed files
- FSx for Windows: Network File System for Windows servers
- FSx for Lustre: High Performance Computing Linus file system








Comments
Post a Comment