1,234
edits
Changes
no edit summary
= THIS PAGE IS A DRAFT, NOT A REAL COURSE PAGE =
''' The current schedule for OPS345 is here: [[OPS335_Weekly_Schedule]]
= Accessing your AWS account =
At the beginning of the semester your professor will create a Leaner Lab in AWS Academy. The professor will add all the students enrolled in their OPS345 sections as students in that Learner Lab. You should automatically receive an email that looks like this in the beginning of the course:
[[File:AWSAcademyInvitation.png|800px|border|center]]
If you haven't recieved such an email: you need to let your professor know.
Once you complete setting up your account: you might want to bookmark this page, or even make it your home page: https://awsacademy.instructure.com
Browse around the interface. To do your work for OPS345 you only ever need to navigate to "Courses" > "AWS Academy Learner Lab - Foundation Services" > "Modules" > "Learner Lab - Foundational Services", which looks like this:
[[File:AWSAcademyLearnerLabHomeScreen.png|800px|border|center]]
The links you'll use most often are highlighted in green:
# This is the amount of credits you have used out of your allocated 100$. Unlike the screenshot yours will start at zero.
# Most of your AWS resources are turned off unless your lab is started. Click this button to start the lab. There is only one lab for the entire OPS345 course, you will start it many times.
# The amount of time the current session of the lab has been running. After the 4 hours runs out the lab will be stopped and the associated resources will be shut down.
# Click here to get to the AWS web interface where you'll do most of your work.
Your work which you save inside your virtual machines is not deleted once the lab stops. AWS Academy simply shuts down your virtual machines. Your virtual machines and the rest of your Learner Lab resources '''will''' be deleted automatically at the end of OPS345.
The first time you start the lab it may take a few minutes, much longer than usual.
= AWS cost monitoring =
Normally using resources from AWS costs money. AWS costs are very competitive, but their resources are not free. In an AWS Academy Learner Lab you get a 100$ credit which will be more than enough to cover all your resources until the end of the course if you're not reckless.
{{Admon/important|You are responsible for your AWS usage!|If you run out of credits: you will have to find another way to finance completing the required hands-on parts of OPS345.}}
Take this as an opportunity during OPS345 to learn what costs how much money in the cloud. The skills of managing cloud costs are very valuable. Unfortunately AWS Academy doesn't make it easy for you. On the unrestricted AWS you have access to AWS Budgets, Amazon CloudWatch Billing Alarms, and other tools to help you monitor and control your costs. But due to the way AWS Academy was designed: you won't have access to those tools. That's in return for the free 100$, which most students don't complain about.
Even without the budget restrictions in AWS Academy: AWS costs are not easy to manage. Here are some examples of what you'll run into:
* Resources that say "Free" on the label, but will only be free in a specific configuration.
* Resources that are free unless you exceed some threshold of usage (CPU usage, bandwidth, etc.)
* Resources that cost money only when they are ''not'' used. That was not a typo.
* And the most common of all: resources that don't have a cost listed next to them at all.
So in order to learn anything about costs on AWS: pay attention whenever you see a note about the cost of anything, even though it will be a distraction from what you're trying to accomplish at that time. There are many places where such notes are scattered. Always keep cost in the back of your mind when doing ''anything'' on AWS. Then hopefully you'll get a general idea, so that when you're done with OPS345 you can have an intelligent conversation about it.
= Basic security on a public-facing server =
Security is a topic most people aren't qualified to address. That's because it's complicated on its own, but in order to set it up properly: it also requires a solid understanding of the fundamentals of the systems which need to be secured.
That doesn't mean you can't learn it. As with most technologies, the recipe for success is simple. The more time you spend on it: the better you get. Every bit of learning you do related to security will make you more qualified. The more qualified you are to speak about security issues: the more valuable you are as a technician or engineer. Even if you're not directly responsible for security of a system: you will always have to work with security measures, and sometimes around them.
{{Admon/tip|Your attitude matters|Usually if you follow the rules of the organization you work for: security breaches are somebody else's problem. But not always. For example if you get your AWS Academy account suspended by Amazon because your password was "123" - I won't feel bad for you, and ''you'' will have to find a way to complete the requirements of the course. And whether it's your problem or not: wouldn't you rather be a part of the solution?}}
So as with AWS costs there are some steps I can tell you to follow, but overall you should take some time to think of security whenever you do anything. Who has access to a specific machine? Network? Service? Storage device? Is it hard to steal/crack a password and impersonate one of your users? Is your system vulnerable to off-the-shelf attacks? Keep those questions in the back of your mind, and as a minimum follow the following guidelines:
* Set a good password for your AWS account, and don't use that password for '''any''' resources inside AWS. Your AWS account password is like a super-root password. It gives you full access not only to a specific machine, but to all machines, networks, storage devices, and billing. You can end up running someone else's botnet, and paying for it too.
* Possibly the most common attack on a Linux machine is the brute-force SSH login attack. It takes very little setup to mitigate almost all these attacks:
** Delete all default usernames, except root which you can't delete.
** Make sure that root is never allowed to log in remotely.
** Whenever possible: don't use passwords at all, use SSH keys for logging in. You've learned how to use them in OPS245.
* Learn how to use sudo and how to configure it.
* Get in the habit of organising your SSH keys so you don't accidentally lose them.
Remember that unlike ULI101/OPS245 your servers are on the real internet, and depending on how you configure them: they might be accessible by any attacker on the planet. You need to pay much more attention to security in this course than was required in ULI101/OPS245.
= First AWS VM =
We're going to set up a virtual machine in AWS now so you can start to get used to the process. You'll be repeating this several times during the course, try to learn a little more about it each time you do it.
== Security group ops345first ==
A '''security group''' is a fundamental concept in AWS. It's not completely clear what it is. The closest thing you would have seen that's similar is a set of iptables rules. You can assign the security group (this set of rules) to one or more virtual machines.
[[File:AWSCreateSecurityGroup.png|800px|border|center]]
* Instance == VM. AMI == VM disk image.
