1 Introduction to AWS security

This chapter covers

• Understanding the shared responsibility model
• Using AWS-native security services
• Adapting to working in the cloud

The public cloud is growing fast, and AWS is a huge part of that. There seems to be an endless stream of blog posts and whitepapers and case studies about companies moving to AWS. I’m sure you’ve heard the common refrains about high availability, pay-for-use, and rapid development. Of all the reasons we’ve heard for moving to the cloud, the most contentious is security.

Is it really more secure to run your applications on AWS? Some people seem to think so, like Capital One CIO Rob Alexander, who believes they can “operate more securely in the public cloud than we can in our own data centers.” This is particularly powerful coming from a bank, which certainly has a lot of money riding on getting security right. And there are several other banks running workloads on AWS as well, like JPMorgan Chase and National Bank of Canada.

But then, how do we justify this with the constant news of big companies with data breaches on AWS? Among many others in 2021, there were Facebook, Dow Jones, and Uber. These are organizations with highly skilled security teams and talented engineers. Can it really be more secure to run on AWS if even these companies still have issues? I can’t tell you whether running on AWS will be more or less secure than running your own on-premises infrastructure, but I can tell you it’s different. One of the keys to a secure environment on AWS is understanding the differences and what you need to do about them. The sections in this chapter will illustrate some of the major differences and introduce you to the basic concepts of security on AWS.

1.1 The shared responsibility model

Let’s start with the good news about the differences on AWS. If you run an application on AWS’s cloud, they agree to provide a certain level of security under their shared responsibility model. The shared responsibility model is an outline of what AWS provides to you in terms of security and what they expect you to do on your own. Figure 1.1 gives you a rough idea of the responsibility split.

Briefly, the shared responsibility model says that AWS manages security of the cloud, while you are responsible for security in the cloud. Let’s take a look at what that means in practice.

1.1.1 What is AWS responsible for?

What exactly is AWS doing for you? Let’s start with an example. Imagine you have a simple web application like a WordPress site running on an EC2 instance. We’ll first go over some of the things that AWS is doing to secure that application that you might have had to do yourself if you were managing your own servers.

Physical and environmental security

AWS ensures that its datacenters are safe from physical and environmental security risks. Physical access to the machine running your EC2 instance is protected by security staff; even access to the facility is strictly controlled. AWS also manages power backup systems, so your EC2 instance will not shut down in the event of a power failure. Other environmental risks to your application, like a fire or other temperature issues, are monitored by AWS with safeguards in place to prevent one of these events from affecting your host.

Host security

Figure 1.2 shows the basic model of host virtualization that AWS uses for creating the virtual machines used in EC2.

The guest OS in the diagram is your EC2 instance. AWS operates the hardware, the host OS, and the hypervisor, and manages the security of those layers. When you run applications on virtualized hosts, there are two new attack vectors you want to be aware of. The first is an attacker gaining access to the host OS and messing with your guest OS. The second is an attacker with a guest OS on the same machine escaping its virtualized environment and gaining access to yours, often called VM escape. Preventing these kinds of attacks is entirely the responsibility of AWS.

Network security

Let’s say for you want to allow SSH connections only between your EC2 instance and your home IP address for your web application. These controls are possible with VPC security groups, which we’ll discuss later in the book. While it is your responsibility to correctly configure those security groups, it is the responsibility of AWS to ensure that those controls are enforced. Once you create the controls, it is AWS’s job to make sure that no one can initiate an SSH connection to your EC2 instance that did not originate from your IP address. It’s also AWS’s responsibility to ensure the integrity of all the traffic within its network.

Generalizing

The example with EC2 shows how AWS’s responsibility is to secure all of the behind-the-scenes infrastructure, such as the host OS that runs your EC2 instance, and to manage the implementation of the security controls, such as by preventing certain network access to your instance. These kinds of responsibilities apply to the rest of AWS’s services as well. AWS secures the infrastructure that powers its compute, database, storage, and all other kinds of services. It also ensures that the security controls you create in services, like Identity and Access Management (IAM) and Virtual Private Cloud (VPC), are correctly enforced.

Before we start talking about what that leaves for you to secure, I want to point out that all of these things are the responsibility of AWS to secure. They are not guaranteed to be secure. To illustrate the difference, in early 2018, the Spectre and Meltdown speculative execution vulnerabilities were discovered. AWS is responsible for securing the EC2 hypervisors, but they were still vulnerable to that threat at one point. The nature of IT security is that AWS cannot guarantee you will be secure from every possible attack. But the shared responsibility model does mean it is the responsibility of AWS to protect against all of the known attacks and to protect against new attacks as soon as possible, as they did with Spectre and Meltdown.

1.1.2 What are you responsible for?

In short, you are responsible for everything you do in AWS’s cloud. Continuing the example of a web application on EC2, let’s look at a couple of things you are responsible for:

• Configuring access controls—You are responsible for correctly configuring the VPC security group controls mentioned earlier for restricting network access to your instance. You are also responsible for managing programmatic or AWS Console access to the EC2 service through AWS IAM. In addition to creating those controls, you also need to ensure the safety of your credentials.

• Application vulnerability protection—You are responsible for protecting against vulnerabilities in the web application and any other software that runs on your EC2 instance. This ranges from patching outdated software on your host to preventing denial of service attacks on your application to removing security bugs in your web application.

In general, with any AWS service you use, you are going to be responsible for correctly utilizing the security controls offered by AWS as well as the security of any software you run on top of their services.

What does this book cover?

Unfortunately, everything you ought to know to secure your applications doesn’t fit into a single book. For that reason, this book focuses on the aspects that are specific to running on AWS. Earlier, I mentioned you were responsible for protecting against denial of service attacks on your application. This book will show you how you can prevent or mitigate these kinds of attacks with VPC security group controls, network ACLs (access-control lists), or an AWS web application firewall. This book will not cover other techniques for preventing denial of service attacks, like rate limiting, that are not specific to AWS. Table 1.1 below shows some characteristic examples of what is and is not covered in this book.

Table 1.1 Comparison of techniques covered and not covered in this book

Broadly speaking, this book covers security concepts (e.g., vulnerabilities, attacks, and tools) that are specific to, or sufficiently different when, running on AWS.

1.2 Cloud-native security tools

One of the fundamental pieces of securing your AWS resources is controlling who has access to them. AWS has built-in services for managing these access controls, and they are something you will need to familiarize yourself with. The first is IAM. The term identity and access management has a much broader meaning outside of AWS, often referring to all the tools and policies used for controlling access to technical assets. Within AWS and this book, IAM refers to the specific AWS service used for controlling access to AWS services. The other service to be familiar with is VPC. Virtual Private Cloud is a service used for creating isolated virtual networks, allowing you to control the network access to and from your resources, primarily EC2 instances and derivative compute resources.

In addition to access control tools, AWS has a large suite of services dedicated to securing your applications. These services are convenient because they can take advantage of integrations with the services you’re already using and are built specifically for workloads running on AWS. For example, AWS Key Management Service (AWS KMS) integrates with many storage and database services, like S3 and DynamoDB, to provide one-click options to enable encryption at rest. Amazon GuardDuty integrates with CloudTrail to continuously monitor all the activity on your account and alerts you when there is unauthorized or malicious behavior. These tools can help you secure your applications without much additional work.

1.2.1 Identity and access management

If you’ve been using AWS, you’re probably already somewhat familiar with IAM. This section offers a quick overview of IAM and an example of it in practice. Chapters 2 through 4 will expand on IAM, covering the implementation of secure controls and policies for maintaining security, respectively. So let’s start with two of the most basic resources in IAM—the user and the policy:

• User—A user is a representation of a person or application. A person or application can only access AWS services by first authenticating as an IAM user.

• Policy—A policy is a JSON document that describes what actions a user can take within AWS services. For example, a policy might let a user list all of the DynamoDB tables.

We can combine these two resources to start granting access to AWS services. If we create a new IAM user named Alice, then we can attach our policy to that user, and then Alice can list the DynamoDB tables in the account. Let’s try that. First, let’s use the IAM console to create the user. From the IAM console, click on the Users tab and press the Add User button. Fill in the user name, and enable programmatic access, then do not enable AWS management console access. Do not add any groups or tags to the user at this point; we will add permissions separately. Review the settings so far, and create the user. At this point you should see a screen similar to that shown in figure 1.3. Record the access key ID and the secret access key, or download them as a file. Either way, you will not be able to view the secret access key later.

Set up a profile for the Alice user on the AWS CLI, using the access key ID and secret access key from before. See the appendix for instructions on setting up the AWS CLI and profiles.

Now, we can try to list the tables as Alice, using the following command:

$ aws dynamodb list-tables

You should get a response that says something like:

An error occurred (AccessDeniedException) when calling the ListTables operation: 
User: arn:aws:iam::123456789012:user/Alice is not authorized to perform: 
dynamodb:ListTables on resource: arn:aws:dynamodb:us-east-1:123456789012:table/*

We were denied access; this is good. We have not yet added a policy to the Alice user that grants ListTables access. All actions in AWS are denied unless they are explicitly permitted by an IAM policy. Let’s now attach a policy to Alice that grants permission to list all tables. We’ll use the IAM console again to add this policy. In the IAM console, navigate to the Users tab and click on the Alice user. In the permissions tab, click on the Add Inline Policy link. Click on the JSON tab, and copy in the policy from the following listing.

Listing 1.1 A sample IAM policy document

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",                   ①
      "Action": "dynamodb:ListTables",     ②
      "Resource": "*"                      ③
    }
  ]
}

① This policy is allowing permissions.

② The allowed permission is the ListTables method from the DynamoDB service.

③ The ListTables action is not specific to a single resource, so we use * to refer to all resources.

Click to review the policy, and give it a name. Then, click the button to create the policy. Now, we can try to call list-tables again as Alice, and this time it should work. Use the same command again:

$ aws dynamodb list-tables

It works! After adding the policy, we are now able to use the ListTables action. The policy in listing 1.1 allows the user to do this because of the Effect, Action, and Resource values specified. Effect designates whether the policy is allowing or denying permissions. The Action value shows which AWS service call is going to be allowed or denied. In this case, the Action is the ListTables method from the DynamoDB service. The resource field determines which AWS resources this policy applies to. In listing 1.1 the policy applies to all DynamoDB tables.

This example illustrates two of the basic concepts of IAM: users and policies. Securing logical access to your AWS resources through IAM will require you to be very familiar with these concepts as well as others, like roles and managed policies. Chapter 2 will expand on these concepts to show you how to make managing IAM controls easier and more secure.

1.2.2 Virtual private cloud

In this section, we’ll go over the basics of VPCs, and then we’ll use those concepts to configure a bastion host for SSH access to your private EC2 instances.

To understand the components of VPCs, you first need to understand how AWS’s network of datacenters is organized. First, datacenters are grouped into large geographic areas, called regions. One of the largest regions is US-EAST-1, which resides in Northern Virginia. Within regions are availability zones. Availability zones, shortened as AZs, are smaller, isolated collections of datacenters much closer together. Some AWS services operate at the AZ level, like EC2, which lets you pick which AZ to run your instance in. Other services run at the region level, like S3, letting you select in which region to store your objects. And lastly, some services are global, like IAM, with resources that are shared across all regions and AZs. The main reason for organizing it this way, as you might be able to guess from the name, is for high availability of AWS’s services. While failure of an entire datacenter is unlikely, failure of an entire AZ is even less likely, and failure of an entire region that much more improbable. Services that operate at the region and AZ levels allow you to architect your own applications for high availability, using the same concepts. For a visualization of these concepts, see figure 1.4.

Now, back to VPCs. A VPC is a private network you can create that exists within a region. A VPC allows you to create secure network connections between AWS resources and other network resources you want to connect to, while blocking access to anything you don’t. There are various tools used to define what connections are permitted in and out of a VPC and between resources within the VPC. The primary native tools are security groups and network access control lists. We’ll explore both of these concepts later, but for right now we’ll focus on security groups. A security group is a stateful firewall that allows you to define a set of inbound and outbound rules for allowed connections. All other connections not specified will be denied. You can then apply those security group rules to an EC2 instance in a VPC by associating the instance with the security group.

The last fundamental resource in a VPC is the subnet. Subnets are the component subnetworks that make up a VPC. An individual subnet is assigned a block of the IP range specified in the VPC and exists within an availability zone. EC2 instances and other resources cannot be put directly into a VPC; rather, they are added to one of the subnets within a VPC. There are two different types of subnets: public and private. Public subnets have routes to an internet gateway, which means that they can communicate with the public internet outside of the VPC. Private subnets have no such route to the public internet. See figure 1.5, which shows a basic configuration of these resources.

Let’s see how we can use this information to secure access to some of our private EC2 instances. Imagine we have an internal application that runs on an EC2 instance. Suppose everything runs on this EC2 instance, and the application doesn’t need any network connections to function. We can put this instance inside its own subnet and VPC with a security group that doesn’t allow any connections. This will ensure no one can access our instance. The network architecture for this application would look like figure 1.6.

We can use the CloudFormation template in listing 1.2 to create all of these resources in the N. Virginia (US-EAST-1) region. The template requires an existing SSH key pair for EC2. If you don’t have one, see the appendix for instructions on setting up a new key pair to connect to an EC2 instance.

Listing 1.2 CloudFormation template for private application with no network connections

---
AWSTemplateFormatVersion: 2010-09-09
Resources:
  VPC:                                     ①
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 172.16.0.0/16             ②
      EnableDnsHostnames: true
  
  PrivateSubnet:                           ③
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC                      ④
      CidrBlock: 172.16.0.0/24             ⑤
      AvailabilityZone: us-east-1a         ⑥
 
  ApplicationSecurityGroup:                ⑦
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: For Sample Internal Application
      VpcId: !Ref VPC                      ⑧
 
  ApplicationInstance:                     ⑨
    Type: AWS::EC2::Instance
    Properties:
      ImageId: ami-0dc2d3e4c0f9ebd18       ⑩
      KeyName: mykeypair
      SubnetId: !Ref PrivateSubnet         ⑪
      SecurityGroupIds:
      - !Ref ApplicationSecurityGroup      ⑫

① Creates a VPC

② VPCs have fixed CIDR blocks, which define the range of IP addresses in the VPC.

③ Creates a subnet

④ Associates the VPC and the subnet. Subnets are contained within VPCs.

⑤ Subnets also have CIDR blocks, which must be nonoverlapping subsets of the VPC block.

⑥ Subnets exist within a single availability zone.

⑦ Creates a security group

⑧ Security groups are specific to a VPC.

⑨ Creates an EC2 instance

⑩ This is the ID for the Amazon Linux 2 image in US-EAST-1.

⑪ Puts the EC2 instance in the private subnet

⑫ Applies the application security group rules to this EC2 instance

That template created our EC2 instance, a VPC, a private Subnet in the US-EAST-1A availability zone, and a security group that does not permit any inbound network access. But now imagine that we need SSH access to our host to debug our application. One option would be to open up a route to the public internet and allow inbound SSH connections to our host, although this would effectively make the subnet public. A more secure alternative is to create a new bastion host that is open to the public internet and also has private access within the VPC to our private host. Then, to get to our private host we first SSH into the bastion host, and then from there, we can SSH into the private host. The network architecture for this solution looks like figure 1.7.

There are several new pieces to this diagram. The first is the public subnet that consists of a subnet, an internet gateway, and a route between them. Then, we have a new host in the public subnet, which will be the bastion. The last new pieces are the new rules for the security groups that allow access between the two hosts and from the bastion to the public internet. We can combine the template in listing 1.3 with our original application CloudFormation template to add all of these resources.

Listing 1.3 CloudFormation template for remaining resources

---
InternetGateway:                                                  ①
  Type: AWS::EC2::InternetGateway
 
VPCGatewayAttachment:                                             ②
  Type: AWS::EC2::VPCGatewayAttachment
  Properties:
    VpcId: !Ref VPC
    InternetGatewayId: !Ref InternetGateway
 
PublicSubnet:                                                     ③
  Type: AWS::EC2::Subnet
  Properties:
    AvailabilityZone: us-east-1a
    VpcId: !Ref VPC
    CidrBlock: 172.16.1.0/24
    MapPublicIpOnLaunch: true                                     ④
 
RouteTable:                                                       ⑤
  Type: AWS::EC2::RouteTable
  Properties:
    VpcId: !Ref VPC
 
InternetRoute:                                                    ⑥
  Type: AWS::EC2::Route
  DependsOn: VPCGatewayAttachment
  Properties:
    DestinationCidrBlock: 0.0.0.0/0
    GatewayId: !Ref InternetGateway
    RouteTableId: !Ref RouteTable
 
RouteTableAssociation:
  Type: AWS::EC2::SubnetRouteTableAssociation
  Properties: 
    RouteTableId: !Ref RouteTable
    SubnetId: !Ref PublicSubnet
 
BastionSecurityGroup:                                             ⑦
  Type: AWS::EC2::SecurityGroup
  Properties:
    GroupDescription: For Bastion Host
    VpcId: !Ref VPC
 
BastionInstance:                                                  ⑧
  Type: AWS::EC2::Instance
  Properties:
    ImageId: ami-79fd7eee
    KeyName: mykeypair
    SubnetId: !Ref PublicSubnet
    SecurityGroupIds: !Ref BastionSecurityGroup
 
ApplicationAllowInboundSSHFromBastion:
  Type: AWS::EC2::SecurityGroupIngress                            ⑨
  Properties:
    GroupId: !Ref ApplicationSecurityGroup                        ⑩
    IpProtocol: tcp                                               ⑩
    FromPort: 22                                                  ⑩
    ToPort: 22                                                    ⑩
    SourceSecurityGroupId: !Ref BastionSecurityGroup              ⑩
 
BastionAllowInboundSSHFromInternet:
  Type: AWS::EC2::SecurityGroupIngress
  Properties:
    GroupId: !Ref BastionSecurityGroup                            ⑪
    IpProtocol: tcp                                               ⑪
    FromPort: 22                                                  ⑪
    ToPort: 22                                                    ⑪
    CidrIp: 0.0.0.0/0                                             ⑪
 
BastionAllowOutboundSSHToApplication:
  Type: AWS::EC2::SecurityGroupEgress                             ⑫
  Properties:
    GroupId: !Ref BastionSecurityGroup                            ⑬
    IpProtocol: tcp                                               ⑬
    FromPort: 22                                                  ⑬
    ToPort: 22                                                    ⑬
    DestinationSecurityGroupId: !Ref ApplicationSecurityGroup     ⑬

① Creates an internet gateway needed for creating a public subnet

② Adds the internet gateway to the VPC

③ Creates a subnet capable of networking with the public internet

④ If set, this property attaches public IP addresses to EC2 instances in this subnet.

⑤ Container for routes—needed for creating a public subnet

⑥ Creates a route between the public subnet and the internet gateway

⑦ Creates a security group for the bastion host

⑧ Creates the bastion host

⑨ SecurityGroupIngress rules define allowed inbound connections to a security group.

⑩ Allows inbound SSH connections to the application SG from the bastion SG

⑪ Allows inbound SSH connections to the bastion SG from anywhere

⑫ SecurityGroupEgress rules define allowed outbound connections from a security group.

⑬ Allows outbound SSH connections from the bastion SG to the application SG

Now, we are able to SSH into the bastion host and from there SSH into our private application host. You can see from this example how configuring VPC network controls can get very complicated. Even this situation that only requires SSH access between two hosts requires creating 14 different resources. It’s especially important to understand these controls, so mistakes are not made that open up security vulnerabilities. Or worse, as I’ve seen from many applications in the past, frustration kicks in after numerous attempts to connect two hosts, and overly permissive controls are applied just to get things working. Chapters 5 and 6 are dedicated to helping you navigate these network access controls, so you can have frustration-free, secure networks.

1.2.3 And many more

There are many other native tools in AWS made to help you keep your applications secure. Table 1.2 shows the rest of the security services within AWS and a brief overview of what they do.

Table 1.2 Summary of security services on AWS

In addition to the AWS security services, there is also a large ecosystem of third-party security services for AWS applications. Many of these can be installed through the AWS Marketplace. These include next-gen firewalls, benchmarks, security benchmarks, vulnerability scanners, and more.

1.3 A new way of operating

A major difference between security in the cloud and on-prem security is that we operate our infrastructure in new and different ways than were common, or even possible, in traditional on-prem settings. We need to adapt our security operations to match this. The first operational change in the cloud is the speed of infrastructure development. When operating in AWS, we have the ability to spin up new infrastructure on demand, and it can be as easy as a couple of clicks in the AWS Console. We need new security tools and automation to handle these rapidly changing environments. Another major change is that, often, fewer people are needed to manage large applications in the cloud. Cloud services give development teams leverage to achieve more with these smaller teams, but they also introduce a shift in responsibility as software engineers find themselves in charge of more of the security of their applications, and there may be fewer security engineers to go around. This shift in responsibility coincides with the DevSecOps (developer-security-operations) movement, which puts more of the security responsibility in the hands of the developers and focuses on putting security in the software development lifecycle (SDLC).

1.3.1 Speed of infrastructure development

One of the ways we operate differently in the cloud is by changing infrastructure rapidly. We can spin one EC2 instance (or ten or a thousand) up or down almost immediately. We can automatically scale up resources and applications based on traffic patterns. These features of AWS make managing infrastructure easier, but they introduce new security concerns. For example, imagine if you had to look at application logs on each of your hosts. If you always had the same three servers, you could probably just save the SSH or RDP credentials and log in to the machines when you need to check the logs. But this situation changes significantly when our application is running as part of an EC2 Auto Scaling group. At any given time we might not even know how many EC2 instances we have running. And the ones that are running today might not be the same ones that were running yesterday.

To make this situation manageable, we need to use some new tools. We need a tool to identify all of the EC2 instances we have running, such as the AWS SDK for EC2. We need a tool for managing the credentials we use for logging into these instances, such as AWS Secrets Manager. We could also use a tool to centralize all of our application logs, so we don’t have to look at each individual EC2 instance. We could use a service like AWS CloudWatch Logs for that. Overall, when we start changing infrastructure quickly, we need to develop new security measures to keep up.

1.3.2 Shifting responsibilities

The other change in the way we operate is that software engineers are in charge of more of the infrastructure. Managed services from AWS often eliminate the need to hire specialists and IT operations teams for provisioning and maintaining the infrastructure. For example, an organization may have previously needed a database administrator to obtain, set up, scale, and manage a relational database server. With AWS Aurora, a developer can create a database in a few clicks or lines of code, and the rest is handled by AWS. Developers can take ownership of infrastructure like this that they wouldn’t have previously. This is in line with the DevOps philosophy of combining the development and IT operations work. But the blurred line between development and operations and the change of ownership of infrastructure bring into question who is responsible for ensuring the security of that infrastructure. The most common answer is that it moves from the operations staff to developers or is shared between them. This is the philosophy behind DevSecOps. However, this can be difficult for developers who haven’t worked on securing infrastructure in the past or haven’t been trained on it. If you’re in this position, you’ve come to the right place. This book walks you through the things you’ll need to know to secure common architectures on AWS.

1.4 Conclusion

This chapter introduced some of the foundations of AWS security and what makes it different from security in other environments. Running your applications on AWS is fundamentally different in many ways, and it is important to take that into account when assessing your security posture.

In this chapter we looked at the shared responsibility model and what it means for you. When you run applications on AWS, there are certain aspects of security you are responsible for and others that AWS takes care of. In general, AWS ensures that the services it provides you with are secure, while you handle the security of everything you do with those services.

We also looked at the native security services built into AWS. Identity and Access Management is the tool for managing access to AWS resources and services. With IAM we saw how users and policies can be used to create fine-grained access controls. For controlling access to networks, we looked at Virtual Private Clouds. VPC and its associated resources, like subnets and security groups, are powerful tools that allow you to restrict network traffic to only what is necessary. There are is a wide range of other security services that can help you protect your applications, such as Amazon Inspector, and alert you to vulnerabilities on your EC2 instances.

Finally, we looked at how teams change operationally when running on AWS and how that impacts security. Many services in AWS are designed to make it easy to build your cloud infrastructure. But we need to be mindful that we’re still maintaining the security of that infrastructure. Often, this calls for new security automation that can keep up with quickly changing infrastructure or using native security tools that are built for this environment. In addition, the cloud tends to push us toward a philosophy of DevSecOps, in which developers inherit more responsibility for the security of the infrastructure. For this reason, it is critical that developers are aware of common threats to cloud applications and how to protect against them.

Additionally, because of the rapidly changing infrastructure, the responsibility of security often shifts outside of dedicated security teams. For this reason, it’s critical for everyone that works with cloud infrastructure to be aware of common threats to cloud applications and how to protect against them.

Summary

• AWS handles the security of all of the infrastructure that runs the services you use. This is security of the cloud.

• The security of everything you run on AWS services is your responsibility. This is security in the cloud.

• IAM is the service used to manage logical access to AWS services. IAM users represent the people and programs that access AWS, and IAM policies are a way of defining permitted actions.

• VPC is the service used to manage network access to your resources. VPCs, subnets, and security groups are used together to configure the allowed network connections to your cloud infrastructure.

• AWS provides a large number of services to help you conveniently manage security.

• Infrastructure changes quickly in the cloud. To keep up, security processes must be automated, typically with cloud-native tools.

• Expertise in cloud security is more important for developers, as they find themselves owning more of the infrastructure.