Getting an Organization started on AWS Part 6: WordPress & Workloads
Part 1: Introduction, AWS Accounts, IAM & AWS Organizations
Part 2: Multi-Account, Landing Zones & AWS Control Tower
Part 3: Domains, DNS & Route53
Part4: Identity Center, Single-Sign-On & Directory Service
Part 5: WorkSpaces & WorkMail — workforce style users
Part 6: WordPress & Workloads
Welcome to part 6 of the course! The final part of this series is where we’ll be demonstrating running real workloads on AWS. In this demo, we’ll be running a public-facing WordPress site on AWS, using our domain name.
Review so far
So far in the course, we’ve covered:
- Creating and securing our first AWS account
- The how & why’s of using multiple AWS accounts as part of one AWS environment
- Granting AWS & third-party app access to members of our organization through single-sign-on
- Providing members of our organization with an email address, mailbox, and remote desktop
- Creating public-facing VPC and sharing it with the organization
We now have a best-practice backbone for running our IT workloads on AWS and inviting members to participate in the development and IT administration.
Now you may be in a position to do either:
- Build on AWS
- Install / host third-party software, or software you’ve developed in-house
Workloads
This kind of work is what we’ll refer to as “workloads”. Workloads can run on their own dedicated accounts, accounts created through Control Tower.
Because we’re using Control Tower Account Factory to create our accounts, these accounts will be created from a configurable, best-practice blueprint.
This means that guardrails/restrictions can be applied to the account, custom VPC’s deployed into the account, and any AWS resource changes within the account will be logged by AWS Config, with the logs being sent to the Log Archive account.
These workload accounts can be grouped under a WorkLoads OU, and any AWS service limitations can be applied at the OU level.
The workloads accounts will typically rely on resources from accounts within the “SharedServices” OU. For example, a website which is hosted on a workloads account may use a domain name managed by the domains account, or perhaps use shared subnets from the network account…
Next steps
As you take your next steps into AWS, you may find yourself managing lots of different AWS resources across accounts and making changes to many resources at once. Let us take a few moments to consider what we could investigate to help with those next steps.
You may find a use for CI/CD (Continous Integration/ Continous Development). CI/CD allows for the creation of “build” and “release” pipelines. These are automated systems which can quality assess, compile, and release stacks of changes to multiple different resources and environments through the click of a button, or triggered automatically through some sort of code change.
These “pipelines” could live within the AWS account it is deploying to, outside of AWS, or in their own “deployment” accounts. This CI/CD approach becomes increasingly necessary as you begin to manage large sets of workloads.
Furthermore, so far in this course, everything we do on AWS has been done through the management console. We’ve created resources through a “drag ’n’ drop” user interface. However, AWS resources can be defined as a configuration file or through code. This “infrastructure as code” approach (often through AWS Cloudformation) involves structured text documents (.json or .yml files) which can define several AWS resources (VPCs, subnets, Ec2 instances, etc..).
Typically, AWS resources are defined in Cloudformation files and the files are versioned within a tool such as Git or CodeCommit. Pipelines can then deploy these files to multiple AWS accounts to automate the creation of AWS resources.
There is also the CDK (Cloud Development Kit), which are libraries offered in many different programming languages, which allow developers the freedom to define AWS infrastructure through code, which can then be interpreted as Cloudformation files by a tool.
WordPress Theory
Now that we’re ready to start running workloads, it’d be a shame to cut the course short and not demonstrate doing something customer-facing with AWS.
I’ll briefly cover the theory of WordPress, explain ideal architectures and ideas for scaling, and demonstrate a very simple (and not very scalable) WordPress deployment onto AWS.
From there, if you had a need to run WordPress, you could grow your architecture according to documented best practices (links will be provided below)
“WordPress is a free, open-source website creation platform. On a more technical level, WordPress is a content management system (CMS) written in PHP that uses a MySQL database. In non-geek speak, WordPress is the easiest and most powerful blogging and website builder in existence today.”
What this means, is we have the following components:
- A computer (server) that has a publicly accessible IP address
- Some kind of OS installed on the server (normally Linux)
- Webhost software (for example Apache or Nginx)
- The WordPress software (blog site software)
- A SQL database (WordPress connects to this)
- A file system (WordPress writes its configuration files to a drive on the computer)
A user enters a URL in their web browser, the DNS redirects that to the IP of the server, and the WebHost software mediates with WordPress. WordPress mediates with the database, as well as the file system, to produce a response (HTML page, CSS, javascript, images, etc..), the WebHost software then returns that, and it ends up on the user’s web browser.
Our end goal is to have the www. subdomain on our custom domain name to return the WordPress website. We want this website to support HTTPS so that it is padlocked.
The simplest way that I could think to do this, is to run an EC2 instance and create it from a public WordPress AMI (Amazon Machine Image).
This way, we can just deploy an EC2 instance, and without any real configuration, have WordPress running straight away. This involves the WordPress software, as well as the files and database that WordPress uses, being all on one server.
This solution can vertically scale, which means if it is ever too slow, we can just upgrade the instance to have more CPU/RAM specs. Bigger machines = better performance.
However, this does not horizontally scale. We can’t have 10 Ec2 instances running WordPress, all load balanced — since each system will have it’s own version of the database and file system, and that isn’t shared.
A potential ideal architecture for WordPress may look something like this:
^^ The above architecture is from a blog post here and is inspired by documented best practices by AWS, Bitnami, and Automattic. Big shout out to Mike Ng for that brilliant approach.
Though this is definitely more complicated than what we currently need, the essential element is that the database and file system uses RDS and EFS respectively, with the compute services running WordPress (Ec2 or ECS) connecting to those managed services, allowing many different WordPress instances to use the same file system and database.
It is exactly that which allows the system to scale horizontally.
The above architecture also makes extensive use of caching content at multiple layers (Memcached, CloudFront, S3…).
However, the above architecture does use a single-account approach and would have to be adjusted for making use of shared services (shared subnets for example)
Since this is not a WordPress course, I’m going for a simple approach just to demonstrate running workloads utilising shared subnets.
WordPress Walkthrough
Step 1: Go to the SSO portal for your organization and log-into the Management account
Step 2: Go to AWS Control Tower => Account factory. Edit the network config to produce no VPCs. Then create a new account in the “Workloads” OU for hosting WordPress.
Step 3: Go back to SSO and refresh. Log in to the newly created account.
Step 4: EC2 => Launch Instance
Step 5: Name your instance (for example, WordPress) and search “WordPress” in “Application and OS images (Amazon Machine Image)”, or go to “Browse more AMIs” and search “WordPress”.
Step 6: Select “WordPress Certified by Bitnami and Automattic”
Step 7: Select your instance size (larger sizes cost more), create a keypair (this may be used to remotely connect to the instance if needed, this will download to your files), and edit the network settings to use the shared VPC and choose a public subnet
Step 8: Launch your instance, and await the instance to be in the “Running” state with 2/2 status checks passed.
Step 9: Copy the public IP address and paste it into your browser, after some time, you should see the WordPress site
Step 10: add /wp-admin to the end of the URL. This will open the admin login page, where you could log in and administer WordPress (add new blog posts for example). The default username is “user”
Step 11: Now we need to find the default password. Go back to Ec2. Select your instance. Under Actions, go to Actions => Monitor and Troubleshoot => Get system log. If the system log is empty, wait and come back in some time. Cntrl + f (search) for “password”. You will find the default password here. Copy that and use it. You will now be logged in to the admin page. This may take some time.
Step 12: Meanwhile, we can create the load balancer. This is what our DNS settings will point to. Go to EC2 => Load balancers
Step 13: Name it, make it internet-facing, and you could leave it as IPv4 to make things simple.
Step 14: Choose the shared VPC, map to all AZ’s if you wish, and for each AZ — choose a public subnet.
Step 15: Create a new security group. Name the security group and provide a description. Leave the outbound rules as they are
Step 16: Add the following inbound rules
Step 17: Back to the load balancer journey, refresh and select your security group
Step 18: Add two listeners, one for HTTP: 80 and one for HTTPS: 443
Step 19: For each listener, click “Create target group”. For each target group, select “instances”. Name the target groups, for example, “WordPress-LB-TG-HTTP”. Both should be on the shared VPC and have the protocol version of HTTP1.
Step 20: For each target group, after clicking next, under “Register targets”, select the instance and click “Include as pending below”. Click “Create target group”.
Step 21: Back to the LB journey, for each listener, hit refresh and select the appropriate target group.
Step 22: Click “Request new ACM certificate”.
Step 23: Hit Request
Step 24: Enter your fully qualified domain, add another name, and do *.yourdomainname. Choose DNS validation. Hit Request
Step 25: Click on the certificate, and you’ll see two domain records. You’ll need to add these CNAME values to the DNS settings of your domain.
Step 26: Once done, refresh and wait a while. Your certificate should now be validated. Now you have a valid domain, go back to the load balancer journey and refresh for certs. Scroll to the bottom and click “Create load balancer”.
Step 27: View your load balancer. Copy the DNS name.
Step 28: Go to your DNS settings and add a new CNAME record. The value should be “www”, the value should be the DNS name for your load balancer
Step 29: Wait some time for the DNS record to propagate, and now you should be able to go to “https://www.yourdomain” and see that your domain now returns your WordPress site to your browser, but secured behind HTTPS.
Next steps:
This solution involves the file system and the WordPress DB running on the same instance as WordPress itself. Next steps to allow scalability would be:
- Create an RDS or Aurora instance
- Create an EFS file system
- Change the WordPress instance to use the RDS instance
- Mount the EC2 instance to the EFS and change WordPress to install to a path on the EFS file system
- Create a new AMI from your EC2 instance
- Deploy it to the other availability zones and update your load balancer target groups to target all the instances
You could also benefit from changing the WordPress password, and investigating content caching through something like CloudFront.
Conclusion & supplementary reading
Thank you so much for following along with this course, hopefully, it has been useful. Now you should be able to start your org on AWS smoothly and tick off plenty of the compliance boxes you may need to check.
If you do plan on using WordPress on AWS, I would suggest the following supplementary material:
