‫So here is a set of theory slides
‫around how to perform an Elastic Beanstalk Migration
‫because that can come up in the exam.
‫So the first one is a Load Balancer,
‫So after you create a Beanstalk environment
‫you cannot change the Elastic Load Balancer type,
‫only its configuration.
‫So we've seen this before
‫If you create a Classic Load Balancer
‫you can only edit the classical bouncer setting,
‫you cannot upgrade it to an Application Load Balancer.
‫So if you want it to somehow upgraded
‫from a Classic Load Balancer to an Application Load Balancer
‫or from an Application Load Balancer
‫to a Network Load Balancer.
‫You will need to perform a migration
‫and the steps are as such.
‫First you would create a new environment
‫with the same configuration except the Load Balancer.
‫And so we can't use the clone feature
‫we just saw in the past lecture
‫because the clone feature would copy
‫the exact same Load Balancer type and configuration.
‫So you have to recreate manually the same configuration
‫and then the old environment
‫will be copied
‫not cloned into a new environment
‫and this one in this new environment,
‫I will have my Application Load Balancer,
‫then we will deploy our application
‫onto the new environment.
‫And then we need to shift the traffic
‫from the old environment to the new environment.
‫So for this, we can do a CNAME swap or we can use Route 53
‫to do a DNS update either work,
‫hopefully that makes sense.
‫Next, we'll talk about RDS Elastic Beanstalk.
‫So RDS can be provisioned with your Beanstalk application,
‫which is great if you want to do development and test.
‫So this looks like this in your Beanstalk
‫you have your own RDS Database.
‫But if you are doing a production deployment,
‫this is not great because the database lifecycle
‫is going to be tied to the Beanstalk environment lifecycle.
‫So the best way to do it in prod is to separate
‫the RDS Database from your Beanstalk environment
‫and reference it using a connection string
‫for example using an environment variable.
‫So how would we do this?
‫How would we Decouple RDS if it's already
‫in our Beannstock stack?
‫Well, the first one we do is that we would create a snapshot
‫of our RDS Database as a safeguard in case things go wrong,
‫so we have a backup or data and we know we're good.
‫The next thing is to go to the RDS console
‫and protect the RDS Database from deletion.
‫This will prevent it from being deleted no matter what
‫then we create a new Elastic Beanstalk environment,
‫this time without RDS.
‫And we point our application
‫to the already existing RDS Database,
‫for example, using an environment variable.
‫So now we have the new environment pointing
‫to the same database.
‫Then we perform a CNAME swap,
‫so a blue/green deployment or route 53 DNS updates
‫and we confirm it's working.
‫So now we have shifted all the traffic
‫from the old version to the new version
‫then we terminate the old environment.
‫And because we have enabled RDS deletion protection
‫then
‫RDS will stay.
‫And then because it's the CloudFormation stack,
‫behind our Elastic Beanstalk environment will have failed
‫to be deleting it will be in the Delete Failed state.
‫And so we need to just go in CloudFormation
‫and delete that CloudFormation stack manually.
‫And there we go will have effectively
‫created an RDS Database on its own outside
‫of our Beanstalk environment.
‫So hope that was helpful
‫and I will see you in the next lecture.