The course is part of this learning path
WordPress is an open source CMS originally built as a web publishing platform, quickly becoming a de-facto standard for blogs. Thanks to its huge third-party plugin ecosystem, WordPress has been adopted for use many different situations never imagined by its creators, including dynamic websites, e-commerce platforms, and online newspapers. It's a terrific software package with a huge user base, but getting the most out of it can be tricky.
This course demonstrate installing and running WordPress on Amazon Web Services. Expert Linux System Administrator David Clinton will guide you through installation, from the easy way (using a Cloudformation template), up to deploying a highly customizable instance on EC2 and RDS. You will learn to use optimization tools like Varnish and Route53 and to monitor availability and costs with CloudWatch.
Who should take this course
This is an intermediate course that will assume some basic knowledge of the AWS system. Some familiarity with the Linux Command Line Interface and MySQL might also be helpful.To move to the next step, check out our EC2 and RDS courses, and our introductory AWS video. You might also enjoy our courses on CloudFormation, LAMP stacks on AWS and Security on Linux based AWS instances, which make great follow ups.
If you want to challenge yourself, check out our questions.
If you have thoughts or suggestions for this course, please contact Cloud Academy at firstname.lastname@example.org.
Hi and welcome to CloudAcademy.com's video series on running your WordPress site in the cloud on AWS.
In this video, we'll discuss monitoring your usage and cost using, among other services, AWS Cloud Watch. If you're running a popular blog or website, for instance, using WordPress, you may not be able to predict how many people might visit or use the things you offer over any given period, but you want to know what's coming. Sudden jumps in good traffic, like getting drudged for instance, which means having your site linked in a very, very heavy traffic site, like Drudgerport, or bad traffic like malicious attacks against your site, can actually bring your server down completely, or could have a huge financial impact. Keep informed. You can use Cloud Watch to set alarms so that you will be alerted if any unusual activity, the way you define it, suddenly starts happening. Click on alarms, click on create an alarm. You can choose a metric.
What would you like to measure? What events would you like to trigger your alarm? So let's for now say per instance metrics on EC2, and let's say disk read bytes. So we'll highlight or select disk read bytes. The wizard will provide us with a graph of recent activity. We'll click next, I should say. We'll give a name to this alert. Let's call it, name.
Couldn't think of anything better at the spur of the moment. Whenever the disk read bytes at this point are equal to or greater than 100,000, that's right, 100,000 bytes for one consecutive period, we could change that greater than or equal to less than or equal, or greater than or just less than. We'll leave it as greater than or equal, for one could obviously be more than one consecutive period, but we'll leave it as one. What to do, when such an alert/event occurs, we should, when the state becomes alarm. We will send a notification. Let's create a new list.
Let's call this list, my list, and let's add an email. User@gmail.com. Obviously, that address doesn't really exist. But it'll do for us.
Let's create the alarm. We will be sent an email or whoever owns User@gmail.com has been sent an email. And we will confirm that we are the owners of this address, if we were the owners of this address in that email. I'm going to say I'll do it later.
There is our new alert. Currently, the state is insufficient data. There is nothing much happening on this EC2 instance. In fact, I don't even think it's running right now. But currently, it's insufficient data. We would be shown alert if there was an alert state occurring at the time. We could also select it and modify it to reset any of the configurations that we've set. So for instance, rather than sending a notification to a list or my list, we could send it simply to list, which will use the SNS console. So another very quick and efficient way to be informed of what's going on with your account. Let's cancel for the meantime. We can also track very carefully actual billing to our account, month by month or really, hour by hour, by going to the AWS billing console.
Amazon does a great job breaking down exactly what you're going to be paying at the end of the month, service by service.
So in my case, you can see that the bulk of my expenses, my horrendous crippling expenses are being spent on EC2, a whole 46 cents so far this month. By the way, it's the 17th of the month today, so it doesn't look like I'm going to be hit that badly then. But if I was using Amazon services a little more robustly, we would really want to know exactly how much I'm spending and where I'm spending. It's a really good idea to keep track of this page. Besides current months, you can also track previous months' spending, previous bills, and various other account information details. Now, the way Amazon bills for their services is really, really complicated, and it's easy to get lost and lose track of exactly where you are.
They're not being dishonest, but it's just a very complicated service. Therefore, we can use their service calculator at calculator.s3.amazonaws.com. You can anticipate what you may end up paying based on various use-case scenarios. So for instance, in Amazon EC2, let's add a row. We could leave a description, so later you'll be able to identify exactly what it was you were thinking about. But let's just say one instance with 100% usage on a T1 micro. On demand, meaning no contract option. If you click on this actually, you can see all the various options and select any one of them, would incur a monthly cost of $14.64. Let's add an EBS volume. Let's say at 10 gigabytes of storage. Now, let's start adding some usage data. Let's say elastic IP non-attached time of 20 hours through the month. Sends the bill up to a staggering 10 cents. Data transfer out at, say 50 gigabytes, would boost it to $4.30. A number of additional elastic IP addresses, let's say five more, would add another $16 or so, besides the monthly cost of the EC2 instance itself.
Let's see S3 briefly, just again, to give you an idea of what's available. If you're going to store on S3, 50 gigabytes of data through the month, that adds another $1.50 or so. Let's say you make, I think that's a million get requests, that adds I think a little bit more. I can't remember what the number was right before. But obviously, you can see how you can play with the data to get better estimates.
Finally, we will take a look at RDS. Let's add a new row, one database instance, with 100% usage using MySQL on a M1 small instance, with standard storage and no IOPs, we'll have added about $25 to your bill. Adding extra data transfer out in gigabytes, say 10 gigabytes per month, adds a bit more. Either way, you see quite clearly how Amazon's not trying to hide what they charge you. They're trying to make it as available as possible. But more importantly, you must track this available data for yourself to know where you might be going and where you've been.
About the Author
David taught high school for twenty years, worked as a Linux system administrator for five years, and has been writing since he could hold a crayon between his fingers. His childhood bedroom wall has since been repainted.
Having worked directly with all kinds of technology, David derives great pleasure from completing projects that draw on as many tools from his toolkit as possible.
Besides being a Linux system administrator with a strong focus on virtualization and security tools, David writes technical documentation and user guides, and creates technology training videos.
His favorite technology tool is the one that should be just about ready for release tomorrow. Or Thursday.