OPS345

Introduction to AWS

Eric Brauer

At This Point…

…You should have some sort of Linux platform working and ready to go. You should have a terminal, and be able to run SSH commands.

The rest of our VMs will be hosted in the Cloud.

Just What Is The Cloud?

A: Somebody else’s computer. Or rather, somebody else’s extensive arrangement of computing power.

Most businesses are moving from onsite solutions (ie. having their own servers and infrastructure) to solutions like AWS (where Amazon provides them everything). Why?

History Lesson

When companies first moved into online spaces, they most likely setting up their own web servers, email servers and so on.

  • Your website was static, it probably just pointed to your telephone number maybe a list of stock or services.
  • Your web traffic was in the hundreds (if that!)
  • One machine (and one employee) might be sufficient!

History Lesson

  • Pets Versus Livestock.
  • This solution doesn’t scale.

Supply Versus Demand

  • The majority of our traffic arrives at peak times (daylight hours).
  • Customers have high expectations of availability for our services. 99.99% uptime.
  • A computer uses power as long as it is running, whether it is doing anything or not. If it’s one machine, this doesn’t matter so much, but what about 10,000?

The Issue

You need computing resources to accommodate peak demand, but don’t want to waste resources when demand eases. So essentially we want our supply of computing to be as flexible as our requirements.

The Solution (From A Manager’s Perspective)

Why maintain our own hardware and infrastructure when we can just put it in the Cloud and pay Amazon per minute? (The same way we pay for electricity)

The Solution (From Our Perspective)

  • ‘Virtualise’ our hardware so that one configuration can be cloned as many times as needed.
  • Create ‘instances’ of these virtual machines as needed.
  • Use ‘load balancing’ to expand/reduce our instances as needed.

This is the logic that has driven migration to the Cloud. The disadvantage is that you are now dependent on the Cloud provider, and trust that they won’t hike their rates, or otherwise leverage their platform.

Anyway, Enough Of That

You have been signed up for AWS Academy Learner Lab Foundational Course. Amazon has envisioned this as a preliminary course to prepare you for one of its exams, but we’re going to use it for this course. (Just in case you were wondering what the other modules and instructions were about).

Important!

⚠Use The Link I Provide You To Log In To AWS⚠

  • Don’t use your account from another course
  • Don’t enter your credit card information
  • Make sure the email address associated with your account is your Myseneca account.

I cannot help you with Billing Problems. You shouldn’t need to pay AWS any money to complete this course, and you won’t if you pay attention and follow instructions.

Starting The Lab

Once you’ve been invited to the course and created an account:

  1. Start Lab to spin up the EC2 Dashboard.
  2. Click AWS when the light is green.
  3. Search for EC2 to find the Dashboard that we will use.

Incurring Costs

  • You get $100 of free AWS credit. Should be more than enough for the course.
  • Running instances will cost money, depending on their state.
  • Idle instances won’t incur much, but it’s always better to power down your instances when you’re finished with them.
  • After 4 hours your instances will be turned off for you.

Security

Unlike OPS245, our instances are on the Internet. You are swimming in the Ocean, no longer in a little pond. Keep that in mind! Our approach to security is this:

  • Create our instances inside of a security group, with only SSH allowed as an inbound connection.
  • Create a non-default user account, and delete the ec2-user account.
  • Use public/private keypair to log in. No passwords!

Security

  • In OPS245, you generated a keypair, and then copied your public key to a remote machine.
  • In this course, Amazon will generate a keypair, and you will download the private key to your local machine.
  • Note: your private key won’t work if its permissions are too relaxed. Your key should only be readable by your user, and all other permissions should be turned off.
  • You can transfer your key to other machines, just make sure that permissions are set correctly. (Hint: use 400)

Security Groups

  • In OPS245, we would create a virtual machine, then modify iptables inside that VM to only allow certain types of traffic.
  • In AWS, you can think of a Security Groups in the same way. It is a way of applying similar rules externally.
  • Another analogy: this allows us to ‘fence off’ certain instances so that they aren’t reachable to outside entities.

Our First Security Group

  • The only change you are making is to allow Inbound SSH connections. Provide a rule name and a description.
  • Scroll down to find the ‘Save Changes’ button. Your change will be rejected! Check which boxes require an input.
  • The instructions specify that SSH should be ‘open to the world’. (This helps if you are accessing your instances from both the lab and then at home!) What CIDR would cover that?

Your First (Cloud-Based) VM

  • You’ll notice that we don’t force you to go through the process of installing an Operating System on one of our AWS instances.
  • Instead, we are choosing an AMI called ‘Amazon Linux’. This is pre-built virtual machine which we can then begin tweaking.
  • AMI: Amazon Machine Image. Essentially a VM template. In the real world a business would be creating their own AMI.

Modifying Virtual Hardware

…costs money. Choosing a different type of AMI costs money. We are in the ‘Free’ tier essentially!

Configuring the Instance

Make sure you are using your security group and keypair for this new instance! Click ‘Network’ -> ‘Edit’ to modify these settings. The instructions make it seem like there’s another screen where you change these, that’s not the case.

Logging Into the Instance

  • Once your instance is ‘running’, check the dashboard for its Public IP.
  • Use your terminal (not the browser!). Specify the private key’s location in your SSH command.
  • Use the user account ec2-user and the public IP.
  • If anything is failing here, first thing to check: your Security Group settings.

Modifying Your Instance

  • Delete the ec2-user account and replace it with your myseneca username.
  • Make the hostname persistent.
  • Follow the instructions carefully to perform the relevant tasks.

Finishing the Lab

As always, I recommend that you power down your instance using the shutdown command, and click on “End Lab” when you’re finished.