Welcome back, Blaine here. We want to talk about security. Anytime you talk about security at AWS, you need to talk about the shared responsibility model. The idea is, at AWS, we talk about security as a partnership. There are things AWS is responsible for and things you are responsible to do, in order to keep your application safe and secure in the cloud. An easy way to understand that, is to take a look at your application not as a single object, but as a collection of pieces that together make up the parts of your app. We start at the beginning, right at the bottom with the physical data centers. This is the concrete and iron, the barbed wire fence and the security guards. Someone's got to maintain control over ingress and egress over that physical facility, and that's 100 percent AWS. Even when it comes to protecting against our fine lizard friends, we take care of that, and you don't have to worry about that part. On top of the physical infrastructure, we have the AWS network. We run our hypervisors for EC2 and other applications, and all of these pieces we take care of. Now, do we disclose information under NDA, or other elements, to help you understand what's happening? Where we need to. But we take care of this, and we provide the security elements to you and your auditors where compliance is needed. When you're running EC2 on AWS, and you launch EC2 when you choose an AMI with an operating system, that guest operating system is a 100 percent in your control. This becomes the dividing line. AWS takes care of everything below the line and with EC2, everything from the operating system, whatever applications you run on EC2, and especially, all of your user data, is controlled by you. This means, it's your responsibility to think about things like, do you want encryption? AWS offers a wide range of encryption tools, whether it's simply a bring-your-own-encryption to automatic server-side encryption on S3 and EBS. Or perhaps, you'd like a more robust managed keys, using AWS CloudHSM or KMS, the Key Management Service. That allows you to retain high level controls even when you've got security like a FIPS 140-2 compliance, we can take care of that and give you the validations needed, so you can prove your certifications. Every service at AWS has a dividing line. Below the line, we are responsible for security, and above the line, it's your job to make sure you protect your data, you take your user management, that your application is free from whatever vulnerabilities might exist. But in some cases, you don't have to worry about the application. Think about RDS, the Relational Database Service we talked about before. In that case, there's still an application, there's still an Oracle application, or Postgres application, or even the new Amazon Aurora application. But in those cases, AWS is responsible for installing and maintaining, and keeping all the patches up to date. You or your DBA, doesn't have to worry about the operating system or the application. In fact, there's a different dividing line for RDS. You though, still maintain 100 percent control over the data itself, over the schema, over user access. Am I encrypted or not? Who has access to read it? Just because you're running on AWS servers, does not give us any visibility at all into your data. If you don't trust that, don't worry about trust, that's what encryption's all about. With enough encryption, you don't have to worry about who else is running inside the cloud or anywhere else in the world. With the shared responsibility model, and understanding where the line exists between the different services, this is going to give you the information you need to know the parts that you need to be responsible for, to stay secure in the cloud.