Adrian Cantrill’s SAA-C02 study course, learn.cantrill.io, 90 minutes:
Review: ‘Database refreshers and models parts 1 & 2’, ‘ACID vs BASE’, ‘Databases on EC2’
Sections: ‘[DEMO] Migrating the WordPress Monolith to a Dedicated EC2 DB’, ‘Relational Database Service (RDS)’
CSA CCSK Exam, 20 minutes:
Sections: ‘The effects of service model and Deployment Model’; part 1: service model
‘[DEMO] Migrating the WordPress Monolith to a Dedicated EC2 DB’: Today I implemented a demo to practice using the theory that was covered in the first four videos for this section, which I reviewed before starting the demo. The goal was to split the WordPress EC2 instance into two separate instances, one instance containing the webserver and application, and the other containing the database. The first step was to click on the one-click deployment to deploy the CFN infrastructure, which created a Animals4Life base VPC Template and Boostrapped WordPress along with an Empty MariaDB EC2. After CFN completed the infrastructure, we opened EC2 in a new tab, where there were two EC2 instances created, an A4L-Wordpress instance, and an A4L-DB-WORDPRESS instance. The plan is to migrate the MariaDB from the WordPress EC2 instance onto the DB-Wordpress EC2 instance. To begin, we installed WordPress. After this we created a simple blog post where we uploaded a few pics to the blog page along with a title. Having created the blog post, we published the post to add some data to the database. We then proceeded to visit the site, and clicked on the name of the blog post in order to see the post. The images for the blog are stored on the A4L-Wordpress instance, while the data for the post is stored on the MariaDB database, and we then proceed to migrate the data from the A4L-Wordpress EC2 instance onto the MariaDB EC2 instance. We started by using instance connect to connect to the A4L-Wordpress EC2 instance, then we took the data stored on the instance and moved it to be stored in a backup .sql file. This was followed by injecting the .sql file into the MariaDB database. We modified the injection command to use the private ip of the MariaDB database, which we copied from the EC2 instance details page for the MariaDB instance. This was followed by configuring WordPress to point to the database server by editing the wordpress configuration file in nano, changing the dbhost from ‘localhost’ to the private ip of the MariaDB server. The point of this whole exercise was to implement worst practices for db management by setting up the db on it’s own EC2 instance.
Relational Database Service (RDS): RDB is often referred to as ‘database-as-a-service’. This is not entirely accurate. With a true database-as-a-service product, your unit of consumption from the product is the database. You pay for access to that database, with a certain capacity and capable of a certain level of performance. RDS is more accurately referred to as a databaseserver-as-a-service product. RDS is a product which provides managed database instances, which can themselves hold one or more databases. With RDS, what you’re paying for and consuming is a database server that you have access to. You get access to a managed database instance, and you can create one or more databases on that instance. The benefits of RDS is that you don’t have to manage the physical hardware or the server operating system or the database system itself. AWS handles all that behind the scenes. RDS supports the most popular database types you will encounter (MySQL, MariaDB, PostgreSQL, Oracle, Microsoft SQL server, etc…). You can pick whichever one you need for your real world requirements, and should have a basic understanding of the limitations and requirements for each database type. Amazon Aurora is another AWS database type, which is technically part of RDS. It is a database engine you can select when creating RDS instances. It is very different than the normal RDS models, to the point where it can be considered to be a separate product. Basically, if you have a requirement within AWS for databases, and don’t want to have to deal with the overhead of running EC2 instances with database software on them, and you can use one of the database engines, then RDS offers massive benefits in terms of reduced admin overhead.
The basic building block of RDS is the db instance. An instance runs one of a few types of database engines, and it can contain multiple user created databases, the first one created when the instance is provisioned, the additional ones being created afterwards. The database instance is accessed using a database CNAME, a database hostname, and this resolves to the database instance itself. This is the only method that you have to connect to this RDS instance. You can’t directly use IIP addresses, you have to use the CNAME. RDS uses standard database engines, so you can access an RDS engine using the same tooling as if you’re accessing a self-managed database. RDS instances come in various shapes and sizes, they share many of the same features of EC2, but they’re all prefixed with db. One example is db.m5, which is a general purpose type, db.r5, which is a memory optimized type, and db.t3, which is a burst instance type. Each of the types also has a variety of sizes, which controls the amount of cpu and memory that the instance comes with. RDS instances can be single-AZ, whether it’s one piece of hardware located in one availability zone, or multi-AZ, where two instances work together to provide and active-passive style of failover.
For RDS, when you provision an instance, you also allocate storage for that instance to use, the storage is dedicated to that instance. So, a single AZ-deployment has one attached piece of block storage, which is essentially EBS storage, and it’s located in the same AZ. So RDS is vulnerable to a failure inside that AZ. The allocated storage can be based on SSD storage (gp2 or io1), or it can be magnetic. The architecture applies as in EC2, with gp2 the default, io1 offers high-end performance, lots of IOPS and consistent low-latency. GP2 has the same burst pool architecture as it goes on EC2. Magnetic is offered more for compatibility. AWS encourages use of gp2 as default.
Billing for RDS has a number of different components. The first thing to understand is that you’re billed for the RDS instance that you use. The instance comes with a certain amount of cpu and memory, and whatever you allocate for your RDS instance, there’s an hourly rate for that compute, cpu and memory. You are also billed an amount for storage, for the amount that you allocate, using a GB/month metric. If you select provisioned IOPS storage, you also pay extra for any IOPS guarantee that you add to that storage. From a security perspective, access to the RDS instance is controlled by a security group which is associated to that RDS instance. You can use an existing security or create your own, but whatever is in that security group that is attached to the RDS instance controls access to that RDS instance.
CSA CCSK study guide: ‘The effects of Service Model and Deployment Model’; part 1. service model
Attention must be paid to how the service and deployment models affect the ability to managed governance and risk.
SaaS: In the majority of cases, SaaS presents the most critical example of the need for a negotiated contract. Such a contract will protect the ability to govern or validate risk as it relates to data stored, processed, and transmitted with and in the application. SaaS users tend to cluster at either end of the size/capability spectrum. The likelihood of a negotiated contract is much higher with a small SaaS provider. Level of visibility into actual operation of infrastructure providing SaaS applications is limited to solely what is exposed in the user interface developed by the Cloud Provider.
PaaS: The level of detail that is available increases from SaaS. The likelihood of a fully negotiated contract is likely lower here than with either of the other service models. This is because the core driver for most PaaS is to deliver a single capability with very high efficiency. PaaS is typically delivered with a rich API, and many PaaS providers have enabled the collection of some of the data necessary to that SLAs are adhered to, although the customer is still in the position of having to exercise a significant effort in determining whether contract stipulations are effectively providing the level of control or support required to enable governance or risk management.
IaaS: This service model represents the closest that Cloud comes to a traditional data center/outsourced managed data center, and most governance and risk management activities that organizations already have built in are directly transferrable. There are new complexities related to underlying orchestration and management layers. In many ways the governance and management of that orchestration and management layer is consistent with the underlying infrastructure of a traditional data center. The same governance and risk management issues are present, but the exposure of those systems is sufficiently different that changes to the existing process are required.