In this video, you will be get an overview of the AWS global infrastructure. You will understand the difference between regions, availability zones, and edge locations. You will get an overview of the core network, compute, database, and storage services offered by AWS. You will learn about the AWS shared responsibilty model. You will understand the division of responsibilities between you and AWS.
- View Offline
- [Voiceover] You've decided to adopt AWS as your enterprise infrastructure as a surface cloud provider. Before we dive into the AWS console and start configuring things, it's important to understand the AWS shared responsibility model. You want to be confident you understand what AWS is responsible for, and where that responsibility ends. AWS provides infrastructure services on a global scale. AWS subdivides the world into regions. A region is a completely independent physical location, such as ap-northeast-1 located in Tokyo, Japan and us-west-2 located in Oregon in the United States.
Each region contains at least two availability zones or AZs. Each AZ is a completely independent data center connected through low-latency, high-speed network links. Independent of region or availability zone, AWS also has edge locations throughout the world. Like places in Osaka, Japan; Milan, Italy; Sao Paulo, Brazil; and South Bend, Indiana. These edge locations power CloudFront, the AWS content delivery network.
The combination of regions, availability zones, and edge locations represent the AWS global infrastructure. AWS is 100% responsible for all security controls of these layers. Riding on top of these layers are AWS's four core service offerings. These offerings consist of compute, database, networking, and storage services. For example, compute includes Elastic Compute Cloud, or EC2, which are virtual servers; the EC2 Container Service for container workloads; Lambda for purely event-driven programing; and Elastic Beanstalk for running and managing web applications.
Storage services include: the Simple Storage Service, or S3, for object storage; EC2 Block Storage, or EBS, for block storage, which you can attach to EC2 instances; Elastic File System Storage, or EFS, for file systems; and Glacier for archival storage. Database services include: Relational Database Services, or RDS, for managed relational databases like MySQL, SQL Server, and Oracle; DynamoDB for a manage NoSQL database; ElastiCache for in-memory caching; and Redshift for data warehousing.
Networking services include Virtual Private Cloud, which lets you create independent isolated virtual networks, think of it as a private data center in the cloud, and Route 53 for domain name services. AWS is responsible for the security of the cloud. That means, the responsibility of securing all the global infrastructure and core services I just described, lies on the shoulders of AWS. This is liberating for you, since physical security controls and their audits can be added to your list of things to not worry about.
That said, what you decide to put in the cloud is another matter, entirely. Most enterprises provide services where application and platform level controls are implemented using identity and access management. These systems rely on appropriate network, firewall, and operating system configurations. The data within these systems can be of varied data classification status, some of which require encryption. And, of course, all enterprises posses valuable data.
The security of what you place and operate within AWS is your responsibility. Let's explore an example. Suppose one of your services is a typical, three-tiered application. Looking at the AWS tools available, you decide to use Route 53 for DNS, CloudFront as your content delivery network, and S3 for storing static resources. You also decide to go with a load-balanced web tier, a load-balanced application tier, and RDS as your database tier.
You draw a pretty diagram, and can breathe easy knowing that the security for the infrastructure of each of these components is the responsibility of AWS. So, what's on your plate? Your responsibility lies in the configuration and patching of the operating systems and software packages you put on the EC2 servers. You're also responsible for security controls for each of the compute, database, and networking components you use. For example, if you use the S3 storage offering, you are responsible for its access controls.
You are also responsible for configuring identity and access management. This is true for administrative access for your Sysops personnel, as well as application access for your end users. Looking ahead, you can focus your attention on securing what you put in the cloud while you can rest easy knowing that Amazon Web Services is maintaining the security of the components that you use.
Sharif Nijim couples pragmatic advice with practical examples that educate organizations on how to create a secure infrastructure within Amazon Web Services. Sharif explores the shared responsibility model of security, which splits duties between your company and AWS, and introduces key identity and access management concepts: users, groups, roles, and policies. At the end of the course, he helps you prepare for the inevitable audit of your AWS account(s).
This course includes trademarks owned by Amazon Web Services. This course has not been prepared, approved, or endorsed by Amazon Web Services.
- The AWS shared responsibility model and security landscape
- Enabling CloudTrail
- Configuring AWS Identity and Access Management (IAM)
- Troubleshooting IAM policies
- Granting temporary access
- Incorporating least privilege
- Controlling access to Simple Storage Service (S3)
- Preparing for security audits
- Getting audit help from Trusted Advisor