Pass Your Amazon AWS Certified Database - Specialty Exam Easy!

Amazon AWS Certified Database - Specialty AWS Certified Database - Specialty exam dumps vce, practice test questions, study guide & video training course to study and pass quickly and easily. Amazon AWS Certified Database - Specialty AWS Certified Database - Specialty exam dumps & practice test questions and answers. You need avanset vce exam simulator in order to study the Amazon AWS Certified Database - Specialty certification exam dumps & Amazon AWS Certified Database - Specialty practice test questions in vce format.

Amazon RDS and Aurora

11. RDS encryption in transit and at rest

Now let's look at the third aspect of RDS security, the encryption. first, the encryption in transit. Now, to encrypt data in transit, VA uses SSL or TLS connections, that is, SSL certificates. To encrypt the data in transit, the clients must use the AWS root CA, which is a certified authority or certification authority. And that means when you connect over SSL, you have to download the SSL certificate from AWS and use that when you connect to your database instance. Now, the process of enforcing SSL is slightly different depending on which database engine you use. If you're using SQL Server or PostgreSQL, you simply set the parameter RDS force equal to one in the parameter group. And remember that this is a static parameter. So you must manually reboot your instance for the parameter changes to take effect. and we have discussed this in the parameter group lecture. That static parameter change requires a manual reboot. Automatic reboots will not apply the static parameters. You must manually reboot the instance. So you have your database, and it has the root certificate from the certification authority, and you set the parameter group parameter RDS force equal to one. If you're using SQL Server or Postgres, SQL If you're using MySQL or MariaDB, you simply use the Alto statement to require SSL for a particular user. And if you're using Oracle, you add the SSL option in the DB instance option group, okay? Not the parameter group, the option group. And this is how you enforce SSL. And to connect using SSL, what you do is simply download the certificate and use that certificate to connect to your database instance. So you provide the SSL trust certificate; that is, you download it first from AWS, and then you provide that certificate while making the connection to the database. Clients download the certificate, and they use that certificate when connecting to the database. And if you've enabled SSL on your database instance, connecting without passing the SSL certificate will almost certainly result in an error, right? Let's look at some examples of SSL connections in various database engines. So in Postgres SQL, you use this kind of syntax: SSL rules equal to the path to the certificate file, and you set the SSL mode to either verify CA or verify for. If you're using MySQL, you use this particular syntax. So SSL mode is set to verify identity. And if you're using Mariah DB, then SSL mode is set to required, okay? And for older versions of MySQL and MariaDB, you use the SSL Verify Server Search option instead of the SSL Mode option. Now, from the exam point of view, you should keep this in the back of your mind. You don't have to memorise it, but keep in mind that the way you connect over SSL in different database engines differs, and the options available vary slightly. All right, now let's look at the Audius encryption at rest. So RDS supports the AES 256 encryption algorithm, and this is managed through the KmsService, the key management service of AWS. This has the potential to encrypt both the masters and the read replicas. And we're going to talk about these replicas later in this section. And you have to enable encryption when you create your instance and not later on. RDS also supports what is called TDE, or Transparent Data Encryption. And this is something that is available with SQL Server and Oracle database engines. Okay, so TDE is a native encryption feature available with SQL Server and Oracle. And you can also use that along with the RDS encryption at rest. and you enable TDE using the option groups. In Oracle, you have the TDE option, and in SQL Server, you have a transparent data encryption option. And you can enable this in the option groups of the particular database engine. And you can use TDE along with the RDS encryption, as I said before. But remember that using both of these together is not a great idea. You can use one because there might be a slight performance hit if you use TDE along with the RDS encryption address. Just remember that using both of them together is not a great idea, but you can still use it if your use case requires it. All right, that's about it. Let's continue to the next lecture.

12. RDS backups

In this lecture, we're going to talk about RDS backups. So, as we have discussed earlier as well, RDS supports automatic backups. So what it does is it captures transaction logs in real time, and these are used to generate your automatic backups. So the daily automatic backups happen during the 30-minute backup window. And when you create your instance, you can specify the backup window during which the backup should be taken. And the backups are enabled by default with a seven-day retention period. So you can have up to 35 days' retention. And if you set the retention to zero, that means you are, in effect, disabling the automatic backups. You can provide the backup window; that's the daily time slot during which the backup should be taken. So a backup window is where you take the backup, whereas the retention period is the number of days you want to retain the backup. And these are not full backups. The first backup is a full backup, while the subsequent backups are incremental. And the backup data is stored in an S-3 bucket. And this bucket is owned and managed by the RDS service. This bucket will not be visible in your S-3 console. And remember, if you have your RDS instance in a single AC instead of a multi-AZ environment, that is, if it doesn't have a standby instance, then when you take the snapshot of your instance, you might experience a brief Il suspension. And that is why it is recommended that you always use a multi-AZ deployment so as to avoid any performance issues when the backups are running. And also, RDS integrates well with the AWS backup service for centralised backup management. So you can use the AWS Backup service to create periodic backups of your database instance. All right? And RDS supports two types of backups: backups and snapshots. What I mean is that backups are the automated backups, while snapshots are something that you manually create. All right? So the backups are automated, they are incremental, and you can retain them up to 35 days. And the automated backups also support PIT, that is, point-in-time recovery within the retention period. Automated backups are great for unexpected failures, as they do support PIT. And when you set a nonzero backup retention period in RDS, it also enables a snapshot before and after your database engine gets an upgrade. AWS might upgrade your database engine, and when it does so, if you have a nonzero backup retention period, then AWS will ensure that it takes a snapshot before and after the engine upgrade. On the other hand, the snapshots are always manually triggered. These are full backups; these are not incremental backups. And you can retain the snapshots as long as you want. There is no restriction on 35-day retention. And you cannot do PIR with manual backups or manual snapshots. And these are great for events like database upgrades and so on. And you can, of course, use lambda functions to take periodic backups and move them to three, let's say, for compliance purposes. So you create a snapshot with a lambda function, then copy that snapshot to s three with another lambda function. And of course, as I mentioned before, you can also use SF, the AWS backup service, to do this, and that's a more operationally efficient way than using a lambda function. But both of the options can be used for creating periodic backups.

13. Copying and sharing RDS snapshots

Now let's see how to copy and share your RDS snapshots. So, you can copy both the automated backups and manual snapshots. And when you copy an automated backup or a manual snapshot, the copy will always be a manual snapshot. And you can copy these snapshots within regions, across regions, or across AWS accounts. For copying across accounts, you have to share the snapshot first, okay? And only after you share, you can copy that shared snapshot into a manual snapshot for your use in that account. and automated backups cannot be shared directly. You must create a manual backup first, and then you can share them. And copying across regions or accounts will, of course, come with its own data transfer costs. Now, let's look at the process of copying and sharing encrypted snapshots. The process is a little bit different. When your snapshots are encrypted with the default RDS encryption key, they cannot be shared directly. All right? So what do you do? You have to first copy that snapshot using a custom encryption key. And then you can share the key along with the snapshot. So you create a manual snapshot with a custom KMS key, and then you share that snapshot along with the custom KMS key. The default RDS key cannot be shared, all right? And snapshots with certain custom option groups cannot be shared. For example, if you have enabled TDE on your database instance, then you will not be able to share those snapshots. TDE is transparent data encryption. And this is available with Oracle's and SQL Server's databases. It's

14. How to encrypt an unencrypted RDS database

Now, how do you encrypt an unencrypted RDS database? You cannot really encrypt an existing RDS database instance that is unencrypted. So there is an elaborate process that you follow to encrypt a database, which is not encrypted. Okay? Also, you cannot create an encrypted read replica from an unencrypted instance. If you have an RDS database that is not encrypted, then you cannot create an encrypted replica from it. So what you do is you simply copy the unencrypted snapshot, and when you copy, you enable the encryption. So you create a manual snapshot that is unencrypted, and then you copy that snapshot with encryption enabled, all right? And then you can restore this encrypted snapshot to a new RDS database instance. So now the new database becomes encrypted. You can, of course, use the MySQL application to synchronise changes between the source and the target instance. And this is called "Bin Log Replication." In addition, if this is an aurora cluster, that is, an aurora unencrypted snapshot, you can directly restore that unencrypted snapshot to an encrypted auroraDB cluster by specifying the KMS key. So you don't have to follow this process of copying the snapshot if it is an Aurora cluster. But in the case of any other RDS database instance, you have to follow this process of copying a snapshot with encryption enabled and then restoring it to a new database. Alright?

15. DB restore options in RDS

Now let's look at how to restore from a snapshot. So remember, you always restore to a new instance, alright? So you have your existing audience instance, you create a snapshot, and you restore and store that snapshot to a new instance. You cannot restore to the same instance. An instance can have one or more databases, and all these databases get restored. You cannot restore selectively. So if there are multiple databases, you cannot say, "I want to just restore one database." All of the databases within the database instance will be restored. And if you want to retain the same name, you should delete the existing database or rename the existing instance before you restore. Right? And then remember that you cannot restorefrom a shared and encrypted snapshot directly. You have to copy it first and then restore from a copy. So if you have a shared and encrypted snapshot, you copy it to a manual snapshot and then restore that snapshot into your new database instance. This also applies when you're restoring from another region. Okay? So you have to copy a snapshot first into the target region, and then you restore to your new instance in the target region. And you can restore from a snapshot of your DB instance outside of VPC to an instance inside of VPC. But the other way around is not possible. Okay? So only from outside the VPC to inside the VPC is this possible. The other way around is not possible. So by default, the restore cluster gets applied with a new security group. So when you restore a database to a new database, when you restore a snapshot to a new RDS instance or RDS cluster, that cluster will get applied with a new security group default parameter group, and it will get the option group that was originally associated with the snapshot. All right, this is a good thing to remember. So while you restore from a snapshot, be sure that you choose the correct security group to ensure connectivity for your historic database. So when you run your restoration process, you have the option to choose the security group, and make sure you choose the correct security group. Also, you should choose the correct parameter group for the store database, otherwise the default parameter group will be applied to it. And it's always recommended that you retain theparameter group of any snapshots to help yourestore with the correct parameter group. Otherwise, they could be inconsistencies, and you might get unexpected results. All right, now let's look at how Pitr works with RDS. Pitr is now in a state of recovery. Even with Pitr, you always restore to a new instance, all right? And you can restore to any point within your backup window. So if you have a seven-day retention period for your automated backups, you get a seven-day window for Pitr. And the maximum you can have is up to 35 days of backup windows. So you can restore to any point within the past 35 days. when you restore with Pit, R, and RDS. uploads the database transaction logs to T3 every five minutes. Right? As a result, this may have an impact on your most recent restorative time. So the maximum RPO, or recovery point objective, will be about five minutes. So you could have about five minutes of data loss when you use Pitr. So that's just a good thing to remember: the RPO is about five minutes, and you can move or restore a database instance from outside the VPC to inside the VPC with Pitr but not the other way around. And this is true with any backups that you use, whether they use Pitr or a manager backup.

16. Exporting RDS DB snapshot to S3

Now let's see how to export your DB snapshot data to S Three. So you can export all types of backups to S3, irrespective of whether they are automated backups, manual backups, or if you've created them using the AWS Backup service. All of them can be exported to S Three.So how do you export? Of course, you set up your S3 bucket with appropriate IAM permissions. And you can create KMS keys for server-side encryption. And then you can export the snapshot using your RDS console from the Actions menu. Simply choose export to S three.Or you can also run the Start Export Task CLI command, and your database data will be exported to Three. And this export process runs in the background. It does not affect your database performance. And the data that gets exported is always in the Apache Parque format. PARK is a compressed and consistent data format. Okay? And once you have your database data in Parquet format, this also allows you to query that data directly in S 3. You can use Athena or Redshift Spectrum to query the data sitting in the S3 bucket. Okay? And when we talk about Redshift, we'll see how the Redshift spectrum works. As a result, you can run SQL queries on the S-3 data directly. So that's really powerful. Alright, so that's about it. Let's continue to the next lecture.

17. RDS backup and restore - Hands on

In this demo, I'm going to quickly show you how to perform backup and restore in RDS. So we have this database that we created earlier. So to create a backup or a manual snapshot, simply select the database, and from the Actions menu you can choose the option to take a snapshot. All right, simply give a database name. Let's say "My Snapshot," okay, and take the snapshot. And that's about it. You can see that it's creating it, and once it is available, you can start using it. Okay, now let's look at how to restore from a snapshot or from a backup. As a result, we cannot use this snapshot to restore because it is still being created. But what we can do instead is go to the System tab. Now, this tab shows all the automated backups that have been taken on your RDS. So we can choose one of the backups here for our database. And from the Actions menu, simply choose the option to restore a snapshot. Now this is going to present you with options similar to what you see when you create a new database instance. You always restore to a new instance. You must enter your name here. So let's say database one is restored. So that's why I'm going to call the database. Then under Connectivity, you can choose the VPC where you want to restore the snapshot. And in the additional connectivity information, make sure that you choose the correct security group. If you want the incident to be publicly available, you can choose yes here. And it's important to make sure that the correct security group is selected here. By default, the default security group is selected. So if you want the instance to be in a particular security group, you can choose it here. In my case, my original database was in the default security group, so I'm going to leave it at that. But if you created a new security group for your database instance, then it's a good idea to place the restored instance in the same security group as well. All right. And then you can choose the database instance size. So in my case, I'm going to use a burst of instances, so that is the smallest one available. And since this is a free tier, you cannot choose Multi AZ.You can choose an Availability Zone if you like, and then you can choose the database authentication. If you want item authentication, then you can enable this under Additional Configuration. This is important to note here: when you restore the database, parameter groups will always be defaulted. What that means is that when you restore by default, RDS will attach the default parameter group to your restored instance. But if your original database has a different parameter group, then you should actually select that particular parameter group here. That's not the case with option groups. Option groups that were attached to your database instance when the snapshot was taken will be automatically applied. But, in the event of a parameter group, keep in mind that the default parameter group will appear here. You should manually change the parameter group. If your original instance has different parameters and configuration, then you can choose Log Experts as per your requirements. And further, you can set the maintenance window and tweak any of the other configuration if you like, then simply hit the "Restore the instance" button to restore your database. And now you can see that this particular database is being created. I'm going to pause the recording here and come back once the instance is ready. All right. Now you can see that the Restore database instance is available. So that's it. Let's continue to the next lecture.

Go to testing centre with ease on our mind when you use Amazon AWS Certified Database - Specialty vce exam dumps, practice test questions and answers. Amazon AWS Certified Database - Specialty AWS Certified Database - Specialty certification practice test questions and answers, study guide, exam dumps and video training course in vce format to help you study with ease. Prepare with confidence and study using Amazon AWS Certified Database - Specialty exam dumps & practice test questions and answers vce from ExamCollection.