Host Website on AWS (110+ New AWS Hacks 2019)

Host Website on AWS

Host Website on Amazon Web Services (110+ New AWS Hacks 2019)

This tutorial explains how to host a website on Amazon web hosting or AWS step by step manner. This Tutorial also explains how to install WordPress on AWS.


A content management system (CMS) is a platform that is made up of files and data sources and has user and content management capabilities as it relates to web content.

Although a blog is a frequent purpose for the deployment of a CMS-type website on AWSother users are small businesses, special interests, or even corporate web content.


At the time of writing this blog, three very popular versions of CMS platforms are WordPress, Drupal, and Joomla. This section of the blog will give you a good foundation of how to use AWS platform services to be able to host any of these CMS web applications.


To do this, I will dedicate the next blog to discussing the structure of a CMS web application and how you can use AWS to host your site. I will spend some time discussing migration options for those who may have a current blog or website that uses one of the above platforms but want to move it to AWS from their current hosting provider.


I will introduce new AWS services and use a few that you’re already familiar with from earlier blogs.


Website Content Overview


This hosting scenario will consist of a CMS platform website, which has the function of being set up to host web content related to a (mock) challenge to promote an active lifestyle and healthy living.


The main content of the site is the blog content that will be authored by multiple administrators. Visitors will consume that blog content; they can also sign up to join the challenge.


Your goals are to set up the CMS platform site on AWS in an easily repeatable fashion, get the main structure of the site administration set up, and post your first message to your visitors. The main areas that you’ll focus on for this website scenario are as follows


Home The home page will be the landing page of the website. This page will hold basic information for the challenge site, a call to action to sign up for the challenge, and your most recent blog content.


Administration This section will be secured by the CMS web application and will help you set up your website. Your focus here will be to have a properly configured web server and database to be able to install your CMS platform so that you can access this area and create users as well as manage your content.


You’ll set up a page that has content linked off the home page that explains more about the challenge and the origin of the idea.


Contact You’ll set up a contact page that has contact details for your Challenge Leaders.


Website Asset Overview

Website Asset Overview

In your example, you will be deploying the WordPress CMS to AWS to host your site. Where possible, I will give examples of migrating content from existing hosting providers and ways to move data between existing CMS sites and the newly deployed site. the structure of the website is broken down into folders for the Administration section (wp-admin) and main content (wp-content).


Note that the majority of the files are of type PHP. PHP is a server-side processing language that can be embedded into HTML or on its own.


For PHP code to be processed the web server must be able to interpret it, which requires web server modules to handle such tasks. Installing a web server and the needed PHP interpreter modules will be part of your installation tasks for getting your CMS up and running.


In addition to these requirements, CMS sites also load their web content dynamically (at runtime) from a data source such as a database.


You will need to set this up as well; for this need, you’ll turn to the AWS RDS (Relational Database Service) for assistance. I’ll get into detail about the requirements for most CMS-style systems in the next blog, so I won’t go too deep right now.


AWS Services Introduced/Used

AWS Services

The following are the AWS services used in this scenario. Some you have used already; some are new.


AWS S3 Amazon Web Services Simple Storage Service will play another large role in your website hosting implementation. You’ll use it to host static files, as you did in the first section of the blog, but this time you won’t enable the website hosting option on your buckets because they will be read from your web server instead.


AWS EC2 Amazon Web Services EC2 (Elastic Cloud Compute) Service will be used to create a virtual server that will host your web server instance. You will learn how to launch an instance and how you can choose settings such as operating system and size of the server.


You will see how you can pass along additional parameters at launch time that will install software for you and get the web server up and running as quickly as possible. Within EC2 I will also discuss concepts such as security groups, elastic IP addresses, and elastic block storage.


AWS RDS Amazon Web Services Relational Database Services is a fully managed service that enables you to leverage AWS infrastructure to host your database services and workloads.


In your example, RDS will be used as your primary data source for your CMS application. This will hold data content that relates to website users and posts data and other web content such as uploaded images.


RDS is not a requirement; you could load your own database server on the same EC2 virtual server instance that your web server application will be running on.


But introducing RDS and separating the database server from the web server will give you a better foundation for what will commonly be used in larger scale website implementations.


The “fully managed” aspect and benefits of using AWS RDS also include the ability to move many of the administrative overhead tasks such as patching the database server and automatic backups to AWS rather than having you responsible for these tasks.


The architecture of a CMS Website

CMS Website

The last blog introduced the concept of a CMS-based website and how they are used across the Internet today. I discussed that you’re going to be using the WordPress CMS in this hosting scenario and deploying it to the AWS platform.


In this blog, I’ll talk about the structure and requirements for hosting your CMS. I’ll take a look at the architecture and similarities of three major CMS applications.


I will walk through, in more detail, the example web scenario and the assets that you will need to set up to be hosted in AWS. Finally, I’ll talk about data export and migration options for moving an existing CMS website from a hosting provider to AWS.


CMS Structure Overview and Requirements

CMS Structure

Although there are many different CMS applications available, they do have similar structure and make-up in that there will be a collection of static files and application files, and most will require some data source, usually in the form of a database.


The three web applications that you’ll focus on are WordPress, Drupal, and Joomla. the file structure comparison across these three CMS platforms.


You can see that each of the platforms is made up a collection of files. What you won’t see in the file structure is the database; each of these platforms requires the connection to a database to complete the installation.


What you do notice is file folders to hold various items such as content, themes, templates, sites, modules, plug-ins, and more.


These are commonly shared features of a CMS. Since the data content is stored in a database and the static files are stored in the file system, it is easy to adjust website attributes such as the template that is used or header images.


Each page is dynamically created at runtime by combining static components such as design elements and data components such as post or page content to bring the page to the visitor when they view it via their browser.


The main engine that handles the work necessary to construct and display the page is the web server and the application modules/interpreter loaded on the web server.


This is why we refer to a CMS as being a “dynamic” website; the content viewed in the browser is assembled and processed at runtime by the web server and the client browser. This differs from static content, which has all processing done via the client browser.


As mentioned, each of these systems requires a data source such as a database to hold application data and the application configuration. The database is a collection of tables and records and data held in each of those records.


It is worth noting that these are just example comparisons of table structures of two CMS sites that are very different from each other in terms of features that have been enabled.


As your website usage grows and features, plug-ins and applications are added on to your CMS, additional data tables will be created and will hold configuration and application data for those features/modules.


The WordPress example is a simple structure shown after basic installation has been completed. The basic data structure has tables to hold application configuration, posts, comments, users, and additional metadata.


I won’t dig in very deep on the database configuration at this point other than to say that both examples are MySQL databases and that you can host MySQL databases using AWS RDS.


I’ll get into much more detail on the database server and hosting options in AWS in blogs to come, but for now, you just want to understand that there is a requirement for CMS application and content data and that it is stored in structures as shown above.


In addition to the database components, the CMS systems will have a mix of static files and application files. Examples of static files are assets such as images, CSS files, JavaScript files, and HTML files. Application files are things such as PHP files, which are the pages that contain content that will be interpreted and run by the web server.


[Note: You can free download the complete Office 365 and Office 2019 com setup Guide for here]


Architecture Considerations

Static Files

As I’ve discussed, the main considerations that you need to think about when choosing a hosting platform for a CMS website are the following


Static Files No specific requirement other than the ability to store these files.


Application Files You require a web server and runtime interpreter to be able to dynamically generate the web pages and to handle application functions.


Data Source You require a database to store data related to your CMS, including application configuration details and content-related data.

There is more than one way to approach hosting your CMS website. You could architect your site so that all the considerations noted above are loaded on the same web server.


This means that that one resource is responsible for running the web server application and application interpreter, would act as a database server hosting the database requirement and would act as a storage solution to hold the relevant static and application files.


For a simple CMS implementation on a website that is either a development site or a low traffic website, this option is perfectly acceptable and simple to set up. 


As your use case moves more towards a production website, especially one that may need to service an unknown amount of website visitors, your architecture design should evolve into a design that isolates the considerations above in a way that offers ease of management and minimizes the risk of disruption by adding layers of abstraction.


A second option is to separate your static and application files away and not host them on the web server/database server


A third option is to have dedicated resources for each of the considerations, meaning that you have a storage resource for the static and application files, a web server resource to host the web server application and application interpreter, and a database server resource to host the database and relevant data content


The decision about which design to implement is dependent upon your use case. In this case, you have no idea how busy the website will be in terms of traffic. The first two options may be the most cost-effective, but the last option will be the best in terms of scalability if site usage is high.


Using AWS “fully managed” services such as AWS RDS for your data layer also allows for storage to scale behind the scenes without your manual intervention.


If you used a single EC2 server instance as the resource for all of your CMS considerations, it would mean that you need to allocate more storage if your databases grow to a size where more space is needed. RDS database storage will grow as needed and you will just be charged for what you use.


Before I spend too much time talking about AWS RDS, it is probably best to start with an introduction to the AWS EC2 (Elastic Cloud Compute) service you’ll use to stand up your web server.


Introduction to AWS EC2


No matter which architectural design you choose, each choice needs an introduction to AWS EC2 because they all use it as the resource that serves your web server component.


Although I will be using a much more efficient method of setting up the example CMS website in later blogs, for this blog I want to cover the basics of EC2 for those who haven’t had a chance to work with it previously.


You will focus on launching a web server instance using the AWS Console and you’ll learn the commands to do the same work using the AWS CLI.


EC2 is an AWS service that offers virtual server instances to be created as compute resources for your applications. The EC2 service is actually a collection of resources related to the compute instances that you can create, things such as networking resources, storage, and security.


In this blog, you’ll focus on the creation of a new instance of a web server with the goal of creating the virtual server instance, installing the web server application, and testing it to see that it correctly serves up the default test page.


The first way that you’ll create your web server is to launch it through the AWS Console. After logging into your account, click the Services menu and choose EC2.


Under the Resources section, you can see that you currently have no instances running. Actually, the only thing that you have defined is a single security group.


Security groups define inbound and outbound network configurations and are applied to resources in AWS to control access to those resources. As you create your new web server, you will create a new security group for use with your web servers; more on that in a bit.


To launch a new web server, click the Launch Instance button. This will start the EC2 Launch Instance Wizard. The high-level overview of launching an instance is listed in the following steps


\1.\ Choose an AMI 

Amazon Machine Image to be used as the base template for your web server. For this example, choose the first Amazon Linux AMI by clicking the Select button to the right of the description of the AMI.


\2.\ Choose an instance type

Instance types can be described as the type of virtual server that you would like to process your computing needs. Attributes of instance types are based on the number of processing resources and optimization.


Available instance types range from the very smallest (T2.micro) to multi-processor virtual servers that can handle the largest computer processing. For this example, T2.micro should be selected by default. To move to the next step, click the “NextConfigure Instance Details” option.


\3.\ Configure Instance

This section allows you to add any configuration details to your instance to be evaluated at launch. You’ll leave all fields at their default value with exception of the UserData field, which can be found by expanding the Advanced Details section. In the UserData section, enter the text included in this blog’s sample files.


The file is called UserData.txt. This file is a bash script that will be evaluated at launch. The script updates the server, installs the Apache Web Server and PHP applications, adjusts the web server configuration, and creates a sample PHP file to display server information, which will act as a test to confirm that the server is up and interpreting PHP code properly.


Once you have copied the text from the UserData.txt file into the text field on the wizard, click the “NextAdd Storage” button.

Configure Storage

\4.\ Configure Storage

 In this section, you can add a storage-related configuration for your instance. For this example, you will leave all the settings at their default, which will add an 8GB SSD storage drive to your instance as the root storage device. Click the “NextAdd Tags” button.


\5.\ Configure Tags

In this section, you can optionally add tag information to your instance. This can be helpful when organizing and reporting on many instances. For this example, let’s add the value of Web Server under the only tag currently defined, which is the Name tag. Click the “NextConfigure Security Group” button.


\6.\ Configure Security Group

 In this section of the wizard, you can apply an existing security group or create a new one to be applied to your instance. Let’s leave the option defaulted to create a new security group. Name the security group “Web Server Security Group” and leave the description in place.


You should notice that by default the security group created will have port 22, which is the SSH management port (the way you can connect to the server to log in and manage it directly), open to the world. You could limit this to a subset of IP ranges, or only “your own IP” to minimize the security risk of anyone else being able to log in.


For this example, since you just want to stand up a web server and don’t actually have a current need to log into it for management, let’s remove the port 22 entry and add one for port 80 (HTTP). Remove the first rule by clicking the X to the far right of the port 22 rule. Then click the Add Rule button.


In the Type drop-down, select HTTP. In the Source drop-down, choose the Anywhere option. This means that anyone will be able to access this server via port 80/standard HTTP calls. Click the “Review and Launch” button.


\7.\ Review and Launch 


Review the configuration information you entered in the wizard and then click the Launch button to start the creation of your instance. When prompted about a Key Pair, choose the drop-down and select “Proceed without a key pair” option, select the acknowledge checkbox, and click the Launch Instances button.


After you have completed these steps, your web server instance will begin to launch in the background. You can check on the status of the launch by browsing back to the EC2 Dashboard via Services ➤ EC2. Once here, click the Instances link in the left-hand navigation to see a list of your instances.


Near the middle bottom of the screen, you should see text for “Public DNS,” which is the DNS name that can be used in a web browser to access your new instance.


Place the code below in a web browser address bar and substitute the section <> with the value of your instance’s public DNS, the address I will use is http// phpinfo.php


As you can see, not only do you have a web server responding to your request, but the page verifies that this web server can interpret PHP code, which means that the Apache Web Server and PHP were loaded on the server as specified in the User Data configuration during your instance launch!


Although the options that you chose through this setup don’t allow you to easily manage this server instance, it does show how easy it is to launch a web server instance and to specify launch configuration to load applications and perform tasks at the time of launch.


Let’s get rid of this instance from your account by heading back to the Instances window in the EC2 service. Select the single instance that you just created and click the Actions button.


From this menu, choose Instance State and click the Terminate option. This will let you know that you’re about to terminate the instance and remove the attached storage. Confirm that this is what you want to do and click the “Yes, Terminate” button.


Launching an EC2 Instance with AWS CLI


The true power and flexibility of AWS as a platform is that anything that can be done using the AWS Console can be done using the command line interface. Your CLI should still be configured up to your AWS account from the S3 sync example that you performed in the first section of this blog.


To launch an EC2 instance, open a command prompt window and browse to the directory where you have the userdata.txt file used in the above example.


Enter the code below to launch an EC2 instance in your account.

The code below calls to the AWS CLI;

  • tells it to use the EC2 service; runs the run-instances command;
  • passes the AMI ID of the Amazon Linux AMI at the time of the writing of this blog;
  • creates one instance;
  • uses the instance type of t2.micro;


passes the userdata.txt file which loads the Apache Web Server and PHP modules, and applies the ID of the Web Server Security Group that you created earlier.


Note that you will need to adjust the security group ID to match the one in your account since the one in the command below is specific to my account and security group that was created earlier.


To obtain your security group ID, browse to the EC2 Dashboard in the AWS Console and under the Network and Security link in the navigation pane, click the Security Groups option.


From within this view, click the name “Web Server Security Group” and you will find the security group ID in the Description pane. It will be formatted similarly to “sg-12345678”.


aws ec2 run-instances --image-id ami-1e299d7e --count 1 --instance-type t2.micro --user-data file//userdata.txt --security-group-ids sg-5381752b


Once the above code is executed, you should receive metadata information about the new instance back in the command prompt window, as You can now go back into the console to grab the Public DNS name for this newly created instance. Or you can use the CLI to get information about your instances by using the following command AWS EC2 describe-instances


If you place the Public DNS in a web browser and add the PHP page name as you did in the section above, you should be presented with the PHP Server Information page, only this time you didn’t have to walk through the graphical wizard.


The benefit in doing something like this is that the commands used are easily adapted to include full virtual server instance configuration and can then be saved for safe storage just in case you ever need to recreate the instance quickly in the future.


A couple things about the command you used above. First, the term “AMI ID” may not be something that you are familiar with, and as I mentioned, the ID associated with the Amazon Linux AMI will change as that server image is updated or patched.


An AMI is an Amazon Machine Image, and you can think of each of them as a unique server template to be used to launch the instances your request.


AMIs are used to launch new instances, and you can also create your own custom AMI from an existing running AWS EC2 instance, allowing you to “clone” an existing server and its configuration much easier than if it were a physical server located in a data center. Each AMI has an identifier, the AMI ID, which is used to reference it.


“Spring Challenge” WordPress Site

WordPress Site

Now that you know a bit about how you can stand up a web server to be used in AWS EC2, let’s introduce the sample site that will be used in the rest of this web hosting scenario.


You have set up a site on http//, which is the commercial site for WordPress. The company offers free and premium hosting of the WordPress CMS platform sites on their own infrastructure. In this case, WordPress itself will host all static/application files and databases, and act as a web server host for your site.


I’ve opted for the “free” site option to use an example of a site that is hosted external to AWS, but one that you’ll migrate over to being hosted on WordPress using AWS Platform resources. This website is a simple WordPress site with a home page, about page, contact page, and blog.


This website will be the one that migrates to AWS. In the next section, I’ll talk about possible migration paths for moving CMS websites to new hosting providers and I’ll provide an export file of this sample site that can be used for the rest of this section.


You may want to set up your own site or maybe you already have one that you’re looking to migrate. I will include the steps necessary to get the export file in the next section.


Migration Paths for CMS Sites

Migration Paths

As I’ve discussed in this blog, the components, and considerations when hosting a CMS website break down into the static files, application files, and related database content.


This means that if you’re interested in performing a migration of your CMS site from one hosting provider to another, you need to find a way to move these things to your new provider.


In the best case scenario, you have access to all of the files and database at your current host, but there will be times when you don’t have access. If you do have access to the files, you can copy them locally using an FTP program.


If you have access to the database server, you can likely perform a database backup and possibly restore this database at your new hosting provider.


In this example, you have a hosted version of a WordPress site at In this case, you have no access to the file system and no access to the database server.


I consider this one of the most limiting in terms of options, but this makes it a good example because the methods used here will be able to be used by anyone hosting a WordPress site, regardless of whether they have access to the file system files and database.


For your example site, you’ll go ahead and log into your account at and you’ll access the WordPress Administration interface for your WordPress site.


Once logged in, you’ll click the Settings option in the left-hand navigation. If you have a self-hosted WordPress site or a WordPress site hosted at another provider such as GoDaddy, the steps will be the same.


The Administrative interface will be available at your WordPress URL with “/wp-admin” added on to the URL. You will need to know your administrative account and password to log in.


Once on the Settings screen in the WordPress Administrative interface, you should see an option for Export.


Click the Export menu option. From here you can choose which data you want to export. In this example, I’m going to leave the default settings alone and just click the Export All button.


When completed, you’ll see a message that a download link has been sent to your email account. Log into your email and click the link in the email to download the export file.


The file will be in zip compressed format and will contain an XML file with your post data. It is worth noting that images and other assets attached to your post will need to be downloaded from the existing site and uploaded to the new one separately. I’ve attached this sample file in this blog’s folder under the name sampleXMLexport.xml.


Joomla doesn’t have an export option within the interface as WordPress does, but the methods to migrate to a Joomla site are similar in that you move the static and application files and database via methods that are available to you.


Here is a link to the Joomla documentation site for the migration steps https//


Drupal has a module called Node Export that can be loaded to allow for migration between Drupal sites. Methods discussed earlier will also work, including a full backup and restore of the database file and copy over the existing static and application file system to the new provider.


Static and Dynamic Storage Options in AWS


Static Hosting in S3

As you likely remember from the first web hosting scenario, AWS S3 is an object-based storage system that is a low cost, unlimited storage, and high availability solution for storing your files. In the first scenario, I showed how you can use S3 to host your static HTML, CSS, and JavaScript files that make up your web content.


You created S3 buckets, attached policies to control permissions to your bucket and objects within them, and walked through the setup of S3’s static website hosting option for S3 buckets.


Now that you’re looking at your second hosting scenario, the CMS website, you may be wondering how this service can fit into this scenario. Of course, you could still use it to host your static content such as images.


But a core component of a CMS website is the ability for users to upload content. This uploaded content needs a place to be stored and retrieved, and using S3 is a great option for such content.


The benefits in putting this type of content in S3 are multi-fold. First, S3 is highly available storage and uses a more robust infrastructure than hosting your data anywhere else. Second, using a storage source that is detached from the CMS installation means that it will offer greater portability.


If for some reason, you need to change where your CMS website is hosted, you could set it up and point it to the same store which is resting securely in S3. A third benefit is that you can leverage another AWS service, CloudFront, to act as your content distribution network to deliver your content globally in a low-latency fashion.


CloudFront copies the S3 content you choose to AWS Edge locations; when visitors request content from your website, it will deliver that content via the closest Edge location to them, thereby giving that visitor the best possible experience in terms of content latency and network delivery. Although CloudFront and its features are outside the scope of this blog.


There are multiple ways to set up your CMS to use S3 as a storage source. The first is to manually edit configuration files.


Using this option, you can create an S3 bucket to hold your content, copy the content manually to S3, make the content public, and update the configuration in your CMS to point to your S3 bucket for chosen storage options. An easier method exists for some CMS platforms.


WordPress, for example, has an Amazon Web Services plug-in available at https// that will allow you to enter bucket details and security credentials and will update the WordPress configuration files to use that S3 bucket for any future upload content.


Joomla CMS has several extensions available that deliver similar results. One of the popular choices created by developer JoomlArt is JA Amazon S3, which is available at https// extension/ja-amazon-s3. This extension allows for multiple accounts and is quite useful when you’re hosting multiple Joomla websites off the same servers.


Drupal CMS has similar extensions that allow users to extend the platform to use S3 as a file system for additional storage. For more information about one of the extensions, go to


Dynamic Hosting in AWS


As discussed, the separation of CMS content from the web application has benefits in terms of portability and redundancy. When you refer to dynamic file hosting, what you’re talking about is the application files that are used by the web server software.


You may remember from the previous blog that your CMS components include the web server which interprets the PHP code at runtime and the PHP code itself can be referred to as the dynamic/application files.


They can be located on the same storage as the web server or can be detached from that file system by being located on an external system. You could use S3 for this, but I suggest another method using AWS EC2’s volume storage system EBS to host your dynamic/ application files. 


In the solution files that you will share in later blogs, you will use EBS to host the CMS application files separate from your web server, which will use your virtual server instance ephemeral storage.


Ephemeral storage is local file system storage that is attached to your virtual server instance at launch. You may remember that in the last blog when you created a new instance it was created with an 8GB storage volume.


This volume was ephemeral in nature, which means that when the server instance is terminated, the storage volume and the data on it are destroyed. Using an EBS storage volume allows you the opportunity to load data on this volume that can persist, even if the virtual server instance is lost/ terminated.


This can enable you to rebuild or upgrade your web server without having to reload CMS specific files and data. You can also easily copy this volume storage to a second copy that allows you to upgrade your CMS separately and then cut over to the new version when ready.


Amazon EBS Volume Storage

Amazon EBS Volume

EBS can be used as volume storage and can be attached to any virtual server instance. Although you’ll handle this in a much easier fashion in your sample stack creation script later in this section, it is worth going over the basics of how a volume is created and attached to an instance.


Amazon EBS Volumes are located under EC2. You can access or create volumes by logging into the AWS Console and clicking the Services menu and then choosing EC2. From the EC2 Dashboard, click the Volumes link in the left-hand navigation under the Elastic Block Store section.


Click the Create Volume button to launch the EBS Create Volume Wizard. The options that you can select in this one-screen wizard. The options available to you in this screen are to choose the type of volume, size, speed/throughput (if applicable based on the type chosen), location, snapshot information, and encryption configuration. Let’s discuss these options in a bit more detail.


The types of volumes supported in EBS are described in the following list


General Purpose SSD (GP2) General purpose volumes provide the ability to burst to 3000 IOPS per volume, independent of volume size, to meet the performance needs of most applications and also deliver a consistent baseline of 3 IOPS/GiB. This is the default selection and, in most cases, the best choice for applications like CMS platforms.


Provisioned IOPS SSD (IO1) Provisioned IOPS volumes can deliver up to 20000 IOPS and are best for EBS-optimized instances. This option is best when you have selected an EBS-optimized virtual server instance. In the last blog, you selected a t2.micro, which is not an EBS-optimized instance type.


Cold HDD (SC1) A fairly new, price-conscious volume option, introduced early in 2016. Designed for workloads similar to those for a throughput-optimized HDD that is accessed less frequently. Starts at 80 MB/s for a 1 terabyte volume, and grows by 80 MB/s for every additional provisioned terabyte until reaching a maximum burst throughput of 250 MB/s.


Throughput Optimized HDD (ST1) Also introduced in 2016, this volume type is designed for high-throughput MapReduce, Kafka, ETL, log processing, and data warehouse workloads.


Starts at 250 MB/s for a 1 terabyte volume, and grows by 250 MB/s for every additional provisioned terabyte until reaching a maximum burst throughput of 500 MB/s.


Magnetic Originally introduced in 2008 as the first EBS volume type, magnetic volumes (previously called “standard volumes”) deliver approximately 100 IOPS on average, with a best effort ability to burst to hundreds of IOPS. This volume type is the lowest cost option of the available EBS volume storage types.


In the example for this volume creation, choose “Magnetic” as your volume type with a size of 10GB. Choosing this volume types makes the IOPS and throughput options “Not Applicable” because this is not configurable for this type of volume. Leave the location of the volume set to the default availability zone.


It is important to note that volumes are created in availability zones within a region and are limited to use in the region scope. That means a volume created in the US-West-2 region cannot be accessed from the US-East-1 region.


Snapshot IDs allow you to select from stored volume snapshots stored (and publically available/or within your account) and use one as an “image” for the volume to be created from. An example of when you might have a need for this is if you had an existing volume that needed to be grown in size.


Taking a snapshot of that EBS volume and then creating a new larger volume that is based on the snapshot of your previous volume will copy all of the information that is in the snapshot to the new volume.


This can be quite handy and is something that takes a large amount of time to accomplish outside of the AWS platform!. For this example, however, let’s not choose a snapshot to be used as an image.


The last option for you to select in the New Volume Creation Wizard is whether you want to encrypt the volume or not. Volumes that are created from encrypted snapshots are automatically encrypted, and volumes that are created from unencrypted snapshots are automatically unencrypted. If no snapshot is selected, you can choose to encrypt the volume.


Encryption offers a way to encrypt the data stored on the volumes using AWS Key Management Service. When encryption is used, data stored on the volume, data moving between the instance, and the volume and snapshots are encrypted.


Since this is just an example, let’s not enable encryption, but for your CMS platform implementation, I do suggest using encryption wherever possible as an additional security measure and way to protect against data theft. 


Now that all options have been chosen, click the Create button to start the volume creation. Within a few moments you’ll see your new volume being created and within a minute or two the state should be updated to With the volume now being in an available state, you can attach it to a virtual server instance. By using the script provided in the last blog, you can easily launch a new instance to attach this volume.


After running the command using the AWS CLI, you can check in EC2 under the Instances menu option to see your new virtual instance starting up. Once it has moved into the “Running” state, you can attach the new volume.


To attach an EBS volume to an EC2 instance, select the Volumes menu option and select the volume you would like to work with by clicking on the Volume ID. Click the Actions button near the top of the screen and choose Attach Volume.


This will bring up the screen where you can select the instance that you want to attach the volume to and then press the Attach button.


The attach process will usually take less than a minute; once it has been attached you will see that the status is “OK” and the relevant attachment information on the Volumes information screen. This volume is now attached to this instance and available for data storage use.


From the Volumes screen, you will also notice that there are tabs that hold additional information about your volumes, including the Monitoring tab which has quite a few CloudWatch metrics to give you a good indication of how your volume is performing.


As with all CloudWatch metrics, you have the ability to set up alerting if there are specific metrics that you would like to monitor closely and be alerted if thresholds that you define are surpassed.


The last action that you’ll take on this newly created volume is to take a backup of the volume, which is known as a snapshot. From the Volumes screen, select the volume that you just created by clicking the Volume ID. Click the Actions button near the top of the screen and select Create Snapshot to launch the Snapshot configuration.


You’ll enter TestSnapshot for the name for your snapshot and “Creating your first backup of a volume” for the description. The encrypted option is set to “No” because the volume itself is not encrypted, therefore the snapshots will not be encrypted.


Click the Create button to start the snapshot creation process.


Click the Close button on the Create Snapshot pop-up. Once completed, you’ll be able to see your newly created snapshot under the Snapshots link in the left-hand navigation.


Database Services in AWS

Database Services

In the last blog, I gave an overview of storage options available for static and application data files for the CMS website. I revisited AWS S3, introduced EC2 EBS volume options and discussed how detached storage can simplify the management of your CMS, improve performance, and make your website more fault tolerant.


Isolating services using the AWS platform also places the responsibility for the availability of the core services such as compute and storage into the hands of Amazon, who has mastered the challenge of scaling architecture and service availability.


In this blog, I am going to talk about database services available in AWS. I’ll introduce AWS RDS, discuss database types that can be hosted on RDS, walk through the manual and scripted setup of RDS services, and introduce remote management tools that may help with the administration of your RDS data source.


AWS Relational Database Service

AWS Relational Database Service

Amazon Web Services offers several services for your data requirements. One of the most popular options is a fully managed relational database management system (RDBMS) that allows you to use AWS to host several different types of relational databases.


Relational databases allow for the organization of a collection of data in a hierarchy that consists of databases, tables, records, and cells that contain data that can easily and efficiently be accessed, searched, and indexed.


AWS also offers data services that are outside of the RDBMS architecture, like DynamoDB (a No-SQL based system), RedShift (a data warehousing system), and ElastiCache (an in-memory caching system) to help optimize and organize any data that you may need to manage.


AWS RDS is similar to other AWS services in that it is easy to get started with; since it is a fully managed service, there is not a lot of work to be done to keep it up and running after configuration.


This allows you to focus on the management of the data within the database rather than the management of the database service and server.


Amazon has designed this service with scalability and availability in mind and although I’ll be covering simple, single availability-zone installations in this blog, I’ll look at the highly available fault-tolerant and recovery benefits in later blogs in the blog.


Database Hosting Using RDS


AWS RDS can be accessed by logging into the AWS Console, clicking the Services menu, and under the Database section, choosing RDS. As you’ve done with other services, you can also add this service to the quick start menu at the top of the browser as a way to quickly access this service in future visits.


If this is the first time that you have accessed RDS, you’ll be greeted with the service welcome page that has overview information about the service and several calls to action to get started using the service and creating your first database.


Before you get started creating your first database, let’s discuss the different types of databases that can be hosted on AWS RDS.

Amazon Aurora A MySQL-compatible, AWS-optimized database service developed and supported by Amazon AWS.
MySQL A very popular open source database format. RDS offers a hosted version of the MySQL Community Edition server.
MariaDB A popular, MySQL-compatible, open source database format. RDS offers a hosted version of the MariaDB Community Edition server.
PostgreSQL A popular, scalable, open source database. Designed for high volume workloads.
Oracle Designed for large, mission-critical applications. Many complex software applications rely on Oracle Database Services as their data provider. AWS RDS supports multiple versions of Oracle Server, including Enterprise Edition, Standard Edition, Standard Edition One, and Standard Edition Two.
Microsoft SQL Server (MSSQL) Designed for medium and large mission-critical applications. Many software applications rely on Microsoft SQL Server Database Services as their data provider, especially Microsoft products such as SharePoint. AWS RDS supports multiple versions of SQL Server, including SQL Server Express, Web Server Edition, Standard Edition, and Enterprise Edition.


For your CMS website, MySQL or Amazon Aurora are the most likely choices, mainly because all of the CMS applications that you’re utilizing (WordPress, Drupal, and Joomla) support MySQL as the source of their data.


Amazon Aurora is optimized for the AWS platform, but it also ineligible for the AWS free tier use, so for your example and for a test implementation, I recommend using MySQL as the database engine.


Database Creation Using the AWS Console

AWS Console

From the AWS RDS welcome screen, click the Get Started button. If the welcome screen hasn’t been displayed in your account, you can click the Instances link in the left-hand navigation and then choose the Launch DB Instance button to start the New Database Instance Wizard.


 In the first step of the wizard, you’ll be asked to select your database engine. For this example, select MySQL as your database engine by clicking the MySQL tab and then clicking the Select button to move to the second step of the wizard.


In the second step of the wizard, you will be asked whether your MySQL implementation is going to be used for production or for dev/test use. Let’s choose the radio button for dev/test because you want to set up a basic instance that will allow you to see the features of RDS, but this implementation won’t be used for your production website.


Once you have selected the radio button under Dev/Test for MySQL, click the Next button to move on to the next step.

In the third step of the process, you’ll specify your database instance configuration. In this case, you’re talking about an “instance” as a “server instance,” so you’ll need to choose what size of the server to run and how much space to allocate to the instance.


Since you want to stay within the parameters of the AWS free tier pricing, check the checkbox labeled “only show options eligible for RDS free tier.” replacing the DB instance identifier with one of your own and choosing an administrative username and password.


Once completed, click the Next Step button to move to the final step of the wizard.


In the final step, you will specify advanced configuration details for your database instance. You will specify which network (VPC) to install the instance into (in your case, you’ll leave this set to the default).


And the security group to be used (leave this set to create a new group as part of the instance creation and leave the publically accessible option set to “Yes” so that you can manage your instance from client tools on your local computer). You will leave the database name blank so that no database is set up at the time of instance creation.


Now you can configure one of the benefits of AWS RDSautomatic backups. You can select a retention period and maintenance window of when to perform the backups.


You can enable enhanced monitoring if desired, and lastly, you can have AWS RDS perform upgrades to your version of MySQL is preferred. and click the Launch DB Instance button to start the creation process.


It is good to make note of the database instance administrative username and password because you’ll need to use them to connect to the database instance from client tools as well as from installation programs for your CMS websites later in the blog.


After clicking the Launch DB Instance button AWS will create your new RDS database instance and security group. You can click the Instances link in the left-hand navigation to check the status of your database instance.


After the instance is created, an initial backup will be created to capture the instance configuration and then the status will change from “backing-up” to “available.”


If you click the Logs button near the bottom of the instance details screen, By choosing the Details tab on the page shown above (also available from the Instances ➤ Instance Actions ➤ See Details link) you can see your full database instance detail information including the endpoint location for your instance.


Take note of this value, because you’ll need it later in the blog for connecting to the system. The endpoint value is your connection point for your database instance; you can also refer to it as your database server.


Connecting to RDS Remotely for Database Management

RDS Remotely

Now that you have configured an AWS RDS database instance, you can use client tools to connect to the instance and manage your data.


Since you have used MySQL as the database engine type for your RDS instance, you’ll use MySQL Workbench to connect to the RDS endpoint. MySQL Workbench is available from http//


After you have downloaded and launched the MySQL Workbench application, the first thing that you’ll need to do is configure a connection to the RDS database instance.


Once you launch the application, you should be presented with the home screen. From the home screen, click the plus sign next to MySQL Connections to start the Setup New Connection Wizard


From the New Connection screen, choose a connection name and enter the AWS RDS endpoint value. Leave the port set to 3306. The RDS database instance creation created a security group for you and allows connections over this port.


You’ll also need to enter your administrative username that you set up in the AWS RDS Database Instance Creation Wizard. Once you have this information, click the Test Connection button and you should be prompted to enter your administrative password for the database instance.


Once entered, a test connection is established and you should receive confirmation of connecting to the database instance.


If you do not receive a message that tells you that you’ve successfully connected to the RDS instance, you may need to double-check the settings on your RDS security group to verify that connections are allowed from your IP address.


By default, the RDS security group that is created is locked down and you’ll need to add your IP address to be able to connect with MySQL Workbench from your local computer to manage the instance.


Click the OK button after the successful connection test to save the new connection to your MySQL Workbench. Double-click the new connection to launch a session connection to the RDS database instance.


You can now manage all aspects of data that will be loaded on this RDS database instance. MySQL Workbench has administrative tools that allow for direct querying of the server and databases on the instance.


You should notice that there are two databases that currently exist on your RDS instance, InnoDB and says, which are databases used by the MySQL server application hosted in RDS.


Creating Databases


From within the MySQL Workbench application, you can utilize Structured Query Language (SQL) to interact with the RDS database instance to do actions such as create a database. The following code will create three databases on your instance, one for each of the CMS website platforms.


Although this is a simple example, using SQL queries you can interact and manage almost every aspect of data on your RDS database instance. You can create users, assign privileges, create tables, and import and export data using the tools available in MySQL Workbench.


You’ll revisit this tool before the end of this blog to learn how to view and export CMS data that is created from an installation of the platform. This process can be used to take a backup of your data and migrate it to a new instance if needed.


Using RDS as a Standalone Data Source

Data Source

Using tools such as MySQL Workbench you can see that the AWS RDS service can be used as an independent data storage solution. Once an RDS database instance has been initiated, it can be used and managed by you in any means you require.


You may even choose to use this as your database platform of choice for web applications hosted externally from the AWS platform. Although unconventional, you could host a blog or CMS website at one hosting provider and still point to AWS for your database instance and data.


Web Server/CMS Installation

Web Server

In this section, I’ll walk you through the installation of each of the CMS platforms I’ve been discussing in this web hosting scenario.


Using the AWS CLI, you will launch an EC2 virtual server instance, install the Apache Web Server application with PHP modules loaded, install MySQL DB server on the same host (although you’ll use the AWS RDS instance that you set up above), download a copy of the CMS platform to be deployed, unzip the archive, and prep the CMS for you to walk through the installation.


You will use a web browser to point to the freshly launched AWS EC2 web servers and will browse to the installation wizards for each platform.


During the installation steps for each CMS, you will provide setup information manually and will point the web server to your AWS RDS database instance for the data source to be used to complete the setup. At the end of each section, you will have a generic, running version of each CMS platform.


Before this can work, however, you’ll need to open up traffic to be allowed from the web server security group inbound on the RDS security group. While you’re making this edit, you’ll also add port 22 for management via SSH from just your IP address (the most secure).


Complete the following steps to add the web server security group to the existing RDS security group that was created for you as part of the AWS RDS database instance creation

\1.\   Click the Services menu from within the AWS Console and click EC2.

\2.\   Click the Security Groups link in the left-hand navigation.

\3.\   Click the rds-launch-wizard group name to select that security group.

\4.\ Click the Inbound tab in the Security Group properties section near the bottom of the screen.

\5.\   Click the Edit button.

\6.\   Click the Add Rule button.

\7.\   Choose MySQL/Aurora in the type drop-down.

\8.\   Choose Custom under the Source column.

\9.\ In the text box next to the Source column, type “Web Server Security Group” and select the group to add the Security Group ID to the text box.

\10.\   Click the Add Rule button.

\11.\   Choose SSH in the type drop-down.

\12.\   Choose My IP under the Source column.

\13.\   Click the Save button.


WordPress Install Using the AWS CLI and User Data File

I have included a file with this blog called UserData_Wordpress.txt. The contents of the file are as follows

find /var/www/html/wordpress -type d -exec chmod 2777 {} + find /var/www/html/wordpress -type f -exec chmod 0666 {} + echo "<?php phpinfo(); ?>" > /var/www/html/phpinfo.php


This code will look familiar; however, this script has the addition of MySQL as well as downloading and extracting the WordPress CMS. From the workstation configured with the AWS CLI, you’ll enter the following command, which is a modified version of the AWS EC2_CLI_Launch.txt file

aws ec2 run-instances --image-id ami-1e299d7e --count 1 --instance-type t2.micro --user-data file//userdata_Wordpress.txt --security-group-ids sg-5381752b --key-name nadonhosting


This code will launch a new EC2 virtual instance using the UserData file that is specific for the WordPress CMS. After running the command above to launch the instance, wait a couple of minutes to allow the instance to spin up, load software, and pass health checks.


After a few minutes, browse to the following URL, replacing the bold text below with your EC2 virtual instance DNS name http//


Click the “Let’s go!” button to begin the installation wizard. You will enter a database name, the RDS database instance username and password, and the RDS database instance endpoint and table prefix, if desired. After you have filled in the needed information, click the Submit button to move on to the next step of the process.


The installation program will test the connection to the database endpoint and, if successful, will let you know that it’s ready to start the installation.


Click the button presented and the next step will collect site configuration details such as site title, administrator username and password to be created, email address, and other options.


Once you have entered in the information requested, click the Install WordPress button to start the installation of the WordPress CMS on the server and the setup of the database in the RDS database instance. When the installation completes, you will be returned to the Administrative Sign-In page.


You can now log in with the administrative username and password that you specified in the site configuration step above. This will then allow you to access the WordPress CMS administration so that you can complete the rest of the site setup.


Exporting/Importing Data Using MySQL Workbench

MySQL Workbench

I want to show you how to use a client-side tool such as MySQL Workbench to back up the data that is stored in AWS RDS because there isn’t a native way to move the data from AWS in an exportable format.


As you learned earlier, it is as simple as setting up a new connection to connect your RDS database instance endpoint with this client software and then you can browse through databases that are set up on RDS.


With this view open, you can click the Server menu item and choose Data Export. When the Data Export screen opens, you will be presented with a screen that lists all of your databases on the RDS database instance.


On this screen, you can select the database that you would like to export (you do have the ability to select multiple, but my suggestion is to keep each database exported as its own file) and ensure that the drop-down box that describes what you would like to export is set to “Dump Structure and Data” so that all tables and the data included within them will be exported.


You also have the ability to include database objects such as stored procedures, functions, database triggers, and events. My suggestion is to export as much of the data as possible.


This data export process will export all information, including structure and data, to a file with the extension of SQL. It actually stores not only the data but the SQL commands necessary to completely recreate this structure and data upon import into a fresh database server instance.


This makes for a very portable solution if you ever want to bring down a copy of your live data to be worked on locally, or if for some reason you want to move your data outside of AWS.


Once you have double-checked the export settings, click the Start Export button to begin the process of creating the export file. After the export file has been created, opened it with a text editor to show the output that is created