Ravindra BagaleCourses & study guides मराठी Track your progress

AWS Elastic IP, AMI and EBS Snapshots Explained

By , trainer LinkedIn Last updated:

Until now, every time our server was stopped and started it came back with a new public IP, and our site, our DNS record and any app that used the old IP broke. In this chapter we fix that with an Elastic IP, a public IP that stays yours. Then we learn to grow a server with very little downtime, and to protect it with an AMI: a full backup of a set-up server, stored as EBS snapshots, that can bring the whole website back after a disaster.

What you'll learn in this class

  • Why a changing public IP breaks apps, bookmarks and DNS records
  • What an Elastic IP is, and why it's regional
  • Allocate, associate, disassociate and release an Elastic IP, and prove it survives a stop and start
  • How AWS charges for public IPv4 addresses, and why you release what you don't use
  • Scaling up vs scaling out, and why changing the instance type needs a stop and start
  • A low-downtime trick: AMI, bigger instance, move the Elastic IP
  • What an AMI is, why we make one, and how it differs from an EBS snapshot
  • sudo systemctl enable nginx vs sudo service nginx start
  • Create an image, wait for available, terminate the server and bring the site back from My AMIs
  • Why snapshots are incremental, and how to clean up AMIs and snapshots

1. Why: a public IP that changes breaks things

Why. A normal EC2 public IP is dynamic: AWS gives it when the instance starts and takes it back when the instance stops. A server can stop for many reasons: a hardware fault, a crash, or someone in the team stopping the wrong server.

Classroom line

Suppose a junior in your company was told to stop another server, and stopped this one by mistake.

Example 1, step by step:

  1. Your website runs on a server with public IP OLD_IP.
  2. The server is stopped, then started again.
  3. EC2 now shows a different public IP, NEW_IP.
  4. Everything that still uses OLD_IP stops working.

Who breaks?

  1. Apps with a hard-coded IP. Suppose we are a big payments app, and our Android and iPhone apps call http://OLD_IP/api. After the IP changes, every installed app fails. Fixing it needs a new app version, the store has to review it, and many users never update. Hard-coding an IP is bad practice; but even with a name, the IP behind it should not keep changing.
  2. Your DNS A record. If example.com points to OLD_IP, you must edit the record. Even after that, resolvers keep the old answer until the record's TTL runs out (for example, a TTL of 600 seconds is 10 minutes), so some visitors still reach the dead IP for a while.
A dynamic public IP changes on stop and start 1. Running OLD_IP The site opens. 2. Stopped, then started AWS takes the IP back and gives a new one. 3. Running again NEW_IP A different public IP. App with a hard-coded IP http://OLD_IP/api Fails until users install an update. DNS A record example.com -> OLD_IP Wrong until you edit it and the TTL runs out.

Figure 1. A stop and start gives a new dynamic public IP. Apps with the old IP fail, and the DNS record is wrong until you edit it and the TTL runs out.

The cloud reality. Servers fail and systems get attacked. Our job is not to promise "it will never go down"; it's to reduce the risk and the downtime. A fixed IP is one of the first tools for that.

Classroom line

We can never build a system that can never be hacked.

Classroom line

What's our job? To stop those attacks as much as we can.

2. What: an Elastic IP is a static public IP

What. An Elastic IP (EIP) is AWS's name for a static public IPv4 address. Azure and Google Cloud simply call it a static IP. You take one from Amazon's pool into your account, and it stays yours until you release it. Attach it to a server, and that server keeps the same public IP across every stop and start.

Three facts to remember:

  1. It belongs to your account, not to one server. You can move it from one server to another in seconds.
  2. It's regional. An Elastic IP from us-east-1 can only be attached to a server in us-east-1. Allocate it in the same region as your server.
  3. It replaces the dynamic IP. When you associate it, the server's old dynamic public IP goes back to AWS, and the Elastic IP takes its place.
Elastic IP lifecycle 1. Allocate Take an IP from Amazon's pool. 2. Associate Attach it to a server in the same region. Stop and start The server keeps the same IP. 3. Disassociate The server gets a new dynamic IP. 4. Release The IP goes back to Amazon's pool. Charged every hour from allocate to release, attached or idle.Release what you do not use.

Figure 2. The Elastic IP lifecycle: allocate, associate, (stop and start keep it), disassociate, release. AWS charges for it from allocate to release.

3. How: allocate and associate an Elastic IP

Step 1. Launch (or pick) an Amazon Linux server with Nginx running and HTTP (port 80) allowed in its security group. Note its current Public IPv4 address, for example OLD_IP, and open http://OLD_IP/.

Step 2. In the EC2 console, left menu: Network & Security > Elastic IPs. Click Allocate Elastic IP address.

Step 3. Keep Amazon's pool of IPv4 addresses. The Network border group is your region, for example us-east-1. Click Allocate.

EC2 console, Allocate Elastic IP address page: Elastic IP address settings, Public IPv4 address pool with Amazon's pool of IPv4 addresses selected and three other options greyed out, and Network border group set to us-east-1.

Console: Allocate Elastic IP address: keep Amazon's pool of IPv4 addresses; the network border group is your region.

Step 4. The new address appears in the list, for example ELASTIC_IP. Select it, then Actions > Associate Elastic IP address.

Step 5. Resource type: Instance. Choose your instance (and its private IP if asked). Click Associate.

Step 6. Open Instances and check the server: its Public IPv4 address is now ELASTIC_IP. Open http://ELASTIC_IP/: the same site.

Step 7. If you have a domain, point its A record to ELASTIC_IP once. You never have to edit it again just because the server restarted.

4. Prove it: stop and start keeps the Elastic IP

Example 2, step by step:

  1. Select the server, Instance state > Stop. Wait for Stopped. The Elastic IP stays attached (a dynamic IP would be gone now).
  2. Instance state > Start. Wait for Running.
  3. The public IPv4 address is still ELASTIC_IP.

  4. Open http://ELASTIC_IP/. If the page doesn't open, connect with SSH and run:

    sudo service nginx start

  5. Refresh: the site is back, on the same IP.

Why did step 4 need Nginx to be started again? Because it was only started, not enabled, so it didn't come up by itself after the stop and start. We fix that properly in section 11.

Classroom line

Let's check it once by stopping the server.

5. Remove it: disassociate, then release

Removing an Elastic IP is two steps, in this order.

Step 1: Disassociate. Elastic IPs, select the address, Actions > Disassociate Elastic IP address, confirm. The server gets a new dynamic public IP from AWS.

Classroom line

See? A new IP came.

Step 2: Release. Select the address again, Actions > Release Elastic IP addresses, confirm. Now it's back in Amazon's pool and gone from your account. You can't release an address that is still associated, which is why disassociate comes first.

The cost. AWS charges a small hourly fee for every public IPv4 address, whether it's a dynamic IP on a running server or an Elastic IP, attached or idle. For an Elastic IP the charge runs from the moment you allocate it until you release it, used or not. So:

  1. Allocate an Elastic IP only for a server that needs a fixed IP.
  2. Release Elastic IPs you no longer need. An idle one costs money and does nothing.
  3. For the current rate, see the public IPv4 section of the Amazon VPC pricing page.

Classroom line

Use it or not: once an Elastic IP is in your account, the charges are running.

6. Why: sometimes the server must grow (scaling up vs scaling out)

Why. Suppose we are a video streaming app on a big release day, or a small shop whose post just went viral. Traffic jumps, and one small server can't keep up. There are two ways to grow:

  1. Scaling up (vertical scaling): make the server bigger: more CPU, more memory. Example: t3.micro (2 vCPU, 1 GiB) to t3.small (2 vCPU, 2 GiB) to t3.medium (2 vCPU, 4 GiB).
  2. Scaling out (horizontal scaling): add more servers of the same size and share the traffic between them (later chapters, with a load balancer).

Classroom line

One is vertical scaling, and the other is horizontal scaling.

Scaling up vs scaling out Scaling up (vertical) micro → small → medium One server, more CPU and memory. Scaling out (horizontal) traffic ↓ small · small · small · small More servers of the same size.

Figure 3. Scaling up makes one server bigger. Scaling out adds more servers of the same size.

7. How: change the instance type (and why it means downtime)

You can't change the size of a running instance. The steps:

  1. Instance state > Stop, wait for Stopped.
  2. Actions > Instance settings > Change instance type.
  3. Pick the bigger type, for example t3.small, and Apply.
  4. Instance state > Start.

The catch. Between steps 1 and 4 the website is down for a few minutes. And without an Elastic IP, the server comes back with a new public IP too.

8. The low-downtime trick: AMI, bigger server, move the Elastic IP

Instead of stopping the live server, build the bigger one next to it, then switch the IP.

Example 3, step by step:

  1. The live site runs on a small server with ELASTIC_IP attached.
  2. Create an AMI (an image) of that server (section 12).
  3. Launch a new, bigger instance from that AMI. It has the same software, settings and files.
  4. Test the new server on its own temporary public IP.
  5. Elastic IPs > Associate ELASTIC_IP with the new instance. (If the console asks, allow it to reassociate the address that is already attached.) The switch takes seconds.
  6. Visitors and DNS keep using ELASTIC_IP; they now reach the bigger server.
  7. When you're happy, stop or terminate the old server.
Low downtime: AMI, bigger server, move theElastic IP Users and DNS ELASTIC_IP 1. Users reach the small server through the Elastic IP. Small server t3.micro 2. Create an AMI of the running server. AMI copy of the server 3. Launch a bigger server from the AMI and test it. Bigger server t3.medium 4. Associate the Elastic IP with the bigger server. Same IPfor users.

Figure 4. Animation: copy the small server into an AMI, launch a bigger server from it, then move the Elastic IP. Users keep the same IP the whole time.

9. Why: what an AMI is and why we make one

What. An AMI (Amazon Machine Image) is a template for launching a server. You already used AWS's AMIs (Amazon Linux, Ubuntu) to launch fresh servers. You can also make your own AMI from a server you have set up: it captures the operating system, the installed software (Nginx, Apache, MySQL), the configuration and your website files.

Why make one?

  1. Backup and disaster recovery. A disk can fail, a data centre can have a fire, or a server can be deleted by mistake. With an AMI you launch an identical server in minutes.
  2. Cloning a finished set-up. Suppose we are an online store, and setting up one web server with all its software took weeks. For a second site or a new client, launch from the AMI instead of doing the work again.
  3. Growing with less downtime (section 8).
Why make your own AMI 1. Disaster recovery Disk failure, fire or a deleted server: launch an identical one inminutes. 2. Clone a set-up Weeks of set-up done once. New site or client: launch from the AMI. 3. Grow with less downtime Launch a bigger server from the AMI, then move the Elastic IP.

Figure 5. Why make an AMI: restore after a disaster, clone a finished set-up, and grow to a bigger server with little downtime.

Classroom line

A server can go down at any time.

10. AMI vs EBS snapshot

What. The server's data lives on EBS volumes (its disks). A backup of one EBS volume is an EBS snapshot. An AMI is the launch template that lists those snapshots plus settings such as the architecture and the device names.

  1. A server with 1 volume gives 1 snapshot + 1 AMI.
  2. A server with 3 volumes gives 3 snapshots + 1 AMI.
  3. The real data is in the snapshots. The AMI points to them.
  4. AWS stores snapshots for you (on Amazon S3 behind the scenes). You manage them in the EC2 console under Elastic Block Store > Snapshots; they don't appear in your own S3 buckets. Turn on EBS encryption as best practice.
AMI vs EBS snapshot EC2 server /dev/xvda  8 GiB snapshot 1: the data /dev/xvdb 20 GiB snapshot 2: the data /dev/xvdc 50 GiB snapshot 3: the data AMI Launch template: settings + a list of the snapshots. 3 volumes = 3 snapshots + 1 AMI. The data is in the snapshots; theAMI points to them.

Figure 6. One AMI points to one snapshot per EBS volume. The data is in the snapshots.

Classroom line

An AMI and a snapshot are two different things. The real backup is in the snapshot.

11. Before the backup: enable your services

Why. A server launched from your AMI boots fresh. If Nginx only starts when someone types a command, the new server comes up with the website down.

What's the difference?

  1. sudo service nginx start starts Nginx now. After a reboot, or on a server launched from the AMI, it stays off.
  2. sudo systemctl enable nginx makes Nginx start at every boot. It does not start it now.
  3. sudo systemctl enable --now nginx does both.

How:

sudo systemctl enable nginx
sudo systemctl is-enabled nginx

The second command prints enabled. Do the same for every service the site needs, for example httpd (Apache) or mysqld.

start vs enable sudo service nginx start Starts Nginx now. After a reboot: off. New server from the AMI: off. Site down until someone starts it. sudo systemctl enable nginx Starts Nginx at every boot. After a reboot: on. New server from the AMI: on. enable --now = enable + start.

Figure 7. start runs the service now; enable makes it start at every boot, including on servers launched from your AMI.

Classroom line

Enable your services before you create an AMI. Never skip it; make it a habit.

12. How: create an image (AMI) of your server

Classroom line

First watch carefully, then do it yourselves.

Step 1. Check the site works at http://ELASTIC_IP/ and that Nginx is enabled (section 11).

Step 2. Instances, select the server, Actions > Image and templates > Create image.

Step 3. Image name: include the date and time, so you can tell backups apart later, for example mywebsite-YYYY-MM-DD-HHMM. The name can't be changed after creation.

Step 4. Image description: what is inside, for example nginx with 10 pages.

Step 5. Keep Reboot instance ticked. EC2 reboots the server so that data still in memory is written to disk before the snapshots are taken. That gives a consistent backup. (The site is down for the short reboot; plan it for a quiet time.)

EC2 console, Create image page: Image details with the instance ID, an empty Image name field (maximum 127 characters, can't be modified after creation), an empty Image description field, and the Reboot instance checkbox ticked with the note that EC2 reboots the instance so that data is at rest when snapshots are taken.

Console: Create image: the instance ID is filled in; type an image name and a description, and keep Reboot instance ticked.

Step 6. Leave the volumes as they are and click Create image.

13. Wait for "available", and look at the snapshot

Step 1. Left menu: Images > AMIs. Your AMI shows Pending. Refresh until it shows Available. This can take several minutes.

Step 2. Left menu: Elastic Block Store > Snapshots. A new snapshot is there, with the description "Created by CreateImage".

Step 3. Compare two columns: Volume size 8 GiB, Full snapshot size about 1.97 GiB. A snapshot stores only the used blocks of the disk, not the empty space, and you pay for the snapshot data stored, not for the full volume size.

EC2 console, Snapshots list owned by me: one snapshot with full snapshot size 1.97 GiB, volume size 8 GiB, description Created by CreateImage, storage tier Standard.

Console: The snapshot list: the full snapshot size is about 1.97 GiB for an 8 GiB volume, because only used data is stored.

Classroom line

Until the status becomes "available", don't terminate the server.

14. Disaster drill: terminate the server, bring the site back

Now we prove the backup works.

Example 4, step by step:

  1. Make sure the AMI shows Available.
  2. Disassociate the Elastic IP from the server (section 5, step 1), so it stays in your account.
  3. Terminate the original server: Instance state > Terminate (delete) instance. This is our "disaster".
  4. Launch instances. Under Application and OS Images, choose My AMIs and select your image.
  5. Pick the instance type, your key pair, and a security group that allows HTTP (and SSH from your IP).
  6. Launch instance and wait for Running.
  7. Associate the Elastic IP with the new instance.
  8. Open http://ELASTIC_IP/. The same pages are back, and Nginx is running because it was enabled before the image was made.
Backup and restore drill 1. Enable systemctl enable nginx 2. Create image dated name, Reboot ticked 3. Wait Pending to Available 4. Terminate the original server 5. Launch from My AMIs, allow HTTP 6. Elastic IP associate it: site is back

Figure 8. The drill: enable services, create the image, wait for available, terminate, launch from My AMIs, move the Elastic IP, and the site is back.

Classroom line

Let the backup finish completely; only then terminate the server.

15. Snapshots are incremental

What. The first snapshot of a volume stores all its used data. Every next snapshot of the same volume stores only the blocks that changed since the previous one. This is called an incremental backup. (The AMI isn't incremental; the EBS snapshots it points to are.)

Example 5, step by step:

  1. An 8 GB volume holds 1.9 GB of data. Backup 1 stores 1.9 GB.
  2. You install more software. The data grows to 2.5 GB. Backup 2 stores only the new 600 MB.
  3. You add a few pages. The data grows to 2.6 GB. Backup 3 stores only the new 100 MB.
  4. Total stored: 1.9 GB + 600 MB + 100 MB = 2.6 GB, not 1.9 + 2.5 + 2.6 = 7 GB.
  5. Each backup still restores as a complete disk for its point in time.
  6. If you delete backup 2, AWS keeps any of its data that backup 3 still needs. Backup 3 still restores completely.
Snapshots are incremental An 8 GB volume holds 1.9 GB ofdata. No backup yet. 0 GB Backup 1 · 1.9 GB 1.9 GB Backup 1 stores all used data: 1.9 GB. Backup 2 · +600 MB 2.5 GB New software: Backup 2 stores only the changed 600 MB. Backup 3 · +100 MB 2.6 GB A few pages: Backup 3 stores only 100 MB. Each still restoresthe full disk. Stored in total: 2.6 GB not 1.9 + 2.5 + 2.6 = 7 GB

Figure 9. Animation: the first snapshot stores 1.9 GB, the second only the 600 MB that changed, the third only 100 MB. Each one still restores the full disk.

Classroom line

Interviews ask: are AWS backups incremental, or what? The answer: incremental.

16. Clean up: deregister the AMI and delete its snapshots

An AMI is deregistered, not deleted. Deregistering does not remove its snapshots by itself, and snapshots keep costing money.

Step 1. Images > AMIs, select the AMI, Actions > Deregister AMI.

Step 2. Tick Delete associated snapshots, then click Deregister AMI.

EC2 console, Deregister AMI dialog: after you deregister an AMI you can't use it to launch new instances; the AMI ID; the Delete associated snapshots checkbox ticked; Associated snapshots (1); Cancel and Deregister AMI buttons.

Console: Deregister AMI: tick Delete associated snapshots so the snapshots don't stay behind and keep costing money.

Step 3. Open Elastic Block Store > Snapshots and check nothing from this AMI is left. If one is, select it and Actions > Delete snapshot.

Step 4. Disassociate and release the Elastic IP if you don't need it (section 5), and terminate test servers.

17. The whole flow on one page

  1. A stop and start changes a dynamic public IP; apps and DNS records with the old IP break.
  2. Elastic IPs > Allocate, then Associate with your server (same region). The IP survives stop and start.
  3. Remove: Disassociate, then Release. Every public IPv4 is charged hourly; release what you don't use.
  4. Changing the instance type needs a stop and start. For less downtime: AMI, bigger server, move the Elastic IP.
  5. sudo systemctl enable nginx before every image.
  6. Create image with a dated name and a description; keep Reboot instance ticked.
  7. Wait for Available; the snapshot holds only used data.
  8. Terminate, launch from My AMIs, associate the Elastic IP: the site is back.
  9. Snapshots are incremental. Deregister AMIs with Delete associated snapshots ticked.

18. Try at home

Try at home

Task 1: Elastic IP

  1. Launch an Amazon Linux server with Nginx and open its page.
  2. Allocate an Elastic IP in the same region and associate it with the server.
  3. Stop and start the server. Check the IP stayed the same, and start Nginx if needed.
  4. Disassociate the Elastic IP and note the new dynamic IP the server gets. Then release the Elastic IP.

Task 2: AMI backup and restore

  1. Run sudo systemctl enable nginx and check it with sudo systemctl is-enabled nginx.
  2. Change the default page, then create an image named with today's date and time, with Reboot instance ticked.
  3. Wait for Available, and compare the volume size and the snapshot size.
  4. Terminate the server, launch a new one from My AMIs, and open your changed page.
  5. Clean up: deregister the AMI with Delete associated snapshots, check the snapshot list, release any Elastic IP and terminate the server.

Recap

In short

  1. A normal public IP is dynamic: a stop and start changes it, and apps, bookmarks and DNS records with the old IP break (DNS also waits for the TTL).
  2. An Elastic IP is a static public IPv4 address that belongs to your account; it's regional and survives stop and start.
  3. Allocate, associate; to remove, disassociate, then release. AWS charges hourly for every public IPv4, so release unused Elastic IPs.
  4. Scaling up makes a server bigger (needs a stop and start); scaling out adds servers.
  5. Low downtime: create an AMI, launch a bigger server from it, move the Elastic IP.
  6. An AMI is a launch template that points to EBS snapshots; the data is in the snapshots.
  7. systemctl enable starts a service at every boot; service ... start only starts it now. Enable before imaging.
  8. Create image with a dated name, keep Reboot ticked, wait for Available before terminating anything.
  9. Snapshots store only used data and are incremental. Deregister AMIs with "Delete associated snapshots".

Practice Tasks

About this scenario

Bengaluru HealthTech is a health technology business in Bengaluru. Arjun Rao looks after its IT and cloud work. They count money in INR and run their AWS resources in the ap-south-1 Region. In the tasks below you do real jobs for them using what this lesson teaches. All names, account IDs, IP addresses and numbers are made up for practice.

0 / 12

Easy Snapshot an EBS volume

Why: A snapshot is a point-in-time backup of one disk, kept in S3 by AWS.

What to do: Create a snapshot of volume vol-05324d33feecfdeed with description "nightly blrhealthtech".

How:
  1. Read the task and decide which AWS service it is about.
  2. Write aws, then the service name, then the operation (the action word).
  3. Add each needed flag (--name) followed by its value from the task.
  4. Flags can be in any order. Click Check answer.

Easy Detach a volume

Why: To move a disk to a rescue server, detach it first.

What to do: Detach volume vol-05324d33feecfdeed.

How:
  1. Read the task and decide which AWS service it is about.
  2. Write aws, then the service name, then the operation (the action word).
  3. Add each needed flag (--name) followed by its value from the task.
  4. Flags can be in any order. Click Check answer.

Medium Delete an old AMI

Why: Old AMIs and their snapshots cost money every month.

What to do: Deregister the image ami-01adbac1bbeffabcd.

How:
  1. Read the task and decide which AWS service it is about.
  2. Write aws, then the service name, then the operation (the action word).
  3. Add each needed flag (--name) followed by its value from the task.
  4. Flags can be in any order. Click Check answer.

Medium List your own AMIs

Why: Only images you own matter when you clean up old AMIs.

What to do: List only the AMIs owned by your own account.

How:
  1. Read the task and decide which AWS service it is about.
  2. Write aws, then the service name, then the operation (the action word).
  3. Add each needed flag (--name) followed by its value from the task.
  4. Flags can be in any order. Click Check answer.

Medium Allocate an Elastic IP

Why: An Elastic IP stays the same after stop/start, so DNS keeps working.

What to do: Allocate a new Elastic IP address for use in a VPC.

How:
  1. Read the task and decide which AWS service it is about.
  2. Write aws, then the service name, then the operation (the action word).
  3. Add each needed flag (--name) followed by its value from the task.
  4. Flags can be in any order. Click Check answer.

Medium Attach the Elastic IP to the server

Why: Associating gives the server the fixed public IP that your domain points to.

What to do: Associate allocation eipalloc-05324c33abbdd44 with instance i-0bba33c4235211a2b.

How:
  1. Read the task and decide which AWS service it is about.
  2. Write aws, then the service name, then the operation (the action word).
  3. Add each needed flag (--name) followed by its value from the task.
  4. Flags can be in any order. Click Check answer.

Medium Create an AMI from a server

Why: An AMI is a full server image. Launch identical copies from it any time.

What to do: Create an AMI named blrhealthtech-web-v1 from instance i-0bba33c4235211a2b.

How:
  1. Read the task and decide which AWS service it is about.
  2. Write aws, then the service name, then the operation (the action word).
  3. Add each needed flag (--name) followed by its value from the task.
  4. Flags can be in any order. Click Check answer.

Medium Attach a volume to an instance

Why: A volume must be attached (same AZ) before the server can see it.

What to do: Attach volume vol-05324d33feecfdeed to instance i-0bba33c4235211a2b as device /dev/sdf.

How:
  1. Read the task and decide which AWS service it is about.
  2. Write aws, then the service name, then the operation (the action word).
  3. Add each needed flag (--name) followed by its value from the task.
  4. Flags can be in any order. Click Check answer.

Medium Make a compressed backup

Why: A .tar.gz file packs a whole folder into one small file you can copy anywhere.

What to do: Create a gzip-compressed archive named blrhealthtech-site.tar.gz from the folder /var/www/blrhealthtech.

How:
  1. Find the Linux command that does this job.
  2. Add the options (like -r or -h) the task needs.
  3. Add the file names, folders or users in the right order.
  4. Use sudo if the job changes system files or users. Click Check answer.

Medium Extract a backup

Why: To restore, you unpack the archive into a folder.

What to do: Extract blrhealthtech-site.tar.gz into the folder /tmp/restore.

How:
  1. Find the Linux command that does this job.
  2. Add the options (like -r or -h) the task needs.
  3. Add the file names, folders or users in the right order.
  4. Use sudo if the job changes system files or users. Click Check answer.

Medium Zip a folder

Why: Zip files open easily on Windows, so they are good for sharing with office staff.

What to do: Create invoices.zip containing the folder invoices and everything in it.

How:
  1. Find the Linux command that does this job.
  2. Add the options (like -r or -h) the task needs.
  3. Add the file names, folders or users in the right order.
  4. Use sudo if the job changes system files or users. Click Check answer.

Hard Copy a snapshot to another Region

Why: A copy in another Region protects you if a whole Region has a problem.

What to do: Copy snapshot snap-024e33beebeef5 from ap-south-1 into us-west-2 (run the command in us-west-2).

How:
  1. Read the task and decide which AWS service it is about.
  2. Write aws, then the service name, then the operation (the action word).
  3. Add each needed flag (--name) followed by its value from the task.
  4. Flags can be in any order. Click Check answer.

See all practice tasks in the Task Hub →

Quick revision cards

Revise this lesson in two minutes. Save the cards on your phone or download them as PNG files. The QR code on each card opens its lesson.

Comparison card: Scale up (vertical) vs Scale out (horizontal). Scale up (vertical): Make one server bigger: more CPU and RAM. Scale out (horizontal): Add more servers of the same size.
Comparison: Scale up (vertical) vs Scale out (horizontal) · Download PNG
Comparison card: EBS snapshot vs AMI. EBS snapshot: A backup copy of ONE EBS disk at a point in time. AMI: Amazon Machine Image: a whole server image (disk snapshots + launch settings).
Comparison: EBS snapshot vs AMI · Download PNG
Revision card: What is an Elastic IP?. A normal public IP changes on every stop and start. Apps and DNS records using it break. An Elastic IP is a static public IPv4 that belongs to your account, in one Region. EC2 › Elastic IPs › Allocate, then Associate it with the server. Server stops and starts: IP stays 13.2.1.9. DNS needs no edit.
Revision card: What is an Elastic IP? · Download PNG
Revision card: Public IPv4 charges. An unused IP still costs money every hour. AWS charges for every public IPv4, in use or not, from allocate to release. After the lab: Disassociate, then Release the Elastic IP. $0.005 per hour × 720 hours = about $3.60 per month per IP.
Revision card: Public IPv4 charges · Download PNG
Revision card: Create an AMI and restore a site. If a server is terminated, everything installed on it is gone. An AMI is a full image of a server: OS, software and files, ready to launch again. Actions › Image and templates › Create image. Wait for "available". Launch from My AMIs. Nginx enabled with systemctl enable comes back by itself after launch.
Revision card: Create an AMI and restore a site · Download PNG
Revision card: Why EBS snapshots are incremental. Copying the full disk every day would be slow and expensive. A snapshot is a backup of one EBS volume in S3. After the first, each saves only changed blocks. Volume › Actions › Create snapshot. To clean up: deregister the AMI, then delete its snapshots. Day 1: 8 GiB copied. Day 2: only 200 MiB changed, so only 200 MiB stored.
Revision card: Why EBS snapshots are incremental · Download PNG
Comparison: systemctl enable vs service start. systemctl enable: Sets a service to start at every boot. service start: Starts a service now, one time.
Comparison: systemctl enable vs service start · Download PNG
Interview card: Why use an Elastic IP for a web server?. It is a static public IP that survives stop and start. Apps, DNS records and firewall rules that use the IP keep working. Allocate and associate; move it to a new server in seconds.
Interview card: Why use an Elastic IP for a web server? · Download PNG
Interview card: How do you change an instance type with low downtime?. Make an AMI, launch a bigger server from it, then move the Elastic IP. Changing type in place needs a stop and start, so the site goes down. t3.micro › AMI › t3.large › reassociate EIP: seconds of downtime.
Interview card: How do you change an instance type with low downtime? · Download PNG
Interview card: Why run systemctl enable before creating an AMI?. enable starts the service at every boot. service start only starts it now. A server launched from the AMI boots fresh; without enable, Nginx stays off. Run it once on the source server:
Interview card: Why run systemctl enable before creating an AMI? · Download PNG
Interview card: How do you clean up an AMI so you stop paying?. Deregister the AMI, then delete its EBS snapshots. Deregister alone keeps the snapshots, and they are billed. Check Snapshots for the AMI ID in the description.
Interview card: How do you clean up an AMI so you stop paying? · Download PNG

More cards: Ravi Sir's Cards.