- All right.
So, now let's review a demo
of launching an Amazon RDS instance.
From the AWS Management Console dashboard, we'll go to RDS.
Before we create a database,
we need to do one very important thing.
We need to set up the networking for our database.
We don't just launch one.
We have to launch it into a network.
And we already have a VPC,
but we can't just select subnets directly.
We have to launch the database into a subnet group.
So, before we can launch the database,
we need to create a subnet group.
And so, we'll go ahead and go over here to subnet groups.
We'll then say create DB subnet group.
And here we'll call this one fundamentals.
You will choose a name
that makes sense for your particular scenario.
And we'll call this one the RDS subnets for AWS LiveLessons.
And then we'll choose the data stores VPC.
And then we will choose the particular subnets that we have.
We can add all the subnets in that VPC.
I've taken the liberty of creating a couple
of slash 28 subnets and the data stores VPC.
And so, now we don't really choose those subnets directly.
We tell AWS hey, here's a group of subnets.
Choose the one that works best for you.
And so, now once we create that,
now that we have a subnet group,
now we have a place within our network
into which we can deploy our RDS database.
All right.
We could go here to databases.
We don't currently have any.
So, let's go ahead and create a database.
That will bring us to the engine.
And of course, we have our choice of different options.
We'll talk more about some of these options
like Aurora later on, but for now, it doesn't really matter.
I'll just go ahead and choose Postgre.
And then we'll go next.
And then now it's asking our use case.
Do you plan to use for production?
If we were to say yes, I'm using it for production,
then that will deploy a Multi-AZ deployment
and Provisioned IOPS storage.
And so, a Multi-AZ deployment would give us two instances.
It would give us a live primary and a live secondary
with synchronous replication between the two.
The cost for that is twice as much
because you have two instances running.
And so, it is a good idea for production
so that you have fault tolerance,
you have the ability to failover to a standby instance
without losing data.
But for a development environment,
I don't think that that's necessary,
at least not for this example.
So, we'll just go with Dev/Test
and go with a single instance.
All right.
We'll go next.
And then of course, we can choose our license models.
We can choose the DB engine.
If you already have code written against an older version,
then you can go all the way back to 9.4.7 if you wanted to.
If this is a new application
you haven't really started on yet,
then perhaps you want to use the latest features
and the latest version.
And then of course, we choose the instance class,
how much memory and CPU do we really need.
We can go all the way up.
You can see in some cases, pretty large machines,
64 cores, 256 gigs of RAM.
And maybe certain database may very well need that,
but for our particular case,
a brand new development environment
with very little data or traffic probably doesn't need much.
So, we could go with a t2.micro.
And the beautiful thing about cloud computing
is that if I'm proven wrong here,
then that gives me the ability
to move closer to being right much quicker.
I don't have to wait.
My decision for this is not set in stone.
I don't have to wait two to five years
to change my mind on that.
If I find within the next week
that one core, one gig of RAM is not enough,
then I can very easily change my mind
and try two cores, four gigs.
And if that's not enough,
I could very easily go up to eight gigs.
And so, again our decisions within the cloud
are not set in stone.
That's the beautiful thing.
So, I'm going to just choose what I think is the best
for this particular environment and go from there.
And if monitoring and experience tells us otherwise,
well, then that's okay.
We won't really lose any money by changing our mind.
And then of course, we can revisit this Multi-AZ deployment.
Again if we chose Multi-AZ,
then it would create a live replica in a different AZ.
We don't really need that.
And then of course, we get to choose our storage type.
It's defaulting to a general-purpose SSD,
very similar to EBS.
Because ultimately RDS is built on top of EC2 and EBS,
we have access to those EBC options.
For development environment,
a general-purpose SSD is probably fine.
We might want more storage.
So, we can say, well, let's get 100 gigs.
And of course, I could be proven wrong, and that's okay.
Through experience using this, we might realize
that we actually do need more performance.
And so, we could come back later and say, well,
you know what, we might actually need a sustained IOPS
of 1,000 or two or 3,000.
And so, we could base that based on monitoring,
based on our experience using it.
So, for now, I always try to go with the cheapest option.
And here I imagine that I could probably easily accrue
100 gigs' worth of data or maybe not,
maybe 50 is more appropriate.
We start there and then see how it goes.
We can always increase that storage later.
So, generally I try to aim for the cheapest solution
that I think will solve the problem
in a performant and reliable way
and then run it, try it out.
The truth is, we don't know anything
until we actually run something
and then we can go from there.
And then of course, it's telling us, you know,
this is what we think is going to cost you
based on that size machine and that much storage,
whether or not you're using Provisioned IOPS,
then we have an estimated cost.
And then of course, we can name the DB instance.
So, the DB instance identifier is a unique name.
It says all DB instances owned by your AWS account
in that region.
So, we're going to call this one,
we might call this one fundamentals,
we might call it fundamentals-dev.
And then somewhere else,
we might have fundamentals production.
So, you typically put that in the name
to help clarify the environment or the project
that it's associated with.
And then of course, we need to specify a master username.
Admin is pretty common, but you could obfuscate that
if you wanted to and call it something else.
And then we can also specify a master password.
And then from there, we'll go ahead and say next.
Then the last step here
is to choose our place in the network.
And of course, we want to choose our data stores VPC.
And then you could see there's only one security group
associated with that VPC, or subnet group, excuse me.
There's only one subnet group associated with that VPC,
which is fundamentals, exactly the one that we just create.
And then we have the option
of making this database publicly accessible.
Now if you were to choose yes,
then the instances would receive a public IP address
and they would be reachable from the internet.
I don't typically like to do that.
There may be a time and a place in your particular scenario
that you feel okay doing that, but I typically don't.
So, I'm gonna say no, I want them to remain private.
And then of course, we can say,
as far as the security groups go,
let's create a new VPC security group
specifically for this database.
Down here under database options,
we could choose to put in a name of the database.
If we were to do that, the RDS service would create
a database on that instance for us.
I don't really need to
because we know that our code will do that.
Our code, as a part of bootstrapping the application,
would probably check for the existence of a database.
If it did not exist, go ahead and create the database,
create tables, populate tables, and so on.
So, that kind of thing, I will leave to my application
or my DBAs to do.
I don't really need RDS to create a database for me.
As far as the port goes, we can change this
to whatever we want.
The default for Postgre is 5432,
but I could obfuscate that.
If I wanted to put it
on a completely different obfuscated port, I could.
Or I could leave it as the default.
We also have access to the ability
to modify parameter groups.
Parameter groups allows us to modify parameters
of the database engine and use that to tune the performance
of the engine.
We don't have any others besides the default,
but we could come back and create.
If we were to go over here to parameter groups,
then we could create a new parameter group
and again tune the engine and then apply that
to the database, reboot the database, and go from there.
We also have the ability down here
to enable IAM DB authentication,
which means that the database user credentials
would be managed through IAM.
If you're using Federation, then that won't be option
because your users will not exist within IAM.
In this particular case, I don't really need to do that.
I'm perfectly happy using the database realm
of authentication to manage users.
As far as encryption, some databases do support that,
but keep in mind
that while the RDS service does support encryption,
it's saying here, you'll notice that it's grayed out,
the selected engine or DB instance class
does not support encryption.
So, not every engine,
not every instance type supports encryption.
As far as backup goes,
RDS will perform automated backups once a day.
And we get to choose how long those backups
are retained for, anywhere from seven days
all the way up to 35 days.
And then we could also select a window.
If we have a particular period of time
during which we see a minimum load on the database,
then we might want to choose that time as the window.
And who knows?
That could be three a.m. UTC,
again whatever makes sense for your particular scenario.
Now as far as monitoring goes,
enhanced monitoring would be very useful in production,
but we probably don't need that
in a development environment.
We probably don't need performance insights
in a development environment either.
Again those two things could be very helpful in production.
Log exports probably would be helpful in development.
If you're trying to work through some kind of complex query
and trying to understand what's going on
between your application, the query, the result set,
and so on, then who knows,
these logs might very well be helpful.
So, we can choose to publish the PostgreSQL log
to CloudWatch Logs.
As far as maintenance goes,
very much like the backup window, we do get to say,
well, yeah, do backups for us and also do minor updates,
minor version updates for us,
and perform them during a particular window.
And so, if we opt into this, then new minor versions
will be automatically applied once they are released.
And again we do get to select that window.
So, we might say, you know what,
I want that to happen on a Saturday
at six a.m. UTC or one p.m.
It could be one p.m. UTC, whatever,
again whatever makes sense for your particular scenario.
And you could say, well, I'll give you two hours
to make that happen.
Very similar to EC2 instances where remember
EC2 instances had that termination protection,
we can also opt into a deletion protection
on the RDS instance.
And it's just that extra layer of security
at that extra safety mechanism to help ensure
that your database can't be accidentally deleted.
Before you can delete the database,
you first have to remove that deletion protection.
All right.
So, now that we've gone through all that,
let's go ahead and say create database.
And it's giving us an error here.
Notice this.
It says, "MasterUsername admin cannot be used
"as it is a reserved word used by the engine."
I did not know that, but that's the beautiful thing
about these kinds of errors.
They help us learn.
And so, that's totally okay.
Let's just go back.
I believe we might have to go back one step,
previous, to admin.
We'll call this one fundamentalsAdmin.
Now that we've saved that, let's go change the password.
Let's go back to make sure that nothing else has changed.
It looks like some of these things have changed here.
Let's just make sure that none of these things have changed.
Backup.
We wanted a particular window that was one UTC,
and we wanted to disable those two things.
Oops.
Disable that.
We wanted the Postgres log to go there.
We wanted this one on Saturday at one p.m. UTC.
All right.
Now let's try that again.
All right.
So, your DB instance is being created.
So, let's go back to RDS.
Let's go to databases.
And there we have it.
We have our fundamentals-dev Postgres
instance being created.
It does take a little while.
You'll see Multi-AZ is no.
That's exactly what we wanted.
It does show the VPC that it belongs to.
And of course, once this is running and in use,
we could get some quick information
about the CPU and current activity as well.
So, we'll give that a moment to finish creating
and then we can take a look at different details.
We can go ahead and drill into the details.
And it's still creating.
And so, you can see here
that we don't have our endpoint and port yet.
Once it finishes creating, then we will be given an endpoint
that we can use to connect to.
So, we'll just give that a few minutes to create.
And there we go.
We have our RDS instance is now available.
And you can see we do get instant information
about the CPU, current activity, zero current connections.
And down here, we get our endpoint and our port.
So, now we can use this endpoint, this is a DNS endpoint
that we can add to our applications.
We don't rely on the IP addresses because those can change
and especially in the case of failover.
So, failover occurs, if this were a Multi-AZ deployment,
failover would occur by just continuing to use
this DNS endpoint and the RDS service would change out
the IP addresses.
And then of course, from here, we can go to monitoring
and see CPU utilization, DB connections,
freeable memory, all of those kinds of things.
So, these kinds of quick access to monitoring
can be really helpful
in doing any kind of performance debugging,
of course along with application logs and whatever else.
Just like that, in a few minutes,
we've created an RDS instance.