AWS EC2 Instance Lifecycle (On-demand)
Refer Here for official docs
Azure VM states
Refer Here for official docs
Disk Related Options in AWS EC2
- In AWS we have virtual disks managed by EBS Volumes and Instance Storage
- Data in instance storage will be erased when you stop instance
- AWS uses EBS volumes for persistence even after ec2 is stopped or terminated
- In AWS only few instance types support instance storage
Disk Related Options in Azure VM
- In Azure we have virtual disks managed by Managed Disk and Temp Disk (Local storage)
- Data in local storage will be erased when you stop instance
- Azure uses Data Disks (Managed disks) for persistence even after vm is stopped or deleted
- In Azure many instance sizes come with local storage and information is present in vm size detailing
- Azure has a restriction on number of disks according to vm size
Agents in Azure VM
- Azure VM will have an inbuilt agent running inside vms
- Linux VM Agents Refer Here
- Windows VM Agents Refer Here
Activity 1 – lost pem file Azure
- Ensure you create a new pem file from ssh keys
- Now use this pem for azure vm (ubuntu)
- delete the pem file from your local system (simulating loss)
- We can recover from this using the inbuilt agent
Activity 2 – lost pem file AWS
- Create a new key pair
- use this for ec2 instance (ubuntu)
- delete the pem file from local system (simulating loss)
Method 1: Using a Helper Instance
- Stop the EC2 Instance: Begin by stopping the instance for which you lost the PEM file. Ensure that you do not terminate it, as this would result in data loss.
- Detach the Volume: Go to the AWS Management Console, navigate to EC2, and select “Volumes” under “Elastic Block Store.” Find the root volume associated with your stopped instance and detach it.
- Create a Helper Instance: Launch a new EC2 instance (referred to as the “helper instance”) in the same region and VPC as the original instance. This instance should have its own PEM file for access.
-
Attach the Detached Volume: Attach the detached volume from your original instance to the helper instance as a secondary volume (e.g.,
/dev/sdf). -
Mount the Volume: SSH into the helper instance using its PEM file and execute the following commands:
bash
sudo mount /dev/xvdf1 /mnt
sudo cp /home/ec2-user/.ssh/authorized_keys /mnt/home/ec2-user/.ssh/authorized_keys
sudo umount /mnt -
Reattach the Volume: Detach the volume from the helper instance and reattach it back to your original instance as its root volume (usually
/dev/xvda). - Start Your Original Instance: Finally, start your original EC2 instance. You should now be able to access it using the PEM file from your helper instance
Scenario
- You have admin access on Azure portal where 100 linux vms are running, you are asked to execute a script
- Note: 100 linux vms have different ssh keys
- Now if the same has to be done in AWS, no direct option, Ensure you have enabled Systems Manager
- Even if you reverse the usecase 1 server and 100 users, sharing keys is not a good idea.
AWS Systems Manager
- AWS Systems Manager is an approach to control AWS instances from a centralized service called as systems manager
- Systems Manager expects/installs an agent into ec2 instances and controls it.
