EBS Snapshots | Overview & Hands-On.

An Overview & Hands-On for EBS Snapshots.

Focus,

• Tailored for DevOps.

Breakdown:

• Intro,
• Key Features and How EBS Snapshots Work,
• Common Use Cases,
• Considerations,
• Key Benefits of EBS Snapshots,
• Reasos to detach EBS volume before creating Snapshots (NOT necessary BUT still recommended)
• Architecture of EBS Snapashot
• Best Practices & Summary table of best Practices,
• Cross-Region Snapshots Copy,
• Cross-Account Snapshot Sharing,
• Restore Snapshot to Volume in Target Region/Account,
• How to Handles Encryption for Snapshots,
• How to enable a retention rule before deleting snapshots,
• How to recover deleted volume snapshots from bin (UI & CLI),
• Tips to mitigate Accidental Deletion of Snapshot,
• Quick Overview of AWS Snapshots Tpyes,
• Project: Hands-On,
• twtech Final thoughts.

Intro:

• EBS snapshots are incremental, point-in-time backups of Amazon Elastic Block Store (EBS) volumes, used for data protection, disaster recovery, and data migration within the AWS cloud. The snapshots are stored securely in Amazon S3 for high durability and availability.
• An EBS Snapshot is a point-in-time backup of an Amazon Elastic Block Store (EBS) volume. Snapshots are stored in Amazon S3 (although not directly accessible from S3), and they are used to back up data or create new EBS volumes.
• Snapshots are incremental—only the blocks that have changed since the last snapshot are saved, making them storage-efficient.

Key Features and How EBS Snapshots Work

Incremental Backups:

•  The first snapshot is a full copy of all data blocks written to the volume.
• Subsequent snapshots only save the blocks that have changed since the previous snapshot, making them cost-effective and efficient for regular backups.

Storage:

•  Although stored in Amazon S3, users cannot access the underlying S3 buckets directly via the S3 console or API; management is done through the EC2 console or APIs.

Restoration: 

• A snapshot contains all the information needed to restore a volume to its state at the moment the snapshot was taken. 
• When a new volume is created from a snapshot, data is "lazily loaded" in the background, meaning the volume is available almost immediately, but performance may be impacted for uninitialized blocks until all data is transferred.

Encryption: 

• Snapshots automatically inherit the encryption status of their source volume. Encrypted snapshots use AWS Key Management Service (KMS) for key management, ensuring data security at rest.

Automation:

•  The creation, retention, and deletion of snapshots can be automated using AWS Data Lifecycle Manager (DLM) or AWS Backup, which helps enforce backup policies and manage costs.

Common Use Cases

Disaster Recovery: 

• Snapshots can be copied across Availability Zones and AWS Regions, providing a robust solution for cross-regional disaster recovery.

Data Migration:

•  They facilitate easy migration of data across different regions, accounts, or even from on-premises environments to AWS.

Development and Testing:

•  Snapshots allow developers to create copies of production environments for testing without affecting the live system.

Use Cases summary

• Backup and Restore
• Dev/Test Environment Cloning
• Volume Migration Across AZs or Regions
• Compliance and Audit Readiness
• Data Recovery in CI/CD Pipelines
•  Not necessary to detach volume to do snapshot, but recommended. 

Considerations

Application Consistency:

•  By default, snapshots are crash-consistent, meaning they capture the disk state at a point in time, which may not include data cached in memory by applications. 
• For database-intensive applications, AWS recommends pausing writes, unmounting the volume, or using application-consistent snapshots via AWS Systems Manager (SSM) agent integration to ensure data integrity.

Cost Management:

•  While incremental backups are cost-effective, accumulating numerous snapshots over time can increase costs. 
• Implementing retention policies and using the EBS Snapshot Archive tier for long-term, seldom-accessed data can help optimize expenses. 

Architecture of EBS Snapashots.

 

Key Benefits of EBS Snapshots

Data Backup and Disaster Recovery

• Protects data against accidental deletion, corruption, or failure.
• Can be used to restore EBS volumes quickly in the same or different Availability Zones or regions.

Incremental Backup

• After the first full snapshot, only changed blocks are saved.
• This reduces storage cost and backup time.

Fast Volume Creation

• twtech can launch a new EBS volume from a snapshot in minutes, enabling fast scaling and deployment.

Cross-Region and Cross-Account Copy

• Snapshots can be copied to other AWS regions or shared across AWS accounts.
• Helps with geo-redundancy, compliance, and cross-account workflows.

Automation with Lifecycle Policies

• Use Amazon Data Lifecycle Manager (DLM) to automate snapshot creation, retention, and deletion.
• Simplifies management and ensures compliance with backup policies.

Cost-Efficient

• Because they're incremental, snapshots are more storage-efficient than full disk clones.

Supports Encryption

• Snapshots of encrypted volumes are encrypted.
• twtech can also copy unencrypted snapshots to create encrypted versions, helping with data security and compliance.

Reasons to detach EBS volume before creating Snapshots (NOT necessary BUT still recommended)

 Recommended Because:

Although technically allowed, detaching the volume (or freezing I/O) is recommended for data consistency, especially for:

 File Systems and Databases

• If twtech snapshot a volume while a database or file system is writing data, it may end up with inconsistent or corrupted data (e.g., incomplete transactions, unflushed file system buffers).
• Think of it like pulling a hard drive out of a computer while it's still writing.
• The blocks might be consistent, but logical files or databases might not be accessible.

Not Necessary Because:

Amazon EBS supports online snapshots—twtech can take a snapshot of a volume while it is attached and in use. 

This is possible because:

• The snapshot captures a point-in-time copy of the data blocks.
• AWS ensures crash-consistent snapshots at the block level.
• This means it captures the data as it exists at that moment—even if the volume is actively being written to.

Best Practices:

• Flush I/O buffers (e.g., use fsfreeze on Linux or sync).
• Stop services or pause the application briefly before snapshotting.
• (Optional) detach the volume to ensure no writes occur at all during snapshot.

Summary table of best Practices

Action	Consistency Level	Recommended When
Snapshot attached, active volume	Crash-consistent only	Low-write workloads,  non-critical data
Snapshot after flushing buffers	Application-consistent	Most workloads
Snapshot after detaching volume	Fully consistent	Critical data, databases,  compliance-sensitive backups

Types of EBS Snapshot Migration 1. Cross-Region Snapshot. Copy an EBS snapshot from one AWS Region to another. Benefits: Disaster recovery / backup in a different region Compliance with data residency laws Enable creation of volumes in other regions AWS CLI  #  bash aws ec2 copy-snapshot \   --source-region us-east-2 \   --source-snapshot-id snap-0123456789abcxxxx \   --destination-region us-east-1 \   --description "twtech Copy to us-east-1" 2. Cross-Account Snapshot Sharing Share snapshots with other AWS accounts by modifying snapshot permissions. Benefits: Centralized backup management Sharing data across teams or organizations Migrating workloads between accounts AWS CLI : How twech Makes a snapshot public or share with a specific account: #   bash aws ec2 modify-snapshot-attribute \   --snapshot-id snap-0123456789abcdxxx \   --attribute createVolumePermission \   --operation-type add \   --user-ids accountID NB:  twtech cannot share encrypted snapshots directly unless using an AWS KMS key shared with the target account. 3. Restore Snapshot to Volume in Target Region/Account Once the snapshot is copied/shared, twtech can create a new volume from it: #   bash aws ec2 create-volume \   --snapshot-id snap-abcdef1234567xxx \   --availability-zone us-east-1a \   --volume-type gp3  How twech Handles Encryption for Snapshots twtech can copy encrypted snapshots across regions, but the KMS key must be accessible in the destination region. For cross-account copies of encrypted snapshots: Share the KMS key with the target account. Re-encrypt with a new key during copy if needed. twtech-Best Practices Tag snapshots with metadata (e.g., source, date, purpose). Use automation tools like AWS Data Lifecycle Manager or AWS Backup. Monitor snapshot copy status with CloudWatch or AWS Config. Secure snapshots using encryption and IAM policies. EBS Snapshots Features • twtech may move EBS Snapshot to Archive.(storage for snapshots)   Moving Snapshots to an ”archive” would be 75% cheaper for twtech to manage (cost efficiency)  Sometimes It takes twtech, between  24 up to 72 hours for the EBS Snapshots to be fully restored from the archive.   For safety, twtech always delete EBS Snapshots into a bin, so that  those deleted snapshots may be restored if need arise.  twtech creates retention rules to retain deleted snapshots so they may recover them if accidental deleted  twtech may specify retention period for deleted snapshots from day-1 up to 1 year.  How twtech recovers deleted volume snapshots from bin. Step-by-step: UI & CLI NB: EBS snapshots cannot be recovered once permanently deleted. There is no "Recycle Bin" for snapshots by default ...deletion is immediate and irreversible, unless twtech explicitly enable the AWS Recycle Bin feature before deletion. Step-1: twech Enabled AWS Recycle Bin The concept: AWS Recycle Bin AWS Recycle Bin lets twtech to retain deleted EBS snapshots for a specified time (retention period), even after they are deleted. twtech must enable a retention rule before the deleting snapshots, This Works for any twtech EBS snapshots and AMIs. This allows EBS Snapshots go to a "recoverable" state during the retention period. Step-2:  How twtech Recovers Snapshots from Recycle Bin If a snapshot was deleted after a Recycle Bin rule was applied: GUI Go to EC2 Console → Snapshots Change the filter to: State: recoverable Select the snapshot to restore Click Recover Snapshot Or twtech may use the:  AWS CLI: #  bash  aws rbin restore-snapshot \   --snapshot-id snap-0abcdef12345xxx NB:  This only works if the snapshot is within the retention window.  If Recycle Bin Was Not Enabled Before Deletion There is no way to recover a permanently deleted snapshot. twtech key options: Look for older snapshots or AMIs. Check if AWS Backup was used (which has its own retention). Restore from application-level backups (e.g., RDS snapshots, S3, or database backups).  twtech tips to mitigate Accidental Deletion, Use Recycle Bin retention rules for all snapshots. Tag critical snapshots with "DoNotDelete" and enforce IAM policies. Automate backups with AWS Backup or Lifecycle Manager. Monitor deletions with CloudTrail logs. Quick Overview of AWS Snapshots Types Types of AWS Snapshots In AWS, the term "snapshot" usually refers to backups of data volumes or machine images, but different services support various kinds of snapshots.  Below are the main types categorized by service:  1. EBS Snapshots (Amazon Elastic Block Store) Type: Point-in-time backup of EBS volumes Storage: Stored in Amazon S3 (not user-visible) Features: Incremental Can be encrypted Can be copied across regions/accounts Supports Recycle Bin (optional)  Use case:  Backup EC2 instance storage, DR, cloning environments.  2. EC2 AMI Snapshots Type: Image-based backup that includes EBS snapshot(s) and instance metadata Components: EBS volume snapshots (root + data volumes) Launch config (instance type, networking, permissions, etc.)  Use case: Launch pre-configured EC2 instances from saved images.  3. RDS Snapshots (Relational Database Service) Types: Automated Snapshots: Managed by AWS (retention based on backup window) Manual Snapshots: User-created, retained until explicitly deleted  Use case: Point-in-time recovery of RDS databases.  4. Redshift Snapshots Types: Automated Snapshots Manual Snapshots Can be copied across regions and accounts.  Use case: Backup and restore Redshift data warehouses.  5. Amazon FSx Snapshots Supports snapshots for: Amazon FSx for Windows File Server Amazon FSx for Lustre Amazon FSx for NetApp ONTAP  Use case: File-level recovery or full file system restore.  6. Amazon EFS (Elastic File System) Backup (via AWS Backup) Not snapshots per se, but AWS Backup lets twtech to take scheduled backups (which act like snapshots). twtech can create restore points and recover data to a new file system. Use case: Versioned backup of NFS file systems.  7. AWS Backup Snapshots A centralized backup service that supports: EBS, RDS, DynamoDB, EFS, FSx, EC2, Storage Gateway These backups are policy-driven and stored in a centralized Backup Vault. Use case: Centralized, policy-managed backups across services. Summary Table of AWS snapshot types: Service Snapshot Type Incremental Manual/Auto Cross-Region EBS Volume Snapshots ✅ Yes ✅ Both ✅ Yes EC2 AMI (uses EBS) ✅ Yes ✅ Manual ✅ Yes RDS DB Snapshots ✅ Yes ✅ Both ✅ Yes Redshift Cluster Snapshots ✅ Yes ✅ Both ✅ Yes FSx File System ✅ Yes ✅ Both ✅ Some types EFS Backup via AWS Backup ❌ (not traditional snapshot) ✅ Both ✅ Yes AWS Backup Multi-service Depends on service ✅ Both ✅ Yes Preject: Hands-on How twtech migrates EBS Snaphots to other regions within its AWS Landscape (environment): UI Step-1: twtech Goes to EC2 UI (console) & select:  EBS / Volumes. Step-2: twtech Selects a volume and Create a snapshot ( EBS-twtech-web-server) Assign a description for the EBS Snapshot: twtech-web-server-SnapShot Step-3: twtech Assigns a tag for the snapshots: Let tag describe snapshot Sample Name: twtech-web-server-SnapShot-do-not-delete-april-05-2025 Create Snapshot. Step-4: twtech Verifies that the snapshots has been created. Go to ----->  EC2-menu: navigate to  ----->  Elastic Bock Store, then  ----->  Snapshots More details for the snapshot:  twtech-web-server-SnapShot-do-not-delete-april-05-2025 Step-5: How twtech migrates (copy) snapshot to another region( from: us-east-2 to us-east-1) Copy snapshots to any destination (region) : from us-east-1 (origin) us-east-2 (Destination) Snapshot destination: us-east-1 Encrypt snapshot with kms key: aws default key Step-6: Assign a tag: Name Copied snap-of-twtech-web-server from us-east-2 to us-east-1 april-05-2025 Step-7: twtech Goes to us-east-1 (N Virginia) to verify that twtech-web-server snapshopts were successfully : (migrated from) us-east-2 (Ohio) Yes: successfully the snapshots was migrated from one region to another. Step-8: twtech needs to creates an EBS volume from EBS snapshopts in distination region (N. Virginia), then attached it to an instance in that same AZ. Create volume Select the target Availability Zone (AZ): AZ can be changed From: To: Assign a tag: Name: twtec-web-server-volume-recreated-migrated-from-us-east-2a to us-east-2b Step-9: Verify that twtech-web-server- snapshot from us-east-2a has been use to create a new twtech web-server volume in us-east-2b. Yes: successfully, twtech recreated a volume in another region from snapshots migrated from another region. Step-10: The status of the volume is still Available, and twtech needs to attach it to an instance in the same AZ (us-east-2b) Select the creatd volume, navigate to Action and Attach volume: to an instance Step-11: How twtech protects snapshots with retaintion rule from accidental deletion with:  aws Recycle Bin  Create retention rule Select the resource type for the retaintion rule: EBS Snapshots Add tag: Name: twtech-web-server-SnapShot-do-not-delete-april-05-2025 Retention period: 365 day (1year) Step-12: Rule lock settings  UnLock the retention rule to prevent snapshots from being accidentally or maliciously updated or deleted. Lock setting: unlock means the rule can be later deleted  if no longer needed. Step-13: Add Tag A tag is a label that twtech assigns to an AWS resource.  Each tag consists of a key and an optional value.  twtech can use tags to search and filter its resources or track its AWS costs.  This is the tag for twtech retention rule. Before deleting snapshots,  verify the resources in the Recycle Bin ( twtech-recycle-bin) Step-14: twtech deletes ebs snapshots:  To verify if the snapshots are store in the recycle bin for later recovery (after accidental deletion) Note: If the snapshot is a standard storage tier, it can be move to an archive before deleting.  Once snapshots is archived, it will take 24 up to 72 hours to restore the snapshots. Deleting the snapashops: Confirm deletion: Step-15: twtecn verifies in the AWS Recycle bin ( twtech-recycle-bin) that the snapshots were move to the bin successesfull and should be recoverable (DR) if they were accidentally deleted.  Successfully, the EBS snapshot was deleted and stored in the aws recycle bin:  Step-16: How twtech recovers deleted snapshots from the aws recycle bin. Confirm recovery: From: To: Step-17: NB: twtech deletes snapshots from aws recycle bin finally, Once the retention rule is deleted, the snapshot will have no place to be stored: To Permanently deletes snaphots from the aws recycle bin, twtech must first delete the created retention rule.  Confirm deletion of retention rule: At this point that there is no aws retention rules ( recycle bin) if the snapshots are deleted, that will be permanent  Confirm deletion: Again, Without a retention rule created before deletion of snapshot, that is catastrophic. Permanent deletion. Final takeaway: EBS Snapshot migration generally refers to copying EBS snapshots across AWS regions or accounts.  twtech does this for disaster recovery (DR), multi-region deployment, cost optimization, or compliance. twtech creates retention rule for aws recycle bin before deleting  unwanted snapshots.

AWS Storage Types | Overview & Hands-On.

An Overview & Hands-On for AWS Storage Types.

Focus:

• Tailored for SRE, DevOps, Cloud, and DevSecOps Engineers

Breakdown:

• Intro,
• Amazon Elastic Block Store (EBS),
• Instance Store,
• Amazon Elastic File System (EFS),
• EC2 instance storage types and use-cases,
• Things to keep in mind,
• Insights,
• How to configures & terminate EC2 instance but retains the EBS root volume with its data still intact,
• Project: Hands-On.

Intro:

• AWS offers several storage types for EC2 instances.
• AWS storage types are categorized primarily into block storage, ephemeral local storage, and shared file storage options that can attach to instances. 

The main storage types for EC2 instances are:

Amazon Elastic Block Store (EBS)

•  EBS provides durable, persistent block-level storage volumes that can be attached to a running EC2 instance. 
• The data on an EBS volume persists independently from the life of the instance, even after the instance is stopped or terminated. 
• EBS volumes are highly available and support snapshots and backups, making them suitable for primary storage for databases, enterprise applications, and the root volumes of most instances.
• EBS offers various volume types, including General Purpose SSD (gp3/gp2), Provisioned IOPS SSD (io2/io1), Throughput Optimized HDD (st1), and Cold HDD (sc1), each optimized for specific performance and cost requirements.

Instance Store

•  Instance store provides temporary block storage that is physically located on the host server to which the EC2 instance is attached. 
• This storage delivers very high random I/O performance and low latency, as it is local to the host. 
• However, the data stored on an instance store volume is ephemeral; it is lost if the instance stops, terminates, or if the underlying host hardware fails.
• It is ideal for use cases like temporary cache, scratch data, buffer layers, or any data that can be easily regenerated.

Amazon Elastic File System (EFS)

•  EFS provides a scalable, fully managed network file system that can be shared across multiple EC2 instanc66. 
• It is suitable for scenarios where multiple instances need concurrent access to the same data, such as content management systems, web serving, and shared development environments. 
• While not physically "attached" to a single instance in the same way as EBS or instance store, it is a primary storage option used with EC2. 

In summary, 

• The key difference lies in durability and performance: 
• use EBS for persistent, critical data, instance store for high-performance temporary data. 
• Use EFS for data that needs to be shared across instances.

EC2 instance storage types and use-cases.

1. Instance Store (ephemeral storage)

• Temporary, local storage physically attached to the EC2 host.
• Data is lost if the instance stops or is terminated.
• Use case: Temporary storage needs like caching or scratch data.

 2. Amazon EBS (Elastic Block Store)

• Durable, persistent storage that attaches to EC2 instances.
• Can store OS, databases, or application data.
• Data remains even after stopping or terminating the instance (if not deleted).
• Use case: Boot volumes, databases, critical app storage.

 3. Amazon EFS/NFS (Elastic File System/Network file system)

• Shared file system that can be accessed by multiple EC2 instances.
• Scales automatically as files grow.
• Use case: Shared access for web servers, CMS, or analytics pipelines.

Things to keep in mind

•  Know the difference between temporary (Instance Store) and persistent (EBS/EFS) storage.
• Know when to use block storage (EBS) vs. file storage (EFS).
• Recognize that Instance Store is not durable and is not used for critical data.
• know that EBS volumes are bound to a specific availability zone.
• twtech EBS Volume in us-east-2a cannot be attached to us-east-1b.
• Thererfore, twtech considers an ebs volume as a “network USB stick”.
• twtech can have Free tier for up to 30 GB of free EBS storage of type General Purpose (SSD) or Magnetic per month.
• EBS is a network drive (it is not a physical drive).
• The ebs volume uses the network to communicate between instances, and that accounts for the reasons behind latency.
• twtech may detached its ebs volume from an EC2 instance and attached to another in the same AZ.
• twtech uses snapshots to move a volume across.
• The ebs volume has a provisioned capacity of size in GBs, or IOPS.

A. GBs (Gigabytes per second)

• Meaning:A measure of data trangfer speed—how fast data can be read from or written to a storage device.
• Example: If a drive has a speed of 2 GB/s, it can transfer 2 gigabytes of data every second.
• Use case: Important for tasks like copying large files, streaming high-resolution video, or loading big databases quickly.

B. IOPS (Input/Output Operations Per Second)

• Meaning: A measure of how many individual read/write operations a storage system can handle per second.
• Example: A drive with 10,000 IOPS can process 10,000 read or write commands each second.
• Use case: Crucial for workloads with lots of small, random reads/writes, like databases or high-traffic web servers.

NB:

•  twtech is billed for its provisioned ebs volumes.
•  twtech may decide to increase ( Scale up/out)  or decrease (Scale down/in)  the capacity of the drive over time
• twtech may apply vertically Scaling (same volume) or horizontally Scaling (different  volumes). 

NB:

• Instance Volume can be manage under Advance-Settings.
• By default, Instance storage is deletes on termination of EC2 instance. 

NB

• Other volumes created (custom volumes) and attached to an instance is not deleted on termination of instance (No).
• Custom volumes must be manually released via AWS console and  CLI.

Insights:

 1. Instance Store (Ephemeral Storage)

Key Traits:

• Physically attached to the host computer.
• High IOPS, low latency.
• Data is lost when the instance stops, hibernates, or terminates.
• Cannot be detached or moved between instances.

 Use Cases:

• Temporary data like cache, buffers, scratch data, or temporary logs.
• Applications with high-speed, short-term storage needs (e.g., video processing, batch jobs).
• High-performance NoSQL databases where persistence is handled elsewhere.

2.    Elastic Block Store (Amazon EBS)

Key Traits:

• Network-attached, persistent block storage.
• Survives instance stop/start/termination (if not explicitly deleted).
• Can be snapshotted, resized, and attached/detached from instances.
• Supports encryption and backup.

Types of EBS volumes:

Type	Key Feature	Use Case
gp3 / gp2	General Purpose SSD	Boot volumes, dev/test workloads
io2 / io1	Provisioned IOPS SSD	Databases like MySQL, PostgreSQL, Oracle
st1	Throughput Optimized HDD	Big data, data warehouses, log processing
sc1	Cold HDD	Infrequently accessed, low-cost storage

Use Cases:

• Boot volumes, application storage.
• Databases, transactional systems, persistent volumes.
• Systems that need durability and reliability.

 3. Amazon EFS (Elastic File System) – Not EC2-specific, but often used with EC2

Key Traits:

• Fully managed, elastic NFS file system.
• Accessible by multiple EC2 instances across AZs.
• Scales automatically.

Use Cases:

• Shared file storage across EC2 instances.
• CMS systems, web servers, data science pipelines.
• Applications needing a common file system.

4. Amazon FSx – File storage optimized for specific workloads (e.g., FSx for Windows, Lustre)

Storage Type	Persistent	Performance	Use Cases
Instance Store	❌ No	Very high	Cache, temp files, scratch data
EBS (gp3/io1/st1)	✅ Yes	Medium to high	Boot, databases, general workloads
EFS	✅ Yes	Shared, scalable	Shared file systems, multi-AZ access
FSx	✅ Yes	Specialized	Windows apps, HPC, Lustre file systems

• How twtech configures and terminate its EC2 instance but retains the EBS root volume with its data still intact.

Step-by-Step in the AWS Console:

1. Go to the EC2 Dashboard.
2. Select the instance you want to terminate.
3. Click the "Actions" dropdown, then go to:
• Instance settings → Change Termination Protection → Make sure it's disabled (select: NO).
4. Now go to:
• Actions → Instance settings → Change root volume delete behavior.
5. Uncheck the box “Delete on termination” for the root volume (usually /dev/xvda or /dev/sda1).
• Or go to Volumes, find the root volume attached to the instance, and:
• Select it → Actions → Modify Volume Attachment → Uncheck "Delete on termination".
6. Click Save.
7. Now terminate the instance:
• Actions → Instance State → Terminate instance.

Notes:

• After termination, the root EBS volume will remain in twtech account, and twtech can later:
• Attach it to another EC2 instance.
• Create a snapshot or AMI from it.
• Mount it as a secondary volume to inspect or recover data.

 CLI Equivalent:

twtech can also use the AWS CLI Configure Termination Protection:

#   bash

aws ec2 modify-instance-attribute \

    --instance-id i-xxxxxxxxxxxxxxxxx \

    --block-device-mappings "[{\"DeviceName\":\"/dev/xvda\",\"Ebs\":{\"DeleteOnTermination\":false}}]"

# Then terminate the instance:

#  bash 

aws ec2 terminate-instances --instance-ids i-xxxxxxxxxxxxxxxxx

Project: Hands-On

How twtech creates an ebs volume and attach it to an instance.

Step-1:

Go EC2 console and navigate to elastic block store, then: volumes

• us-east-2 is selected because it  corresponds to zone where the instance is located. ( same AZ)

• Add tags

• Create volume:

Step-2:

• Attach volume to instance in the same AZ. Make sure the state is:  available.

• Select the instance and device name to attach volume to:

Step-3:

Verify that the volume has been attached to the instance:

Successfully, twtech-web-server storage has been horizontally scaled (another volume added)

Step-4:

• How twtech detaches and delete unwanted ebs volumes that is attached to an instance:
• First: Detach volume from instance

• Confirm to detach:

Step-5:

• Next. Delete the detached volume: refresh the page if need be.

• Confirm and detete volume:

Step-5:

• If twtech terminates an instance, the root volume is destroyed because by default delete on termination is set: YES.
• This can also be set to, (if need be) to : No (root-volume will not be deleted on termination of instance)

• But the default ebs volume remains available.
• Verify that the instance (twtech-webserver) has only the root volume still attached:
• Yes,