Intro
0:00
AWS elastic Beanstalk is a platform as a service solution designed to help you
0:05
deploy your applications without manually configuring the underlining infrastructure to host and support that
0:12
application all you need to do is upload your application source code and provide details of how you want the
0:18
infrastructure that supports the application to be configured elasticbeam stock will then build deploy and manage
0:24
that infrastructure on your behalf in this video you will gain hands-on experience deploying a multi-tier AWS
0:31
application using the elastic Beanstalk service you will learn about the core features of elastic Beanstalk its key
0:37
components recommended best practices and security measures when deploying real-world applications in the cloud
About your instructor
0:45
hello and welcome to my channel my name is Rajesh and I am a Senior Solutions architect with over 20 years of
0:51
experience in the IT industry I've helped numerous clients migrate to the AWS cloud and have worked with
0:56
businesses across the US UK and India over the last five years I've delivered technical training programs on AWS I'm
1:03
also the author of The AWS certified Cloud practitioner exam guide published by Pact publishing and available on
1:09
Amazon and major bookstores now I've designed this video to help you gain practical experience with the AWS
1:14
elastic Beanstalk service if you already have some knowledge of elastic Beanstalk feel free to skip ahead to the Hands-On
1:20
Labs using the timestamps below if you are new to elastic Beanstalk then I highly recommend that you go through the
1:26
entire video okay that's enough about me let's start the AWS tutorial even though
The problem with traditional application deployments
1:32
cloud computing has made it much easier to build and deploy your applications you must still consider the vast array
1:38
of infrastructure services that need to be configured to support and host those applications and so you need to design
1:44
plan and provide the necessary infrastructure to host and support the application and that also means that you
1:50
should configure your infrastructure components to ensure security reliability scalability and high
1:56
availability to ensure that your application is always available for your end users and so in a typical
2:02
infrastructure configuration you're going to host vast array of different components so there will be networking
2:08
components as an example you'll need to build a VPC within which you will deploy your application you may need to
2:14
configure some load balances to distribute traffic across your compute services within that VPC not to mention
2:21
that you might also need to deploy cloudfront if you're hosting your application in one region but want to
2:26
provide access across the globe there's compute services that you need to configure you need to firstly decide
2:33
whether you're going to use ec2 ECS or Lambda functions but ultimately you still need to configure those individual
2:39
Hardware components you may also need to configure some storage services such as object storage like Amazon S3 or block
2:46
storage devices that need to be attached to your ec2 instances let's not forget about databases most
2:53
applications need to store structured data somewhere and databases are sitting in the back end of every application out
2:59
there hosting valuable data and then there's the security aspect of
3:05
it you may need to configure some IAM roles to allow your applications to interact with various AWS services on
3:10
the platform or you may need to think about configuring encryption services so that your data is safe and secure let's
3:16
not forget about Secrets manager which allows you to host database credentials and secrets which can be dynamically
3:22
retrieved by your application and then finally you may also need to have some monitoring and logging
3:28
services so you're using Amazon cloudwatch for instance is going to be a vital component in your overall infrastructure
3:35
design and so hopefully you're beginning to realize that hosting an application is not all that easy and so you have to
3:42
carefully plan and design not just the application but also the underlying infrastructure that's hosting that
3:47
application now AWS has another solution that can allow you as a developer to focus more
Introduction to AWS Elastic Beanstalk
3:52
on your code rather than the underlining infrastructure and that's where I'd like to introduce you to the AWS elastic bean
3:59
stock service so the AWS elastic bean stock service is a platform as a service solution a Paz
4:05
solution that can help you deploy and manage your applications on AWS without having to individually configure and
4:11
manage the underlining infrastructure that supports your application as a developer you can upload your code
4:17
to elastic Beanstalk and elastic Beanstalk will configure the infrastructure and the environment the
4:23
service will also provision supported platform versions to put your applications that are designed and built
4:29
in supported languages such as gojava.net node.js PHP python and a few
4:35
others how to help you do need to be aware of the fact that as a developer you still need to understand the
4:41
infrastructure and architecture design principles for your application requirements and
4:46
what this means is that you still need to be in a position to dictate exactly what the infrastructure needs to look
4:52
like how the network needs to be built what sort of storage Services you need to consume whether you're going to go
4:58
with load balancing and auto scaling all of those components that fulfill your application infrastructure needs is
5:05
something that you do need to have a good understanding of and the reason for that is elastic Beanstalk gives you full
5:12
flexibility on how the underlying infrastructure is built and configured to support your application elastic been
5:18
supposed to do the heavy lifting of actually configuring and setting up that infrastructure but you need to tell it
5:23
what to do you could leave elastic Beanstalk to provision a base standard infrastructure
5:29
for your application but most of the time you're going to find yourself in a position where you need to actually be
5:34
involved in how that infrastructure is going to be set up now elastic Beanstalk uses cloud formation to build
5:40
infrastructure for your application so cloud formation is an infrastructure as a code solution that Provisions
5:45
infrastructure from code based on the templates that Define how that
5:51
infrastructure should be built and elastic Beanstalk actually makes use of cloud formation to build infrastructure
5:56
that you are trying to set up to host your application this is something to be aware of and specifically the
6:02
differences between elastic Beanstalk and cloudformation for your exam so whereas cloud formation will help you
6:07
build underlining core infrastructure components to support one or more applications elastic Beanstalk is highly
6:14
focused on that individual application that you're trying to deploy on AWS and Provisions the necessary infrastructure
6:20
using cloud formation to support that application so next let's look at which platforms elastic Beanstalk actually
6:27
supports so elastic Beanstalk Provisions your core infrastructure and environments for the following supported platforms and
AWS Elastic Beanstalk Supported Platforms and Languages
6:33
languages and as long as your application is built in these supported languages and platforms then you're
6:40
pretty much good to go and will be able to deploy your application using elastic Beanstalk and these include Apache
6:46
Tomcat for Java applications Apache https for PHP and Python nginx and
6:51
Apache HTTP server for node.js DOT node core for Linux and dotnet for Windows go
6:57
Ruby and a few others now a really cool feature of elastic Beanstalk is that if
7:03
your application architecture isn't built using one of these supported platforms or runtime environments you
7:08
can always use Docker containers with Docker containers you can Define your own runtime environment platform
7:13
programming language and any application dependencies because Docker containers are self-contained and include all the
7:19
software that your web application needs you have extensive flexibility on the type of applications you can host using
7:26
elastic Beanstalk now we've got two options when it comes to Docker so the first option is to use Docker runtime on
7:31
64-bit Amazon Linux 2. this is ideal for single Docker containers where it refers to deploying a single or multiple
7:37
containers on ec2 instances the docker image can be built by supplying a Docker file an elastic Beanstalk will actually
7:45
go and set up your Docker image or you could provide it with access to a Docker
7:50
image the second option is to use ECS running on 64-bit Amazon Linux 2 ECS
7:56
stands for elastic container services and it is a container orchestration management solution offered by AWS with
8:03
this second option elastic Beanstalk performs all of the ECS activities such as creating your ECS clusters task
8:09
definitions task execution you can also Define the environmental variables in the elastic Beanstalk console which are
8:15
then passed on to the containers now an important point to note however about this easiest option is that your
8:21
Docker images must be pre-built and stored in a repository unlike the previous option you cannot simply Supply
8:27
a Docker file and expect elastic bean stock to then build out your Docker image now before the introduction of
8:33
ecss being used to host multi-docker containers there was an option otherwise known as
8:39
Docker Legacy to host multi-container Docker containers and these can actually
8:44
be migrated to ECS running on 64-bit Amazon Linux 2. so if you are running an
8:50
older multi-container Docker running on 64-bit Amazon Linux platform Branch those can now be migrated to ECS running
8:58
on 64-bit Amazon Linux 2 platform branch okay next I'd like to take a look at a
9:04
typical architecture design pattern about how the various components of elastic Beanstalk work with each other
9:09
so let's do that next okay so let's take a look at the different elastic bean stock components next so here we have
AWS Elastic Beanstalk Components
9:15
our developer menu he's been working for our company and he's built an application that he wants to deploy on
9:22
AWS but he doesn't want to do the heavy lifting when it comes to the underlining infrastructure so it's going to go with
9:27
elastic bean stock which is our platform as a service solution now menu needs to actually create what's called an elastic
9:33
Beanstalk application now this is not an application in a traditional sense from an elastic Beanstalk perspective this
9:40
application describes the container that will contain the actual application code
9:46
environments runtime libraries and and the infrastructure components to support the application
9:51
so think of the elastic Beanstalk application as simply a container to hold all of this stuff together and so
9:57
for the exam remember that elastic Beanstalk application is simply a collection of the infrastructure resources environments application
10:03
versions and configurations once you've got the application created you can then describe and configure the
10:11
elastic Beanstalk environments now what do we mean by that is essentially what menu needs to do is he needs to upload
10:17
the application code to elastic Beanstalk an elastic Beanstalk will deposit that code into a managed S3
10:24
bucket so menu essentially uploads the application code to elastic Beanstalk and elastic beadstock puts that
10:31
application code into a manage S3 bucket these are called application versions and there are specified versions of
10:37
Deployable code that are stored as a bundle in the Amazon S3 platform and it could be in a zip format or a wire file
10:43
stored in the S3 environment now this S3 bucket is linked to your
10:49
elastic Beanstalk application okay so when you create your elastic Beanstalk application and you upload your code an
10:55
elastic Beanstalk bucket is created if one doesn't already exist just support and host the application code next for
11:02
the application menu we'll need to create one or more environment so when you're deploying applications on AWS
11:07
usually you're going to deploy it in multiple environments you'll be a Dev environment a test environment and a production environment
11:13
and usually you'll have different application versions deployed across this environment where the production
11:19
environment will usually have an older more stable version of your application code as opposed to your Dev environment
11:25
where you may be testing out some new features for example as part of your elastic bead stock
11:32
configuration menu does need to be aware of the core infrastructure components that is going to support that
11:37
application now menu is not going to manually configure most of that infrastructure elastic Beanstalk will do
11:43
that heavy lifting nevertheless menu needs to describe whether we're going to be using a default VPC or a custom VPC
11:49
whether we're going to be using Auto scaling Services how many instances what
11:55
sort of Auto scaling policies we're going to have whether we need an elastic load balancer to distribute traffic
12:00
across those instances and also if we need a backend database in addition to
12:06
that menu will also need to specify any service rules and instance profile for
12:11
your ec2 instances and IM rules are basically assumed by elastic Beanstalk as a service role and ec2 instance
12:18
profile to allow elastic Beanstalk to create and manage your environment so this becomes an absolute necessity when
12:24
you think about permissions and the ability for your instances to interact with other components of the AWS service
12:30
once this environment is configured and set up elastic Beanstalk will then go ahead and
12:36
actually deploy your application versions to your environments and provision your application within those
12:43
ec2 instances ready for your users to be able to interact with them
12:52
it's like whether you want to export log files to cloudwatch the help monitoring of your services if you want to send out
12:59
email notifications to the administrator whenever events takes place in your in our sick bead stock environment and so
13:04
ultimately menu does need to be aware of the core infrastructure components that is going to be used to support the
13:10
application but elastic Beanstalk actually goes and Provisions all of these infrastructure bits and pieces
13:15
using cloud formation okay so this describes at a very high level what an elastic bead stock environment looks
13:21
like and what its various components are however there's a little bit more to it when it comes to the environments that
13:26
elastic Beanstalk allows you to create let's take a look at that next when considering using elastic Beanstalk
AWS Elastic Beanstalk Environment Tiers
13:32
to host your application on AWS you do need to take into account the complexity and the architecture design patterns of
13:38
your application if your application is designed with a front-end element and a back-end element to it as most
13:44
production Enterprise grade applications are then you want elastic Beanstalk to take this into consideration when
13:50
building out the necessary environments to support and host that application now front end refers to the presentation
13:56
layer of your application using a combination of Technologies like HTML JavaScript and CSS developers build the
14:03
user experience element on the web page such as buttons menus Pages links graphics and so on
14:10
backend refers to the server-side development and focuses on the backend operations of your application an
14:16
example could include when you visit an e-commerce website where you purchased an item and are now trying to pull tracking information on your order back
14:23
in services will retrieve the status of your order and present that data to the front end often back-end operations may
14:30
take longer and need to keep up with incoming requests made on the front end of the application and in this scenario
14:35
it is recommended to separate front-end requests from backend processes and use a queuing system to host and manage
14:41
pending requests to support both front and back-end components of your application elastic Beanstalk offers
14:47
what's called environmental tiers these are called web and worker tiers let us
14:53
look at how this all works from an architectural perspective if you have a really complex application that has both
14:58
the front-end and a back-end element to it elastic beams took in provision what are called environmental tiers to support your application architecture
15:05
and so when it comes to deploying your application you do need to specify by whether you're deploying it for the
15:12
front end or the back-end processing element of your application you start off with elastic Beanstalk application
15:17
which is the ultimate container that will host the application the infrastructure and the environment for
15:23
the application in addition to that elastic Beanstalk will provision and manage an S3 bucket which will be used
15:29
to host all of your application versions when it comes to deploying the application within elastic Beanstalk you
15:35
need to specify if you're deploying it for the front-end part of your application or for the backend part of
15:40
your application accordingly elastic Beanstalk will provision a web tier that's for the front end or a worker
15:47
tier which is for the back end when it comes to actually provisioning
15:52
the resources for those environmental tiers elastic bean stock will provision one or more ec2 instances depending on
15:58
the configuration that you choose and will deploy the application on those ec2 instances the instances for the web tier
16:05
will be supported by an auto scaling group and scaling policies to help you scale out or scale back in depending on
16:12
the sort of load that you have on your instances you can actually Define what that scaling policy is as well in
16:19
addition to that for the web tier elastic Beanstalk Provisions an application load balances so that it can
16:24
distribute traffic coming from the internet to those ec2 instances now elastic beam stock will provision the
16:30
ec2 instances for your application which will be dependent on what's known as the container type the container type
16:36
basically defines the infrastructure topology and the software stack that will be used by the environment you need
16:42
to tell elastic Beanstalk what platform your application has been built on what language is being used
16:47
Etc an elastic bean stock will then provision the appropriate container type
16:53
so for example an Apache Tomcat container would comprise of an Amazon Linux operating system Apache web server
16:59
and Apache Tomcat software likewise for your worker environment
17:04
again elastic Beanstalk will provision one or more ec2 instances these instances will be supported by an auto
17:09
Skilling group and auto scaling policies note that there is no application load balancer being configured for your work
17:16
environment that's only for your web environment an additional component that's configured within a multi-tier
17:21
environment such as the one that you're looking at on the screen is the fact that elastic Beanstalk provisions and
17:27
sqsq now an sqsq is designed to take messages from the web tier and hold it
17:34
in the queue and these are going to be basically the requests made from your users coming in from the front end
17:40
within the backend instances there is something called an sqs Daemon that runs
17:45
as an agent on those instances waiting to retrieve any messages that have been
17:51
placed in the queue and these are then retrieved and processed for backend operations the demon pulls the items
17:59
from the queue processes the messages and if successful deletes the messages
18:04
from the queue and as new messages come into the queue this process continues by utilizing a queuing system we can ensure
18:11
that back-end instances that need to do a lot more processing aren't overloaded with massive amounts of incoming
18:17
requests that hit the front end and this helps to manage your front-end and back-end operations very seamlessly when
18:24
it comes to managing the scaling for the backend instances AWS uses a number of
18:29
different metrics in order to manage the scale out of the scaling of those instances one such metric is the
18:36
approximate number of messages visible cloudwatch metric that is used to define whether elastic bean stock should scale
18:43
out and provision more ec2 instances or cutback and terminate certain ec2 instances and once all of this is set up
18:50
obviously your customers are able to come in into your application load balancer and access your web services
18:56
their requests are processed and sent to the queue and then retrieve my backend
19:02
instances to perform all necessary back-end operations an additional point that I want to
19:07
highlight with regards to this entire infrastructure setup by elastic Beanstalk is that elastic Beanstalk
19:12
Provisions each instance with something called a host manager the host manager is an agent that runs on all of your
19:18
instances that manages the deployment of applications generating instance level events monitoring the application server
19:25
patching instance components and Publishing application log files to S3 amongst a few others
19:32
okay now that we've looked at environmental tiers in a little bit more detail it's time to move on to look at
19:37
an actual application design but before we do that there's one more element of your typical application architecture
19:44
that I want to discuss with you and that is the placement of relational databases for your application stack let's do that
Strategic placement of RDS databases for Elastic Beanstalk
19:52
next now within a standard elastic Beanstalk deployment elastic Bean circuit provision for you the
19:57
application okay so that's the container the S3 bucket to host your application code your bundles and the versions of
20:04
application code when configuring your environment you can actually specify an existing VPC to
20:10
deploy your application into or on the Fly set up a brand new VPC you can also Define the environment and
20:18
then within that environment choose your instances that you want to deploy within the auto scaling group configuration you
20:24
can choose the auto scaling policies as well and like we've previously discussed also deploy your application load
20:29
balancer and Define your application layout balancer properties there one of the fundamental elements for most
20:36
applications is that they need to store data in some form of database and as
20:41
part of the elastic Beanstalk configuration you can actually configure a database on the fly so a relational
20:48
database as part of your overall configuration when you configure your application this way you are essentially
20:55
integrating the RDS database within the environment
21:00
and this comes with a lot of benefits so for example elastic Beanstalk is seamlessly integrated with RDS and that
21:06
also means that the settings for your environmental properties the settings to connect to your database are
21:11
automatically set so the environmental properties comprising of the database hostname the port number the username
21:18
the password and the database name are all set for you and ready to go and then
21:23
you just need to test your application and make sure that it connects to the database but with this integration in
21:28
place it's very seamless your application and your database are all
21:34
part of that environment now with some advantages also comes some
21:39
disadvantages so let's take a look at that next if you choose the option to integrate your RDS database deployment with your
21:46
elastic Beanstalk environment and there's a few things that you need to be aware of firstly this configuration
21:52
means that the elastic Beanstalk environment will provision and manage that database for you if you ever need
21:58
to deploy another version of this application perhaps in another environment for testing purposes then
22:03
what that means is the elastic Beanstalk service will deploy another database in
22:09
that new environment and so now you have two separate databases supporting two environments in your application
22:17
it is likely that you were simply trying to make modifications to the application
22:23
code rather than the actual data being held in the database and so if anything both of those environments need access
22:29
to that same data however in this configuration we now have a brand new database that perhaps doesn't have the
22:35
same data as the previous environments database and so you may have some management overhead where you may need
22:41
to copy some of that data from the old database to the new database another important point to consider is
22:49
that when you are using your standard default configuration for setting up an environment that has the database
22:55
integrated within it the default database deletion policy is to delete
23:00
the database when you terminate the elastic Beanstalk environment now that means if you go ahead and delete that
23:06
environment then you're going to lose data as well and this is something that you need to be aware of so when it comes
23:12
to terminating the environment obviously elastic Beanstalk will terminate the core infrastructure it will terminate
23:18
all of the instances but it will also terminate the database resulting in data loss
23:24
if you were mindful of how the database deletion policy needs to be set because you wanted to retain that data prior to
23:31
getting rid of the environment then obviously you would have made that modification then but this is something to be aware of that the default policy
23:37
is set to delete of the RDS database when you go to delete the environment
23:42
now in cases where you already have a database integrated as part of your
23:48
environment you may be wondering whether it's possible to actually remove that database from the environment and
23:53
separate it out from the environment and the answer is yes you can do something called decoupling of your database so
24:00
you can modify the database settings in your environment so that you can decouple the database from the
24:06
environment and decoupling a database will not affect the health of the environment but the thing to be aware of
24:11
is that the database will follow the deletion policy that you choose and that is something you really want to be aware
24:17
of so what happens if you've already set up an environment and perhaps you've used a standard
24:24
deletion policy the default deletion policy and now you've made a decision that you want to decouple that database
24:30
from the environment because you want it to support other environments let's take a look at that next
24:36
so next I'd like to walk you through the steps to decouple your database and one such reason why you might want to do
24:41
that is because you've decided to introduce additional environments into your elastic Beanstalk deployment and
24:48
you want to share that database across those environments you may also want to get rid of some other environments that
24:55
you no longer use and so now you've come to the decision that you need to decouple that database so the steps
25:01
required to decouple the database are as follows the first thing you want to do and this is just a precautionary thing
25:06
is to create an rdsdb snapshot and so ultimately from within the environment
25:13
you can edit the environment and do a snapshot of that database so that Amazon RDS stores a snapshot for you in case
25:20
something goes really horribly wrong the next step is you want to enable
25:25
delete protection in the RDS console of that database now this is something
25:31
again that's just a precautionary measure primarily because when you set up the environment originally if you
25:37
didn't pay attention to the configuration items you may have left the deletion policies set to delete so
25:43
what we need to do is we need to enable delete protection against the database itself and you do this from the RDS
25:49
console next you create your brand new environment okay so if you're doing this
25:55
because you're shifting environments you've got a new application code that you've deployed and you want to share that database so you go ahead and create
26:02
your brand new environment with your instances you deploy your code your load balances Etc however in this environment
26:08
you do not provision a database as part of the environmental configuration steps that you take to deploy the environment
26:15
when you have deployed your new environment the green environment in this case what you want to do is you
26:20
want to make sure that your application is connecting to the database so you may
26:25
need to just test that out and ensure that all of that is working next you want to perform something called a blue
26:30
green deployment or a URL swap another word for it is a c name swap so when
26:37
you've deployed your application on elastic bean stock elastic Beanstalk provides you with a URL to connect to
26:44
your application and your users generally would Connect into the application through a hosted Zone that
26:50
elastic being manages for you and it publishes that URL that is then
26:55
accessible from the internet so your users are able to come in and access your application elastic Beanstalk offers you a service
27:01
called a cname URL swap because you're able to create multiple environments you can perform something called a URL swap
27:07
so that now that you have the new environment what we call the green environment you're able to just perform
27:13
something called a cname swap that will send traffic to this new environment it's a very simple process you do it in
27:19
the console or using the command line and the job is done it takes a matter of a few few minutes you do need to have a
27:26
bear in mind that obviously with DNS you need to give it some time to propagate across the internet
27:33
okay so once you've performed the blue green deployment and done the CNM URL
27:38
swap give it a bit of time and ensure that your users are now able to connect to the green environment hence the name
27:43
blue green deployment [Music] once you are satisfied that everyone is
27:48
now connecting to the green environment the next step is to update the deletion policy in the environment of dev1 so the
27:55
blue environment so that you select the retain option rather than the delete
28:02
option that is the default option when you're building out this environment
28:07
and this is imported you want to make sure that you do this setting first save
28:12
the settings so that it gets registered with elastic Beanstalk before you take the next step and then the next step is
28:18
to perform the actual decoupling exercise from the screenshot that I shown you earlier in this video
28:24
you perform the decoupling exercise that will decouple the database from the environment
28:30
and at that point you want to make sure that your new environment can still connect to the database run all your
28:36
tests and then finally you want to terminate the old environment so that you would take when you know if
28:42
you have started off with an environment that has the database tightly coupled and the deletion policy was set to
28:50
delete so all of the default configurations and you've decided that you want to decouple the database and build new environments so you want to
28:56
follow these steps very carefully now if you're taking the aw Solutions architect exam you probably want to
29:02
remember these steps as well because you might get a scenario type question there
29:08
okay so you obviously now have the steps to follow if you find yourself in a situation where you've built an
29:14
environment with your database tightly coupled and then you want to decouple it later on however in the real world when
29:19
you build design and deploy your applications on elastic Beanstalk it pays well to plan your environment build
29:26
out beforehand it is possible to connect your environment to an external RDS
29:31
database that's managed outside of those environments separately and often this
29:37
can be a good step to take because it takes away all of this heavy lifting that you might have to do later on so
29:43
next we taking a look at how to build a typical architecture design pattern to
29:49
support any future elastic Beanstalk deployments within a real life scenario we'll then move on into a lab
29:55
environment where I'll provide you with some sample application code a fully functioning application code that you
30:01
can actually use to build out a real world type environment in your own AWS account okay so let's do that next
AWS Elastic Beanstalk Application Architecture
30:09
Okay so we've covered a lot of theory and obviously now you're itching to try and really work with the elastic
30:14
Beanstalk service so that's exactly what we're going to do next I want to walk you through an architecture design diagram now this is by no means a
30:22
complete end-to-end solution it's a cut down version of what you will deploy in the real world but it will help you
30:28
understand the core components that actually go on to build a real life project there are several components to
30:35
help you deploy host and manage your application on the AWS platform and we're going to be looking at some of
30:41
these Services next elastic bean stock is a platform as a service solution that can help incorporate all of these
30:47
different services to provide the necessary infrastructure for your application so let's get started with the
30:53
architecture design plan unless you're going pure serverless you're going to need a VPC your VPC is the isolated
30:59
Network within which elastic Beanstalk will deploy your application you can set up the PC up prior to actually working
31:06
with elastic bead stock or whilst configuring elastic beam stock set one up on the Fly we'll be setting one up in
31:12
the lab from scratch and I'll show you how to set this up now our VPC is going
31:18
to follow some best practices so we are going to be using our VPC across two availability zones remember vpcs span
31:24
the entire region for the purpose of this lab we're going to make use of two availability zones for high availability
31:30
purposes we're then going to be deploying six subnets
31:35
two subnets are going to be reserved for public subnet Services okay that's where we're going to be hosting our load
31:42
balances and our NAD gateways and I'll come on to that in a second but we're going to be having two public subnets one in each availability Zone to offer
31:48
that redundancy that high availability element we're going to have two private subnets that are going to be used to
31:54
host the application itself again one in availability Zone Us East one a and the other one in Us East 1B and then we're
32:01
going to have another two private subnets that's going to be used for our database we're going to be using a mySQL database for this project so we're going
32:09
to work with the RDS service and deploy a mySQL database in rvpc
32:16
obviously with a VPC we're going to deploy an internet gateway because the VPC will need internet access and in
32:23
addition to that we're also going to be deploying a nut Gateway and not Gateway allows instances in the private subnet
32:28
to get access to the internet by way of a proxy by way of a relay service that
32:34
the NAT Gateway service provides okay and the reason why we're doing this is because our instances may need to access
32:40
the internet they may need to download software updates and all that stuff so in that Gateway is also going to be
32:46
deployed now bearing in mind all of this configuration is going to happen well before we actually work with elastic
32:51
beanstock and the primary reason for that is because we want to host our RDS database
32:57
outside of the elastic Beanstalk configuration and environment and as a result of that we have to set up the
33:03
necessary infrastructure to host that database first and so we are setting up the VPC another element of the VPC that
33:09
we need to configure are security groups security groups allow you to ensure that you only allow the type of traffic you
33:14
want to allow inbound to the resources that are available in your VPC so in the
33:20
case of the database we obviously want to allow inbound traffic to the database on Port 3306 which is the port number
33:27
for my SQL by default and we need to set that up and so we will be configuring a
33:34
security group for our database and it will need to be configured traffic on inbound Port 3306. now obviously when
33:39
you set up the security group for the database you need to define the source of that
33:45
traffic so we will be setting up an additional Security Group one that we will attach to our instances that
33:51
elastic Beanstalk deploys now bear in mind that elasticbeam stock will also deploy a security group for those very
33:58
same instances so that it can allow the instances to be able to accept traffic inbound from the load balancer that it
34:04
configures later on so your instances will actually have two security groups attached to them one will be the one
34:11
that we're configuring now which is the app SG Security Group and another one which will be configured
34:18
by elastic Beanstalk now the reason for doing this is because I want to restrict inbound traffic to our databases on Port
34:25
3306 but only from instances that are associated with this app SG Security
34:30
Group ensuring that it's only the instances that elastic Beanstalk deploys
34:35
that will be able to talk to my database okay so that's an additional security measure we're trying to preempt and
34:42
configure okay so we will be creating these two security groups manually as well
34:47
the next thing that we will be doing obviously is deploying our database so we'll be going into the RDS Management
34:52
console we will deploy a mySQL database now I have put in a second database here
34:58
in Us East 1B but I've grayed it out because when we come to do the lab we'll just be deploying the single instance in
35:04
a real world scenario you want to be deploying a multi-az configuration for the purposes of high
35:10
availability but as this is just a lab environment and I'm trying to keep the costs down and if you were to do this in
35:16
your own AWS accounts I want you to keep the cost down and so as a result of that we'll just deploy the single DB instance
35:23
okay so far we've got our base configuration set up in place now as a
35:29
Next Step we're also going to be using AWS Secrets manager now aw Secrets manager is a service that allows you to
35:35
host database credentials secrets so that you can dynamically retrieve
35:41
them into your application and your applications can make connections to the database remember your databases will
35:47
have some credentials in order to authenticate against it that information will be stored in Secrets manager
35:54
the application code that I'm supplying you for the purposes of this lab which is available to you in our GitHub
36:00
repository is configured and designed in such a way so that it can actually work with
36:06
Secrets manager and so what we'll need to do as a precursor is configure Secrets manager
36:12
so we'll go into the secrets manager console we'll set up the secrets for our database another feature of AWS Secrets
36:19
manager is the fact that you can enable something called DB rotation database rotation now what this does is it
36:25
actually changes and rotates the database credential information at
36:30
regular intervals you can set those intervals yourself it can be every four days four weeks four months whatever is
36:35
your corporate policy but this is an absolutely important security feature because what it means is that you can
36:41
have the database credentials automatically rotated by Secrets manager Secrets manager updates the secrets in
36:47
its database as well with what the new credentials are and that information is then available to your application to be
36:53
able to access the database this further enhances the security of your overall application in the AWS platform
37:02
another key component that we're going to be working with is IAM and we're going to be configuring an IM role for
37:09
the purposes of creating an ec2 instance profile which will allow your ec2 instances to
37:15
interact with services such as Secrets manager as well as work with elastic
37:21
Beanstalk Services okay so we will need to configure an IM rule with the appropriate permissions and I'll show
37:27
this in the lab so far we've built out all of this
37:33
infrastructure outside of the elastic Beanstalk configuration and remember the reason why we're doing this is because
37:39
we want to set up our database externally to the elastic Beanstalk environment next we're going to actually
37:45
work with elastic Beanstalk so here's our developer menu has got the application code that he
37:50
wants to deploy using elastic beadstock he's going to configure the elastic Beanstalk application as we've seen
37:56
previously upload the code to elastic Beanstalk which will involve elastic
38:01
Windows setting up an S3 bucket to manage that application version and bundle
38:07
and as part of the elastic Beanstalk configuration menu will instruct elastic Beanstalk to perform the following
38:13
configurations so one of those will be configuring an application load balancer menu will instruct elastic Beanstalk to
38:20
design the application environment for high availability and therefore this will entail configuring an application
38:27
load balances so elasticquin stock will then configure that application load balancer when it deploys the application
38:32
another component that menu will instruct elastic Beanstalk to take care of is the auto scaling group and also
38:40
environment properties now environment properties need to be manually updated with information to access the database
38:48
that is external to the elastic Beanstalk environment and also the name of Secrets manager the name of the
38:54
secret within Secrets manager to pull the secrets from so whereas we need to play elastic Beanstalk environments with
39:01
the database integrated within it the environment properties are set for you because we're trying to keep the RDS
39:07
database external to the elastic Beanstalk environment this is one thing that you will need to do that menu will need to do here will need to set up the
39:13
environmental properties to connect to the database so you'll need to provide the database endpoint name and also the
39:18
secret name within Secrets manager that is hosting the credential data once menu
39:24
has set up all of the necessary configuration and submitted the request elastic Beanstalk elasticity Beanstalk
39:29
will go ahead and provision the necessary security groups as I'm in mentioned earlier so elastic Beanstalk
39:34
will be setting up a security group for the load balancer to accept inbound traffic on Port 80 from the internet and
39:40
then also setting up another Security Group for the instances to accept inbound traffic on Port 80 from
39:47
the load balances Security Group so from the load balancer okay and because the
39:52
instances also are associated with app SG security group that we created manually the instances can now also talk
39:59
to the backend database in addition to that elastic Beanstalk will obviously consume the application code and deploy
40:07
the ec2 instances as per the configuration of the auto scaling policies
40:12
and deploy the application on those instances those instances will be able to consume
40:18
the data in environment properties so that is you know the name of the database the name of the secrets that
40:24
contains the credential data and ultimately the instances will then be
40:29
able to retrieve the data from Secrets manager the credential information and access the backend database at this
40:36
point elastic Beanstalk has deployed the application successfully and delivered a DNS name for the URL of the application
40:43
and then menu can distribute this URL to the end users to access the application
40:48
obviously you can go one step ahead you can associate a custom domain name within Route 53 and Associate it with
40:55
this elastic Beanstalk URL and that's it so enough of all of this Theory let's
41:01
jump into the AWS Management console to set this all up now I've actually broken the slab exercises into multiple steps
LAB - Step 1 - Create a VPC for Elastic Beanstalk
41:07
for you so that it's easy to follow so for step one let's go into the AWS Management console and create that VPC
41:15
okay so here we are in my AWS account and the first thing that we're going to work with is the VPC we're going to
41:21
build out a virtual private Cloud which is going to be our isolated Network that will host our application now this VPC
41:28
is going to comprise of six subnets across two availability zones an internet gateway and that Gateway and
41:35
the two security groups that we spoke about earlier so let's go ahead and create our VPC first
41:43
and I'm just going to go into the VPC Management console open that up in another tab
41:48
and we're going to go into your vpcs and in there we're going to click creative ABC now we're building a VPC from
41:54
scratch I want to walk you through all of the steps rather than use the wizard so that you see exactly what's happening
42:01
we're gonna give this VPC a name I'm going to call it the dev hyphen VPC
42:06
and the ipv4 side 4 block is going to be 10.0.0.016. now if you're interested in
42:13
learning more about vpcs in a bit more detail and best practices for how you define your ipv4 cider block ranges then
42:21
check out our course the AWS certified Solutions architect and the cloud practitioner on our website IIs
42:27
academy.com okay so next we're going to go ahead and click create VPC and this
42:32
creates the basic core VPC in your AWS account
42:38
okay so that's how VPC created the next step is let's give this VPC an internet gateway so we're going to go ahead and
42:44
click internet gateways click create a new internet gateway we'll give this one a name so I'm going to call this Dev igw
42:50
internet gateway for short and click create internet gateway now when you create the internet gateway it isn't
42:57
attached to any vpcs so you're going to have to attach it to the VPC you just created so click attach to a VPC
43:05
click of the Box select your VPC that you just created and click attach internet gateway
43:11
at this point your VPC has an internet gateway so we can move on to the next step so we're going to create six
43:18
subnets remember they're going to be two public subnets that's going to host our Edge services
43:23
like the load balancer and the net Gateway and four private subnets two for the application layer which will host
43:30
the instances that elastic Beanstalk will configure and two for our database that we'll create using RDS
43:37
so we're going to go into subnets and I'm going to click create subnet
43:42
make sure you select the right way PC that you're placing the subnets in and Define your subnets here okay so we're
43:49
going to start with our first Subnet this is going to be Dev hyphen public
43:54
subnet01 and we're going to place that in availability Zone 1A and the IP block
44:00
for that is going to be 10.0.1.0 24. so this block is a subset
44:06
of our vpc's block remember our VPC was 10.0.0.016 which comes with 65 000 odd
44:13
IP addresses this is just a subset of that block 10.0.1.0 24 giving you a total of 256
44:21
addresses but on AWS you have 251 available usable IP addresses
44:29
Okay click add a new subnet we'll give this one a name and this is going to be our
44:35
public subnet 2. I'm going to place this in availability Zone 1B
44:41
and the IP block for it is 10.0.2.0 24.
44:47
Okay add a new subnet this time we're going to do our private subnet so I'm
44:52
going to call this one the app subnet okay or one this is where we're gonna
44:57
host our instances and we're going to do it in such a way so that it's aligned with our public subnets so
45:05
whereas we have public subnet 01 in availability Zone 1A app subnet01 is
45:10
also going to be an availability Zone 1A whereas app subnet or two is going to be an availability Zone 1B so hopefully
45:16
you're beginning to see the pattern here so this is going to go in 1A the IP block for it I'm going to go and
45:23
put 10.0.10.0 24. you want to leave a gap
45:28
between your different subnet categories and the reason for that is if we ever
45:34
need to add additional subnets like additional public subnets or additional private subnets we want to make sure
45:39
that it's within its relevant ranges so what we can think of this is that we're putting all of our public subnets
45:45
between 10.08.1.0 and 10.0.9.0 and we're putting
45:50
our private subnets 10.0 10.0 to 10.019 so zero so if you ever need to
45:56
add additional subnets you can add them in there I'm going to add another subnet this is going to be the app subnet
46:05
or two and this is going to go in availability Zone 1B and I'm going to give the IP block
46:11
10.0.11.0 24 okay and then we need to set up our database subnets so we'll
46:19
create a subnet 5 Dev hyphen data subnet
46:24
hyphen 01 and this is also going to go on an availability Zone 1A
46:29
for this subnet I'll give it the IP address 10.0.20.0 24.
46:36
okay and then finally we'll have our database subnet02
46:44
in availability Zone 1B
46:49
with an IP block of 10.0.21.0 24. okay
46:54
and just check that it is all okay so that's
46:59
zero public something two apps update 1 up subnet 2 take the
47:05
subnet 1 data subnet 2 and create subnets and that will create all of your subnets for you
47:12
fantastic now that we've got all the subnets created the next thing we want to do is
47:17
we want to set up our route tables so the route tables will Define exactly how those subnets can send traffic to each
47:24
other and outside to endpoints such as the internet gateway so we're going to go ahead and take a look at our route
47:30
tables next so click on Route tables and when you create a VPC it creates What's
47:36
called the main route table for you now subnets when you create them they attach themselves to the main route table by
47:43
default the main route table is this one over here so this is their VPC I'm just
47:48
gonna edit that name and just say Dev main RT just so I know what it is and if I look
47:56
at the routes and look at the subnet Association you will see that all of the subnets are associated with this route
48:02
table the routes has just one internal route now when you're setting up a VPC you
48:09
want to make sure that your public subnets have their own route table with routes to the internet that is
48:14
explicitly for public services Okay so we've got our main route table already
48:20
so we're just going to create one more route table we're going to create the public route table that we're going to attach to our public subnets
48:25
so click create a route table and we'll call this one Dev hyphen public RT
48:33
select the right VPC and click create route table and that creates a route
48:39
table for us which is called the public route table now if you remember we've got our internet gateway so we're going
48:45
to set up a route for the public route table we're going to send traffic to the internet via this route table or using
48:52
the routes defined in this route table so click edit routes we'll click add a
48:58
route and we'll add a route to the Internet so the four zeros zero represents external networks or any
49:04
network outside of this range and the target for that is going to be our internet gateway I'm going to select
49:10
our internet gateway and we're going to save changes at this point this route table gives you direct access to the
49:16
internet via the internet gateway and so as an additional steps we can go into
49:23
subnet associations click edit subnet associations and
49:28
select the public subnets and click save Association so what's
49:33
happened is the public subnets as we called in public subnets are now truly public subnets because they're
49:39
associated with the public route table that has a direct access to the internet via the internet gateway so if I take
49:44
you back into subnets Association again you'll see that the two public subnets are explicitly associated with the
49:51
public route table the other four subnets that we have are associated with
49:56
the main route table okay so if we go back to round tables and click on the main route table now
50:04
the main route table has just a single route which is an internal route the instances that we
50:11
deploy in the app subnets are associated with the main route table now those instances will also need internet access
50:18
but we want to make sure that we keep them private and so rather than exposing them with a public IP address and
50:24
associating them with a public route table we're going to create something called an ad Gateway so I spoke about it
50:30
and that gave me a little bit earlier which is basically a method of granting access to instances that you deploy in a
50:36
private subnet by way of a proxy okay so the not Gateway acts as that proxy as
50:42
that relay machine to relay internet requests from those instances in the private subnet out to the internet and
50:49
then translate back responses to those instances when the replies come back
50:54
from the internet so the next thing we need to do is create an ad Gateway so I'm going to go click create in our
51:00
Gateway and we're going to give it a name so we're going to call this Dev Nat GW
51:06
and and you need to place the net Gateway in a public subnet and the reason for that is because in that
51:11
Gateway will need a Target to send those internet requests through and in this
51:17
case it will be sending it to the internet gateway and in order to send traffic to the internet gateway it
51:22
physically needs to sit in a public subnets because the public subnets are associated with the public route table that has that route defined to the
51:30
internet gateway okay so normally what you would do is when you have multiple
51:35
public subnets across multiple availability zones you will create multiple Nat gateways for redundancy and high availability but for the purposes
51:41
of this lab which is creating one Nat Gateway and I'm going to put this in public subnet one
51:48
okay so that's this one will be a Dev public subnet one and this will just ensure that we keep our costs down for
51:54
the purposes of the lab but in the real world you definitely want multiple net gateways across multiple public subnets
52:00
across multiple availability zones you also need to be aware of the fact that NAD gateways need to have an elastic IP
52:06
address associated with them now an elastic IP address is basically a public IP address that is static and doesn't
52:12
change so we're going to allocate an elastic IP address to our Nat Gateway and then go ahead and click create Nat
52:19
Gateway at this point your night Gateway is getting created it takes a few seconds and then it is all good to go but if I
52:27
click on that gateways over here again you will see that it's in the pending State and it will swiftly change into
52:33
being available okay so after a few seconds that changed to the available State and you can see it's been
52:38
allocated with a public IP address as well and so this is our Nat Gateway and
52:44
so to complete this process we now need to go back into our tables and click on
52:49
the main route table click on routes and we'll create a route to the Internet so the route to the internet is going to be
52:56
indirect not via the internet gateway but instead via the NAT Gateway okay so
53:02
that will help us select on that Gateway and we click save and so at this point any resources that you deploy in the
53:10
public subnets have a direct access to the internet via the internet gateway provided they've been allocated a public
53:15
IP address any resources such as ec2 instances you deploy in the private subnets
53:21
can also access the internet but via the NAT Gateway and continue to have just a
53:26
private IP address and that way you keep it secure and this is considered best practice you don't want to expose any of
53:32
your servers out on the public subnet unless you absolutely have to okay so now at this point we've set up our VPC
53:39
our internet gateway our NAD Gateway six subnets and configure the route tables the last thing to do in our VPC
53:46
Management console is to set up those security groups so let's do that now so we go down to security groups and we're
53:54
going to be creating two security groups you're going to create one for the database and one that we'll assign to
54:00
any instances that elastic Beanstalk Provisions in the elastic Beanstalk environment so Security Group one I'll
54:07
call this one Dev hyphen app SRV SG so basically it's the app server
54:14
Security Group okay and we'll give it the same for the description obviously we can give a much better description
54:20
than that and we need to make sure we place it in the right VPC so that's the dev APC because you're creating a
54:27
security group we want to create an inbound rule I'm just going to create an HTTP rule from any location okay so
54:34
we're accepting inbound traffic on Port 80. so the app service will be able to accept HTTP traffic
54:39
on Port 80. and that's from any location and we'll create a security group okay so that is
54:47
the app server security group created for you okay so there it is so I'm also
54:52
going to just put that copy that name and edit the name tags just so that it's
54:57
in there and it's easily visible so I know which security groups I'm working with create another Security Group this
55:03
is going to be Dev database hyphen SG so this is a database Security Group
55:09
okay and again make sure you put it in the right VPC now this time the inbound
55:15
rules are going to be the MySQL traffic so MySQL Aurora which defaults to Port
55:20
3306 we will be using the default Port range and the traffic for that is going to
55:27
come from any instance associated with the dev app server SG so that basically
55:32
means that unless you're a member of Dev server app SGA you cannot talk to my database which is an additional security
55:38
measure okay and then we'll create that security group as well and again just go back
55:45
into security groups and just make sure that you've got that name edited in the name column just so that
55:53
it's easily visible okay so that's our VPC we've got our vbc
55:58
our internet gateway our NAD Gateway we've got our six subnets we've got our security groups and we're pretty much
56:04
good to go to the next step two let's launch an RDS database in our VPC
LAB - Step 2 - Launch an external RDS database for Elastic Beanstalk
56:11
okay so back into my AWS Management console we're going to move into RDS so I'm just going to search for the RDS
56:16
service here and open that up in another tab that will bring up our RDS console now
56:25
when you're setting up an RDS database you're going to launch it in your VPC and if you remember we had set aside two
56:32
subnets okay data subnet one and data subnet2 which will be used to host our
56:38
database now prior to actually launching a database you need to create something called a subnet group a subnet group is
56:43
essentially telling RDS which subnets are going to be used to launch our database and you need a minimum of two
56:50
subnets ideally across two availability zones that you need to Define for your subnet group so that's what we're going
56:56
to do first so on the left hand side I'm going to click on subnet groups and then click create a DB subnet group and we're
57:02
going to give it a name so I'll call this Dev DB subnet group okay
57:09
and we can just use the same name for the description make sure you select the
57:14
right VPC so that's the devvpc and then the availability zones that we've defined in our VPC are for availability
57:21
zones 1A and 1B in the US East one region within those two availability zones we're going to be deploying our
57:28
database in the database subnet 1 and database subnet 2. now it's a little bit
57:33
difficult to see it here because it just shows it to you in the form of an IP address and the subnet IDs but if I
57:38
quickly go back to my VPC console and I click on subnets
57:44
then I know for a fact that database subnet 1 was 10.0.20.0 24 and database subnet 2 was
57:54
10.0.21.0 24. so those are the two subnets that I want to select so from this drop down list I'll select the
58:01
subnet 21 and 20 those two okay so those are going to be my database subnets and
58:07
I'll click create and that creates my DB subnet group within which I will launch my database fantastic
58:14
right now that we've got the sub Nets click on databases okay and we'll
58:19
create a new database and we're going to set up a standard create database you want to select MySQL for this exercise
58:28
we'll leave all of the defaults in terms of the addition and the engine version and select free tier because we want to
58:36
make sure that you don't get charged that will turn off some options unfortunately but that's fine we're not
58:41
going to use it for the lab anyway specifically around things like multi-az now we have to give our database
58:46
instance a name so I'll call this one devdb okay and for the credentials I'm
58:54
going to leave the master username to admin okay and I'm going to give it a password
59:01
and I'm choosing a very simple password better in the real world you want to choose a really complex one okay and
59:08
we're not going into managing Master credentials in Secrets manager because I want to do Secrets manager if it's separate as a separate exercise because
59:14
I want to show you how it all works so for now just set a master username and a password of your choice make sure you
59:20
remember the password otherwise you will not be able to access the database so make a note of it somewhere safe
59:27
we'll scroll down and we'll select the default option of dbt3 micro instance
59:32
type for our database foreign it's going to use a general purpose SSD
59:38
with an allocated storage space of 20 gigs and I'm going to disable the enabled storage Auto scaling because we
59:43
don't need it for the purposes of this exercise so I'll just deselect that in terms of connectivity so this is
59:50
where you need to make sure that you select the right VPC so that is the dev
59:55
VPC and leave the setting to dome connect to an ec2 compute resource because we will be getting elastic bean
1:00:01
stock to provision the instances to talk to our database because I've selected the right VPC it's
1:00:08
picked up the fact that I've got a single subnet group in there the database subnet group so it selected that for me already
1:00:16
ensure that it's set to no under Public Access because this database is sitting in the back end right in the private
1:00:22
subnet so it doesn't need Public Access no public IPS and then you need to select the security prayer database now
1:00:28
we've already created a database Security Group when we did the VPC section of this exercise so untick
1:00:37
default and from the drop down list select database SG
1:00:42
okay availability Zone we'll select 1A is our
1:00:48
preference where we want to place our database expand additional configuration just make sure that the default Port is set
1:00:54
to 3306 which is exactly what we want a little bit further we'll leave the
1:01:00
database authentication to password authentication and then you want to expand additional configuration now here
1:01:06
you need to provide a database name so I'll use the same name devdb
1:01:12
we'll set the backups to enabled we'll set the retention period to one day okay
1:01:19
and we can leave the encryption enabled as well so with encryption it's going to use the
1:01:25
default KMS key for RDS and if you're interested in learning more about encryption and kms's check out our
1:01:33
website for some more videos on that I'll leave everything
1:01:38
else at its default settings okay and I'll scroll all the way down and
1:01:44
click create a database now this takes a good five to ten minutes to create so
1:01:50
you probably want to go ahead and grab yourself a cup of coffee tea or whatever I'm going to pause the video over here and then when it's all done I'll resume
1:01:56
the video so here we are our database has been launched and configured and is in the available state if we actually
1:02:03
take a quick look at the database so you've got your connectivity and security details here so that is your
1:02:09
endpoint okay so that is what your application needs to connect to in addition to that the application will
1:02:15
need to know the database name which is dvdb and obviously the username and password and these pieces of information
1:02:21
especially the username and password we're going to configure in Secrets manager so now that we've set up the
1:02:27
database okay the next step is to move on and work with Secrets manager and configure Secrets manager to store the
1:02:33
credentials of this database let's move on to step three next okay let's move on to step three where
LAB - Step 3 - Configure Secrets Manager for your RDS database
1:02:40
we're going to go into Secrets manager and configure a secret for our database
1:02:45
okay here we are back in my AWS Management console so I'm just going to go into Secrets manager
1:02:51
open that up in another tab okay so in Secrets manager we're going
1:02:56
to go ahead and store a secret Now secrets manager will allow you to store credential data for your RDS database
1:03:03
the service also provides the ability to rotate your credentials for databases like RDS but we'll do that a little bit
1:03:10
later initially what we want to do is Click store a new secret and you want to select the secret type as being
1:03:16
credentials for an RDS database next you're going to put the username and the password for your database so hopefully
1:03:22
you made a note of it okay we don't need to make any other
1:03:28
changes other than select the database that we are going to provide the secrets for click next and then you need to
1:03:35
provide a secret name you can use the strategy of using slashes to have different names for different
1:03:41
environments and different versions of your application okay so I'm just going to select Dev MySQL
1:03:49
credits okay and then you can have a description as well in there for What
1:03:55
that particular secret is used for leave everything else again as it is and click next this is the page where you
1:04:01
configure automatic rotation now we're going to skip this for now okay because I just want to revisit this a little bit
1:04:07
later click next and then once you're happy with all of this click store okay
1:04:13
so this now configures your secret so if I just quickly refresh this page there's my secret currently rotation is disabled
1:04:21
like I said we will revisit that but all of my secret information so my credential information for my database
1:04:26
is actually stored in secret so if I click retrieve secret value
1:04:33
okay you will actually see all of the data related to my database come out including the username and password that
1:04:39
I specified Okay so book manager created for us next we're
1:04:46
going to move on to step four now step four is we need to set up some permissions and an IM role in order to
1:04:52
allow ec2 to access Secrets manager as well as obviously interact with the elastic Beanstalk service okay so let's
1:04:59
do that next okay so for step four we're going to create an I am role with necessary
LAB - Step 4 - Configure IAM roles for Elastic Beanstalk
1:05:05
permissions now the purpose of creating an IM role is to create an instance profile an instance profile is something
1:05:11
that you attach to an ec2 instance when it needs to have certain permissions assigned to it so that it can go and do
1:05:19
something it can interact with other services on the AWS platform an instance profile is essentially a container for
1:05:26
the IM rule that has the required permissions so this instance profile that we're going to create will need to have an IM
1:05:32
role that we need to Define that allows our ec2 instances to interact with elastic Beanstalk environment now the
1:05:39
role is going to Grant the ec2 instances to perform specific actions so for example retrieving application versions
1:05:46
from your S3 bucket writing logs to the S3 service if you're using ECS and Docker environments as we
1:05:54
previously discussed then obviously coordinating the deployment of ECS container services and if you are
1:06:01
building a worker environment then you know performing actions like being able to read from the sqsq for example is
1:06:07
another permission that the ec2 instance is required so we're going to move on and create our IM role in this step
1:06:15
let's get back into the database Management console okay so back to my AWS Management console we're going to go
1:06:20
ahead and go into the IEM dashboard so I'm just going to open IAM in another
1:06:26
tab and then I am we're going to create this IEM role that's going to be consumed by
1:06:32
an instance profile that will be attached to your ec2 instances that elastic Beanstalk deploys the ec2
1:06:39
instances with this instance profile will have the permissions to interact with elastic Beanstalk and we also need
1:06:46
to Grant the ec2 instances permissions to interact with Secrets manager remember Secrets manager has a secret
1:06:51
that we configured that has the credentials of our database in order for your ec2 instances to talk
1:06:58
to Secrets manager and pull that secret okay it needs permissions to do so so
1:07:04
let's do that next from the left hand side go ahead and click roles and then
1:07:09
click create a role and it's an AWS service role entity type and The Trusted
1:07:15
entity is going to be ec2 in this permissions policy filter AWS
1:07:22
elastic and what that will do is that will give you a series of manage policies that AWS
1:07:29
has created already for you that you can use now the three policies that you need to use are AWS elasticbean stock web
1:07:36
tier AWS elastic Beanstalk worker tier and AWS elastic bean stock multi
1:07:42
container Docker okay we're just adding some additional policies but essentially these permissions allow you to do things
1:07:48
like upload log files to S3 interact with sqs if we did create a worker tier
1:07:54
and all that stuff so I'm just creating a role that has all the necessary policies
1:08:00
let's give the roller name so I'm going to call this one Dev EB ec2
1:08:06
I am roll okay so I know exactly what it is and then we'll click create a role so at
1:08:13
the moment what we've done is we've created the role with those three policies but we still need two if we go
1:08:19
to Dev EB ec2im role add an inline policy so that the role can also talk to
1:08:25
Secrets manager so click add permissions click create an inline policy
1:08:30
click on the Json Tab and I've actually got a policy that I have created for you
1:08:36
and here's the policy it's available to you in our GitHub repository as a sample policy and you're welcome to use this
1:08:42
policy along with the application code when you deploy the application in your AWS account
1:08:48
so just to show you what the policy does the effect is allow so it's an allow policy and the action is the ability to
1:08:54
get secret value from Secrets manager and in order for the policy to work you need to provide the secret manager Arn
1:09:00
the AR end of the secret that you created so let's grab that policy first
1:09:06
and we'll replace this with our policy and then go back to Secrets manager and
1:09:13
just grab the Arn of the secret you created which is that one over there in my case and replace the placeholder value with
1:09:22
the actual Arn okay and then click next you need to
1:09:27
give the policy a name so this is Dev EB ec2 secrets
1:09:35
policy so I know exactly what it is and click create policy right there's our IM
1:09:41
rule it's got the three elastic Beanstalk managed policies that AWS manages and it's got one inline policy
1:09:47
that I have put in there that I manage that has access to Secrets manager of
1:09:54
that specific secret Arn fantastic let's move on to step five
LAB - Step 5 - Create an Elastic Beanstalk Application
1:10:01
right you've done all of the prerequisites you've built a VPC you've deployed an RDS database in that VPC
1:10:08
you've configured Secrets manager and you've set up the necessary IM rules with all the permissions that you
1:10:14
possibly need next we're going to move on and actually work with elastic Beanstalk and deploy
1:10:19
the application into elastic Beanstalk before you do that though you need to download the application source code
1:10:24
bundle from our GitHub repository so let me show you where that is first and then we'll jump back into the AWS Management
1:10:29
console and deploy this application okay so you have access to the
1:10:35
application source code bundle that we're using for this project it's available in our GitHub repository the link of which is available to you in the
1:10:42
resources section of this video or down in the description box below you'll need to download the EBS RDS to do app code
1:10:48
version 2's zip file and place it on your desktop or in a location that's easily accessible you will actually be
1:10:55
uploading the ZIP code bundle as it is as a zip file to the elastic Beanstalk
1:11:01
application when you configure elastic Beanstalk but I wanted to extract the contents of the zip file and just show
1:11:06
you what it contains so let me do that first okay so here we are the contents of my application source code bundle
1:11:13
it's got a few files and a few folders and specifically it's also got the vendors folder which has a lot of the
1:11:18
sdks that AWS supplies for its various services so the application makes use of
1:11:24
those in order to connect to the Amazon web services platform and make use of
1:11:29
certain Services now specifically there is an index a PHP file and a server.php
1:11:35
file all of the front end look and feel is all set up in the
1:11:40
index.php file the server.php file is what connects to the backend database and performs all of the back end magic
1:11:47
let me open that up for you in Visual Studio code okay and there we are so this is my
1:11:54
visual studio code with the server.php file and it's open State and I just wanted to quickly show you a couple of
1:12:00
things over here firstly this includes the AWS PHP SDK so it allows you to
1:12:06
interact with the platform as this application is built using PHP what it does is it inputs the secret manager
1:12:12
client and the AWS exception clients as part of the code and then it also
1:12:18
specifies the region that it's working in okay and furthermore it actually is able
1:12:25
to retrieve the secret value from Secret manager okay and it stores that as an
1:12:31
environmental variable now the important thing is that the secrets particularly the username and password are encoded in
1:12:36
plain Json string and there's a Json date code function here that basically retrieves that usernames and password
1:12:42
and once it retrieves that username and password dynamically it is allocated to two variables which are DB username and
1:12:48
DB password DB server and DB database are additional names that we'll add in
1:12:54
the elastic Beanstalk environment properties from which it will retrieve those values but the username and
1:12:59
password will be dynamically retrieved from the secrets manager client okay so
1:13:05
that's why this becomes very very secure as it's dynamically retrieving the credential information and subsequently
1:13:12
we will be able to also rotate those secrets and continue to still access the database because we will dynamically
1:13:19
retrieve the credential data the ec2 instances on which this particular piece
1:13:25
of application code runs on has the instance profile and therefore the IAM role to be granted access to Secrets
1:13:31
manager and that's where the power of IAM roles and IM profiles come into play okay enough about all the code and stuff
1:13:38
let's actually jump back into the AWS Management console and set up our elastic Beanstalk application okay so
1:13:44
back into my AWS Management console we're going to go into the elastic Beanstalk dashboard so in the search bar
1:13:49
just search for elastic Beanstalk and open that up in another tab
1:13:57
so the first thing that we're going to do is create the elastic Beanstalk application remember that the application is simply the container that
1:14:04
will host your environments within which we will deploy the application and I'm going to give the application a name so
1:14:10
this is a Dev to do application so the application that you'll be
1:14:15
deploying is actually a to-do list application that allows you to create
1:14:21
your to-do list and it saves that data in a back-end RDS database and performs all the crud operations against the
1:14:27
database so let's take a look at what that application looks like so we'll go ahead and create the application
1:14:35
and once you've created the application we then need to create an environment
1:14:41
within which to deploy the actual application code into so when you click configure environment you need to select
1:14:48
whether you're setting up a web server environment or a work environment so we'll be creating a web server
1:14:53
environment which incidentally has both the front-end back-end elements in it in a real world scenario depending on how
1:14:59
complex your application is you want to properly split the two as we have discussed in our previous
1:15:05
slides but for now let's just create the web server environment so the web server
1:15:10
environment has been built for our dev2do application and you can choose your own domain name
1:15:16
I'm going to leave that as default as well you'll just need to type in a preferred name and then check that it's
1:15:22
available when it comes to the platform ensure that you select PHP because the
1:15:27
application is built using PHP the platform branch is going to run on a 64-bit Amazon Linux 2 and the version is
1:15:34
3.5.9 next you want to upload the code so this is going to be the zip file bundle
1:15:43
so you want to click local file and select the location where you have your
1:15:48
application source code bundle downloaded so in my case it's over here so remember
1:15:54
you want to upload the zip file itself okay and click open next you want to click on high
1:16:00
availability because we want elastic beam stock to provision load balances and auto scaling for us for high
1:16:06
availability and then to scale out as well as scale in Click next oh need to
1:16:12
give it a version name I'm going to call this one V1 and then click next
1:16:17
okay so the next step is to create service access now this is
1:16:23
where creating necessary I am role comes into play now what you need to be aware of are there are two roles basically
1:16:30
used by elastic Beanstalk there's a service rule that allows elastic Beanstalk to assume the service role and
1:16:36
to perform various elastic Beanstalk actions against the environment that is
1:16:41
being built now you could get a service role created for you I've got one
1:16:46
previously created so I'm just selecting the same one just to show you what permissions this service will contain
1:16:52
let's go back into IM roles and this one over here AWS elastic Beanstalk service
1:16:57
rule essentially it contains two managed policies that allows for health monitoring and managing updates on the
1:17:04
elastic Beanstalk environment okay so that needs to be selected or you create one from scratch so you
1:17:11
allow elastic Beanstalk to create it for you next you have the ec2 keypad now this is only needed if you're logging
1:17:17
onto your ec2 instances however I strongly recommend that you know instead of using easy to key pair to use SSH to
1:17:24
log into your instances you use AWS session manager if you want to know a bit more about session manager check out our other video in this course that
1:17:32
talks a little bit more about how it works and then finally you want to select the
1:17:37
instance profile now this is the IEM role we created a few moments ago that has necessary permissions to allow our
1:17:43
instances to talk to elasticbeam stock S3 sqsq depending on which environment you're placing it in
1:17:50
as well as the inline policy to allow the ec2 instances to retrieve the credentials from Secrets manager okay so
1:17:57
you select the instance profile there and click next networking database and tags option for
1:18:04
the VPC select the VPC where we're going to deploy our elastic Beanstalk instances in and that's the dev VPC that
1:18:10
we built right at the start of this lab then you need to specify where those instances need to be deployed now
1:18:17
remember in our architecture diagram we created the app subnets okay which was a private subnet that we want to use for
1:18:22
all of our instance deployment so that was app subnet02 and app subnet01 okay
1:18:29
so these two subnets are going to be used to deploy our instances this option allows you to configure
1:18:36
database integrated with your environment and we said that whilst this allowed you to quickly and easily set up
1:18:41
databases in real world production environments you probably want to have your database externally hosted from the
1:18:47
environment so we're not going to enable database here in any case we already have our RDS database already configured
1:18:54
scroll all the way down and click next okay now with regards to configuring the
1:18:59
instance traffic and scaling okay leave the root volume at its default settings
1:19:05
for the ec2 security group make sure you select the dev app server SG Security Group remember the purpose of creating
1:19:11
the security group was so that we can define a source for our database Security Group okay so our database that
1:19:18
we launched in the RDS section of this lab has this bit particular Security
1:19:23
Group attached to it the dev database SG and it allows inbound traffic on Port 3306 to mySQL port
1:19:29
only from instances associated with the app server SG so we want to make sure that when elastic Beanstalk launches
1:19:36
your instances it attaches the security group to it okay so all of our instances must be
1:19:43
attached to this Security Group from a capacity point of view it's going to be load balance and I'm just going to
1:19:48
put two over there okay scroll down a little bit further and we want to just go with the T3 micro
1:19:55
types I'm just going to remove T3 small we don't want it to be charged we're going to use free tier
1:20:01
that's the Ami ID that elastic Beanstalk is going to use we're going to leave all
1:20:06
of these other values as it is and move on to load balancer network settings now for the load balancer
1:20:12
you want to place a load balance in the public subnet okay the nodes need to be deployed in the public subnets and
1:20:19
specifically that's going to be public subnet01 and public subnet02 okay because the load
1:20:26
balancer sits right at the edge receiving traffic from the internet and Wheeling that traffic back into
1:20:31
instances in the private subnet and the type of load balancer is going to be an application load balancer because we're
1:20:36
routing HTTP traffic in this case and then you want to pretty much leave everything else on this page at its
1:20:43
default value and click next okay when it comes to configuring updates monitoring and logging for the
1:20:49
help reporting ensure that it's set to enhanced you could set up email notifications if
1:20:54
you wanted to be notified of important events in your environment and then there's also the rolling
1:21:00
updates and deployments for when you make upgrades to your application now we have another video that talks about this
1:21:06
in a bit more detail as an advanced topic feel free to check that out as well but for now just leave everything at its
1:21:13
default value scroll down until you get to environment properties now this is the important
1:21:19
part for the environment properties you're going to set up three environmental variables so the first one
1:21:24
is going to be the DB underscore endpoint okay so this is the actual DB
1:21:31
server endpoint and if you go back to your RDS Management console and go into your database
1:21:38
and click on your database that's this one over here so you've got the endpoint value there you just want to grab that
1:21:46
and place that in there next you're going to add the DB name so DB
1:21:51
underscore name and this is going to be devdb
1:21:56
okay and then finally you want to type in the secret name okay now the secret name is the name of
1:22:04
the secret that hosts my credentials so if I go back to Secrets manager that's this one over here so that's my secret
1:22:10
name and we're going to place that value in there and our ec2 instances are going to
1:22:17
connect to Secrets manager look for this name and pull the username and password for the database dynamically okay then
1:22:22
we click next this is your page to review all of your settings make sure it's all in order and
1:22:30
finally click submit and so now what we're doing is we're submitting the job to elastic Beanstalk to go and do all of
1:22:37
its magic and in the back end it's going to use cloud formation to build everything for us as per our
1:22:42
configuration requirements okay so it says elastic Beanstalk is launching environment this will take a few minutes
1:22:48
and it does take a few minutes so why don't you go ahead and grab yourself another cup of tea or coffee I'll pause
1:22:54
the video for now and once this is all set up we'll continue from where we left off right welcome back
1:23:01
free launched so elastic Beanstalk went ahead and did all this wonderful magic in the back end to set up our
1:23:08
environment and to deploy our application onto the AWS platform
1:23:14
now elastic Beanstalk gives you a domain name to connect to so if I open this up
1:23:19
in another browser tab you will see that the application has
1:23:25
now come up so this is a to-do list application okay it gives you the date
1:23:30
and the time and it gives you this little form that you can fill up so let's give it a try so let's say I have
1:23:37
a work to do list okay complete video on elastic Beanstalk
1:23:46
okay and the due date is oh it has a nice calendar format let's put in that
1:23:51
date and the status is in progress so I'm going to click submit and it says to do add it successfully
1:23:58
well nice to know and if I scroll a little bit further down you will see that my
1:24:04
table is updated okay fantastic Let's uh let's add another one another work one
1:24:10
okay um prepare elastic being stock
1:24:18
deployment presentation this is going to be the next topic that I'm going to work on
1:24:23
and the due date is oh let me give myself some time to work on this
1:24:29
and it's not started let's submit that one and there you go so you can see what's
1:24:37
happening this application interfaces with the backend database the RDS database it stores all of this data in the RDS
1:24:44
database okay and it also retrieves the data from the RDS database so it's a PHP
1:24:51
application it does this bit of magic and performs all the crud operations for the database I can change the status so
1:24:58
let's say I've already started working on something over here maybe started and
1:25:04
that will change the status and that's all done so once I've completed this
1:25:09
video I'll click completed and it will change the status and oh it gives me a nice green block as well so my intention
1:25:17
is to get everything green for you guys so that I can prepare more videos like this one well I hope you enjoyed the
1:25:23
application as I said it's just a simple application just a one pager but it demonstrates the fact that this
1:25:30
is a multi-tier application there's a front and backing element to it there's a database element to it and you can use
1:25:35
elastic Beanstalk to provision the underlining infrastructure deploy the application and manage its life cycle I
1:25:41
wanted to also give you a quick run through about some of the things that elastic Beanstalk has done so if I go into the VPC section you'll see on the
1:25:47
security groups elastic Beanstalk went ahead and created two more security groups this one over here for example
1:25:53
is the load balancer security group so that it is configured the inbound rules to allow traffic on Port 80 from the
1:26:00
internet and this next one is a VPC security group that in fact
1:26:08
has the source as the load balancer Security Group so now if I go into ec2 in another tab very quickly
1:26:17
okay let's go into ec2 you'll see that one instance is running that's my instance that was deployed by elastic
1:26:22
Beanstalk okay there it is and that particular instance if I click
1:26:28
on security is attached to two security groups one is the dev app server Security Group which we created and one
1:26:34
is the one that elastic Beanstalk created so in effect this instance has two security groups once you accept
1:26:39
traffic from the internet via the load balancer and one to act as a source for traffic that's going to hit the database
1:26:46
in the back end okay okay so that's how the security groups work in this architecture
1:26:52
so elastic bean stock has also provisioned our load balancer so if I go on the left hand side and click on load
1:26:58
balances okay and you can see this is a load balancer that elastic Beanstalk deployed
1:27:03
for me and elasticbeat stock manages this load balancer go down to Auto scaling groups
1:27:08
and you can see that elastic beanstalker also provisioned the auto scaling grip and its activities are available to me
1:27:16
as well okay so elastic Beanstalk did all of this heavy lifting that I would have had to do manually if I wasn't
1:27:23
using elastic Beanstalk okay so now that all of that is in place just go back to the application our
1:27:28
application is fully functional it's performing all its crud operations and it's connecting to the database
1:27:34
there's one more step left let's go on to step six six I wanted to go back and revisit
LAB - Step 6 - Enable RDS credential rotation in Secrets Manager to enhance Elastic Beanstalk application security.
1:27:41
Secrets manager I wanted to update the secret that we had created earlier in Secrets manager to enable rotation of
1:27:48
the database credentials and as long as your application code has been designed in such a way so that it can use the
1:27:54
sdks and interact with the AWS Services it can dynamically retrieve updated credentials from Secrets manager and
1:28:02
access the database and the back end so let's get back into the AWS Management console and edit the secret that we
1:28:09
created earlier okay so here we are back into our AWS Management console let's just go into our secrets manager and go
1:28:16
into our secret and all I want to do is go down to edit rotation and enable
1:28:21
automatic rotation and I'm going to make a change to the rotation schedule and set that to days and set it to every
1:28:27
seven days okay and we're gonna go ahead and basically
1:28:33
enable Secrets manager to create a rotation function okay and we can add a
1:28:39
particular value here so it will have the prefix of Secrets manager and I'll do something like MySQL
1:28:47
Dev rotation okay and then we'll click save now what
1:28:56
this is doing is it's actually enabling the feature for rotating my database credential now
1:29:02
you may have noticed that very briefly the rotation status went to enabled and then it's gone back to disabled and that
1:29:08
is because cloud formation in the backend is performing all the magic it's actually setting up a stack in order to enable
1:29:15
this feature and if we quickly went into cloud formation and if I open that up in a different tab
1:29:22
you will see that Secrets manager RDS MySQL rotation
1:29:28
is in a create in progress state so we're just going to have to wait for this to run through and then once it's
1:29:35
complete we should find that rotation configuration has been enabled I'm going
1:29:40
to pause the video over here and then we'll come back as soon as the cloud formation templates have been deployed
1:29:45
and the stack is ready okay so here we are back at my cloud
1:29:50
formation console and you can see that the stacks have been deployed this status is set to create complete okay so
1:29:57
we're good now what this basically means is that if I take you back into Secrets manager you will see that the rotation
1:30:03
status is set to enabled it's going to happen every seven days and that's the
1:30:08
next rotation date now what actually happens in the background is that cloud formation creates a Lambda function and
1:30:15
the Lambda function integrates with a database and is able to change the
1:30:20
credentials in this case every seven days on our data now let's just take a quick look at the Lambda function itself
1:30:26
I just want to show you what's happening so if we go into Lambda
1:30:31
and take a look at our Lambda function so this is the function that cloud formation created okay it rotates the
1:30:38
secrets manager secret with the MySQL credentials at the specified schedule
1:30:44
that we defined when we enabled rotation okay and you can see the function Arn if
1:30:50
you scroll down a little bit and go into configuration and VPC there's something
1:30:56
I want to point out over here your Lambda function needs permissions
1:31:01
to talk to the database and when AWS cloud formation creates this Lambda function it Associates it with the same
1:31:09
security group that the database is associated with in this case Dev database is cheap so cloud formation
1:31:16
configured all of this up for us so our Lambda function is now associated with the security group Dev database SJ
1:31:23
as a means of now being able to communicate with our database however there's a slight problem here if we go
1:31:31
to this Security Group so if I go back into VPC okay here's my VPC these are my security groups if I go to Dev database
1:31:38
SG and go into inbound rules the only entities that can communicate with our
1:31:45
database okay is in fact any instance Associated or any resource
1:31:52
for that matter associated with a Dev app server SG okay and this is important although your Lambda function is
1:32:00
associated with the dev database SG which is the same security group that the database is associated with you will
1:32:07
see that the dev database SG is the security group associated with the database the problem is that the only
1:32:14
resources that can communicate or send traffic to the database on Port 3306 are
1:32:20
any resources associated with the dev app SG and so what this means and hopefully
1:32:26
you've got this already that the Lambda function will perform the necessary action that it needs to
1:32:32
perform but it will fail okay it will not be able to change the database because technically it's not able to
1:32:39
send traffic to the dev database SG so what we're going to do is we're actually going to create a new security group and
1:32:44
attach it to the Lambda function and use that to Grant the Lambda function the
1:32:50
ability to access the RDS database so create a new Security Group let's call this one Dev
1:32:56
Lambda SJ okay I'm just going to give it the same for the description make sure
1:33:02
you put it in the right VPC and click create Security Group
1:33:07
okay now so that's the security group created we then need to go back to our security group lists go to the dev
1:33:14
database SG edit inbound rules there and add the same MySQL traffic
1:33:24
from the Lambda SG okay so that's this one over here okay so we're allowing
1:33:30
inbound traffic from any resource that is attached to the Lambda Security Group
1:33:35
on Port 3306 so we'll save that okay and also just once we're here let's just put
1:33:41
copy this name and put it under the name column just so that we can easily recognize all of our security groups so
1:33:47
that's that's good and then go back into your Lambda function okay and in your
1:33:53
Lambda function you want to go back to configuration back to VPC and then edit
1:33:59
the security group configuration So currently the security group is set to Dev database we want to get rid of that
1:34:04
and you want to select the Lambda SG Security Group and then click save and
1:34:12
at this point in time the Lambda function is going to be updated so that it can consume and use the dev Lambda
1:34:18
Security Group in order to make its connection to the database that we have in the back end now this takes a few
1:34:25
moments to complete so I'm going to pause the video over here again and then come back as soon as it's done okay so as you can see the configuration has now
1:34:31
successfully updated the Lambda function and so the Lambda function is now using the dev Lambda SG group in order to
1:34:38
granted the necessary ability to talk to the backend database so if we go back to
1:34:43
our secrets manager what we should be able to do is Click rotate secret immediately
1:34:49
and not wait for the seven days and I'm just going to click rotate and then if we go and click on retrieve secret value
1:34:56
you will see in fact that the secret has now changed so this is not the password I'd use when I set up the database what
1:35:02
this means is that secret manager has made use of the Lambda function the Lambda function has updated the database
1:35:07
password and now our application should be able to pull this new password using the environment properties that was
1:35:14
configured in elastic Beanstalk to say where to retrieve the secret from IE
1:35:20
from this secret name here okay so now if I go back to my application and just do a quick refresh
1:35:28
okay so that's refreshing my page okay so if we scroll down we can see that we can still read from the database let's
1:35:33
see if we can add stuff to the database I'm going to click on another work task and I'm going to say create slides for
1:35:43
machine learning okay and the due date for that is I'm going to set a due date to 30th of July
1:35:51
and I'm going to say not started and click submit and it says to do added
1:35:56
successfully and if we scroll all the way down and yes indeed it has so in fact the new credentials are being used
1:36:03
the application is dynamically pulled those credentials and it's still able to communicate with our database fantastic
1:36:08
our multi-tier application has been successfully deployed it is using
1:36:14
best practice methodology is about where the application is based the database placement within the VPC it's also using
1:36:20
Secrets manager to interact with the database and it's in a highly secure VPC configured with necessary security
1:36:27
groups and permissions it also uses IEM roles that grants it the necessary permissions
1:36:33
to interact with the other services on AWS and so hopefully this has been a really useful Hands-On demonstration of
1:36:40
how to deploy an application on the elasticbean stock service the application source code as I mentioned to you earlier is available to you
1:36:47
absolutely free of cost and so you're welcome to try this out in your own environment follow the step-by-step
1:36:52
guide in this video and gain that much needed hands-on experience of actually working with elastic Beanstalk because
1:36:58
that's how you will develop your skills on the AWS platform now if you enjoyed this video and you found it useful
1:37:04
please hit the thumbs up and please subscribe to this channel so that I can notify you as and when I release new AWS
1:37:10
projects and you can continue to develop your skills on the AWS platform thank you

summarize this video trasscipt in points like
Intro
0:00
AWS elastic Beanstalk is a platform as a service solution designed to help you
0:05
deploy your applications without manually configuring the underlining infrastructure to host and support that
0:12
application all you need to do is upload your application source code and provide details of how you want the
0:18
infrastructure that supports the application to be configured elasticbeam stock will then build deploy and manage
0:24
that infrastructure on your behalf in this video you will gain hands-on experience deploying a multi-tier AWS
0:31
application using the elastic Beanstalk service you will learn about the core features of elastic Beanstalk its key
0:37
components recommended best practices and security measures when deploying real-world applications in the cloud
About your instructor
0:45
hello and welcome to my channel my name is Rajesh and I am a Senior Solutions architect with over 20 years of
0:51
experience in the IT industry I've helped numerous clients migrate to the AWS cloud and have worked with
0:56
businesses across the US UK and India over the last five years I've delivered technical training programs on AWS I'm
1:03
also the author of The AWS certified Cloud practitioner exam guide published by Pact publishing and available on
1:09
Amazon and major bookstores now I've designed this video to help you gain practical experience with the AWS
1:14
elastic Beanstalk service if you already have some knowledge of elastic Beanstalk feel free to skip ahead to the Hands-On
1:20
Labs using the timestamps below if you are new to elastic Beanstalk then I highly recommend that you go through the
1:26
entire video okay that's enough about me let's start the AWS tutorial even though
The problem with traditional application deployments
1:32
cloud computing has made it much easier to build and deploy your applications you must still consider the vast array
1:38
of infrastructure services that need to be configured to support and host those applications and so you need to design
1:44
plan and provide the necessary infrastructure to host and support the application and that also means that you
1:50
should configure your infrastructure components to ensure security reliability scalability and high
1:56
availability to ensure that your application is always available for your end users and so in a typical
2:02
infrastructure configuration you're going to host vast array of different components so there will be networking
2:08
components as an example you'll need to build a VPC within which you will deploy your application you may need to
2:14
configure some load balances to distribute traffic across your compute services within that VPC not to mention
2:21
that you might also need to deploy cloudfront if you're hosting your application in one region but want to
2:26
provide access across the globe there's compute services that you need to configure you need to firstly decide
2:33
whether you're going to use ec2 ECS or Lambda functions but ultimately you still need to configure those individual
2:39
Hardware components you may also need to configure some storage services such as object storage like Amazon S3 or block
2:46
storage devices that need to be attached to your ec2 instances let's not forget about databases most
2:53
applications need to store structured data somewhere and databases are sitting in the back end of every application out
2:59
there hosting valuable data and then there's the security aspect of
3:05
it you may need to configure some IAM roles to allow your applications to interact with various AWS services on
3:10
the platform or you may need to think about configuring encryption services so that your data is safe and secure let's
3:16
not forget about Secrets manager which allows you to host database credentials and secrets which can be dynamically
3:22
retrieved by your application and then finally you may also need to have some monitoring and logging
3:28
services so you're using Amazon cloudwatch for instance is going to be a vital component in your overall infrastructure
3:35
design and so hopefully you're beginning to realize that hosting an application is not all that easy and so you have to
3:42
carefully plan and design not just the application but also the underlying infrastructure that's hosting that
3:47
application now AWS has another solution that can allow you as a developer to focus more
Introduction to AWS Elastic Beanstalk
3:52
on your code rather than the underlining infrastructure and that's where I'd like to introduce you to the AWS elastic bean
3:59
stock service so the AWS elastic bean stock service is a platform as a service solution a Paz
4:05
solution that can help you deploy and manage your applications on AWS without having to individually configure and
4:11
manage the underlining infrastructure that supports your application as a developer you can upload your code
4:17
to elastic Beanstalk and elastic Beanstalk will configure the infrastructure and the environment the
4:23
service will also provision supported platform versions to put your applications that are designed and built
4:29
in supported languages such as gojava.net node.js PHP python and a few
4:35
others how to help you do need to be aware of the fact that as a developer you still need to understand the
4:41
infrastructure and architecture design principles for your application requirements and
4:46
what this means is that you still need to be in a position to dictate exactly what the infrastructure needs to look
4:52
like how the network needs to be built what sort of storage Services you need to consume whether you're going to go
4:58
with load balancing and auto scaling all of those components that fulfill your application infrastructure needs is
5:05
something that you do need to have a good understanding of and the reason for that is elastic Beanstalk gives you full
5:12
flexibility on how the underlying infrastructure is built and configured to support your application elastic been
5:18
supposed to do the heavy lifting of actually configuring and setting up that infrastructure but you need to tell it
5:23
what to do you could leave elastic Beanstalk to provision a base standard infrastructure
5:29
for your application but most of the time you're going to find yourself in a position where you need to actually be
5:34
involved in how that infrastructure is going to be set up now elastic Beanstalk uses cloud formation to build
5:40
infrastructure for your application so cloud formation is an infrastructure as a code solution that Provisions
5:45
infrastructure from code based on the templates that Define how that
5:51
infrastructure should be built and elastic Beanstalk actually makes use of cloud formation to build infrastructure
5:56
that you are trying to set up to host your application this is something to be aware of and specifically the
6:02
differences between elastic Beanstalk and cloudformation for your exam so whereas cloud formation will help you
6:07
build underlining core infrastructure components to support one or more applications elastic Beanstalk is highly
6:14
focused on that individual application that you're trying to deploy on AWS and Provisions the necessary infrastructure
6:20
using cloud formation to support that application so next let's look at which platforms elastic Beanstalk actually
6:27
supports so elastic Beanstalk Provisions your core infrastructure and environments for the following supported platforms and
AWS Elastic Beanstalk Supported Platforms and Languages
6:33
languages and as long as your application is built in these supported languages and platforms then you're
6:40
pretty much good to go and will be able to deploy your application using elastic Beanstalk and these include Apache
6:46
Tomcat for Java applications Apache https for PHP and Python nginx and
6:51
Apache HTTP server for node.js DOT node core for Linux and dotnet for Windows go
6:57
Ruby and a few others now a really cool feature of elastic Beanstalk is that if
7:03
your application architecture isn't built using one of these supported platforms or runtime environments you
7:08
can always use Docker containers with Docker containers you can Define your own runtime environment platform
7:13
programming language and any application dependencies because Docker containers are self-contained and include all the
7:19
software that your web application needs you have extensive flexibility on the type of applications you can host using
7:26
elastic Beanstalk now we've got two options when it comes to Docker so the first option is to use Docker runtime on
7:31
64-bit Amazon Linux 2. this is ideal for single Docker containers where it refers to deploying a single or multiple
7:37
containers on ec2 instances the docker image can be built by supplying a Docker file an elastic Beanstalk will actually
7:45
go and set up your Docker image or you could provide it with access to a Docker
7:50
image the second option is to use ECS running on 64-bit Amazon Linux 2 ECS
7:56
stands for elastic container services and it is a container orchestration management solution offered by AWS with
8:03
this second option elastic Beanstalk performs all of the ECS activities such as creating your ECS clusters task
8:09
definitions task execution you can also Define the environmental variables in the elastic Beanstalk console which are
8:15
then passed on to the containers now an important point to note however about this easiest option is that your
8:21
Docker images must be pre-built and stored in a repository unlike the previous option you cannot simply Supply
8:27
a Docker file and expect elastic bean stock to then build out your Docker image now before the introduction of
8:33
ecss being used to host multi-docker containers there was an option otherwise known as
8:39
Docker Legacy to host multi-container Docker containers and these can actually
8:44
be migrated to ECS running on 64-bit Amazon Linux 2. so if you are running an
8:50
older multi-container Docker running on 64-bit Amazon Linux platform Branch those can now be migrated to ECS running
8:58
on 64-bit Amazon Linux 2 platform branch okay next I'd like to take a look at a
9:04
typical architecture design pattern about how the various components of elastic Beanstalk work with each other
9:09
so let's do that next okay so let's take a look at the different elastic bean stock components next so here we have
AWS Elastic Beanstalk Components
9:15
our developer menu he's been working for our company and he's built an application that he wants to deploy on
9:22
AWS but he doesn't want to do the heavy lifting when it comes to the underlining infrastructure so it's going to go with
9:27
elastic bean stock which is our platform as a service solution now menu needs to actually create what's called an elastic
9:33
Beanstalk application now this is not an application in a traditional sense from an elastic Beanstalk perspective this
9:40
application describes the container that will contain the actual application code
9:46
environments runtime libraries and and the infrastructure components to support the application
9:51
so think of the elastic Beanstalk application as simply a container to hold all of this stuff together and so
9:57
for the exam remember that elastic Beanstalk application is simply a collection of the infrastructure resources environments application
10:03
versions and configurations once you've got the application created you can then describe and configure the
10:11
elastic Beanstalk environments now what do we mean by that is essentially what menu needs to do is he needs to upload
10:17
the application code to elastic Beanstalk an elastic Beanstalk will deposit that code into a managed S3
10:24
bucket so menu essentially uploads the application code to elastic Beanstalk and elastic beadstock puts that
10:31
application code into a manage S3 bucket these are called application versions and there are specified versions of
10:37
Deployable code that are stored as a bundle in the Amazon S3 platform and it could be in a zip format or a wire file
10:43
stored in the S3 environment now this S3 bucket is linked to your
10:49
elastic Beanstalk application okay so when you create your elastic Beanstalk application and you upload your code an
10:55
elastic Beanstalk bucket is created if one doesn't already exist just support and host the application code next for
11:02
the application menu we'll need to create one or more environment so when you're deploying applications on AWS
11:07
usually you're going to deploy it in multiple environments you'll be a Dev environment a test environment and a production environment
11:13
and usually you'll have different application versions deployed across this environment where the production
11:19
environment will usually have an older more stable version of your application code as opposed to your Dev environment
11:25
where you may be testing out some new features for example as part of your elastic bead stock
11:32
configuration menu does need to be aware of the core infrastructure components that is going to support that
11:37
application now menu is not going to manually configure most of that infrastructure elastic Beanstalk will do
11:43
that heavy lifting nevertheless menu needs to describe whether we're going to be using a default VPC or a custom VPC
11:49
whether we're going to be using Auto scaling Services how many instances what
11:55
sort of Auto scaling policies we're going to have whether we need an elastic load balancer to distribute traffic
12:00
across those instances and also if we need a backend database in addition to
12:06
that menu will also need to specify any service rules and instance profile for
12:11
your ec2 instances and IM rules are basically assumed by elastic Beanstalk as a service role and ec2 instance
12:18
profile to allow elastic Beanstalk to create and manage your environment so this becomes an absolute necessity when
12:24
you think about permissions and the ability for your instances to interact with other components of the AWS service
12:30
once this environment is configured and set up elastic Beanstalk will then go ahead and
12:36
actually deploy your application versions to your environments and provision your application within those
12:43
ec2 instances ready for your users to be able to interact with them
12:52
it's like whether you want to export log files to cloudwatch the help monitoring of your services if you want to send out
12:59
email notifications to the administrator whenever events takes place in your in our sick bead stock environment and so
13:04
ultimately menu does need to be aware of the core infrastructure components that is going to be used to support the
13:10
application but elastic Beanstalk actually goes and Provisions all of these infrastructure bits and pieces
13:15
using cloud formation okay so this describes at a very high level what an elastic bead stock environment looks
13:21
like and what its various components are however there's a little bit more to it when it comes to the environments that
13:26
elastic Beanstalk allows you to create let's take a look at that next when considering using elastic Beanstalk
AWS Elastic Beanstalk Environment Tiers
13:32
to host your application on AWS you do need to take into account the complexity and the architecture design patterns of
13:38
your application if your application is designed with a front-end element and a back-end element to it as most
13:44
production Enterprise grade applications are then you want elastic Beanstalk to take this into consideration when
13:50
building out the necessary environments to support and host that application now front end refers to the presentation
13:56
layer of your application using a combination of Technologies like HTML JavaScript and CSS developers build the
14:03
user experience element on the web page such as buttons menus Pages links graphics and so on
14:10
backend refers to the server-side development and focuses on the backend operations of your application an
14:16
example could include when you visit an e-commerce website where you purchased an item and are now trying to pull tracking information on your order back
14:23
in services will retrieve the status of your order and present that data to the front end often back-end operations may
14:30
take longer and need to keep up with incoming requests made on the front end of the application and in this scenario
14:35
it is recommended to separate front-end requests from backend processes and use a queuing system to host and manage
14:41
pending requests to support both front and back-end components of your application elastic Beanstalk offers
14:47
what's called environmental tiers these are called web and worker tiers let us
14:53
look at how this all works from an architectural perspective if you have a really complex application that has both
14:58
the front-end and a back-end element to it elastic beams took in provision what are called environmental tiers to support your application architecture
15:05
and so when it comes to deploying your application you do need to specify by whether you're deploying it for the
15:12
front end or the back-end processing element of your application you start off with elastic Beanstalk application
15:17
which is the ultimate container that will host the application the infrastructure and the environment for
15:23
the application in addition to that elastic Beanstalk will provision and manage an S3 bucket which will be used
15:29
to host all of your application versions when it comes to deploying the application within elastic Beanstalk you
15:35
need to specify if you're deploying it for the front-end part of your application or for the backend part of
15:40
your application accordingly elastic Beanstalk will provision a web tier that's for the front end or a worker
15:47
tier which is for the back end when it comes to actually provisioning
15:52
the resources for those environmental tiers elastic bean stock will provision one or more ec2 instances depending on
15:58
the configuration that you choose and will deploy the application on those ec2 instances the instances for the web tier
16:05
will be supported by an auto scaling group and scaling policies to help you scale out or scale back in depending on
16:12
the sort of load that you have on your instances you can actually Define what that scaling policy is as well in
16:19
addition to that for the web tier elastic Beanstalk Provisions an application load balances so that it can
16:24
distribute traffic coming from the internet to those ec2 instances now elastic beam stock will provision the
16:30
ec2 instances for your application which will be dependent on what's known as the container type the container type
16:36
basically defines the infrastructure topology and the software stack that will be used by the environment you need
16:42
to tell elastic Beanstalk what platform your application has been built on what language is being used
16:47
Etc an elastic bean stock will then provision the appropriate container type
16:53
so for example an Apache Tomcat container would comprise of an Amazon Linux operating system Apache web server
16:59
and Apache Tomcat software likewise for your worker environment
17:04
again elastic Beanstalk will provision one or more ec2 instances these instances will be supported by an auto
17:09
Skilling group and auto scaling policies note that there is no application load balancer being configured for your work
17:16
environment that's only for your web environment an additional component that's configured within a multi-tier
17:21
environment such as the one that you're looking at on the screen is the fact that elastic Beanstalk provisions and
17:27
sqsq now an sqsq is designed to take messages from the web tier and hold it
17:34
in the queue and these are going to be basically the requests made from your users coming in from the front end
17:40
within the backend instances there is something called an sqs Daemon that runs
17:45
as an agent on those instances waiting to retrieve any messages that have been
17:51
placed in the queue and these are then retrieved and processed for backend operations the demon pulls the items
17:59
from the queue processes the messages and if successful deletes the messages
18:04
from the queue and as new messages come into the queue this process continues by utilizing a queuing system we can ensure
18:11
that back-end instances that need to do a lot more processing aren't overloaded with massive amounts of incoming
18:17
requests that hit the front end and this helps to manage your front-end and back-end operations very seamlessly when
18:24
it comes to managing the scaling for the backend instances AWS uses a number of
18:29
different metrics in order to manage the scale out of the scaling of those instances one such metric is the
18:36
approximate number of messages visible cloudwatch metric that is used to define whether elastic bean stock should scale
18:43
out and provision more ec2 instances or cutback and terminate certain ec2 instances and once all of this is set up
18:50
obviously your customers are able to come in into your application load balancer and access your web services
18:56
their requests are processed and sent to the queue and then retrieve my backend
19:02
instances to perform all necessary back-end operations an additional point that I want to
19:07
highlight with regards to this entire infrastructure setup by elastic Beanstalk is that elastic Beanstalk
19:12
Provisions each instance with something called a host manager the host manager is an agent that runs on all of your
19:18
instances that manages the deployment of applications generating instance level events monitoring the application server
19:25
patching instance components and Publishing application log files to S3 amongst a few others
19:32
okay now that we've looked at environmental tiers in a little bit more detail it's time to move on to look at
19:37
an actual application design but before we do that there's one more element of your typical application architecture
19:44
that I want to discuss with you and that is the placement of relational databases for your application stack let's do that
Strategic placement of RDS databases for Elastic Beanstalk
19:52
next now within a standard elastic Beanstalk deployment elastic Bean circuit provision for you the
19:57
application okay so that's the container the S3 bucket to host your application code your bundles and the versions of
20:04
application code when configuring your environment you can actually specify an existing VPC to
20:10
deploy your application into or on the Fly set up a brand new VPC you can also Define the environment and
20:18
then within that environment choose your instances that you want to deploy within the auto scaling group configuration you
20:24
can choose the auto scaling policies as well and like we've previously discussed also deploy your application load
20:29
balancer and Define your application layout balancer properties there one of the fundamental elements for most
20:36
applications is that they need to store data in some form of database and as
20:41
part of the elastic Beanstalk configuration you can actually configure a database on the fly so a relational
20:48
database as part of your overall configuration when you configure your application this way you are essentially
20:55
integrating the RDS database within the environment
21:00
and this comes with a lot of benefits so for example elastic Beanstalk is seamlessly integrated with RDS and that
21:06
also means that the settings for your environmental properties the settings to connect to your database are
21:11
automatically set so the environmental properties comprising of the database hostname the port number the username
21:18
the password and the database name are all set for you and ready to go and then
21:23
you just need to test your application and make sure that it connects to the database but with this integration in
21:28
place it's very seamless your application and your database are all
21:34
part of that environment now with some advantages also comes some
21:39
disadvantages so let's take a look at that next if you choose the option to integrate your RDS database deployment with your
21:46
elastic Beanstalk environment and there's a few things that you need to be aware of firstly this configuration
21:52
means that the elastic Beanstalk environment will provision and manage that database for you if you ever need
21:58
to deploy another version of this application perhaps in another environment for testing purposes then
22:03
what that means is the elastic Beanstalk service will deploy another database in
22:09
that new environment and so now you have two separate databases supporting two environments in your application
22:17
it is likely that you were simply trying to make modifications to the application
22:23
code rather than the actual data being held in the database and so if anything both of those environments need access
22:29
to that same data however in this configuration we now have a brand new database that perhaps doesn't have the
22:35
same data as the previous environments database and so you may have some management overhead where you may need
22:41
to copy some of that data from the old database to the new database another important point to consider is
22:49
that when you are using your standard default configuration for setting up an environment that has the database
22:55
integrated within it the default database deletion policy is to delete
23:00
the database when you terminate the elastic Beanstalk environment now that means if you go ahead and delete that
23:06
environment then you're going to lose data as well and this is something that you need to be aware of so when it comes
23:12
to terminating the environment obviously elastic Beanstalk will terminate the core infrastructure it will terminate
23:18
all of the instances but it will also terminate the database resulting in data loss
23:24
if you were mindful of how the database deletion policy needs to be set because you wanted to retain that data prior to
23:31
getting rid of the environment then obviously you would have made that modification then but this is something to be aware of that the default policy
23:37
is set to delete of the RDS database when you go to delete the environment
23:42
now in cases where you already have a database integrated as part of your
23:48
environment you may be wondering whether it's possible to actually remove that database from the environment and
23:53
separate it out from the environment and the answer is yes you can do something called decoupling of your database so
24:00
you can modify the database settings in your environment so that you can decouple the database from the
24:06
environment and decoupling a database will not affect the health of the environment but the thing to be aware of
24:11
is that the database will follow the deletion policy that you choose and that is something you really want to be aware
24:17
of so what happens if you've already set up an environment and perhaps you've used a standard
24:24
deletion policy the default deletion policy and now you've made a decision that you want to decouple that database
24:30
from the environment because you want it to support other environments let's take a look at that next
24:36
so next I'd like to walk you through the steps to decouple your database and one such reason why you might want to do
24:41
that is because you've decided to introduce additional environments into your elastic Beanstalk deployment and
24:48
you want to share that database across those environments you may also want to get rid of some other environments that
24:55
you no longer use and so now you've come to the decision that you need to decouple that database so the steps
25:01
required to decouple the database are as follows the first thing you want to do and this is just a precautionary thing
25:06
is to create an rdsdb snapshot and so ultimately from within the environment
25:13
you can edit the environment and do a snapshot of that database so that Amazon RDS stores a snapshot for you in case
25:20
something goes really horribly wrong the next step is you want to enable
25:25
delete protection in the RDS console of that database now this is something
25:31
again that's just a precautionary measure primarily because when you set up the environment originally if you
25:37
didn't pay attention to the configuration items you may have left the deletion policies set to delete so
25:43
what we need to do is we need to enable delete protection against the database itself and you do this from the RDS
25:49
console next you create your brand new environment okay so if you're doing this
25:55
because you're shifting environments you've got a new application code that you've deployed and you want to share that database so you go ahead and create
26:02
your brand new environment with your instances you deploy your code your load balances Etc however in this environment
26:08
you do not provision a database as part of the environmental configuration steps that you take to deploy the environment
26:15
when you have deployed your new environment the green environment in this case what you want to do is you
26:20
want to make sure that your application is connecting to the database so you may
26:25
need to just test that out and ensure that all of that is working next you want to perform something called a blue
26:30
green deployment or a URL swap another word for it is a c name swap so when
26:37
you've deployed your application on elastic bean stock elastic Beanstalk provides you with a URL to connect to
26:44
your application and your users generally would Connect into the application through a hosted Zone that
26:50
elastic being manages for you and it publishes that URL that is then
26:55
accessible from the internet so your users are able to come in and access your application elastic Beanstalk offers you a service
27:01
called a cname URL swap because you're able to create multiple environments you can perform something called a URL swap
27:07
so that now that you have the new environment what we call the green environment you're able to just perform
27:13
something called a cname swap that will send traffic to this new environment it's a very simple process you do it in
27:19
the console or using the command line and the job is done it takes a matter of a few few minutes you do need to have a
27:26
bear in mind that obviously with DNS you need to give it some time to propagate across the internet
27:33
okay so once you've performed the blue green deployment and done the CNM URL
27:38
swap give it a bit of time and ensure that your users are now able to connect to the green environment hence the name
27:43
blue green deployment [Music] once you are satisfied that everyone is
27:48
now connecting to the green environment the next step is to update the deletion policy in the environment of dev1 so the
27:55
blue environment so that you select the retain option rather than the delete
28:02
option that is the default option when you're building out this environment
28:07
and this is imported you want to make sure that you do this setting first save
28:12
the settings so that it gets registered with elastic Beanstalk before you take the next step and then the next step is
28:18
to perform the actual decoupling exercise from the screenshot that I shown you earlier in this video
28:24
you perform the decoupling exercise that will decouple the database from the environment
28:30
and at that point you want to make sure that your new environment can still connect to the database run all your
28:36
tests and then finally you want to terminate the old environment so that you would take when you know if
28:42
you have started off with an environment that has the database tightly coupled and the deletion policy was set to
28:50
delete so all of the default configurations and you've decided that you want to decouple the database and build new environments so you want to
28:56
follow these steps very carefully now if you're taking the aw Solutions architect exam you probably want to
29:02
remember these steps as well because you might get a scenario type question there
29:08
okay so you obviously now have the steps to follow if you find yourself in a situation where you've built an
29:14
environment with your database tightly coupled and then you want to decouple it later on however in the real world when
29:19
you build design and deploy your applications on elastic Beanstalk it pays well to plan your environment build
29:26
out beforehand it is possible to connect your environment to an external RDS
29:31
database that's managed outside of those environments separately and often this
29:37
can be a good step to take because it takes away all of this heavy lifting that you might have to do later on so
29:43
next we taking a look at how to build a typical architecture design pattern to
29:49
support any future elastic Beanstalk deployments within a real life scenario we'll then move on into a lab
29:55
environment where I'll provide you with some sample application code a fully functioning application code that you
30:01
can actually use to build out a real world type environment in your own AWS account okay so let's do that next
AWS Elastic Beanstalk Application Architecture
30:09
Okay so we've covered a lot of theory and obviously now you're itching to try and really work with the elastic
30:14
Beanstalk service so that's exactly what we're going to do next I want to walk you through an architecture design diagram now this is by no means a
30:22
complete end-to-end solution it's a cut down version of what you will deploy in the real world but it will help you
30:28
understand the core components that actually go on to build a real life project there are several components to
30:35
help you deploy host and manage your application on the AWS platform and we're going to be looking at some of
30:41
these Services next elastic bean stock is a platform as a service solution that can help incorporate all of these
30:47
different services to provide the necessary infrastructure for your application so let's get started with the
30:53
architecture design plan unless you're going pure serverless you're going to need a VPC your VPC is the isolated
30:59
Network within which elastic Beanstalk will deploy your application you can set up the PC up prior to actually working
31:06
with elastic bead stock or whilst configuring elastic beam stock set one up on the Fly we'll be setting one up in
31:12
the lab from scratch and I'll show you how to set this up now our VPC is going
31:18
to follow some best practices so we are going to be using our VPC across two availability zones remember vpcs span
31:24
the entire region for the purpose of this lab we're going to make use of two availability zones for high availability
31:30
purposes we're then going to be deploying six subnets
31:35
two subnets are going to be reserved for public subnet Services okay that's where we're going to be hosting our load
31:42
balances and our NAD gateways and I'll come on to that in a second but we're going to be having two public subnets one in each availability Zone to offer
31:48
that redundancy that high availability element we're going to have two private subnets that are going to be used to
31:54
host the application itself again one in availability Zone Us East one a and the other one in Us East 1B and then we're
32:01
going to have another two private subnets that's going to be used for our database we're going to be using a mySQL database for this project so we're going
32:09
to work with the RDS service and deploy a mySQL database in rvpc
32:16
obviously with a VPC we're going to deploy an internet gateway because the VPC will need internet access and in
32:23
addition to that we're also going to be deploying a nut Gateway and not Gateway allows instances in the private subnet
32:28
to get access to the internet by way of a proxy by way of a relay service that
32:34
the NAT Gateway service provides okay and the reason why we're doing this is because our instances may need to access
32:40
the internet they may need to download software updates and all that stuff so in that Gateway is also going to be
32:46
deployed now bearing in mind all of this configuration is going to happen well before we actually work with elastic
32:51
beanstock and the primary reason for that is because we want to host our RDS database
32:57
outside of the elastic Beanstalk configuration and environment and as a result of that we have to set up the
33:03
necessary infrastructure to host that database first and so we are setting up the VPC another element of the VPC that
33:09
we need to configure are security groups security groups allow you to ensure that you only allow the type of traffic you
33:14
want to allow inbound to the resources that are available in your VPC so in the
33:20
case of the database we obviously want to allow inbound traffic to the database on Port 3306 which is the port number
33:27
for my SQL by default and we need to set that up and so we will be configuring a
33:34
security group for our database and it will need to be configured traffic on inbound Port 3306. now obviously when
33:39
you set up the security group for the database you need to define the source of that
33:45
traffic so we will be setting up an additional Security Group one that we will attach to our instances that
33:51
elastic Beanstalk deploys now bear in mind that elasticbeam stock will also deploy a security group for those very
33:58
same instances so that it can allow the instances to be able to accept traffic inbound from the load balancer that it
34:04
configures later on so your instances will actually have two security groups attached to them one will be the one
34:11
that we're configuring now which is the app SG Security Group and another one which will be configured
34:18
by elastic Beanstalk now the reason for doing this is because I want to restrict inbound traffic to our databases on Port
34:25
3306 but only from instances that are associated with this app SG Security
34:30
Group ensuring that it's only the instances that elastic Beanstalk deploys
34:35
that will be able to talk to my database okay so that's an additional security measure we're trying to preempt and
34:42
configure okay so we will be creating these two security groups manually as well
34:47
the next thing that we will be doing obviously is deploying our database so we'll be going into the RDS Management
34:52
console we will deploy a mySQL database now I have put in a second database here
34:58
in Us East 1B but I've grayed it out because when we come to do the lab we'll just be deploying the single instance in
35:04
a real world scenario you want to be deploying a multi-az configuration for the purposes of high
35:10
availability but as this is just a lab environment and I'm trying to keep the costs down and if you were to do this in
35:16
your own AWS accounts I want you to keep the cost down and so as a result of that we'll just deploy the single DB instance
35:23
okay so far we've got our base configuration set up in place now as a
35:29
Next Step we're also going to be using AWS Secrets manager now aw Secrets manager is a service that allows you to
35:35
host database credentials secrets so that you can dynamically retrieve
35:41
them into your application and your applications can make connections to the database remember your databases will
35:47
have some credentials in order to authenticate against it that information will be stored in Secrets manager
35:54
the application code that I'm supplying you for the purposes of this lab which is available to you in our GitHub
36:00
repository is configured and designed in such a way so that it can actually work with
36:06
Secrets manager and so what we'll need to do as a precursor is configure Secrets manager
36:12
so we'll go into the secrets manager console we'll set up the secrets for our database another feature of AWS Secrets
36:19
manager is the fact that you can enable something called DB rotation database rotation now what this does is it
36:25
actually changes and rotates the database credential information at
36:30
regular intervals you can set those intervals yourself it can be every four days four weeks four months whatever is
36:35
your corporate policy but this is an absolutely important security feature because what it means is that you can
36:41
have the database credentials automatically rotated by Secrets manager Secrets manager updates the secrets in
36:47
its database as well with what the new credentials are and that information is then available to your application to be
36:53
able to access the database this further enhances the security of your overall application in the AWS platform
37:02
another key component that we're going to be working with is IAM and we're going to be configuring an IM role for
37:09
the purposes of creating an ec2 instance profile which will allow your ec2 instances to
37:15
interact with services such as Secrets manager as well as work with elastic
37:21
Beanstalk Services okay so we will need to configure an IM rule with the appropriate permissions and I'll show
37:27
this in the lab so far we've built out all of this
37:33
infrastructure outside of the elastic Beanstalk configuration and remember the reason why we're doing this is because
37:39
we want to set up our database externally to the elastic Beanstalk environment next we're going to actually
37:45
work with elastic Beanstalk so here's our developer menu has got the application code that he
37:50
wants to deploy using elastic beadstock he's going to configure the elastic Beanstalk application as we've seen
37:56
previously upload the code to elastic Beanstalk which will involve elastic
38:01
Windows setting up an S3 bucket to manage that application version and bundle
38:07
and as part of the elastic Beanstalk configuration menu will instruct elastic Beanstalk to perform the following
38:13
configurations so one of those will be configuring an application load balancer menu will instruct elastic Beanstalk to
38:20
design the application environment for high availability and therefore this will entail configuring an application
38:27
load balances so elasticquin stock will then configure that application load balancer when it deploys the application
38:32
another component that menu will instruct elastic Beanstalk to take care of is the auto scaling group and also
38:40
environment properties now environment properties need to be manually updated with information to access the database
38:48
that is external to the elastic Beanstalk environment and also the name of Secrets manager the name of the
38:54
secret within Secrets manager to pull the secrets from so whereas we need to play elastic Beanstalk environments with
39:01
the database integrated within it the environment properties are set for you because we're trying to keep the RDS
39:07
database external to the elastic Beanstalk environment this is one thing that you will need to do that menu will need to do here will need to set up the
39:13
environmental properties to connect to the database so you'll need to provide the database endpoint name and also the
39:18
secret name within Secrets manager that is hosting the credential data once menu
39:24
has set up all of the necessary configuration and submitted the request elastic Beanstalk elasticity Beanstalk
39:29
will go ahead and provision the necessary security groups as I'm in mentioned earlier so elastic Beanstalk
39:34
will be setting up a security group for the load balancer to accept inbound traffic on Port 80 from the internet and
39:40
then also setting up another Security Group for the instances to accept inbound traffic on Port 80 from
39:47
the load balances Security Group so from the load balancer okay and because the
39:52
instances also are associated with app SG security group that we created manually the instances can now also talk
39:59
to the backend database in addition to that elastic Beanstalk will obviously consume the application code and deploy
40:07
the ec2 instances as per the configuration of the auto scaling policies
40:12
and deploy the application on those instances those instances will be able to consume
40:18
the data in environment properties so that is you know the name of the database the name of the secrets that
40:24
contains the credential data and ultimately the instances will then be
40:29
able to retrieve the data from Secrets manager the credential information and access the backend database at this
40:36
point elastic Beanstalk has deployed the application successfully and delivered a DNS name for the URL of the application
40:43
and then menu can distribute this URL to the end users to access the application
40:48
obviously you can go one step ahead you can associate a custom domain name within Route 53 and Associate it with
40:55
this elastic Beanstalk URL and that's it so enough of all of this Theory let's
41:01
jump into the AWS Management console to set this all up now I've actually broken the slab exercises into multiple steps
LAB - Step 1 - Create a VPC for Elastic Beanstalk
41:07
for you so that it's easy to follow so for step one let's go into the AWS Management console and create that VPC
41:15
okay so here we are in my AWS account and the first thing that we're going to work with is the VPC we're going to
41:21
build out a virtual private Cloud which is going to be our isolated Network that will host our application now this VPC
41:28
is going to comprise of six subnets across two availability zones an internet gateway and that Gateway and
41:35
the two security groups that we spoke about earlier so let's go ahead and create our VPC first
41:43
and I'm just going to go into the VPC Management console open that up in another tab
41:48
and we're going to go into your vpcs and in there we're going to click creative ABC now we're building a VPC from
41:54
scratch I want to walk you through all of the steps rather than use the wizard so that you see exactly what's happening
42:01
we're gonna give this VPC a name I'm going to call it the dev hyphen VPC
42:06
and the ipv4 side 4 block is going to be 10.0.0.016. now if you're interested in
42:13
learning more about vpcs in a bit more detail and best practices for how you define your ipv4 cider block ranges then
42:21
check out our course the AWS certified Solutions architect and the cloud practitioner on our website IIs
42:27
academy.com okay so next we're going to go ahead and click create VPC and this
42:32
creates the basic core VPC in your AWS account
42:38
okay so that's how VPC created the next step is let's give this VPC an internet gateway so we're going to go ahead and
42:44
click internet gateways click create a new internet gateway we'll give this one a name so I'm going to call this Dev igw
42:50
internet gateway for short and click create internet gateway now when you create the internet gateway it isn't
42:57
attached to any vpcs so you're going to have to attach it to the VPC you just created so click attach to a VPC
43:05
click of the Box select your VPC that you just created and click attach internet gateway
43:11
at this point your VPC has an internet gateway so we can move on to the next step so we're going to create six
43:18
subnets remember they're going to be two public subnets that's going to host our Edge services
43:23
like the load balancer and the net Gateway and four private subnets two for the application layer which will host
43:30
the instances that elastic Beanstalk will configure and two for our database that we'll create using RDS
43:37
so we're going to go into subnets and I'm going to click create subnet
43:42
make sure you select the right way PC that you're placing the subnets in and Define your subnets here okay so we're
43:49
going to start with our first Subnet this is going to be Dev hyphen public
43:54
subnet01 and we're going to place that in availability Zone 1A and the IP block
44:00
for that is going to be 10.0.1.0 24. so this block is a subset
44:06
of our vpc's block remember our VPC was 10.0.0.016 which comes with 65 000 odd
44:13
IP addresses this is just a subset of that block 10.0.1.0 24 giving you a total of 256
44:21
addresses but on AWS you have 251 available usable IP addresses
44:29
Okay click add a new subnet we'll give this one a name and this is going to be our
44:35
public subnet 2. I'm going to place this in availability Zone 1B
44:41
and the IP block for it is 10.0.2.0 24.
44:47
Okay add a new subnet this time we're going to do our private subnet so I'm
44:52
going to call this one the app subnet okay or one this is where we're gonna
44:57
host our instances and we're going to do it in such a way so that it's aligned with our public subnets so
45:05
whereas we have public subnet 01 in availability Zone 1A app subnet01 is
45:10
also going to be an availability Zone 1A whereas app subnet or two is going to be an availability Zone 1B so hopefully
45:16
you're beginning to see the pattern here so this is going to go in 1A the IP block for it I'm going to go and
45:23
put 10.0.10.0 24. you want to leave a gap
45:28
between your different subnet categories and the reason for that is if we ever
45:34
need to add additional subnets like additional public subnets or additional private subnets we want to make sure
45:39
that it's within its relevant ranges so what we can think of this is that we're putting all of our public subnets
45:45
between 10.08.1.0 and 10.0.9.0 and we're putting
45:50
our private subnets 10.0 10.0 to 10.019 so zero so if you ever need to
45:56
add additional subnets you can add them in there I'm going to add another subnet this is going to be the app subnet
46:05
or two and this is going to go in availability Zone 1B and I'm going to give the IP block
46:11
10.0.11.0 24 okay and then we need to set up our database subnets so we'll
46:19
create a subnet 5 Dev hyphen data subnet
46:24
hyphen 01 and this is also going to go on an availability Zone 1A
46:29
for this subnet I'll give it the IP address 10.0.20.0 24.
46:36
okay and then finally we'll have our database subnet02
46:44
in availability Zone 1B
46:49
with an IP block of 10.0.21.0 24. okay
46:54
and just check that it is all okay so that's
46:59
zero public something two apps update 1 up subnet 2 take the
47:05
subnet 1 data subnet 2 and create subnets and that will create all of your subnets for you
47:12
fantastic now that we've got all the subnets created the next thing we want to do is
47:17
we want to set up our route tables so the route tables will Define exactly how those subnets can send traffic to each
47:24
other and outside to endpoints such as the internet gateway so we're going to go ahead and take a look at our route
47:30
tables next so click on Route tables and when you create a VPC it creates What's
47:36
called the main route table for you now subnets when you create them they attach themselves to the main route table by
47:43
default the main route table is this one over here so this is their VPC I'm just
47:48
gonna edit that name and just say Dev main RT just so I know what it is and if I look
47:56
at the routes and look at the subnet Association you will see that all of the subnets are associated with this route
48:02
table the routes has just one internal route now when you're setting up a VPC you
48:09
want to make sure that your public subnets have their own route table with routes to the internet that is
48:14
explicitly for public services Okay so we've got our main route table already
48:20
so we're just going to create one more route table we're going to create the public route table that we're going to attach to our public subnets
48:25
so click create a route table and we'll call this one Dev hyphen public RT
48:33
select the right VPC and click create route table and that creates a route
48:39
table for us which is called the public route table now if you remember we've got our internet gateway so we're going
48:45
to set up a route for the public route table we're going to send traffic to the internet via this route table or using
48:52
the routes defined in this route table so click edit routes we'll click add a
48:58
route and we'll add a route to the Internet so the four zeros zero represents external networks or any
49:04
network outside of this range and the target for that is going to be our internet gateway I'm going to select
49:10
our internet gateway and we're going to save changes at this point this route table gives you direct access to the
49:16
internet via the internet gateway and so as an additional steps we can go into
49:23
subnet associations click edit subnet associations and
49:28
select the public subnets and click save Association so what's
49:33
happened is the public subnets as we called in public subnets are now truly public subnets because they're
49:39
associated with the public route table that has a direct access to the internet via the internet gateway so if I take
49:44
you back into subnets Association again you'll see that the two public subnets are explicitly associated with the
49:51
public route table the other four subnets that we have are associated with
49:56
the main route table okay so if we go back to round tables and click on the main route table now
50:04
the main route table has just a single route which is an internal route the instances that we
50:11
deploy in the app subnets are associated with the main route table now those instances will also need internet access
50:18
but we want to make sure that we keep them private and so rather than exposing them with a public IP address and
50:24
associating them with a public route table we're going to create something called an ad Gateway so I spoke about it
50:30
and that gave me a little bit earlier which is basically a method of granting access to instances that you deploy in a
50:36
private subnet by way of a proxy okay so the not Gateway acts as that proxy as
50:42
that relay machine to relay internet requests from those instances in the private subnet out to the internet and
50:49
then translate back responses to those instances when the replies come back
50:54
from the internet so the next thing we need to do is create an ad Gateway so I'm going to go click create in our
51:00
Gateway and we're going to give it a name so we're going to call this Dev Nat GW
51:06
and and you need to place the net Gateway in a public subnet and the reason for that is because in that
51:11
Gateway will need a Target to send those internet requests through and in this
51:17
case it will be sending it to the internet gateway and in order to send traffic to the internet gateway it
51:22
physically needs to sit in a public subnets because the public subnets are associated with the public route table that has that route defined to the
51:30
internet gateway okay so normally what you would do is when you have multiple
51:35
public subnets across multiple availability zones you will create multiple Nat gateways for redundancy and high availability but for the purposes
51:41
of this lab which is creating one Nat Gateway and I'm going to put this in public subnet one
51:48
okay so that's this one will be a Dev public subnet one and this will just ensure that we keep our costs down for
51:54
the purposes of the lab but in the real world you definitely want multiple net gateways across multiple public subnets
52:00
across multiple availability zones you also need to be aware of the fact that NAD gateways need to have an elastic IP
52:06
address associated with them now an elastic IP address is basically a public IP address that is static and doesn't
52:12
change so we're going to allocate an elastic IP address to our Nat Gateway and then go ahead and click create Nat
52:19
Gateway at this point your night Gateway is getting created it takes a few seconds and then it is all good to go but if I
52:27
click on that gateways over here again you will see that it's in the pending State and it will swiftly change into
52:33
being available okay so after a few seconds that changed to the available State and you can see it's been
52:38
allocated with a public IP address as well and so this is our Nat Gateway and
52:44
so to complete this process we now need to go back into our tables and click on
52:49
the main route table click on routes and we'll create a route to the Internet so the route to the internet is going to be
52:56
indirect not via the internet gateway but instead via the NAT Gateway okay so
53:02
that will help us select on that Gateway and we click save and so at this point any resources that you deploy in the
53:10
public subnets have a direct access to the internet via the internet gateway provided they've been allocated a public
53:15
IP address any resources such as ec2 instances you deploy in the private subnets
53:21
can also access the internet but via the NAT Gateway and continue to have just a
53:26
private IP address and that way you keep it secure and this is considered best practice you don't want to expose any of
53:32
your servers out on the public subnet unless you absolutely have to okay so now at this point we've set up our VPC
53:39
our internet gateway our NAD Gateway six subnets and configure the route tables the last thing to do in our VPC
53:46
Management console is to set up those security groups so let's do that now so we go down to security groups and we're
53:54
going to be creating two security groups you're going to create one for the database and one that we'll assign to
54:00
any instances that elastic Beanstalk Provisions in the elastic Beanstalk environment so Security Group one I'll
54:07
call this one Dev hyphen app SRV SG so basically it's the app server
54:14
Security Group okay and we'll give it the same for the description obviously we can give a much better description
54:20
than that and we need to make sure we place it in the right VPC so that's the dev APC because you're creating a
54:27
security group we want to create an inbound rule I'm just going to create an HTTP rule from any location okay so
54:34
we're accepting inbound traffic on Port 80. so the app service will be able to accept HTTP traffic
54:39
on Port 80. and that's from any location and we'll create a security group okay so that is
54:47
the app server security group created for you okay so there it is so I'm also
54:52
going to just put that copy that name and edit the name tags just so that it's
54:57
in there and it's easily visible so I know which security groups I'm working with create another Security Group this
55:03
is going to be Dev database hyphen SG so this is a database Security Group
55:09
okay and again make sure you put it in the right VPC now this time the inbound
55:15
rules are going to be the MySQL traffic so MySQL Aurora which defaults to Port
55:20
3306 we will be using the default Port range and the traffic for that is going to
55:27
come from any instance associated with the dev app server SG so that basically
55:32
means that unless you're a member of Dev server app SGA you cannot talk to my database which is an additional security
55:38
measure okay and then we'll create that security group as well and again just go back
55:45
into security groups and just make sure that you've got that name edited in the name column just so that
55:53
it's easily visible okay so that's our VPC we've got our vbc
55:58
our internet gateway our NAD Gateway we've got our six subnets we've got our security groups and we're pretty much
56:04
good to go to the next step two let's launch an RDS database in our VPC
LAB - Step 2 - Launch an external RDS database for Elastic Beanstalk
56:11
okay so back into my AWS Management console we're going to move into RDS so I'm just going to search for the RDS
56:16
service here and open that up in another tab that will bring up our RDS console now
56:25
when you're setting up an RDS database you're going to launch it in your VPC and if you remember we had set aside two
56:32
subnets okay data subnet one and data subnet2 which will be used to host our
56:38
database now prior to actually launching a database you need to create something called a subnet group a subnet group is
56:43
essentially telling RDS which subnets are going to be used to launch our database and you need a minimum of two
56:50
subnets ideally across two availability zones that you need to Define for your subnet group so that's what we're going
56:56
to do first so on the left hand side I'm going to click on subnet groups and then click create a DB subnet group and we're
57:02
going to give it a name so I'll call this Dev DB subnet group okay
57:09
and we can just use the same name for the description make sure you select the
57:14
right VPC so that's the devvpc and then the availability zones that we've defined in our VPC are for availability
57:21
zones 1A and 1B in the US East one region within those two availability zones we're going to be deploying our
57:28
database in the database subnet 1 and database subnet 2. now it's a little bit
57:33
difficult to see it here because it just shows it to you in the form of an IP address and the subnet IDs but if I
57:38
quickly go back to my VPC console and I click on subnets
57:44
then I know for a fact that database subnet 1 was 10.0.20.0 24 and database subnet 2 was
57:54
10.0.21.0 24. so those are the two subnets that I want to select so from this drop down list I'll select the
58:01
subnet 21 and 20 those two okay so those are going to be my database subnets and
58:07
I'll click create and that creates my DB subnet group within which I will launch my database fantastic
58:14
right now that we've got the sub Nets click on databases okay and we'll
58:19
create a new database and we're going to set up a standard create database you want to select MySQL for this exercise
58:28
we'll leave all of the defaults in terms of the addition and the engine version and select free tier because we want to
58:36
make sure that you don't get charged that will turn off some options unfortunately but that's fine we're not
58:41
going to use it for the lab anyway specifically around things like multi-az now we have to give our database
58:46
instance a name so I'll call this one devdb okay and for the credentials I'm
58:54
going to leave the master username to admin okay and I'm going to give it a password
59:01
and I'm choosing a very simple password better in the real world you want to choose a really complex one okay and
59:08
we're not going into managing Master credentials in Secrets manager because I want to do Secrets manager if it's separate as a separate exercise because
59:14
I want to show you how it all works so for now just set a master username and a password of your choice make sure you
59:20
remember the password otherwise you will not be able to access the database so make a note of it somewhere safe
59:27
we'll scroll down and we'll select the default option of dbt3 micro instance
59:32
type for our database foreign it's going to use a general purpose SSD
59:38
with an allocated storage space of 20 gigs and I'm going to disable the enabled storage Auto scaling because we
59:43
don't need it for the purposes of this exercise so I'll just deselect that in terms of connectivity so this is
59:50
where you need to make sure that you select the right VPC so that is the dev
59:55
VPC and leave the setting to dome connect to an ec2 compute resource because we will be getting elastic bean
1:00:01
stock to provision the instances to talk to our database because I've selected the right VPC it's
1:00:08
picked up the fact that I've got a single subnet group in there the database subnet group so it selected that for me already
1:00:16
ensure that it's set to no under Public Access because this database is sitting in the back end right in the private
1:00:22
subnet so it doesn't need Public Access no public IPS and then you need to select the security prayer database now
1:00:28
we've already created a database Security Group when we did the VPC section of this exercise so untick
1:00:37
default and from the drop down list select database SG
1:00:42
okay availability Zone we'll select 1A is our
1:00:48
preference where we want to place our database expand additional configuration just make sure that the default Port is set
1:00:54
to 3306 which is exactly what we want a little bit further we'll leave the
1:01:00
database authentication to password authentication and then you want to expand additional configuration now here
1:01:06
you need to provide a database name so I'll use the same name devdb
1:01:12
we'll set the backups to enabled we'll set the retention period to one day okay
1:01:19
and we can leave the encryption enabled as well so with encryption it's going to use the
1:01:25
default KMS key for RDS and if you're interested in learning more about encryption and kms's check out our
1:01:33
website for some more videos on that I'll leave everything
1:01:38
else at its default settings okay and I'll scroll all the way down and
1:01:44
click create a database now this takes a good five to ten minutes to create so
1:01:50
you probably want to go ahead and grab yourself a cup of coffee tea or whatever I'm going to pause the video over here and then when it's all done I'll resume
1:01:56
the video so here we are our database has been launched and configured and is in the available state if we actually
1:02:03
take a quick look at the database so you've got your connectivity and security details here so that is your
1:02:09
endpoint okay so that is what your application needs to connect to in addition to that the application will
1:02:15
need to know the database name which is dvdb and obviously the username and password and these pieces of information
1:02:21
especially the username and password we're going to configure in Secrets manager so now that we've set up the
1:02:27
database okay the next step is to move on and work with Secrets manager and configure Secrets manager to store the
1:02:33
credentials of this database let's move on to step three next okay let's move on to step three where
LAB - Step 3 - Configure Secrets Manager for your RDS database
1:02:40
we're going to go into Secrets manager and configure a secret for our database
1:02:45
okay here we are back in my AWS Management console so I'm just going to go into Secrets manager
1:02:51
open that up in another tab okay so in Secrets manager we're going
1:02:56
to go ahead and store a secret Now secrets manager will allow you to store credential data for your RDS database
1:03:03
the service also provides the ability to rotate your credentials for databases like RDS but we'll do that a little bit
1:03:10
later initially what we want to do is Click store a new secret and you want to select the secret type as being
1:03:16
credentials for an RDS database next you're going to put the username and the password for your database so hopefully
1:03:22
you made a note of it okay we don't need to make any other
1:03:28
changes other than select the database that we are going to provide the secrets for click next and then you need to
1:03:35
provide a secret name you can use the strategy of using slashes to have different names for different
1:03:41
environments and different versions of your application okay so I'm just going to select Dev MySQL
1:03:49
credits okay and then you can have a description as well in there for What
1:03:55
that particular secret is used for leave everything else again as it is and click next this is the page where you
1:04:01
configure automatic rotation now we're going to skip this for now okay because I just want to revisit this a little bit
1:04:07
later click next and then once you're happy with all of this click store okay
1:04:13
so this now configures your secret so if I just quickly refresh this page there's my secret currently rotation is disabled
1:04:21
like I said we will revisit that but all of my secret information so my credential information for my database
1:04:26
is actually stored in secret so if I click retrieve secret value
1:04:33
okay you will actually see all of the data related to my database come out including the username and password that
1:04:39
I specified Okay so book manager created for us next we're
1:04:46
going to move on to step four now step four is we need to set up some permissions and an IM role in order to
1:04:52
allow ec2 to access Secrets manager as well as obviously interact with the elastic Beanstalk service okay so let's
1:04:59
do that next okay so for step four we're going to create an I am role with necessary
LAB - Step 4 - Configure IAM roles for Elastic Beanstalk
1:05:05
permissions now the purpose of creating an IM role is to create an instance profile an instance profile is something
1:05:11
that you attach to an ec2 instance when it needs to have certain permissions assigned to it so that it can go and do
1:05:19
something it can interact with other services on the AWS platform an instance profile is essentially a container for
1:05:26
the IM rule that has the required permissions so this instance profile that we're going to create will need to have an IM
1:05:32
role that we need to Define that allows our ec2 instances to interact with elastic Beanstalk environment now the
1:05:39
role is going to Grant the ec2 instances to perform specific actions so for example retrieving application versions
1:05:46
from your S3 bucket writing logs to the S3 service if you're using ECS and Docker environments as we
1:05:54
previously discussed then obviously coordinating the deployment of ECS container services and if you are
1:06:01
building a worker environment then you know performing actions like being able to read from the sqsq for example is
1:06:07
another permission that the ec2 instance is required so we're going to move on and create our IM role in this step
1:06:15
let's get back into the database Management console okay so back to my AWS Management console we're going to go
1:06:20
ahead and go into the IEM dashboard so I'm just going to open IAM in another
1:06:26
tab and then I am we're going to create this IEM role that's going to be consumed by
1:06:32
an instance profile that will be attached to your ec2 instances that elastic Beanstalk deploys the ec2
1:06:39
instances with this instance profile will have the permissions to interact with elastic Beanstalk and we also need
1:06:46
to Grant the ec2 instances permissions to interact with Secrets manager remember Secrets manager has a secret
1:06:51
that we configured that has the credentials of our database in order for your ec2 instances to talk
1:06:58
to Secrets manager and pull that secret okay it needs permissions to do so so
1:07:04
let's do that next from the left hand side go ahead and click roles and then
1:07:09
click create a role and it's an AWS service role entity type and The Trusted
1:07:15
entity is going to be ec2 in this permissions policy filter AWS
1:07:22
elastic and what that will do is that will give you a series of manage policies that AWS
1:07:29
has created already for you that you can use now the three policies that you need to use are AWS elasticbean stock web
1:07:36
tier AWS elastic Beanstalk worker tier and AWS elastic bean stock multi
1:07:42
container Docker okay we're just adding some additional policies but essentially these permissions allow you to do things
1:07:48
like upload log files to S3 interact with sqs if we did create a worker tier
1:07:54
and all that stuff so I'm just creating a role that has all the necessary policies
1:08:00
let's give the roller name so I'm going to call this one Dev EB ec2
1:08:06
I am roll okay so I know exactly what it is and then we'll click create a role so at
1:08:13
the moment what we've done is we've created the role with those three policies but we still need two if we go
1:08:19
to Dev EB ec2im role add an inline policy so that the role can also talk to
1:08:25
Secrets manager so click add permissions click create an inline policy
1:08:30
click on the Json Tab and I've actually got a policy that I have created for you
1:08:36
and here's the policy it's available to you in our GitHub repository as a sample policy and you're welcome to use this
1:08:42
policy along with the application code when you deploy the application in your AWS account
1:08:48
so just to show you what the policy does the effect is allow so it's an allow policy and the action is the ability to
1:08:54
get secret value from Secrets manager and in order for the policy to work you need to provide the secret manager Arn
1:09:00
the AR end of the secret that you created so let's grab that policy first
1:09:06
and we'll replace this with our policy and then go back to Secrets manager and
1:09:13
just grab the Arn of the secret you created which is that one over there in my case and replace the placeholder value with
1:09:22
the actual Arn okay and then click next you need to
1:09:27
give the policy a name so this is Dev EB ec2 secrets
1:09:35
policy so I know exactly what it is and click create policy right there's our IM
1:09:41
rule it's got the three elastic Beanstalk managed policies that AWS manages and it's got one inline policy
1:09:47
that I have put in there that I manage that has access to Secrets manager of
1:09:54
that specific secret Arn fantastic let's move on to step five
LAB - Step 5 - Create an Elastic Beanstalk Application
1:10:01
right you've done all of the prerequisites you've built a VPC you've deployed an RDS database in that VPC
1:10:08
you've configured Secrets manager and you've set up the necessary IM rules with all the permissions that you
1:10:14
possibly need next we're going to move on and actually work with elastic Beanstalk and deploy
1:10:19
the application into elastic Beanstalk before you do that though you need to download the application source code
1:10:24
bundle from our GitHub repository so let me show you where that is first and then we'll jump back into the AWS Management
1:10:29
console and deploy this application okay so you have access to the
1:10:35
application source code bundle that we're using for this project it's available in our GitHub repository the link of which is available to you in the
1:10:42
resources section of this video or down in the description box below you'll need to download the EBS RDS to do app code
1:10:48
version 2's zip file and place it on your desktop or in a location that's easily accessible you will actually be
1:10:55
uploading the ZIP code bundle as it is as a zip file to the elastic Beanstalk
1:11:01
application when you configure elastic Beanstalk but I wanted to extract the contents of the zip file and just show
1:11:06
you what it contains so let me do that first okay so here we are the contents of my application source code bundle
1:11:13
it's got a few files and a few folders and specifically it's also got the vendors folder which has a lot of the
1:11:18
sdks that AWS supplies for its various services so the application makes use of
1:11:24
those in order to connect to the Amazon web services platform and make use of
1:11:29
certain Services now specifically there is an index a PHP file and a server.php
1:11:35
file all of the front end look and feel is all set up in the
1:11:40
index.php file the server.php file is what connects to the backend database and performs all of the back end magic
1:11:47
let me open that up for you in Visual Studio code okay and there we are so this is my
1:11:54
visual studio code with the server.php file and it's open State and I just wanted to quickly show you a couple of
1:12:00
things over here firstly this includes the AWS PHP SDK so it allows you to
1:12:06
interact with the platform as this application is built using PHP what it does is it inputs the secret manager
1:12:12
client and the AWS exception clients as part of the code and then it also
1:12:18
specifies the region that it's working in okay and furthermore it actually is able
1:12:25
to retrieve the secret value from Secret manager okay and it stores that as an
1:12:31
environmental variable now the important thing is that the secrets particularly the username and password are encoded in
1:12:36
plain Json string and there's a Json date code function here that basically retrieves that usernames and password
1:12:42
and once it retrieves that username and password dynamically it is allocated to two variables which are DB username and
1:12:48
DB password DB server and DB database are additional names that we'll add in
1:12:54
the elastic Beanstalk environment properties from which it will retrieve those values but the username and
1:12:59
password will be dynamically retrieved from the secrets manager client okay so
1:13:05
that's why this becomes very very secure as it's dynamically retrieving the credential information and subsequently
1:13:12
we will be able to also rotate those secrets and continue to still access the database because we will dynamically
1:13:19
retrieve the credential data the ec2 instances on which this particular piece
1:13:25
of application code runs on has the instance profile and therefore the IAM role to be granted access to Secrets
1:13:31
manager and that's where the power of IAM roles and IM profiles come into play okay enough about all the code and stuff
1:13:38
let's actually jump back into the AWS Management console and set up our elastic Beanstalk application okay so
1:13:44
back into my AWS Management console we're going to go into the elastic Beanstalk dashboard so in the search bar
1:13:49
just search for elastic Beanstalk and open that up in another tab
1:13:57
so the first thing that we're going to do is create the elastic Beanstalk application remember that the application is simply the container that
1:14:04
will host your environments within which we will deploy the application and I'm going to give the application a name so
1:14:10
this is a Dev to do application so the application that you'll be
1:14:15
deploying is actually a to-do list application that allows you to create
1:14:21
your to-do list and it saves that data in a back-end RDS database and performs all the crud operations against the
1:14:27
database so let's take a look at what that application looks like so we'll go ahead and create the application
1:14:35
and once you've created the application we then need to create an environment
1:14:41
within which to deploy the actual application code into so when you click configure environment you need to select
1:14:48
whether you're setting up a web server environment or a work environment so we'll be creating a web server
1:14:53
environment which incidentally has both the front-end back-end elements in it in a real world scenario depending on how
1:14:59
complex your application is you want to properly split the two as we have discussed in our previous
1:15:05
slides but for now let's just create the web server environment so the web server
1:15:10
environment has been built for our dev2do application and you can choose your own domain name
1:15:16
I'm going to leave that as default as well you'll just need to type in a preferred name and then check that it's
1:15:22
available when it comes to the platform ensure that you select PHP because the
1:15:27
application is built using PHP the platform branch is going to run on a 64-bit Amazon Linux 2 and the version is
1:15:34
3.5.9 next you want to upload the code so this is going to be the zip file bundle
1:15:43
so you want to click local file and select the location where you have your
1:15:48
application source code bundle downloaded so in my case it's over here so remember
1:15:54
you want to upload the zip file itself okay and click open next you want to click on high
1:16:00
availability because we want elastic beam stock to provision load balances and auto scaling for us for high
1:16:06
availability and then to scale out as well as scale in Click next oh need to
1:16:12
give it a version name I'm going to call this one V1 and then click next
1:16:17
okay so the next step is to create service access now this is
1:16:23
where creating necessary I am role comes into play now what you need to be aware of are there are two roles basically
1:16:30
used by elastic Beanstalk there's a service rule that allows elastic Beanstalk to assume the service role and
1:16:36
to perform various elastic Beanstalk actions against the environment that is
1:16:41
being built now you could get a service role created for you I've got one
1:16:46
previously created so I'm just selecting the same one just to show you what permissions this service will contain
1:16:52
let's go back into IM roles and this one over here AWS elastic Beanstalk service
1:16:57
rule essentially it contains two managed policies that allows for health monitoring and managing updates on the
1:17:04
elastic Beanstalk environment okay so that needs to be selected or you create one from scratch so you
1:17:11
allow elastic Beanstalk to create it for you next you have the ec2 keypad now this is only needed if you're logging
1:17:17
onto your ec2 instances however I strongly recommend that you know instead of using easy to key pair to use SSH to
1:17:24
log into your instances you use AWS session manager if you want to know a bit more about session manager check out our other video in this course that
1:17:32
talks a little bit more about how it works and then finally you want to select the
1:17:37
instance profile now this is the IEM role we created a few moments ago that has necessary permissions to allow our
1:17:43
instances to talk to elasticbeam stock S3 sqsq depending on which environment you're placing it in
1:17:50
as well as the inline policy to allow the ec2 instances to retrieve the credentials from Secrets manager okay so
1:17:57
you select the instance profile there and click next networking database and tags option for
1:18:04
the VPC select the VPC where we're going to deploy our elastic Beanstalk instances in and that's the dev VPC that
1:18:10
we built right at the start of this lab then you need to specify where those instances need to be deployed now
1:18:17
remember in our architecture diagram we created the app subnets okay which was a private subnet that we want to use for
1:18:22
all of our instance deployment so that was app subnet02 and app subnet01 okay
1:18:29
so these two subnets are going to be used to deploy our instances this option allows you to configure
1:18:36
database integrated with your environment and we said that whilst this allowed you to quickly and easily set up
1:18:41
databases in real world production environments you probably want to have your database externally hosted from the
1:18:47
environment so we're not going to enable database here in any case we already have our RDS database already configured
1:18:54
scroll all the way down and click next okay now with regards to configuring the
1:18:59
instance traffic and scaling okay leave the root volume at its default settings
1:19:05
for the ec2 security group make sure you select the dev app server SG Security Group remember the purpose of creating
1:19:11
the security group was so that we can define a source for our database Security Group okay so our database that
1:19:18
we launched in the RDS section of this lab has this bit particular Security
1:19:23
Group attached to it the dev database SG and it allows inbound traffic on Port 3306 to mySQL port
1:19:29
only from instances associated with the app server SG so we want to make sure that when elastic Beanstalk launches
1:19:36
your instances it attaches the security group to it okay so all of our instances must be
1:19:43
attached to this Security Group from a capacity point of view it's going to be load balance and I'm just going to
1:19:48
put two over there okay scroll down a little bit further and we want to just go with the T3 micro
1:19:55
types I'm just going to remove T3 small we don't want it to be charged we're going to use free tier
1:20:01
that's the Ami ID that elastic Beanstalk is going to use we're going to leave all
1:20:06
of these other values as it is and move on to load balancer network settings now for the load balancer
1:20:12
you want to place a load balance in the public subnet okay the nodes need to be deployed in the public subnets and
1:20:19
specifically that's going to be public subnet01 and public subnet02 okay because the load
1:20:26
balancer sits right at the edge receiving traffic from the internet and Wheeling that traffic back into
1:20:31
instances in the private subnet and the type of load balancer is going to be an application load balancer because we're
1:20:36
routing HTTP traffic in this case and then you want to pretty much leave everything else on this page at its
1:20:43
default value and click next okay when it comes to configuring updates monitoring and logging for the
1:20:49
help reporting ensure that it's set to enhanced you could set up email notifications if
1:20:54
you wanted to be notified of important events in your environment and then there's also the rolling
1:21:00
updates and deployments for when you make upgrades to your application now we have another video that talks about this
1:21:06
in a bit more detail as an advanced topic feel free to check that out as well but for now just leave everything at its
1:21:13
default value scroll down until you get to environment properties now this is the important
1:21:19
part for the environment properties you're going to set up three environmental variables so the first one
1:21:24
is going to be the DB underscore endpoint okay so this is the actual DB
1:21:31
server endpoint and if you go back to your RDS Management console and go into your database
1:21:38
and click on your database that's this one over here so you've got the endpoint value there you just want to grab that
1:21:46
and place that in there next you're going to add the DB name so DB
1:21:51
underscore name and this is going to be devdb
1:21:56
okay and then finally you want to type in the secret name okay now the secret name is the name of
1:22:04
the secret that hosts my credentials so if I go back to Secrets manager that's this one over here so that's my secret
1:22:10
name and we're going to place that value in there and our ec2 instances are going to
1:22:17
connect to Secrets manager look for this name and pull the username and password for the database dynamically okay then
1:22:22
we click next this is your page to review all of your settings make sure it's all in order and
1:22:30
finally click submit and so now what we're doing is we're submitting the job to elastic Beanstalk to go and do all of
1:22:37
its magic and in the back end it's going to use cloud formation to build everything for us as per our
1:22:42
configuration requirements okay so it says elastic Beanstalk is launching environment this will take a few minutes
1:22:48
and it does take a few minutes so why don't you go ahead and grab yourself another cup of tea or coffee I'll pause
1:22:54
the video for now and once this is all set up we'll continue from where we left off right welcome back
1:23:01
free launched so elastic Beanstalk went ahead and did all this wonderful magic in the back end to set up our
1:23:08
environment and to deploy our application onto the AWS platform
1:23:14
now elastic Beanstalk gives you a domain name to connect to so if I open this up
1:23:19
in another browser tab you will see that the application has
1:23:25
now come up so this is a to-do list application okay it gives you the date
1:23:30
and the time and it gives you this little form that you can fill up so let's give it a try so let's say I have
1:23:37
a work to do list okay complete video on elastic Beanstalk
1:23:46
okay and the due date is oh it has a nice calendar format let's put in that
1:23:51
date and the status is in progress so I'm going to click submit and it says to do add it successfully
1:23:58
well nice to know and if I scroll a little bit further down you will see that my
1:24:04
table is updated okay fantastic Let's uh let's add another one another work one
1:24:10
okay um prepare elastic being stock
1:24:18
deployment presentation this is going to be the next topic that I'm going to work on
1:24:23
and the due date is oh let me give myself some time to work on this
1:24:29
and it's not started let's submit that one and there you go so you can see what's
1:24:37
happening this application interfaces with the backend database the RDS database it stores all of this data in the RDS
1:24:44
database okay and it also retrieves the data from the RDS database so it's a PHP
1:24:51
application it does this bit of magic and performs all the crud operations for the database I can change the status so
1:24:58
let's say I've already started working on something over here maybe started and
1:25:04
that will change the status and that's all done so once I've completed this
1:25:09
video I'll click completed and it will change the status and oh it gives me a nice green block as well so my intention
1:25:17
is to get everything green for you guys so that I can prepare more videos like this one well I hope you enjoyed the
1:25:23
application as I said it's just a simple application just a one pager but it demonstrates the fact that this
1:25:30
is a multi-tier application there's a front and backing element to it there's a database element to it and you can use
1:25:35
elastic Beanstalk to provision the underlining infrastructure deploy the application and manage its life cycle I
1:25:41
wanted to also give you a quick run through about some of the things that elastic Beanstalk has done so if I go into the VPC section you'll see on the
1:25:47
security groups elastic Beanstalk went ahead and created two more security groups this one over here for example
1:25:53
is the load balancer security group so that it is configured the inbound rules to allow traffic on Port 80 from the
1:26:00
internet and this next one is a VPC security group that in fact
1:26:08
has the source as the load balancer Security Group so now if I go into ec2 in another tab very quickly
1:26:17
okay let's go into ec2 you'll see that one instance is running that's my instance that was deployed by elastic
1:26:22
Beanstalk okay there it is and that particular instance if I click
1:26:28
on security is attached to two security groups one is the dev app server Security Group which we created and one
1:26:34
is the one that elastic Beanstalk created so in effect this instance has two security groups once you accept
1:26:39
traffic from the internet via the load balancer and one to act as a source for traffic that's going to hit the database
1:26:46
in the back end okay okay so that's how the security groups work in this architecture
1:26:52
so elastic bean stock has also provisioned our load balancer so if I go on the left hand side and click on load
1:26:58
balances okay and you can see this is a load balancer that elastic Beanstalk deployed
1:27:03
for me and elasticbeat stock manages this load balancer go down to Auto scaling groups
1:27:08
and you can see that elastic beanstalker also provisioned the auto scaling grip and its activities are available to me
1:27:16
as well okay so elastic Beanstalk did all of this heavy lifting that I would have had to do manually if I wasn't
1:27:23
using elastic Beanstalk okay so now that all of that is in place just go back to the application our
1:27:28
application is fully functional it's performing all its crud operations and it's connecting to the database
1:27:34
there's one more step left let's go on to step six six I wanted to go back and revisit
LAB - Step 6 - Enable RDS credential rotation in Secrets Manager to enhance Elastic Beanstalk application security.
1:27:41
Secrets manager I wanted to update the secret that we had created earlier in Secrets manager to enable rotation of
1:27:48
the database credentials and as long as your application code has been designed in such a way so that it can use the
1:27:54
sdks and interact with the AWS Services it can dynamically retrieve updated credentials from Secrets manager and
1:28:02
access the database and the back end so let's get back into the AWS Management console and edit the secret that we
1:28:09
created earlier okay so here we are back into our AWS Management console let's just go into our secrets manager and go
1:28:16
into our secret and all I want to do is go down to edit rotation and enable
1:28:21
automatic rotation and I'm going to make a change to the rotation schedule and set that to days and set it to every
1:28:27
seven days okay and we're gonna go ahead and basically
1:28:33
enable Secrets manager to create a rotation function okay and we can add a
1:28:39
particular value here so it will have the prefix of Secrets manager and I'll do something like MySQL
1:28:47
Dev rotation okay and then we'll click save now what
1:28:56
this is doing is it's actually enabling the feature for rotating my database credential now
1:29:02
you may have noticed that very briefly the rotation status went to enabled and then it's gone back to disabled and that
1:29:08
is because cloud formation in the backend is performing all the magic it's actually setting up a stack in order to enable
1:29:15
this feature and if we quickly went into cloud formation and if I open that up in a different tab
1:29:22
you will see that Secrets manager RDS MySQL rotation
1:29:28
is in a create in progress state so we're just going to have to wait for this to run through and then once it's
1:29:35
complete we should find that rotation configuration has been enabled I'm going
1:29:40
to pause the video over here and then we'll come back as soon as the cloud formation templates have been deployed
1:29:45
and the stack is ready okay so here we are back at my cloud
1:29:50
formation console and you can see that the stacks have been deployed this status is set to create complete okay so
1:29:57
we're good now what this basically means is that if I take you back into Secrets manager you will see that the rotation
1:30:03
status is set to enabled it's going to happen every seven days and that's the
1:30:08
next rotation date now what actually happens in the background is that cloud formation creates a Lambda function and
1:30:15
the Lambda function integrates with a database and is able to change the
1:30:20
credentials in this case every seven days on our data now let's just take a quick look at the Lambda function itself
1:30:26
I just want to show you what's happening so if we go into Lambda
1:30:31
and take a look at our Lambda function so this is the function that cloud formation created okay it rotates the
1:30:38
secrets manager secret with the MySQL credentials at the specified schedule
1:30:44
that we defined when we enabled rotation okay and you can see the function Arn if
1:30:50
you scroll down a little bit and go into configuration and VPC there's something
1:30:56
I want to point out over here your Lambda function needs permissions
1:31:01
to talk to the database and when AWS cloud formation creates this Lambda function it Associates it with the same
1:31:09
security group that the database is associated with in this case Dev database is cheap so cloud formation
1:31:16
configured all of this up for us so our Lambda function is now associated with the security group Dev database SJ
1:31:23
as a means of now being able to communicate with our database however there's a slight problem here if we go
1:31:31
to this Security Group so if I go back into VPC okay here's my VPC these are my security groups if I go to Dev database
1:31:38
SG and go into inbound rules the only entities that can communicate with our
1:31:45
database okay is in fact any instance Associated or any resource
1:31:52
for that matter associated with a Dev app server SG okay and this is important although your Lambda function is
1:32:00
associated with the dev database SG which is the same security group that the database is associated with you will
1:32:07
see that the dev database SG is the security group associated with the database the problem is that the only
1:32:14
resources that can communicate or send traffic to the database on Port 3306 are
1:32:20
any resources associated with the dev app SG and so what this means and hopefully
1:32:26
you've got this already that the Lambda function will perform the necessary action that it needs to
1:32:32
perform but it will fail okay it will not be able to change the database because technically it's not able to
1:32:39
send traffic to the dev database SG so what we're going to do is we're actually going to create a new security group and
1:32:44
attach it to the Lambda function and use that to Grant the Lambda function the
1:32:50
ability to access the RDS database so create a new Security Group let's call this one Dev
1:32:56
Lambda SJ okay I'm just going to give it the same for the description make sure
1:33:02
you put it in the right VPC and click create Security Group
1:33:07
okay now so that's the security group created we then need to go back to our security group lists go to the dev
1:33:14
database SG edit inbound rules there and add the same MySQL traffic
1:33:24
from the Lambda SG okay so that's this one over here okay so we're allowing
1:33:30
inbound traffic from any resource that is attached to the Lambda Security Group
1:33:35
on Port 3306 so we'll save that okay and also just once we're here let's just put
1:33:41
copy this name and put it under the name column just so that we can easily recognize all of our security groups so
1:33:47
that's that's good and then go back into your Lambda function okay and in your
1:33:53
Lambda function you want to go back to configuration back to VPC and then edit
1:33:59
the security group configuration So currently the security group is set to Dev database we want to get rid of that
1:34:04
and you want to select the Lambda SG Security Group and then click save and
1:34:12
at this point in time the Lambda function is going to be updated so that it can consume and use the dev Lambda
1:34:18
Security Group in order to make its connection to the database that we have in the back end now this takes a few
1:34:25
moments to complete so I'm going to pause the video over here again and then come back as soon as it's done okay so as you can see the configuration has now
1:34:31
successfully updated the Lambda function and so the Lambda function is now using the dev Lambda SG group in order to
1:34:38
granted the necessary ability to talk to the backend database so if we go back to
1:34:43
our secrets manager what we should be able to do is Click rotate secret immediately
1:34:49
and not wait for the seven days and I'm just going to click rotate and then if we go and click on retrieve secret value
1:34:56
you will see in fact that the secret has now changed so this is not the password I'd use when I set up the database what
1:35:02
this means is that secret manager has made use of the Lambda function the Lambda function has updated the database
1:35:07
password and now our application should be able to pull this new password using the environment properties that was
1:35:14
configured in elastic Beanstalk to say where to retrieve the secret from IE
1:35:20
from this secret name here okay so now if I go back to my application and just do a quick refresh
1:35:28
okay so that's refreshing my page okay so if we scroll down we can see that we can still read from the database let's
1:35:33
see if we can add stuff to the database I'm going to click on another work task and I'm going to say create slides for
1:35:43
machine learning okay and the due date for that is I'm going to set a due date to 30th of July
1:35:51
and I'm going to say not started and click submit and it says to do added
1:35:56
successfully and if we scroll all the way down and yes indeed it has so in fact the new credentials are being used
1:36:03
the application is dynamically pulled those credentials and it's still able to communicate with our database fantastic
1:36:08
our multi-tier application has been successfully deployed it is using
1:36:14
best practice methodology is about where the application is based the database placement within the VPC it's also using
1:36:20
Secrets manager to interact with the database and it's in a highly secure VPC configured with necessary security
1:36:27
groups and permissions it also uses IEM roles that grants it the necessary permissions
1:36:33
to interact with the other services on AWS and so hopefully this has been a really useful Hands-On demonstration of
1:36:40
how to deploy an application on the elasticbean stock service the application source code as I mentioned to you earlier is available to you
1:36:47
absolutely free of cost and so you're welcome to try this out in your own environment follow the step-by-step
1:36:52
guide in this video and gain that much needed hands-on experience of actually working with elastic Beanstalk because
1:36:58
that's how you will develop your skills on the AWS platform now if you enjoyed this video and you found it useful
1:37:04
please hit the thumbs up and please subscribe to this channel so that I can notify you as and when I release new AWS
1:37:10
projects and you can continue to develop your skills on the AWS platform thank you
..etc