Amazon Web Services (Best AWS Tutorial 2019)

Amazon Web Services

 

Amazon Web Services (AWS) Tutorial 2019

This tutorial explains the complete overview of Amazon Web Services with best examples. And we will also explain Amazon Web Services EC2, AWS CloudFront, AWS Security Services and AWS Enterprise Solutions 2019 in detail.

 

This tutorial explains e-commerce hosting scenario, you’ll also start looking at the features of the AWS platform that will appeal to those hosting enterprise architecture in data centers who are looking to extend their service catalog or infrastructure into the cloud. 

 

Before I describe the architecture of the next hosting scenario, let’s touch base on the concepts and AWS services that will be covered in this section of the blog.

 

AWS Services Introduced/Used

AWS Services

AWS S3 Amazon Web Services Simple Storage Service will be revisited a third time as your main storage location, although this time you’ll also start managing a storage lifecycle for your S3 assets. You’ll also use the AWS Glacier Storage Solution as a long-term archiving solution.

 

AWS EC2 Amazon Web Services EC2 (Elastic Cloud Compute) Service will be used in this scenario. Your e-commerce website will be fully redundant and will support Auto Scaling to adapt your infrastructure based on your website traffic needs.

 

This means that you’ll have multiple EC2 virtual server instances running your web server application and available to serve your content.

 

You’ll learn AWS networking concepts including VPC (virtual private cloud), Elastic IPs and their use, and more, including a deeper look at web traffic load balancing using Elastic Load Balancers and Application Load Balancers.

 

AWS CloudFront You’ll use Amazon Web Services CloudFront, the CDN (content distribution network) solution for efficiently delivering your website content to customers across the globe in a low-latency, geographically optimized way.

AWS RDS

AWS Workflow Services You’ll spend some time learning about the ability to extend your efficiency and interaction with your new infrastructure by using AWS Workflow Services including SNS (Simple Notification Service), SQS (Simple Queue Service), and code deployment options including Elastic Beanstalk, OpsWorks, and CodeDeploy.

 

AWS Security Services You’ll learn about the various services and products that are at your disposal to help with infrastructure security, reporting, and compliance. Topics will include implementing SSL certificates on your website, as well as introductions to AWS Inspector, AWS CloudTrail, and AWS Trusted Advisor.

 

AWS Enterprise Solutions Lastly, you’ll learn about AWS platform services, which enable you to extend your business into the cloud and deliver desktop workstations, enterprise mail, directory services, and document management to your employees. You’ll also see how these services can be used to fill short-term needs for trainers or instructors.

 

Overview of Services

In addition to the information covered above, you’ll explore the current service list offered by AWS at the time of writing this blog and you’ll learn about the release rate of new products and services from this cloud vendor 

 

 

Website Content Overview

Website Content

This hosting scenario will be focused on a hypothetical enterprise-level website that has e-commerce capabilities plus the requirement to support a small staff operating in a physical location. In your scenario, the website will have the following resources and requirements

 

Home The home page will be the landing page of the website. This is the place where the majority of the advertising and “call to action” activity will occur for this website. It is also the front door to the e-commerce sections of the website content.

 

Products This section will have the sales information on the products that you are selling from your online store. As you’ll see from the folder structure breakdown later in this blog, there will be a few different product types. In this example, the business is selling various artworks on the site.

 

Promotions This area of the site will hold information pertaining to monthly promotions and discounts that the business will offer to its customers.

Static Content This section of the website will hold your static assets, such as images and documents.

 

Store This e-commerce website scenario will most definitely have a shopping cart/online merchant component. Some may choose to implement a simple way to process payments and orders from a site such as PayPal, and others may choose to use a more complex online store solution like Magento. In your scenario, you will assume and plan for the latter.

 

The installation of the Magento application will be installed in the Store directory within the site structure and you’ll need to plan for not only database resources for your website but also for this component, which will hold your product inventory and all the details about it.

 

Contact The traditional contact page will also have a feedback form, your social media presence information, and physical store location information.

 

Website Architecture Design

Website Architecture

This section covers the architecture design for the website scenario. This design will deliver a highly available, fault-tolerant website hosted in AWS and leveraging the built-in redundancy of having multiple availability zones (AZ) within a given AWS region.

 

When deploying resources such as EC2 instances or RDS database instances in AWS, you can select whether you’d like them to be placed in a specific AZ.

 

In most cases, when you’re standing up resources for testing or development, fault tolerance is not an issue at the top of your mind, so you usually just deploy a single resource to a single AZ within a single region.

 

However, production-level websites and applications require fault tolerance, so for this website hosting scenario, you will deploy multiple resources in multiple availability zones.

 

You will front all of your web traffic using AWS Route53, which you’ll remember is a highly available DNS service with a 100% SLA. From here, you’ll have Route53 route your web traffic to a pair of redundant EC2 Elastic Load Balancers.

 

The load balancers will pass the traffic on to your EC2 instances, which will be part of an Auto Scaling group configuration so that you can configure a minimum and maximum setting for how many web servers you want and allow AWS to handle scaling up the infrastructure for you on-demand as your resources become more utilized from web traffic or processing requests.

 

Each EC2 Auto Scaling group will be inside an availability zone with an RDS database instance for that availability zone. You’ll have the same infrastructure configured in a second availability zone for an additional level of fault tolerance.

 

Think of availability zones as data centers. This setup allows you to have EC2 and RDS resources in two locations so that if the infrastructure in one of them fails, you can route traffic to the second. EC2 resources in

 

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

 

Content Lifecycles, Management, and Backup

AWS_manage

 

Managing Content Lifecycles in S3

Managing Content

Throughout this blog, you’ve been introduced to and revisited features within AWS Simple Storage Solution (S3).

 

In this third hosting scenario I presented the enterprise website scenario, a business that not only supports and hosts a highly available, fault-tolerant e-commerce website in AWS but wants to be able to use other services on the platform in order to be as effective as possible.

 

Content lifecycles refer to the effective lifespan of a piece of data. The start of the lifecycle is when the data is created and the end of the lifecycle is when the data is deemed no longer of value. Lifecycle management features are accessed through your S3 Dashboard and specifically at the bucket properties level.

 

By default, objects (including buckets and folders) created in S3 use the Standard storage class. You’ve seen the other types mentioned earlier in this blog, but I didn’t spend much time talking about them. Let’s take a look at the three storage classes now.

 

The Standard storage class is the default storage type for all S3 objects. This class offers the highest level of durability in terms of SLA at “eleven nines” or 99.999999999% durability and “four nines” or 99.99% availability. This storage class is used for general storage where items are accessed frequently.

 

Behind the scenes, AWS replicates your data across its own infrastructure to make sure that your data is there when you need it.

 

As it relates to your promotions folder, this class is the default setting for all objects (bucket, folder, and object) contained within it, so there are no changes to be considered until you learn more about the other class types.

 

Standard - Infrequent Access is the next level of storage class available for S3 objects. This class offers the same level of durability and one less “nine” or 99.9% availability.

 

This class is best for data that is still needed in terms of accessibility, but less frequently. This class has a lower per-GB fee for storage of objects but also has a per-GB fee for retrieval of objects of this class.

 

In terms of your promotions folder, it would make sense to have your current month promotions set as Standard, but you could change the storage class to Standard - Infrequent Access once the current month promotions have passed.

 

 

Using AWS as a Backup Strategy

AWS_backup

We all know how important it is to have a current backup of your data. Bad things do happen and it is important to plan so that you can return to being productive as soon as possible after an incident where data restoration is needed. Amazon Web Services offers backups and fault tolerance in all of its platform services.

 

You had some exposure to this earlier in the blog when you configured AWS RDS. As part of the configuration process within RDS, you can specify your preferred backup preferences.

 

RDS automated backups are set for a three-day period. Each day during the configured maintenance window a backup (also referred to as a snapshot) will be taken of the RDS database instance state.

 

This snapshot can be used to restore the database instance to a point in time, or used as a baseline for setting up a new database instance.

 

The concept of a snapshot is used widely across the platform services in AWS as a method for providing infrastructure backups. A list of available RDS snapshots is available for viewing from the RDS Dashboard, under the Snapshots link in the left-hand navigation. 

 

Backup options exist for all platform infrastructure services. Copies of CloudFormation templates are stored on S3. S3 buckets can be copied across regions to provide redundancy and data protection.

 

EC2 uses the concept of snapshots for backing up data volumes attached to EC2 Virtual Server instances. To access this, you can log into the EC2 Dashboard and under the Elastic Block Store section, click the Snapshots link.

 

From here you can click the Create Snapshot button to create a new snapshot manually, which will capture information about the snapshot you would like to create and for which volume you would like to create a snapshot.

 

In addition to doing this manually, you can also choose to script this process using the AWS command line interface or other development and administration tools. Taking a snapshot of an EBS volume is a simple process and is an incremental backup based on the last successful snapshot.

 

This allows you to do point-in-time restores of the data if needed. The following link is to online documentation from AWS of a tutorial on how to set up automatic snapshots of EBS volumes using CloudWatch

http//docs.aws.amazon.com/AmazonCloudWatch/latest/events/TakeScheduledSnapshot.html

EC2 Virtual Server

EC2 Virtual Server instances can also be backed up for later use/restoration. In this case, the backup process is referred to as taking an image of the server instance state.

 

Taking an image of an instance is accessed through the Action menu from the EC2 Dashboard. Browsing under the Image menu option, you’ll find the link/option for Creating an Image. 

 

Now that I’ve talked about some of the infrastructure backup options that AWS provides for your infrastructure services in the cloud, I should mention that AWS can also be used as a platform to back up important information from your home or business.

 

I showed you how to create S3 buckets and how to use the AWS CLI to sync local folder content with the S3 bucket. This same methodology can be used to scheduled tasks and network share locations on your business network.

 

A contextual use case for this type of backup is backing up customer orders, shared documentation, and company marketing assets or training material. AWS S3 is an excellent, low-cost, highly available option for your backup storage, but if you’re looking for something that is even lower cost, AWS Glacier may be a better fit for your storage needs.

 

Getting Large Datasets into AWS

AWS_datasets

There may be times when you need to get a large amount of data or resources migrated from your location into Amazon Web Services. There are a couple key services that may assist with these tasks.

 

AWS has a Database Migration Service (DMS) that will help you migrate and replicate your data from your on-premise database system into the AWS platform. The process requires at least a source database, replication instance, and a target database.

 

Database conversion tools are available to help you to migrate from one platform to another, including modifying the data schema of the database. More information on the service can be found at https//aws.amazon.com/documentation/dms/.

 

For migrating server instance resources, the AWS platform offers the AWS Server Migration Service. This service helps you move your virtual server infrastructure from your location to the cloud.

 

The most popular Windows and Linux operating systems are supported by the service, and this is a great option when the goal is to move a server from being hosted on-premise to AWS.

 

More information about this service can be found in the AWS documentation at http//docs.aws.amazon.com/server-migration-service/latest/ userguide/server-migration.html.

 

If the resource that you need to move into AWS is a large amount of raw data, the AWS Snowball service may be the best fit for you. Snowball is an ultra-secure option for migrating large amounts of data from your site into AWS.

 

The device will be shipped to your location, ready to be plugged in and accessed by your network and computing resources. Snowball devices come in 50TB and 80TB sizes, allowing you to transfer data to them locally and then ship them back to AWS.

 

Then AWS will migrate that data to its storage resources and make it available to you. For data sets larger than 10TB, this process is often much more cost/time effective than trying to transfer the data via the Internet, and it is definitely more reliable and secure.

 

More information about AWS Snowball can be found at https//aws.amazon.com/documentation/ snowball/.

 

 

External/Third-Party Monitoring Options

AWS_monitoring

The previous section discussed how you can use CloudWatch as a monitoring solution for your services and infrastructure in AWS. CloudWatch is definitely not the only option for enterprise monitoring of your resources. There are many third-party applications that offer cloud monitoring services.

 

A few examples that come to mind are DataDog and AppDynamics. DataDog is available from www.datadoghq.com/ and has a nice list of application integrations to help you receive notifications about infrastructure health in applications you may already use frequently, such as Slack.

 

AppDynamics is available from www. appdynamics.com/ and is well designed for monitoring application stacks and the health of the application components. Both of these providers have free trials that can be used to test their services and reporting on your infrastructure before committing to a long-term engagement with them.

 

The two examples above are third-party service providers that can help with your monitoring; however, if you want to host your enterprise monitoring solution yourself, you can spin up AWS resources within your AWS account to monitor infrastructure. There are many open-source options available for this method of implementing enterprise monitoring.

 

Two that come to mind are Zabbix, which is available at www.zabbix.com/, and Nagios, which is available at www.nagios.org/. Both offer enterprise-level monitoring for your infrastructure and applications and can be set up with minimal resources to monitor your environment.

 

Choosing self-hosted, third-party, or the AWS-included monitoring solution is most definitely a choice based on preference, time, and cost-based commitment.

 

Some may choose the flexibility and lower cost of self-hosting, while others will prefer the time-saving option of using a third-party service provider. While looking at either of these options, you can use AWS CloudWatch and evaluate whether or not it fits your needs.

 

AWS Security and Securing Website Communication

AWS Security

 

AWS Trusted Advisor

 AWS Trusted Advisor

AWS Trusted Advisor is a best practices analyzer that runs at the account level within AWS and analyzes your accounts and resources within AWS and reports on best practices that should be implemented.

 

An example is the EC2 security groups that are open to anyone or if your AWS root account is not using multi-factor authentication.

 

In addition to security best practices as the previous two examples illustrate, the tool will also report on performance optimization that can be achieved, such as applications that are running on underutilized EC2 instances. 

 

There is a summary at the top of the Trusted Advisor dashboard that shows checks that are OK or have warnings and issues. This resource is a very valuable one and should be used at the beginning of your AWS hosting journey and at regular intervals thereafter.

 

AWS Inspector

AWS Inspector is an agent-based security tool that can be used to run against EC2 resources to report back on security vulnerabilities and give information on how to remediate them.

 

The process for using AWS Inspector is to load the agent on resources that you would like scanned and then to set up scheduled assessment scans to run against those resources.

 

You can limit not only the scheduled time but how long the assessment scans run and analyze the resource. This fine-tuning means that you can gather information about the resources with minimal overhead and impact on your operation of them.

 

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

 

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

 

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.

 

CMS Structure Overview and Requirements

 

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.

 

 

Architecture Considerations

 

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.

 

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.

 

“Spring Challenge” 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//wordpress.com, 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 wordpress.com 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.

 

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.

 

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.

 

Using RDS as a Standalone 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

 

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.

 

Recommend