Getting Started with Amazon RDS – Relational Database Service on AWS

Getting Started with Amazon RDS – Relational Database Service on AWS


Hi, I’m Matt from Amazon Web Services. And in this short video, I’m going
to give you a guided tour of one of our database products, the Amazon Relational Database Service, or RDS. RDS is a web service which makes
it easy to set up, operate and scale relational databases
on the AWS cloud. It provides the familiar capabilities
of MySQL or Oracle databases without the common, time-consuming
database administration tasks associated with a relational database. This means that you can spend less
time on the undifferentiated heavy lifting of administering your
database service, and more time focusing on your applications
and your customers. Amazon RDS has advanced features
which are available to anyone. In just a few API calls or a couple of clicks in the AWS web-based management console. It supports rapid provisioning of
relational databases in a utility computing environment. Just as electricity is delivered
to you as a utility service, where you can consume what you need,
when you need it, and only pay when you’re using it,
so MySQL and Oracle databases are available in a similar manner via RDS. RDS database instances are available on demand, with metered billing based on the
capacity you consume. RDS databases offer scalable storage
under the hood, so you can provision additional storage capacity for your databases as and when you need it. It provides high availability options, allowing you to provision databases
which span datacenters that are redundantly powered and connected, providing a redundant database service
to your application and customers, again, in just a few clicks. It’s also possible to quickly increase
or decrease the computational resources available
to your databases, including CPU and memory. This means that you can increase
the horsepower of your database as your application grows to support
higher number of queries, or an increase in the complexity
of your relational queries. We’ll explore all of these features, illustrated across the entire application lifecycle, from initial development and testing, where teams can quickly get up and
running with a managed database service, which handles tasks
such as backups, patches and replication, allowing
developers to spend more time on their application, and
getting you to release your products to market
more quickly. As your application moves into production, we’ll see how you can schedule maintenance
windows and backup periods and increase the capacity and redundancy
of your database, and show how features, such as read replicas, can help balance database queries
as your product gets more popular. This is a hands-on video, so feel
free to follow along. This is the architectural blueprint
for the application we’re going to deploy live on the
Amazon cloud. It’s a typical multi-tier web application
with a database layer and a collection of application servers
behind a load balancer. We’ll start with a fresh Amazon RDS
MySQL database. Then quickly provision a collection
of application servers on EC2. And balance the connections with
the Elastic Load Balancer. So, let’s take a look at how to provision your first Amazon RDS database instance. This is the dashboard of the Amazon
Web Services web management console, where you can see the list of all
the services on offer. We’ll select the RDS tab, and we’re
shown an overview of our RDS usage. To create a new database, we click
on Launch DB Instance, and then select the database engine,
in this case, MySQL. We can then select some parameters
for our database, the database engine version, the
instance class. This is the size of the underlying
resources for our database. And whether we want to run across
availability zones. We then choose the amount of initial storage available to our database, and enter
the name of our instance, along with a master username and password, which we can use to connect to MySQL
running on the instance. We click continue, and then give
the optional name of the first database to create on
the MySQL instance. Next, we select the backup retention period. RDS databases are automatically backed up and allow point-in-time recovery. We can also select the daily time range during which automated backups are created, and the weekly time range in which
our system maintenance tasks, such as patch level updates, can occur. Finally, we can review the settings
and launch our new instance. Easy as that. You can see that RDS is creating
our database here. This only takes a few minutes, but
we’ll skip forward to when our database is ready for use. So, there we have a MySQL database deployed and ready for use in just a few minutes. From here, we can now attach the
database to the rest of the application. A collection of application servers
running on Amazon EC2, and spin up an Elastic Load Balancer. The app we’ll deploy is a very simple
content management system with a simple relational model. It allows registered users to create new pages, with each page having many page elements,
such as text or pictures. It’s called Clarity, and it will
persist the users, page information, relationships and
page elements to our RDS database. Pictures will be uploaded to a separate bucket in the Amazon Simple Storage Service,
S3. Since we’re focusing on databases here, I’ve automated the rest of this setup
using an AWS CloudFormation template. These templates define a stack of infrastructure building blocks, and
how they are connected. And we can use this to provision
the rest of the infrastructure for us, and automatically configure it to
talk to our RDS database. This is a great approach for spinning
up your deployment, as you go to release your application, and in managing updates to your running
application. So, let’s take a look. Back in the management console, we
can see our running RDS instance, which is freshly installed with a
new database, but doesn’t yet contain our application schema. RDS provides an endpoint, which we
can use to configure our application to connect and start
driving queries and data to MySQL. Take a note of that endpoint, as
we’ll need it again in a minute. We’ll jump to the CloudFormation
tab and click Create New Stack. We give the stack a name and provide the location of our CloudFormation template. If you’re following along, you can
use the same template, which is available here, by just
copying and pasting that URL into the CloudFormation console like so. We can then provide our RDS connection details, the password, the database endpoint,
master username, and the name of the default database. Click the checkbox, review our settings,
and we’re away. CloudFormation will provision the
application instances, S3 buckets and load balancers. We’ll skip forward again to when
our stack is fully deployed. If you click on the stack’s outputs,
you’ll see the website URL, which we can use to access our full
application stack and the security group of the application service. By default, all application and database instances are secured without any open ports. You can control which ports are available
for communication between application tiers using security groups. For example, the application tier
has port 80 opened to the Elastic Load Balancer. Similarly, database instances require
you to specify which resources in the application
architecture can communicate with MySQL. For convenience, we can specify all
application instances with a particular security group. We can take note of the security
group of the application instances, jump back to the RDS tab, select
DB Security Groups from the sidebar, select our default security group, and add permissions to the application
to talk to MySQL on RDS. We can select a new connection type,
EC2 Security Group, select the appropriate group, click add, and you’ll see the status changing
from authorizing to authorized when the change has been applied. We can now jump back to the CloudFormation
tab to view our running application by clicking
on the supplied website URL. This is the URL of the Elastic Load Balancer, and can be mapped to your domain
name using a CNAME, or via the Amazon DNS Service, Route
53. You can now see our fully configured, RDS-backed database application running
in a browser. We just need to add a new user, and we can get started managing our content, adding new pages and page elements,
such as text and images. It’s best practice to deploy a number
of application servers for redundancy at the application tier. These instances can also be spread across a number of availability zones, which are physically separated with
redundant power and connectivity. This means that, if an instance or
even a datacenter becomes unavailable for any reason, our application will remain available
to customers. And we can do exactly the same thing
with our RDS database. We can switch RDS into a high availability mode, which will automatically set up a
standby replica in a different availability zone. Database updates are made concurrently
on the primary and standby resources to prevent
replication lag, and in the event of planned database
maintenance, instance failure or an availability
zone failure, Amazon RDS will automatically fail
over to the up to date standby so that database queries can resume quickly. So, let’s take a look at how to set this up in the AWS management console. To place RDS in this high availability mode, we select the RDS instance and click modify. This presents us with a range of settings, which can be updated on the database instance, including multi-AZ or multi-availability
zone deployment. We change this setting to yes, and can then choose to apply the
change immediately, or wait until our next scheduled
maintenance window. We can then click yes, modify. The relational database service will
then provision and manage a second instance in a different
availability zone. And if we fast forward a little,
the process is complete when the status changes from modifying
to available. So, this gives us a high-availability, multi-availability zone deployment, coupled with a redundant application
tier and scalable load balancer to cope with maintenance and unplanned problems. RDS can also help as your application
grows in stature, receives more visitors, customers and data. There are a range of features built
into Amazon RDS to help you add and remove capacity
to your database instances. For example, as your application
becomes more popular, or the complexity of your queries
increases, you might want to add additional CPU or memory resources
to your database. With the elastic capacity of RDS, you can easily add additional resources by scaling your instances up when
you need to, and scale back down at a later date. In addition to scaling up, RDS can also help scale your database for read-heavy workloads beyond the capacity of a single database instance. You can create one or more read replicas
from a given source database and serve high volume read traffic
from multiple copies of your data. This can increase aggregate read
throughput. Back in the console, we can click modify to view the database instance settings
once again. We can increase the amount of CPU
and memory available by changing the database instance class, and also increase the amount of allocated
storage for our data. Again, we can choose to apply immediately
or at a later time. And click yes, modify, to apply our changes. RDS will then make the necessary
resource modifications automatically. The status will change to available
when the changes have been applied. To spin up a read replica, we can
just click on Create Read Replica. And enter a new instance identifier. We can set the instance class size independently from the source database,
modify some other settings, and select the availability zone
to run the replica in. When we’re happy, we just click yes, create, and RDS will provision a second source
of our data with the appropriate replication
from the master database. It’s that simple. So, there you have it. A guided tour of the Amazon Relational
Database Service. RDS is a powerful tool, which can
support the full application lifecycle. It provides rapid provisioning, automated backups, and point-in-time snapshot recovery. We see how easy it is to use the
RDS high availability features with multi-availability zone deployment. And use replication to scale out
read heavy workloads while modifying database capacity
in just a few clicks. To help get you started with Amazon RDS, we have a free trial available, which
will allow you to run a database with 20 GB of storage for up to 60 days, free of charge. Full details are available on our
website at aws.amazon.com/rds/free-trial. And if you have a larger scale project
already in mind, feel free to get in touch with us
through the form on our website. And with that, I’d like to thank
you very much for watching this introduction to
Amazon RDS. I hope you enjoyed it. Thanks for watching.

Danny Hutson

10 thoughts on “Getting Started with Amazon RDS – Relational Database Service on AWS

  1. excellent content and presentation; can i have concurrent updates between primary and secondary only, but only periodic updates (once daily) to my read copies? scenario is data pull at the customer/client end is once a day usually at a specific time…

  2. Great tutorial! I have a question Can I connect my java app directly to the RDS instance without having an EC2 instance?

  3. Hi:)

    Very Nice video but i have one doubt that; how to access uploaded image again?

    Thanks and Regards
    Pavan

  4. The fact that I just consumed a 16oz iced mocha + watched this == going to make me jump threw a window or something. This is just blowing my mind. Thank you for making this vid!

  5. Oracle 12c Features Not Supported

    The following features are not supported for Oracle 12c on Amazon RDS:

    Automated Storage Management
    Data Guard / Active Data Guard
    Database Vault
    Java Support
    Locator
    Multitenant Database
    Real Application Clusters (RAC)
    Spatial

Leave a Reply

Your email address will not be published. Required fields are marked *