Adrian Cantrill’s SAA-C02 study course, 60 minutes: RDS section: [DEMO] ‘Migrating to Aurora Serverless’
Migrating to Aurora Serverless:
This demo focused on migrating a snapshot from Aurora running in provisioned mode to Aurora running in Serverless mode. To start the process we logged into our general AWS account, verified that we were situated in the us-east-1 (N. Virginia) region, and then clicked on a link for a one-click deployment. We needed to find the Aurora snapshot name for the snapshot we created in a previous demo. For this we navigated to RDS, which we opened in a new tab. Once the RDS console had finished loading, we navigated to snapshots. Locating the snapshot we wanted to use, we copied the snapshot name into our clipboard; because we’re restoring an Aurora provisioned snapshot into Aurora serverless, we’re not performing a migration, we’re performing a restore, so we don’t need a snapshot ARN, we need the snapshot name.
After doing this we returned to the one-click deployment page for the CFN stack we would be deploying, and pasted in the snapshot name in the appropriate box, clicked the acknowledgment box, and created the stack. This process was very time consuming, so while the stack was being provisioned, we looked at the steps for performing the same provisioning process manually, to help us understand the process more deeply and gain more hands-on experience in the process.
For the manual process we navigated back to the RDS snapshots console, checked the selection box for the same snapshot name, and then chose ‘restore snapshot’ from the dropdown ‘Actions’ menu. In the ‘restore snapshot’ screen we walked through the available options, which included choices for the type of db engine we wanted to use, if we were going to restore the snapshot in provisioned or serverless mode, the version of Aurora serverless we wanted to use, the DB instance identifier, coneectivity (VPC) information, subnet group, VPC security group, a data API to enable an SQL HTTP endpoint, minimum and maximum Aurora capacity units, additional scaling configuration (force scaling and pause compute capacity options), Encryption, and also Backup options with the option to copy any existing tags to the snapshots. After making all the selections that were required, we could then choose to restore the DB instance.
Moving on from this, we looked at the options available to us if we decided to create a serverless architecture from scratch. After selecting Aurora and choosing to create our new instance as serverless, we had even more options, including cluster identifier, credentials settings, admin user name and password, initial DB name, DB cluster parameter group information, backup retention period, encryption, and deletion protection, all in addition to the set of options that were also available in the restore-to-serverless options screen.
After reviewing all this, we refreshed our screen to find that the serverless instance had finished provisioning, we went inside the cluster to study the composition of its architecture. The first thing we took note of is that our serverless cluster was using two Aurora capacity units, running in us-east-1, and overall was very similar to an Aurora provisioned cluster.
The next step was to open the ec2 console in a new tab, navigate to instances running, where we able to see a single wordpress instance that was available. We selected it, copied the ip4 into our clipboard, opened a new tab, and navigated to our WP site. Navigating to the post we created, we took note of the fact that the images were missing because – as we were reminded- the images are not stored on the DB, but on the local instance file system.
From here we looked into the differences between Aurora provisioned and Aurora serverless. For this we navigated back to the RDS console, and focused on the ACU’s again. We noted again the two ACU’s and touched on the fact that this architecture carries a high amount of overhead along with it. We then proceeded to keep refreshing our screen with the WP site in an idle state to watch the amount of ACU’s drop from two to one, and then from one to zero, due to pausing because of zero usage. To help impress this concept on our working understanding, we reviewed the capacity settings information in the ‘Configuration’ tab. We looked at ‘logs & events’ to see no events listed (verifying inactivity), and we also looked at ‘monitoring’ to see the serverlesss database capacity, cpu utilization, and db connections, noting with especial interest the quick drop in cpu utliziation, and how the db connections dropped from one to zero (all information displayed by graphs in the ‘monitoring’ section).
Moving on, we refreshed the WP site page, and took note of the fact that the refresh took longer than normal, learning that the DB unpause requires time to take effect.
CloudMastermind 