1 00:00:12,230 --> 00:00:16,890 Welcome back to Backspace Academy. In this lecture we'll build on what we 2 00:00:16,890 --> 00:00:21,930 already know from our cloud practitioner course on backing up and restoring our 3 00:00:21,930 --> 00:00:27,330 applications and data that is on AWS. We'll start off by looking at some of 4 00:00:27,330 --> 00:00:31,230 the concepts and terminology around backing up and then we'll look at the 5 00:00:31,230 --> 00:00:38,399 options that are available for ec2, for databases both DynamoDB and RDS, 6 00:00:38,399 --> 00:00:45,690 for Amazon s3 and also for storage gateway. Then we'll look at the AWS Backup 7 00:00:45,690 --> 00:00:51,390 service which can control centrally all of these backups that we are doing 8 00:00:51,390 --> 00:00:56,489 across many different AWS services, and then finally, we'll look at the data 9 00:00:56,489 --> 00:01:02,370 transfer options to lift and shift data that has been backed up and restore it 10 00:01:02,370 --> 00:01:11,640 on the AWS cloud. RPO or recovery point objective and RTO or recovery time 11 00:01:11,640 --> 00:01:17,340 objective are two terms that you need to understand when assessing backup and 12 00:01:17,340 --> 00:01:23,070 restore options. Recovery point objective, that is maximum age of files 13 00:01:23,070 --> 00:01:28,850 or objects that are restored from a backup. So if you're doing a monthly 14 00:01:28,850 --> 00:01:34,829 backup then the maximum age will be one month. If you're doing weekly 15 00:01:34,829 --> 00:01:37,890 backups and that recovery point objective is going to be better, it's 16 00:01:37,890 --> 00:01:44,909 going to be smaller. So a higher backup frequency means a lower RPO cost. If 17 00:01:44,909 --> 00:01:49,799 you're doing monthly backups then that obviously is going to be a high RPO 18 00:01:49,799 --> 00:01:55,219 because it could be up to one month old with some of those files. If you're doing 19 00:01:55,219 --> 00:02:00,090 incremental backups, and we'll talk about that in the next slide, and you're using 20 00:02:00,090 --> 00:02:05,579 a write event, so whenever you write or you delete something on that data source 21 00:02:05,579 --> 00:02:11,160 and if you use it to trigger an incremental backup then your recovery 22 00:02:11,160 --> 00:02:13,800 point objectives going to be very low. So it 23 00:02:13,800 --> 00:02:20,580 could even be in the order of seconds or milliseconds. Recovery time objective is 24 00:02:20,580 --> 00:02:26,250 a maximum length of time that the system can be down. So if you've backed up 25 00:02:26,250 --> 00:02:31,020 everything to tape storage, that's going to take a significant amount of time to 26 00:02:31,020 --> 00:02:36,030 get it from tape storage over back onto your live system, and this is something 27 00:02:36,030 --> 00:02:40,950 to take into consideration with Glacier. If you're using Glacier, depending on 28 00:02:40,950 --> 00:02:46,680 what storage class you use, they can take hours to restore those objects. If you're 29 00:02:46,680 --> 00:02:53,310 using something like s3 it could be a lot quicker. There are two ways in 30 00:02:53,310 --> 00:02:58,680 which we can do a backup of a system. In the olden days we would do a full backup 31 00:02:58,680 --> 00:03:03,840 on a regular basis. We would just basically take a snapshot of all of our 32 00:03:03,840 --> 00:03:08,430 data and then we will back that up to tape and we do that on a daily basis or 33 00:03:08,430 --> 00:03:13,110 whatever it would be. Now this captures the entire system and 34 00:03:13,110 --> 00:03:18,360 as such if it's been done on a regular basis this will require a large amount 35 00:03:18,360 --> 00:03:23,070 of disk base. The advantage of a full backup is that the recovery time 36 00:03:23,070 --> 00:03:28,290 objective is very fast. You're simply taking the entire system and bring it 37 00:03:28,290 --> 00:03:33,209 over to your live system without any modification or any reassembling of 38 00:03:33,209 --> 00:03:38,850 anything. It has a poor recovery point objective because this captures the 39 00:03:38,850 --> 00:03:43,320 entire system it's not going to be done on a regular basis, you're probably going 40 00:03:43,320 --> 00:03:48,570 to do this at the most everyday. The other option is an incremental backup 41 00:03:48,570 --> 00:03:54,600 and what that does when it first does a backup it will capture the entire system 42 00:03:54,600 --> 00:03:59,790 and from that point on all of the backups from that will only capture the 43 00:03:59,790 --> 00:04:05,280 changes that were made since the last incremental backup, because of that it 44 00:04:05,280 --> 00:04:11,970 requires less disk space. The disadvantage is that it has a slower recovery time 45 00:04:11,970 --> 00:04:17,190 objective because to bring that data back it needs to be reassembled from all 46 00:04:17,190 --> 00:04:22,200 of the individual incremental backups. The advantage of it is that it's going 47 00:04:22,200 --> 00:04:26,850 to have a good recovery point objective because you're going to be doing these 48 00:04:26,850 --> 00:04:30,600 incremental backups on a regular basis the files 49 00:04:30,600 --> 00:04:38,640 contained will be not as old as you would expect from a full backup. When we 50 00:04:38,640 --> 00:04:43,260 have multiple hard drives we can set those up as a redundant array of 51 00:04:43,260 --> 00:04:49,350 inexpensive disks or RAID for short. The two main types of RAID that you need to 52 00:04:49,350 --> 00:04:56,070 be aware of are striping or raid zero and mirroring raid 1. With striping 53 00:04:56,070 --> 00:05:01,380 on the left there, we can see that we have no duplication of the data. So there on 54 00:05:01,380 --> 00:05:06,120 the left hand side there we've got ABC on one disk and we've got DEF on the 55 00:05:06,120 --> 00:05:12,420 other disk. So there's no redundancy whatsoever in a raid zero striping setup 56 00:05:12,420 --> 00:05:17,880 but the advantage of striping is that you have double the bandwidth that you 57 00:05:17,880 --> 00:05:22,740 would have if you are only using one disk. So you're getting a very high 58 00:05:22,740 --> 00:05:27,450 performance your rates of access are going to be significantly more over 59 00:05:27,450 --> 00:05:33,480 using a single disk. You're also getting high storage utilization because you're 60 00:05:33,480 --> 00:05:40,830 not duplicating that data in those disks. In contrast, mirroring or raid one 61 00:05:40,830 --> 00:05:46,740 configuration, has high redundancy because you have duplicate copies of 62 00:05:46,740 --> 00:05:52,260 your data on one disk and in the other and that is regularly updated to make 63 00:05:52,260 --> 00:05:57,960 sure that they match, they are synced together. So that has low storage 64 00:05:57,960 --> 00:06:02,700 utilization because you need two disks to store the same amount of 65 00:06:02,700 --> 00:06:07,740 data that you would need with striping. So there's low storage utilization but 66 00:06:07,740 --> 00:06:12,210 the advantage is high redundancy. The other disadvantage is that you're only 67 00:06:12,210 --> 00:06:17,220 going to be having one lot of bandwidth there. So you're going to have half the 68 00:06:17,220 --> 00:06:22,500 performance that you would get on a striping raid 0 configuration because 69 00:06:22,500 --> 00:06:27,660 all of the data will be going through through to one run disk and then it will 70 00:06:27,660 --> 00:06:31,370 be syncing to another disk there. 71 00:06:33,300 --> 00:06:38,710 Amazon Machine Images or AMIs provide a backup of our system image 72 00:06:38,710 --> 00:06:44,350 that is running on ec2. When we create an AMI it will be registered and then saved 73 00:06:44,350 --> 00:06:49,780 to Amazon s3 and we can view that in the console. When we don't need it anymore we 74 00:06:49,780 --> 00:06:54,130 can simply deregister it and that will be removed from both the console 75 00:06:54,130 --> 00:07:00,430 view and also from Amazon s3. The AMIs, they are region specific, so that if you 76 00:07:00,430 --> 00:07:05,320 need to have an AMI to launch instances into another region, you will need to 77 00:07:05,320 --> 00:07:13,120 copy that AMI over to the other region. If you create an AMI that is sellable 78 00:07:13,120 --> 00:07:17,380 then you can sell it on the AWS marketplace to other people who might 79 00:07:17,380 --> 00:07:22,510 take advantage and use that themselves. An AMI image it will contain EBS 80 00:07:22,510 --> 00:07:27,790 snapshots or instant store root volume templates and, it also has the 81 00:07:27,790 --> 00:07:32,980 launch permissions of who can launch this AMI or can launch instances using 82 00:07:32,980 --> 00:07:38,830 this AMI It will also have block device mapping that defines what block device is 83 00:07:38,830 --> 00:07:47,820 what EBS volumes are attached to this ec2 instance after it has been launched. 84 00:07:47,820 --> 00:07:52,960 EBS snapshots allow us to take incremental snapshots of our elastic 85 00:07:52,960 --> 00:07:57,580 block stores that are attached to our ec2 instances and save those 86 00:07:57,580 --> 00:08:02,830 automatically to s3. They are created using the console or the command-line 87 00:08:02,830 --> 00:08:09,100 interface or one of the SDKs using the EC2 create snapshot command. When you 88 00:08:09,100 --> 00:08:13,990 want to restore an EBS volume what you need to do is, you need to first of all 89 00:08:13,990 --> 00:08:19,900 create a new EBS volume using that snapshot and then unmount the existing 90 00:08:19,900 --> 00:08:24,360 EBS volume and then mount the new one in its place. 91 00:08:24,360 --> 00:08:31,300 EBS volumes are replicated by default within an availability zone but they're 92 00:08:31,300 --> 00:08:37,750 not replicated within different regions but you can copy an EBS snapshot over 93 00:08:37,750 --> 00:08:43,510 to a different region if you would like to do that. One advantage of using EBS 94 00:08:43,510 --> 00:08:46,480 snapshots is it makes it quite straightforward to 95 00:08:46,480 --> 00:08:52,510 set up a raid one mirrored configuration. To do that you would unmount your 96 00:08:52,510 --> 00:08:58,330 existing EBS volume take a snapshot of it and then remount it and then mount 97 00:08:58,330 --> 00:09:03,550 another EBS volume from that snapshot and from there you could use your 98 00:09:03,550 --> 00:09:10,060 operating system to make sure that raid 1 mirroring is occurring. So here we 99 00:09:10,060 --> 00:09:16,390 have the MD ADM command now MD ADM is a tool within the Linux operating 100 00:09:16,390 --> 00:09:21,490 system for managing raid volume configurations. So there we can see it's 101 00:09:21,490 --> 00:09:28,470 MD ADM. We're creating a level 1 or a raid 1 configuration and we're having 102 00:09:28,470 --> 00:09:32,410 two devices there so we can see there we've got device name 1 and 103 00:09:32,410 --> 00:09:38,170 device name 2 and that will, after we've created those two volumes from 104 00:09:38,170 --> 00:09:45,250 those EBS snapshots, that will maintain that for us. Elastic filesystem volumes 105 00:09:45,250 --> 00:09:51,340 can be backed up using an EFS - EFS solution that is provided by AWS and 106 00:09:51,340 --> 00:09:58,060 that will backup from one EFS volume to a backup volume for you. What it is is is 107 00:09:58,060 --> 00:10:04,120 a cloud formation template that is provided by AWS and that will launch the 108 00:10:04,120 --> 00:10:08,350 architecture that you need to back up these volumes and that will consist of 109 00:10:08,350 --> 00:10:15,100 an NodeJS application running on AWS Lambda that will coordinate that continual 110 00:10:15,100 --> 00:10:20,410 backup and those incremental backups of that of that volume and those 111 00:10:20,410 --> 00:10:25,450 incremental backups will be on a customer defined schedule. So that will be 112 00:10:25,450 --> 00:10:31,330 on a schedule that you define. So here is an example architecture of what 113 00:10:31,330 --> 00:10:35,080 it would look like using this cloud formation template. So here we have our 114 00:10:35,080 --> 00:10:42,520 ec2 instance and we have our amazon EFS volume which is our source and we also 115 00:10:42,520 --> 00:10:49,780 have next to it there in the same VPC is our amazon EFS backup volume and then on 116 00:10:49,780 --> 00:10:53,860 the left hand side there we can see that we have our lambda function that would 117 00:10:53,860 --> 00:11:00,450 be orchestrating the backup between the two EFS volumes. 118 00:11:03,380 --> 00:11:10,380 There are two options available for us to back up our RDS instances. We can do 119 00:11:10,380 --> 00:11:14,940 automated backups where they are done on a regular basis without manual 120 00:11:14,940 --> 00:11:20,810 intervention from us at all. We can do RDS DB snapshots and those are user 121 00:11:20,810 --> 00:11:26,280 initiated. So we actually do those. So automated backups they will be a daily 122 00:11:26,280 --> 00:11:32,550 snapshot of the data and our transaction logs for that RDS instance the retention 123 00:11:32,550 --> 00:11:37,590 period will be one day by default or it could be up to five day. So you can hold 124 00:11:37,590 --> 00:11:43,590 them for up to five days. So those automated backups will be automatically 125 00:11:43,590 --> 00:11:51,960 deleted when that RDS instance is terminated but you can create a final DB 126 00:11:51,960 --> 00:11:58,050 snapshot when you delete or terminate that instance and the AWS console will 127 00:11:58,050 --> 00:12:01,890 ask you as well whether you want to actually take a final DB snapshot before 128 00:12:01,890 --> 00:12:07,710 terminating that instance. You can define the backup window for those periodic 129 00:12:07,710 --> 00:12:11,310 incremental backups if you want to have it for example 3 o'clock in the morning 130 00:12:11,310 --> 00:12:13,950 till 5 o'clock in the morning or something like that 131 00:12:13,950 --> 00:12:20,940 where your system is not being used as much. Those periodic backups and the 132 00:12:20,940 --> 00:12:28,860 related transaction logs allow you to recover up to last restorable time which 133 00:12:28,860 --> 00:12:34,650 is normally the last five minutes So there is a very good recovery point 134 00:12:34,650 --> 00:12:41,100 objective for these automated backups. RDS DB snapshots they're a little bit 135 00:12:41,100 --> 00:12:45,420 like EBS snapshots. They're user-initiated, you just basically take a 136 00:12:45,420 --> 00:12:51,540 snapshot of that instance. Now one thing to consider is that they are not deleted 137 00:12:51,540 --> 00:12:55,650 when that DB instance is deleted. So if you want to get rid of it everything you 138 00:12:55,650 --> 00:12:59,970 need to make sure that you also delete those RDS snapshots as well 139 00:12:59,970 --> 00:13:03,750 otherwise you will continue to pay for those. If you want to find where they 140 00:13:03,750 --> 00:13:08,700 are or view them you can do describe DB snapshots the command line interface 141 00:13:08,700 --> 00:13:13,680 command and that will list all of those snapshots for an instance and you can 142 00:13:13,680 --> 00:13:17,370 use a delete DB snapshot command to delete any 143 00:13:17,370 --> 00:13:26,220 snapshots. Dynamo DB data can be backed up using the dynamo DB table import and 144 00:13:26,220 --> 00:13:31,830 export. You access it through the console or you can also use a command-line 145 00:13:31,830 --> 00:13:36,300 interface or one of the many software development kits and the command is 146 00:13:36,300 --> 00:13:42,660 create backup to create that backup. You can export all of that tables data and 147 00:13:42,660 --> 00:13:48,990 the Associated log files over to Amazon s3. One thing to consider when you're 148 00:13:48,990 --> 00:13:55,430 doing this is that by doing a backup you will be taking resources from that 149 00:13:55,430 --> 00:14:01,440 dynamodb table and so that may impact the performance that your end users are 150 00:14:01,440 --> 00:14:07,170 seeing when they're using that table. So you can decide how much of that 151 00:14:07,170 --> 00:14:12,870 tables provision throughput to allocate to that export process. So for example it 152 00:14:12,870 --> 00:14:18,330 could be 10 percent or it could be up to 100 percent in five percent increments 153 00:14:18,330 --> 00:14:21,450 so obviously they're going to use 100 percent that's going to have a pretty 154 00:14:21,450 --> 00:14:26,250 massive impact on the performance of that table while you're doing that. 155 00:14:26,250 --> 00:14:31,410 You can set that up as a daily export job and when you want to get it back you can 156 00:14:31,410 --> 00:14:35,490 simply import it back to that table quite straightforward again using the 157 00:14:35,490 --> 00:14:39,710 console or the CLI or SDK. 158 00:14:42,449 --> 00:14:48,490 Now we already know from our cloud practitioner course quite a bit about s3 159 00:14:48,490 --> 00:14:53,949 and glacier and how we can set up lifecycle management rules for example 160 00:14:53,949 --> 00:15:01,990 we can have an object be deleted from s3 after a specific expiry time or we could 161 00:15:01,990 --> 00:15:05,350 have that object archived over to glacier 162 00:15:05,350 --> 00:15:10,929 after that expiry time as well as being deleted and we can simply restore from 163 00:15:10,929 --> 00:15:17,769 glacier back to s3 very easily but depending on what storage class we have 164 00:15:17,769 --> 00:15:23,740 chosen for glacier that time taken to restore could be quite a few errors or 165 00:15:23,740 --> 00:15:26,860 it could be quite a few minutes depending on what the storage class we 166 00:15:26,860 --> 00:15:30,149 have chosen for glacier. 167 00:15:32,660 --> 00:15:40,740 AWS Storage Gateway enables hybrid cloud storage between on-premise data centers 168 00:15:40,740 --> 00:15:46,560 and the AWS cloud. It does this by creating a virtual appliance that 169 00:15:46,560 --> 00:15:52,590 connects directly to your local data center infrastructure and that virtual 170 00:15:52,590 --> 00:15:57,600 appliance could be connected as a file server or as a local disk volume or as a 171 00:15:57,600 --> 00:16:03,870 virtual tape library as well the first option is a file gateway and that will 172 00:16:03,870 --> 00:16:11,130 interface your local data center to Amazon s3 using file protocols such as 173 00:16:11,130 --> 00:16:18,510 NFS and so those objects can be accessed directly in Amazon s3, so for all intents 174 00:16:18,510 --> 00:16:25,950 and purposes that will will be viewed by your data center as a file server. Next 175 00:16:25,950 --> 00:16:32,700 we have volume gateways and they are iscsi protocol access to the Amazon s3 176 00:16:32,700 --> 00:16:39,360 service on the AWS cloud and so your local data center infrastructure will 177 00:16:39,360 --> 00:16:46,560 see that as a local disk volume so you can access that data in AWS as an Ebs 178 00:16:46,560 --> 00:16:53,520 snapshot and you can use it to create a new EBS volume as well, and finally we 179 00:16:53,520 --> 00:17:00,750 have a type gateway which is an iscsi virtual tape library access to Amazon s3 180 00:17:00,750 --> 00:17:06,570 on the AWS cloud and so your local infrastructure will see that as a 181 00:17:06,570 --> 00:17:12,180 virtual tape, there will be a virtual media changer and there we virtual tape 182 00:17:12,180 --> 00:17:19,500 drives and also virtual tapes, and so that data once it is archived over to 183 00:17:19,500 --> 00:17:25,350 Glacier can then be accessed on the AWS cloud through the glacier service. So 184 00:17:25,350 --> 00:17:28,860 here we have an example of what it might look like on the left there we've got 185 00:17:28,860 --> 00:17:34,680 our customer data center and between our application server on that customer 186 00:17:34,680 --> 00:17:39,900 infrastructure we have an AWS Storage Gateway appliance and that could be a 187 00:17:39,900 --> 00:17:44,850 file gateway it could be a volume gateway or a type gateway 188 00:17:44,850 --> 00:17:50,309 and that is going to connect through the AWS Direct Connect high-speed service 189 00:17:50,309 --> 00:17:55,100 through to the AWS cloud you will connect to the AWS Storage Gateway 190 00:17:55,100 --> 00:18:01,530 back-end if it's a file gateway then then it will allow access from that 191 00:18:01,530 --> 00:18:07,320 application server through to Amazon s3 using standard file protocols such as 192 00:18:07,320 --> 00:18:12,990 NFS and it will see that as a simple file server if it's a volume gateway 193 00:18:12,990 --> 00:18:19,620 then it will access Amazon or it will create Amazon EBS snapshots and it will 194 00:18:19,620 --> 00:18:24,289 view that as a simple volume that is connected to that infrastructure and 195 00:18:24,289 --> 00:18:30,240 finally if it's a type Gateway then it will interface through storage gate 196 00:18:30,240 --> 00:18:35,150 right through to the Amazon glacier service. 197 00:18:38,620 --> 00:18:45,950 AWS backup is a fully managed centralized backup solution for many AWS 198 00:18:45,950 --> 00:18:50,840 resources and this is great because instead of creating individual EBS 199 00:18:50,840 --> 00:18:58,910 snapshots or RDS snapshots or EFS - EFS solutions, we can use AWS backup to do 200 00:18:58,910 --> 00:19:05,570 that for us and centrally manage it in one location. It is policy based we 201 00:19:05,570 --> 00:19:10,370 create backup plans that define what that backup looks like and when it 202 00:19:10,370 --> 00:19:15,680 occurs access policies who can access who can not access and retention 203 00:19:15,680 --> 00:19:20,570 policies how long we going to keep these backups for and lifecycle policies are 204 00:19:20,570 --> 00:19:24,340 we going to migrate this over - for example Glacier or something like that, 205 00:19:24,340 --> 00:19:29,900 they are tag-based, so you can apply a tag to resources and 206 00:19:29,900 --> 00:19:35,600 then the backup service can pick up on those tags and apply those backups to 207 00:19:35,600 --> 00:19:41,390 those resources that have that tag. You can create a backup schedule for 208 00:19:41,390 --> 00:19:46,070 whatever you want it will perform incremental backups it can also perform 209 00:19:46,070 --> 00:19:52,010 cross region backups in multiple regions and all of these backups will be stored 210 00:19:52,010 --> 00:19:59,660 in Amazon s3. On the left there we've got the AWS backup service and we can access 211 00:19:59,660 --> 00:20:04,940 it through the AWS management console or we can use the command-line interface or 212 00:20:04,940 --> 00:20:09,620 one of the many software development kits the way that we set this up is that 213 00:20:09,620 --> 00:20:16,700 we create a backup plan that will define how and when this backup is to concur 214 00:20:16,700 --> 00:20:22,720 then we define the AWS resources that we want to be backed up and from there on a 215 00:20:22,720 --> 00:20:28,910 predefined schedule that backup will occur and that will be backed up over to 216 00:20:28,910 --> 00:20:34,160 Amazon s3 and from there we can using the management console we can monitor 217 00:20:34,160 --> 00:20:38,150 the performance and what's happening with those backups we can modify those 218 00:20:38,150 --> 00:20:43,670 backups and the back-up plan and we can also restore those backups back to the 219 00:20:43,670 --> 00:20:47,230 assigned AWS resources. 220 00:20:47,790 --> 00:20:54,040 Backup plans are a policy that defines when and how to back up our resources, 221 00:20:54,040 --> 00:21:00,660 that could be an EFS file system dynamodb table, ec2 instance, EBS volume, 222 00:21:00,660 --> 00:21:07,900 RDS database or a storage gateway volume. Within those backup plans they will have 223 00:21:07,900 --> 00:21:13,450 rules that are defined. So we define the frequency of that backup, how often we 224 00:21:13,450 --> 00:21:19,300 are going to backup, the backup window which defines when we want these backups 225 00:21:19,300 --> 00:21:24,790 to occur. If you are backing up EFS volumes you can also define a life cycle 226 00:21:24,790 --> 00:21:31,140 which will copy that or back that up over to EFS infrequent access storage. 227 00:21:31,140 --> 00:21:37,450 You can define the backup vault where these backups are to be stored, you can 228 00:21:37,450 --> 00:21:43,600 also have the option to copy this backup to multiple regions, you can define the 229 00:21:43,600 --> 00:21:50,890 tags that this backup plan applies to so any resources that have these tags will 230 00:21:50,890 --> 00:21:57,400 have that backup plan applied to it, you can also define recovery point tags to 231 00:21:57,400 --> 00:22:02,940 identify different recovery points within a backup. 232 00:22:02,940 --> 00:22:08,260 Backup vaults are containers to organize your backups that are created 233 00:22:08,260 --> 00:22:14,049 from a back-up plan and you need to define a backup vault when you create a 234 00:22:14,049 --> 00:22:21,070 backup plan. A KMS encryption key can be defined with this backup vault and any 235 00:22:21,070 --> 00:22:25,840 backups within that backup vault we'll have that KMS key or encryption 236 00:22:25,840 --> 00:22:31,600 key associated to it and will be encrypted using that KMS key. 237 00:22:31,600 --> 00:22:37,929 Access policies can be assigned to an IAM role, user or group of users and that will 238 00:22:37,929 --> 00:22:43,780 restrict access to the backup vault and its resources or, you could have access 239 00:22:43,780 --> 00:22:48,970 only to a certain resource type for example, s3 buckets but not EFS volumes 240 00:22:48,970 --> 00:22:55,919 for example.Recovery points are individual incremental backups that 241 00:22:55,919 --> 00:23:01,929 represent the resource contents at a specific point in time and those are 242 00:23:01,929 --> 00:23:06,789 saved within those backup vaults. If you want to find those recovery points they 243 00:23:06,789 --> 00:23:10,419 can be found is in the management console or using the command-line 244 00:23:10,419 --> 00:23:15,250 interface or one of the many software development kits using the list recovery 245 00:23:15,250 --> 00:23:23,020 points by backup vault or at least recovery points by resource command. 246 00:23:23,020 --> 00:23:28,539 EC2 AMIs will be listed as image / and then the name of the AMI, 247 00:23:28,539 --> 00:23:32,049 EBS snapshots will be listed as snapshot / and then the name of the snapshot. 248 00:23:32,049 --> 00:23:36,850 Storage Gateway volumes will again be listed the same as an EBS snapshot , 249 00:23:36,850 --> 00:23:44,890 RDS instances will be listed as a DBS backup and then the job. EFS will 250 00:23:44,890 --> 00:23:50,679 be listed as a very long hash there and dynamodb will be listed as table / 251 00:23:50,679 --> 00:23:55,840 the name of the table then / backup and then a hash for that 252 00:23:55,840 --> 00:23:58,860 individual backup. 253 00:24:01,590 --> 00:24:08,559 If you have massive amounts of data on premises and you want to back that up to 254 00:24:08,559 --> 00:24:13,090 the AWS cloud you're going to have to have some way of getting that large 255 00:24:13,090 --> 00:24:18,760 amount of data into AWS first and then from that point onwards conduct your 256 00:24:18,760 --> 00:24:24,220 incremental backups. So to do that initial lift and shift of that large 257 00:24:24,220 --> 00:24:29,440 amount of data that is where the AWS snowboard device has come in. So an AWS 258 00:24:29,440 --> 00:24:35,679 snowball device it's a petabyte scale data transfer to the Amazon s3 service. 259 00:24:35,679 --> 00:24:41,890 It has enforced encryption and you can control those jobs with the console, the 260 00:24:41,890 --> 00:24:45,610 command-line interface or one of the many software development kits. 261 00:24:45,610 --> 00:24:51,309 How it works is AWS will send out this this snowball device and you will have a 262 00:24:51,309 --> 00:24:57,280 standalone snowball local client software which will allow you to upload 263 00:24:57,280 --> 00:25:03,280 all of your data to that snowball device and also if it's a large amount 264 00:25:03,280 --> 00:25:07,150 of data that exceeds the 50 or 80 terabyte bottles models that are 265 00:25:07,150 --> 00:25:12,280 available it will allow you to break that up into multiple snowball devices 266 00:25:12,280 --> 00:25:16,990 so the 80 terabyte models they are only available in the US region they're not 267 00:25:16,990 --> 00:25:22,510 available in all regions as such and again if you want to do a petabyte scale 268 00:25:22,510 --> 00:25:27,340 job for uploading a large amount of data to Amazon s3. You can again use that 269 00:25:27,340 --> 00:25:33,580 snowball local client break it up into smaller jobs and put that onto these 50 270 00:25:33,580 --> 00:25:37,300 or 80 terabyte snowball devices and from there 271 00:25:37,300 --> 00:25:42,340 AWS will put that back together for you, and you can manage that again using the 272 00:25:42,340 --> 00:25:47,940 console or the CLI or the many software development kits. 273 00:25:48,120 --> 00:25:54,429 AWS snowball edge is a snowball device which has additional on-board 274 00:25:54,429 --> 00:26:02,160 storage and compute power and also has up to a 100 gigabit per second network 275 00:26:02,160 --> 00:26:08,410 adapter. It is available in three configuration options it can be 276 00:26:08,410 --> 00:26:13,149 optimized for storage or it can be optimized for compute 277 00:26:13,149 --> 00:26:19,869 operations or can be optimized with an additional GPU installed for GPU 278 00:26:19,869 --> 00:26:26,469 operations. You can cluster many of these devices say five to ten devices and that 279 00:26:26,469 --> 00:26:34,599 will allow you to have up to 99.999% of durability of your data. A good example 280 00:26:34,599 --> 00:26:39,849 of using this sort of service, is that you may have a remote location, such as a 281 00:26:39,849 --> 00:26:44,950 a mine site in the middle of the Amazon and you don't have very good internet 282 00:26:44,950 --> 00:26:49,389 access or no internet access but you need to have access to a large 283 00:26:49,389 --> 00:26:53,559 amount of data. So you can use this as a temporary file server or you could also 284 00:26:53,559 --> 00:27:03,789 use it as as a server to run workloads on that data in remote locations 285 00:27:03,789 --> 00:27:09,729 AWS Snowmobile is a truck with a 45 foot long trailer on the back of it that 286 00:27:09,729 --> 00:27:18,039 contains a massive amount of storage and that is used to transport hundred 287 00:27:18,039 --> 00:27:24,309 petabytes of data per each one of these Snowmobile trucks or trailers and that 288 00:27:24,309 --> 00:27:32,009 enables exabytes scale data transfer from on-premises to the AWS cloud, it's 289 00:27:32,009 --> 00:27:36,940 extremely secure, of course we have encryption of all this data but there 290 00:27:36,940 --> 00:27:43,690 are also security guards to protect this truck, it has tamper proof devices 291 00:27:43,690 --> 00:27:48,099 throughout of it to make sure that nothing has been tampered with 292 00:27:48,099 --> 00:27:54,369 while it has been transported, it has a very sophisticated alarm with GPS tracking, it 293 00:27:54,369 --> 00:28:01,029 also has 24/7 video surveillance of the truck at all time, so it is a great 294 00:28:01,029 --> 00:28:06,009 service if you have got a very large enterprise that is transporting 295 00:28:06,009 --> 00:28:13,109 very large amounts of data that requires a lift and shift solution of that data. 296 00:28:13,559 --> 00:28:19,599 Applications that are running on premises as virtual machines, we can 297 00:28:19,599 --> 00:28:26,830 migrate those over to AWS quite simply using the AWS server migration service. 298 00:28:26,830 --> 00:28:32,440 How it works is that we will have a server migration connector which will be 299 00:28:32,440 --> 00:28:39,970 a virtual machine that will be installed at our on-premises data center and that 300 00:28:39,970 --> 00:28:47,220 will take snapshots of our source of virtual machines and send them over to 301 00:28:47,220 --> 00:28:55,360 Amazon s3. When those are on Amazon s3 the server migration service 302 00:28:55,360 --> 00:29:01,000 will then grab those and will convert those to Amazon machine images. Once 303 00:29:01,000 --> 00:29:08,159 they've been converted to AMIs then the AWS SMS service will then launch the 304 00:29:08,159 --> 00:29:13,840 destination infrastructure by creating a cloud formation template and then 305 00:29:13,840 --> 00:29:19,690 launching that using that cloud formation template. The AWS database 306 00:29:19,690 --> 00:29:26,470 migration service not only manages the migration of individual databases over 307 00:29:26,470 --> 00:29:31,899 to another database at the same type on AWS, it also allows for migrations 308 00:29:31,899 --> 00:29:37,149 between different database platforms for example if you want to go from Oracle to 309 00:29:37,149 --> 00:29:42,580 Amazon Aurora it can achieve that and it does that by defining how that occurs 310 00:29:42,580 --> 00:29:46,570 through the different schemas and the different fields within those schemas, it 311 00:29:46,570 --> 00:29:51,039 does that with minimum downtime as well because it will manage everything for 312 00:29:51,039 --> 00:29:56,230 you and it will do that cut over for you. Not only can those sources be from the 313 00:29:56,230 --> 00:30:02,350 AWS cloud we can also migrate data bases that are on-premises over to the AWS 314 00:30:02,350 --> 00:30:05,190 cloud as well. 315 00:30:06,010 --> 00:30:12,460 AWS CloudEndure is a lift and shift solution for moving Windows and Linux 316 00:30:12,460 --> 00:30:19,640 applications and databases over to the AWS cloud. The way it works is the 317 00:30:19,640 --> 00:30:25,940 CloudEndure agent will be installed on those servers that are to be migrated and that 318 00:30:25,940 --> 00:30:32,630 CloudEndure agent will communicate with the CloudEndure service on the AWS 319 00:30:32,630 --> 00:30:39,590 cloud and that allows the AWS cloud in your service to replicate that 320 00:30:39,590 --> 00:30:48,350 application or that database on the AWS cloud. If we have many migration jobs 321 00:30:48,350 --> 00:30:52,820 running we may want to have a centralized view of that and that is 322 00:30:52,820 --> 00:30:58,160 where the AWS migration hub comes in. It's a centralized monitoring of these 323 00:30:58,160 --> 00:31:03,410 multiple migration jobs and they could be AWS database migrations, server 324 00:31:03,410 --> 00:31:08,930 migration or CloudEndure migrations or there are a number of other partner 325 00:31:08,930 --> 00:31:14,630 services that you can monitor using the AWS migration hub. A great advantage of 326 00:31:14,630 --> 00:31:18,410 the migration hub is that it has no additional cost 327 00:31:18,410 --> 00:31:24,250 other than those services that you are using. So that brings us to the end of a 328 00:31:24,250 --> 00:31:28,970 very long lecture I hope you've got a lot out of it and I look forward to 329 00:31:28,970 --> 00:31:32,230 seeing you in the next one.