LEO ZHADANOVSKY: Hi, everyone.
I'm Leo Zhadanovsky.
I'm a solutions architect at Amazon Web Services.
And I'm going to talk to you today about what Amazon Web Services is,
its history, a brief overview of the services that we offer.
And also I'll do a live demo of how to launch a LAMP stack in AWS
both on a single instance and through using some of our other
[? managed ?] services, such as our relational database
service, and our load balancers, and our instances.
>> So first of all, let's talk about AWS history.
So how did Amazon.com get into this cloud computing business?
Well, Amazon's really good at providing a big selection of products
and shipping those to customers efficiently.
And behind that capability lies years of experience
with operating data centers, with logistics, with all kinds of things.
And so we discovered over 10 years that we
wanted to enable our customers to do a lot of different things, right?
>> So we ended offering some internal services up to third-party sellers.
As we published simple web services such as our catalog search.
And it became really apparent really fast
that developers were hungry for more of our services.
And so this led us to develop AWS.
So we asked what if we could package everything
we do and offer it to others over the web?
>> So the AWS mission is to enable businesses and developers
to use web services to build scalable sophisticated applications.
And web services is what people now call the Cloud.
So in 2006, AWS was born.
And let's talk about what AWS actually is.
>> So we provide different services at different tiers.
So we have kind of our core services, our compute storage and database.
And then we also have a networking layer,
and we've got a global infrastructure, so we've
got regions around the world and availability zones around the world.
And then we've got higher level services,
like application services that you use to build horizontally
scalable applications.
And then we've got deployment and administration services.
So these are services that you use to deploy your code in the AWS
and to administrate your AWS account as it scales.
>> So let's talk about our global infrastructure first.
We have 11 regions around the world.
So we just added a new region a few weeks ago in Frankfurt,
but each region is like a separate cloud.
So these services I'm going to talk about, they
exist in the different regions.
So in the US, there's a region in northern Virginia.
There's a region in North California and in Oregon.
>> The region in Oregon is also carbon neutral.
We also have a region in Oregon called GovCloud.
So if you have a workload that needs to be ITAR compliant, so that's
International Traffic and Arms Reduction Treaty, you should use GovCloud.
>> So the important thing about this is that you
pick and choose where your data goes and where your apps go.
So we don't move your data across regions, or across availability zones
if it's a service where you can choose the availability zone.
You can pick and choose where it goes.
You can move it.
We give you tools to move your data, but we won't move it for you.
>> And so within each region there's at least two availability zones,
and we'll talk about what those are in a second.
And there's also 52 edge locations around the world.
So edge locations are basically for our CloudFront, [? cloud ?] distribution
network, and our Route 53 DNS service.
And so there's a lot of them because they're closer to the users,
because those are latency-based services.
So latency matters for them.
>> So this is what a typical region looks like.
And then [? within ?] each region there's,
like I said, at least two availability zones.
An availability zone is at least one data center,
sometimes it can be more within the same geographic area.
And our availability zones are designed to be on different floodplains, fault
plains to have distinct power utilities and different tier 1 ISPs.
So you should design your application [? mind ?]
where something can happen in one availability zone,
but so you should spread out your application in multiple availability
zones because they're built with these redundancies in mind.
>> And so we power a lot of businesses that you recognize.
So from Airbnb, to Netflix, to Dropbox, to Yelp,
we have all kinds of startups and enterprises that run workloads on us.
In the public sector, we've got all kinds of government agencies
that run on us, edtech startups, universities.
The Obama campaign ran basically all of their stuff on Amazon Web Services.
>> And just to give you a perspective on our scaling, on an average day
we had enough new server capacity to support
Amazon.com's global infrastructure when it was a $7 billion
business back in 2004.
So that's how much we had on an average day.
>> So the general concept is if you think about how do you get power.
So you get power, it's on demand, right?
So you know when you're getting it, you know you can get it.
It's uniform, so you know what voltage you're getting.
It's pay as you go, so you pay for exactly how much you use.
And it's available.
So you plug in, you know you're gonna get power.
So we've taken that and extended it to computing.
>> So this solves a lot of problems.
We typically see a lot of IT organizations.
They have this capacity problem.
So they have certain amounts of IT needs, and then they
have to over-provision their capacity.
So either they're way over-provisioning, or they don't have enough capacity,
and they have unsatisfied customers.
>> So for example, these are different patterns of traffic.
So whether you have things that turn on and off,
or grow fast, or have variable peaks or predictable peaks, for all these,
you're either going to over-provision typically,
or you're going to under-provision.
So you either have waste, or you have unhappy customers.
>> So what AWS allows you to do is you can scale up and down dynamically
based on what your actual usage pattern is.
So you can pay just for what you use.
And you can launch instances, so instance
is our word for virtual server.
You can launch one instance, you can launch
thousands of instances in minutes or seconds, just as much as you need.
And you can dial it up and down as required.
So let me talk to you about an example that's kind of close to home.
So this is a typical traffic chart for November for Amazon.com.
And the last two peaks here, does anyone know what they are?
So they're--
>> AUDIENCE: Cyber Monday?
>> LEO ZHADANOVSKY: Cyber Monday and Black Friday, right?
So traditionally, what Amazon.com had to do was they had to provision capacity
to cover those two peaks.
So as a result, 76% of the time, they had too much capacity.
And only 24% of the time were they fully utilizing it.
And so in 2010 Amazon.com turned off its last physical web server
and moved it to AWS.
So this is what the traffic pattern looks like now.
The capacity is just above what's actually needed.
>> So why do we see customers adopting cloud computing in AWS so quickly?
Well, agility.
So that's the primary reason that we see.
Why is agility important?
Well, it allows customers to do things that in the old world
took weeks or months to do them in minutes or seconds.
So you can do things like spin up a whole new Dev or Test environment,
spin up a whole new DR environment, spin up
50 instances, or 1,000 instances for peak traffic,
remove those 1,000 instances, set up an HPC cluster, or a GS cluster,
and you can do that all in minutes on AWS.
>> So what this leads to is a culture of innovation.
So you can experiment often.
You can pay only for what you use and you can fail without risk.
So if you try something out, you've paid for a few hours of usage.
It's not a big deal.
You haven't put a big capital investment up front for that.
>> So what are customers actually using AWS for?
Well, so the University of Notre Dame, they moved their website over to AWS.
They have an average of about 38,000 visitors per day to their site,
but it can swell to 150,000 during sporting events and football games.
So they moved their website over to us.
And now their website can support a 500% increase in traffic, all the
while they've saved 40% over their existing
on-premise setup for their website.
>> NASA JPL, they use AWS to live stream the Curiosity Mars rover landing.
And so they found out only six days in advance
that they needed to find another provider
from their regular provider for their live stream.
This was also the same time as the Olympics.
So they couldn't buy CDM capacity anywhere at the time.
And so they basically set up their own content delivery network
on our EC2 service in six days.
And they were able to have it scale up to their needs.
They were, I think, envisioning about a million viewers.
So it was a really interesting technical feed they used,
Adobe Flash Media servers and [? internet ?] caches.
And they were able to deploy whole clusters of these programmatically as
needed.
And then they spun them down when they didn't use them anymore.
>> The Obama campaign in 2012 used AWS for over 200 applications
that they hosted on the platform.
They had everything ranging from call tools, to payment processors,
to mobile applications, to volunteer organization websites,
to big data analytics tools.
And everything had to work on Election Day.
So to move Election Day would require a constitutional amendment,
so that wasn't going to happen.
So all their systems were going to have to work on day one.
And they did.
>> So let's talk about the actual services.
So first the networking services.
So Amazon VPC is the Virtual Private Cloud.
It is basically a software-defined network
that lives on top of your EC2 instances, and your RDS, which we'll talk about,
and ElastiCache.
>> And so you can define a private address space for your instances.
You can break that up into public subnets, private subnets.
You can do VPN connections to your on-premise data center.
You can then also extend your on-premise address space to the VPC.
You have power to manipulate the route table so you can customize things.
You have network access control lists in the VPC.
[? So it ?] gives you a lot of flexibility
over what you have running in AWS.
>> Then there's AWS DirectConnect.
So DirectConnect is a private connection to our regions.
So you can get a one or a 10 gig link or multiple one or 10 gig links
up to a region.
So if you are uploading a lot of data or downloading a lot of data
and need private connectivity, that's an option there.
>> There's also Route 53.
So Route 53 is our DNS service.
It does all kinds of interesting things.
So it supports health checks.
So you can, say, run two copies of your website at the same time.
And if one of them fails, you redirect traffic to the other copy.
>> Or you can do geography-based records so you can route traffic for one country
to one cluster from another country to another cluster.
You can do A/B testing, so you can have 80% of your traffic
to one copy of your website and 20% to the new copy of your website
and see which one performs better.
So you can do all kinds of interesting things there.
You can do latency based records.
So you can have copies of your website all over the world
and have the user sent to whichever one's closest to them based on latency.
It also has deep integration with AWS services,
so such as our load balancers, and S3, and CloudFront,
so it's really easy to point things to CloudFront
distributions for your LBs or S3 buckets.
>> Then there's EC2.
So EC2 is our virtual server service.
You can run on Windows.
You can run Linux on it.
You have full control of the operating system.
There's different flavors of Windows and Linux, so Red Hat, Debian, Ubuntu.
We have our own distribution called Amazon Linux.
You can pick which one you want.
>> There's different types of instances.
So there's over 27 instance types at this point.
So there's different instance families based on different workloads.
So there's general purpose instances, which
are just, if you don't know what you need, you can start with those.
>> There's compute optimized, which are great for things like web servers,
right?
There's memory optimized instances, which
are great for things like date relational databases.
There's storage-optimized instances, so these have big SSDs on them.
So they're great for things like Mongo or NoSQL, right?
>> And there's graphics optimized instances,
which are great for GPU compute and cluster instances.
And lastly there's cost optimized instances.
So if you're just trying to experiment, you
can get a bunch of low cost instance types that are great for that use case.
Then there's Auto Scaling.
So Auto Scaling is an API for EC2.
And it allows you to horizontally scale up and down tiers of EC2 instances.
So let's say you have a bunch of web servers.
>> And, like in the Notre Dame case, you normally you need to have two of them,
but you might have to scale for 10.
Well, you can use Auto Scaling to automatically trigger
scale up or down events based on a metric.
So [? CPU ?] usage, latency.
You can do custom metrics, so it's pretty open ended there.
>> You can also scale based on a schedule.
So if you know that you're going to have a lot of traffic on Monday at 6:00 AM,
you can scale up on Monday at 6:00 AM and scale down on Monday at 5:00 PM.
You can also do it based on just command line commands.
>> Then there's elastic load balancing.
So elastic load balancing is a managed load balancer.
So you click a button, it provisions a load balancer for you.
The load balancer lives in multiple availability zones.
It does SSL offloading for ports 25, 80, 443,
and anything over 1024 for TCP traffic.
>> It does connection draining, proxy protocol support.
So it's a very featureful load balancer.
And it's got integration with Auto Scaling.
So when you're using Auto Scaling and you're scaling up and down,
you can have your instances automatically join or leave
an elastic load balancer.
>> So then there's our storage services.
So the first one is Amazon EBS, or Elastic Block Store.
These are persistent volumes that you can mount to your EC2 instances.
So you can snapshot them.
So when snapshot an EBS volume, it goes to S3,
which we'll talk about in a second.
There's three different types of EBS volumes.
>> There's magnetic EBS, which is just the sort of standard sort of magnetic disk.
It's the most economical option.
Then there's general purpose SSD, where we
get three IOPS per gigabyte provision.
So if you have one terabyte volume, you have 3,000 IOPS.
And then there's provisioned IOPS.
So provisioned IOPS is when you pay for how much disk space you use
and how much IOPS capacity you need.
So you can provision up to 4,000 IOPS per volume.
>> So then there's the Amazon S3.
The Amazon S3 is our object store.
So Amazon S3, you can use it to store just any kind of data.
You can use it to store static websites and hose static websites.
You can use S3 for backups and archives in some use cases
as your source and output bucket for big data analytics, or transcoding.
It also can be used as an origin for a CloudFront distribution.
>> So S3's super powerful.
S3's designed for 11 lines of durability.
So what that means is it can sustain the loss of at least two data
centers at the same time without losing your data.
You can do encryption on S3.
So server set encryption, or server set encryption with your key.
So if you want to manage the keys, you can do that as well.
>> And there's Glacier.
So Glacier is our long-term archival service.
It is also designed for 11 lines of durability,
but it's for when you want to save something and forget about it, right?
So whether for compliance or other reasons you need to archive something,
you should use Glacier.
So Glacier costs $0.01 per gigabyte per month.
And Amazon S3 starts at $0.03 per gigabyte per month.
So Glacier is less expensive and Glacier takes three to five hours
to get your data back.
So if that's OK, if it's an archival case,
then Glacier's probably the right use case for that.
>> Then there's Storage Gateway.
So the Storage Gateway is a virtual machine
that you can run locally in VMware, or Hyper-V.
It gives you an iSCSI endpoint.
You can then set up another VM on top of that
that exposes that iSCSI endpoint with CIFS or NFS.
Anything that goes into that network share and then gets
backed up to Amazon S3, or Glacier, or EBS depending on how you set it up.
So it's a easy way to get your data up to AWS.
>> So then there's our database services.
So the first one is Amazon RDS.
So this is our relational database service.
So this is a managed relational database [? for you. ?]
It will support SQL Server, Oracle, MySQL, and Postgres engines.
>> It does automatic failover.
So if you have the Multi-AZ option enabled,
it does synchronous block level replication across availability zones.
And then if your primary fails, it'll just automatically
failover between them.
It also, for the MySQL engine, supports read replicas within the same region
or across regions.
And there's all kinds of interesting options there.
So it'll do your backups for you.
So it'll backup to S3.
It'll do your patching for you as well.
>> Then there's DynamoDB.
DynamoDB is our managed NoSQL service.
For Dynamo DB it takes away all the administrative burden
of managing a NoSQL service for you.
So you just provision the table and you say
how much read and write capacity you want.
And it will deliver that for you.
So it's an extremely simple service to use.
Then there's ElastiCache.
So ElastiCache is our managed caching service.
It is basically a managed Redis or ElastiCache.
So again, you can provision a cluster of ElastiCache or Redis instances
and not have to worry about backups, or failover, or any of that stuff.
>> Then we have our application services.
So CloudFront is our content delivery network
and it lives on those Edge locations that I talked about before.
So CloudFront can be used for live video streaming,
for on demand video streaming, and for just having a website,
so hosting a website.
So you can have website hosted on elastic load balancers,
or instances, or S3 buckets, or just on-premise hardware.
And you can put a CloudFront distribution in front of it.
It'll cache your content.
It'll put it on the edge locations.
And so when somebody goes to your website
they'll be hitting CloudFront, which is going to probably closer to them
than whatever the origin is.
And it'll offload a lot of the load off the origin,
thus both saving you money and getting a better user experience.
>> Then there's Amazon CloudSearch.
So CloudSearch is a managed search service.
So you send it your searchable data and talk to it through an API,
and it'll do search results for you.
Then there's the Elastic Transcoder.
So it's a managed transcoding solution.
You put your videos into an S3 bucket, tell it what to transcode into,
what format and what size and everything.
And it'll transcode it and put it into an S3 bucket for you.
>> Then there's our big data services.
So we've got Amazon EMR, which is Elastic Map Reduce.
So this is a hosted Hadoop framework.
So you can spin up a Hadoop cluster from one instance to hundreds of instances
if you need.
It's got deep integration of S3, so as a file system for it
you can use HDSF, which you traditionally do with Hadoop.
Or you can do S3 as the file system.
>> It's got support for spot pricing, which is,
on Amazon, how you bid for excess capacity.
So it supports all that.
It supports common Hadoop frameworks such as Spark and Shark and Hive
and Pig.
And we've seen over 5.5 million EMR clusters
launched at this point on Amazon.
>> Then we've got AWS Data Pipeline.
So Data Pipeline is a service that will allow
you to move data across our different data stores.
So you can take something from S3, put it into RDS, then do some EMR on it,
put it into Redshift, which is our data warehousing appliance,
and then you can pull something out of an on premise, MySQL instance.
So there's all kinds of things you can do with that.
>> Then there's Redshift.
Redshift is our managed data warehouse appliance.
It's meant to be petabyte scale, so you can store lots of data on it.
It's a massively parallel architecture.
So you can have many nodes if you wanted to.
And it does all the backups and all the administrative stuff for you.
And then there's Kinesis.
Kinesis is our real-time processing service.
So you can take some source of real-time streaming data,
so say like the Twitter Firehose, or a bunch of log data, send it to Kinesis.
Kinesis handles all that for you.
And then you can connect workers to it to pull things out
and, say, do a live dashboard or do live analytics on it.
>> So then we have our deployment services.
So AWS OpsWorks is a DevOps framework.
So you take your application, you break it up into layers.
So you've got your load balancer layer, your web layer, your app layer,
your database layer, and you provision things on those layers
based on Chef recipes.
Chef is a configuration management system.
So it also supports life cycle events and so
if you don't want to manage your own Chef, right,
if you want to have some kind of programmatic way to deploy things
onto your instances this is one option for you.
>> Then we have Elastic Beanstalk.
So Elastic Beanstalk is a service that allows you to-- say you're a developer.
You have your code in a Git repo.
You don't want to have to worry about deploying your own ELBs or RDS
instances or regular EC2 instances.
So what you do is you, from your code, just send it to Elastic Beanstalk.
Elastic Beanstalk will provision RDS instances and ELBs and all that stuff
for you and deploy your code onto them.
So it makes it a lot easier for developers
to deploy their code onto AWS.
>> Then there's CloudFormation.
So CloudFormation is a service for treating your infrastructure as code.
So now that you have all this stuff in your application,
you've got your VPC, and your security group rules,
and your EC2 instances, and your RDS instances.
So you've got this whole architecture on AWS.
Well, how do you programmatically spin that up or recreate it?
You can write a JSON file that represents all of that.
And then you can [? take ?] that JSON file
and deploy your infrastructure off of it.
So you can have an architecture where, every time you deploy code,
it spins up a fresh copy of your whole architecture and then fails over to it.
So you can also do this to have a mutable infrastructure.
>> Then finally there's our administration services.
So our administration services start with Amazon IAM,
so it's Identity and Access Management.
So that allows you to manage your AWS account
so you can have sub users and groups and do
identity federation and all kinds of stuff.
It's really important for security.
>> Then we have Amazon CloudWatch, which is our metrics service.
So it gives you CPU usage and all kinds of metrics.
And you can do custom metrics, and [? you can do ?]
auto scaling based on those metrics.
>> And then we have CloudTrail.
So CloudTrail is our service for auditing.
So it will log API calls against Amazon Web Services.
So who rebooted this instance?
Who changed this security group?
And log them into necessary buckets so you
can see what happened in your account and who did it.
>> A new service that we have is WorkSpaces.
So it's a desktop virtualization on AWS.
So you can provision a workstation, a Windows workstation,
and it will then come up in a few minutes.
It'll be connected to your active directory, so with your users.
And you can easily rebuild it.
You can easily provision a new one.
There's different types with different software on there.
>> So now that we've gone through a lot of our services, let's
do an actual live demo.
So I'm going to switch over to my web browser here.
So what I want to show you is how to quickly set up
an EC2 instance with Wordpress on it.
And then we're going to do the same thing,
but we're going to spin up an RDS instance and an ELB.
So we'll do it just on the instance and we'll break all the tiers out as well.
>> So let's launch an EC2 instance.
So the first thing which I've already done here
is you're going to want to have a key pair.
So a key pair allows you to log into the actual instance.
So you keep the private part of the key pair,
and we put the public part onto the instance.
And that's what allows you to log in.
So I've already imported my key pair, just my regular SSH key pair here.
>> And so the other thing I'm going to do here is,
I already have some instances running, but I'll launch a new one.
So I'm going to pick my operating system here.
So you can see I have a pretty big choice of operating system.
So I'm just going to pick your standard Amazon Linux.
>> And I'm going to pick an instance type.
And since this is a web server, I'm going
to do a c3.large because it's probably compute intensive.
So I'm going to pick a c3.large, and I'm going to launch one of them.
I'm going to leave it in the default VPC for now.
I'm going to leave all this stuff alone.
>> And I'm going to enable CloudWatch monitoring
because CloudWatch detailed monitoring changes CloudWatch
monitoring from five-minute resolution to one-minute resolution.
So I want that with my web server here.
And then I'm going to go to storage.
So I want General Purpose SSD on here.
8 gigs is probably enough for me, so I'm just going to keep that.
I'm just going to label it Wordpress Demo.
So this is the tag so I know what it actually is.
And then I'm going to configure a security group.
So a security group is like a firewall for the instance.
So I'm going to use one of my existing ones.
So this security group, it enables SSH, so I can SSH into it.
And it enables HTTP.
>> Now, I'm going to want to lock down that SSH a little bit more.
You don't want just anybody from any IP address SSHing in.
So we'll do that after it launches.
>> So I'm happy with all of this stuff here.
And I'm going to launch.
And then I'm going to choose what key pair I want.
So I'm going to choose that key pair that I updated before.
>> So now that I'm waiting for it to launch, let's
go look at our security group.
So we've got security groups here.
Here's my security group that I put it in.
>> I'm going to just change this here.
So let me make this a little bit bigger here.
So I want to change this from Anywhere to My IP.
Because that will automatically pick up my IP
address here and lock it down a little bit.
>> And so while that instance is spinning up,
let's spin up some stuff for our other instance
where we're going to break out the database and the load balancer
so that it can be ready for us.
So the first thing I'm going to want to do is spin up a load balancer.
So I'm going to choose a load balancer here.
And I'm going to call it WordpressELB.
And I'm going to just-- all I want is port 80 in here.
>> And for now for the health check, I'm just going to do TCP.
So if Apache's running, it'll be good.
And I'm going to lower the healthy threshold just so it becomes healthy
pretty quickly.
Then, again, this has a security group.
So I've already made a security group for this called Wordpress ELB.
And it's basically just going to accept traffic from Port 80.
And then I'm not going to add any instances to it for now.
And I'm going to skip the tagging.
And so we're going to create this ELB right now.
>> So created the load balancer.
I'm also going to launch one more instance here,
just for the web part of my Wordpress.
So here we go.
I'll just do the same thing I did before.
So c3.large, CloudWatch detailed monitoring enabled.
General purpose SSDs.
Call this Wordpress Web.
>> And I want to choose a-- I already have a security group for this.
So this security group accepts traffic on port 80 from my Wordpress ELB
security group, from the security group from my load balancer,
but also SSH, which again, we're going to lock down.
So I'm going to launch this.
Right.
>> And then what I'm going to do next is I'm going to launch an RDS instance.
RDS is going to be my database.
So I'm going to go here.
I'm going to go to RDS.
I'm going to launch a new instance.
So I'm going to pick my engine.
So here I have a choice of MySQL, Postgres, Oracle, or SQL Server.
I want MySQL.
And so I'm going to say yes.
>> So this is an option for Multi-AZ.
So Multi-AZ, again, those replications is going to spin up two RDS instances
and do replication between them.
And if I don't want that I can just have a single instance, but I do want that.
And then I'm going to pick my database engine.
So I'm going to pick the latest one here.
And then I'm going to pick what type of instance I want.
>> So I want an R3, so that's the memory optimized instance.
So I'm going to pick the R3.
And I'm going to pick Yes, I want Multi-AZ.
And I want general purpose SSD.
>> And I probably want a little bit more storage.
I'm going to have 10 gigs here.
And then I'm going to pick some credentials.
So what's identifier for my database?
So it's going to be wordpressdb1.
I'm going to call this root.
I'm going to give it a password.
>> And we're going to pick a security group for this as well.
So I've already made a security group for this.
And then I'm going to give it a database name.
So we're going to just call it wordpress.
And we're going to choose a retention window
so that this does backups for you.
So I want a week of backups.
And I don't have a preference for the backup window.
And I want it to automatically upgrade my minor version here.
So I'm going to leave that as default.
And so now I'm launching my RDS instance.
Right?
So now it's being created.
So now we're just waiting for it to install.
So while that's going on, let's log in to the first EC2 instance we made.
So it's this Wordpress Demo.
And we'll just verify that.
Yep.
>> So let's see if we can log in to it.
So I'm going to copy the public host name of it.
I'm going to open up a shell window here.
[INAUDIBLE] SSH.
The default user is ec2-user.
>> AUDIENCE: Leo, would you mind Command [INAUDIBLE]?
>> LEO ZHADANOVSKY: Good?
And so let's try to SSH in.
Yep.
So I'm in my instance right now.
So I'm SSHed in.
It's up for five minutes so it's definitely my instance.
>> So first thing we're going to want to do here
is it's telling me that, oh, I have some security updates.
So I'm just going to run every security update on here.
[? sudo yum ?] minus y update.
So it's going to quickly install those.
Next thing I want to do is I want to install some more stuff.
So I'm going to have to install MySQL.
I'm going to have to install Apache.
I'm going to have to install PHP.
I'm going to have to install the PHP plugin for MySQL.
And I have to install the MySQL server.
So let's install this stuff.
>> Installing.
So that's done.
So now I want [? HTTPD. ?] I want Apache to start on boot.
So I'm going to do this.
OK.
So now if I reboot this it'll start.
>> I also want MySQL to start on boot.
So same thing.
Oops, typo here.
All right.
And then actually I'll start my web server later.
Now I want to start my database server, though.
So do this.
And so it's starting for the first time, so I'm
going to have to do some basic steps here.
So the first thing I'm going to do is set a root password for my MySQL.
>> So I'm just going run this MySQL secure installation command.
So it's got no current root password, so let's set one.
And I'm going to remove these anonymous users that it creates
and disable root login.
And remove test databases.
So this all kind of productionizes your MySQL install.
>> So that's done.
So now I should be able to connect to my MySQL server.
So I'm going to see if that works here.
Yep.
So I'm in my MySQL server.
>> So now the next thing I want to do is I want to create my Wordpress database.
So I'm going to do MySQL admin.
[INAUDIBLE]
All right.
So I created my database.
>> And now what I want to do is I want to create a Wordpress user.
So I don't want to log in to my Wordpress with the root user
because that would be bad.
So I want a user that can only access the Wordpress database.
So let's go in here again.
And we're going to [? move ?] this here.
>> So what I'm doing here is I'm creating a user that
can connect from localhost that's identified by my super secure password
here.
And then I'm going to grant this user access to the whole database.
All right.
And then now I should be able to log in as that user
and only see that database [? and ?] test database.
>> So I'm going to do mysql minus u wordpress, instead of root.
All right?
And then we should be able to do-- right?
So I can see my Wordpress database here.
So that's great.
>> So now we need to actually download and install Wordpress.
So let's go to our web directory.
So I'm going to Wget Wordpress, the latest version of Wordpress here.
I'm going to extract that.
And now I'm going to swap the HTML directory, which
is the default [? web ?] root, with the Wordpress directory, so.
>> All right.
And now I'm going to just change the permissions so that the Apache
user owns the Wordpress directory.
All right.
And lastly, I'm going to start up my web server and hope everything works.
All right.
So now let's see what happens here.
So I'm going to go here.
And see if I can get into this instance here.
All right.
So here's our Wordpress setup screen.
So we know all this information.
So our database name is wordpress.
>> Our username is going to be wordpress.
I've got my super secure password here.
We're going to be connecting to localhost.
And we're going to run the install.
>> Now we're just going to give my website a name.
So Leo's Amazing Blog.
[INAUDIBLE] username.
I'm going to get a password for my username.
I'm going to put in my email address.
And since it's a test one, I don't want search engines to index this.
So now we're installing Wordpress.
So now we're all set.
>> So here's my Wordpress.
And here's my dashboard.
It's a fully functioning Wordpress.
I can update the plugins here if I wanted to.
Do whatever I want here.
And so here's my actual fully running Wordpress on my one instance.
>> Now, this is great if you have a test site, but this doesn't scale.
We have one instance.
We can make that instance really huge, but at some point
you're going to run out of vertical scaling room.
So you're going to want to scale it more than that.
>> That's why we spun up with all this other stuff.
So let's see if our RDS instance is done.
[? Yes, ?] our RDS instance is almost done.
So that's OK because in the meantime we can set up our EC2 instance.
It's going to be just a slightly different procedure.
>> So we've got our Wordpress web.
Now I already had one running yesterday.
So I've just got to figure out which one was it that I launched today.
So this one was launched November 4.
So that's the one from today.
[? I know ?] this one was launched, oh, 4:00 PM.
So actually this is the new one.
Yep.
OK.
>> So this is my new instance.
So again, I'm going to SSH into it.
So let's go back to my terminal here.
So I'm going to get out of this one.
I'm going to SSH into the new instance.
All right.
So I'm going to have to do some of the same stuff here.
So I'm going to run security updates.
I'm going to install some packages.
The packages are going to be slightly different now.
>> So I don't need the MySQL server because we're breaking that out.
So I'm still going to install the MySQL client.
I'm still going to install Apache.
I'm still going to install PHP and PHP MySQL.
I'm just not going to install the MySQL server.
>> Then I'm still going to make sure Apache starts on boot.
Now we need the database to be up.
So while we do that let's add this instance to the load balancer.
So we're going to go to our load balancer here.
And we're just going to copy down the instance ID.
Got my instance ID here.
>> When I go to my load balancer, see, here's my load balancer,
here's its DNS name.
So it's got zero instances in service right now
because I haven't added any instances to it.
So I'm going to add my instance.
So here's my list of instances.
So if I want this one, so I'm going to add this one to it.
>> Now it's going to wait and it's not going
to enable this instance until it becomes healthy.
And it's not going to become healthy until I turn on my web server.
So let's see if our RDS instance is back up.
All right.
Great.
So our new RDS instance is ready.
So this is the end point for my RDS instance.
So what I'm going to do is I'm going to connect to my RDS instance.
So this is now a fully managed MySQL database.
It's got backup set up on it.
It's redundant.
It spun up in only a few minutes.
So now I should be able to SSH into it from-- or not SSH,
but log into it with the MySQL client.
>> Yep.
So here I am.
I'm in.
So now this is going to be similar except we're just breaking it out.
So, again, I'm going to actually get out of this for a second.
Well, we already created the Wordpress database
because we put Wordpress in there, so I'm going to create the Wordpress user.
And there's going to be some slight differences in here
from what we did last time.
So we're going to create the Wordpress user,
but now we're not going to be logging in from localhost anymore.
We're going to be logging in from the EC2 instance.
And we're not going to necessarily know about what IP address it's coming from,
or we don't want to specify it to that granularity.
>> We're going to have security groups that make sure that only
our web servers can connect to this.
So I'm just going to allow it from, at this level,
from any IP address connection.
So we just did that.
And now we're just going to have to, again,
grant this user access to the Wordpress database.
So now I'm just going to change this to a wild card.
All right.
So we've got that.
Let's get out of here.
So we'll just make sure that we can log in now.
I'm just going to change my username to wordpress.
All right.
So we're in.
So that works.
Now we're going, again, I have to set up Wordpress on this instance.
So what we're going to have to do is go to Var, www.
I have to move the HTML directory to html.old.
All right.
And we're going to have to download Wordpress.
>> All right.
Extract Wordpress.
We're going to move it to the HTML directory.
All right.
And we're going to change the permissions.
And then we're going to start Apache.
>> So what should happen now is there's going
to be basically five retries on this ELB.
And it's eventually, this instance is going to become healthy on the ELB.
So [INAUDIBLE] here.
Let's see.
This instance is not yet healthy.
So what I'm actually going to do is I'm going
to change the health check a little bit more just to make it quicker.
We can change it back later.
So let's say I want healthy threshold of three instead of five.
OK.
So now we're in service.
>> So now I'm going to go to this load balancer.
And it should proxy me back through to this instance,
and we'll set up Wordpress on here.
Now, if you have your own domain name or something,
you can just do a CNAME record to this DNS name.
And the elastic load balancing service is scalable on the back end,
so it scales up and down on its own.
So it could be multiple IP addresses.
The IPs could change.
So you should always reference it from that DNS name.
>> All right.
So here we go.
We're back at our setup screen.
Now we're going to do the same process almost.
So our database name is wordpress.
Our username name is wordpress.
We've got the same super secure password as before,
except the database host is now going to be the RDS instance.
>> So we're going to go here.
We're going to go to RDS.
We're going to go to my instances.
I need my end point name here.
It's this one.
So I'm just going to copy and paste this.
All right?
So let's see if that worked.
All right.
So that works.
So you can connect to the RDS instance.
Again, it's going to be Leo's Awesome Blog.
All right.
>> So now we're going to install our Wordpress.
So we're done.
So let me just log in to make sure it worked.
OK.
>> So now we've got a fully running Wordpress.
We can do all kinds of operations on it.
So the difference now is that we have a separate database.
That databases is redundant.
We still only have one web server, but we could now
take an image of this web server, launch it again,
and then we have two web servers behind this load balancer.
>> The endpoint doesn't change whether it's one, or two, or 50 web servers.
We can scale it beyond this.
So there's plugins for Wordpress where you can use S3 for your static assets.
You can use CloudFront to cache those assets.
You can use ElastiCache so you can use Memcached basically
to store session state there.
>> So as you scale from one to more instances,
you're going to assume that those instances are ephemeral,
so they can go away.
So you've got to think about where do I store logs,
where do I store session state.
How do I make it so it's OK that these instances can disappear, or more
of them can appear?
So you're going to have to answer questions like that.
But it's fairly common pattern.
So you just start offloading any persistent things to other tiers.
>> So now we've got this, we're done [? three tier ?] thing.
The last thing I'm going to do here is I'm
going to make my load balancer a little bit more solid
now that it's marked as healthy.
So it's usually not a good idea for websites
to do TCP health checks because your Apache could be up,
but it could be returning PHP errors.
So you don't want that.
>> So what I'm going to do here is I'm going
to change this to an HTTP health check.
And it's going to be index.php, not index.html.
And we're going to change this healthy threshold back to five.
So that's done.
So that should still be healthy.
Yep.
So we're still in service.
>> So that's how you set up Wordpress on AWS.
So I think in less than 20 minutes we've both set up on an instance, on its own,
and a full three tier architecture where each tier is independently scalable.
You can do all kinds of interesting stuff
with the database to scale as well.
>> Let me show you one more interesting thing here.
So let's say for this I want to break out the reads from the writes.
I can create a read replica.
So I'm going to just create a read replica.
So this is going to be wordpressdb1 read1.
I'm going to do it on the same region, but I
could do it in a different region.
So we're going to start provisioning a read replica here.
So now we're creating read replica.
That's being created there at the bottom.
So you can do all kinds of cool stuff here.
>> So I'm done with the demo.
So I think we have about 10 minutes.
So I'll take any questions anybody has, about any AWS related topic.
Anyone?
Cool.
All right.
Thanks everyone.