In this chapter, we will learn about security in AWS cloud. We will learn about security processes in place to secure all workloads deployed in AWS environment. We will begin by exploring AWS shared security responsibility model, a primer for all thing security in AWS. To secure anything, we first need to know who is responsible for security. We will deep dive into this fundamental principle of AWS Security to know about security responsibilities of AWS and users of AWS services for various models that AWS offers to all its customers.

Moving on, we will go through AWS Security responsibilities in detail across multiple verticals such as physical security, network security, and so on. We will also go through various processes AWS has put in place to ensure business continuity and seamless communication in event of an incident. Alongside, we will walk through customer security responsibilities for all workloads deployed in AWS cloud. This will include things such as protecting credentials, data security, access control, and so on.

Furthermore, we will go through security features of your AWS account.

Next, we will go through overview of all security services and features provided by AWS such as KMS, CloudWatch, Shield, CloudTrail, penetration testing, and so on.

Lastly, we will go through various resources available in AWS for learning more about these security services and features. These resources include AWS documentation, white papers, blogs, tutorials, solutions, and so on.

AWS and cloud in general have evolved considerably from the time when security in cloud was seen as an impediment to moving your data, applications, and workload to cloud to today when security in cloud is one of the major reasons organizations are moving from data centers to cloud. More and more executives, decision makers, and key stakeholders are vouching that security in cloud is further ahead, and more reliable and economical than security in on-premise data centers. These executives and decision makers are from multiple geographies, and various industries with stringent security requirements and regulatory compliance such as Department of Defense, Banking, Health Care, Payment Card Industry, and so on, and belong to all levels such as CIO, CTO, CEO, CISO, System Administrators, Project Managers, Developers, Security Analysts, and so on.

As a result, cloud adoption rate has been rapidly increasing for the past few years across the globe and across industries. This trend is led by large enterprises where security plays a pivotal role in deciding if an enterprise should move to the cloud or not. AWS provides fully integrated and unified security solutions for its cloud services that enables its customers to migrate their workloads to cloud. Let us look at some predictions for the exponential growth of Cloud Computing by industry leaders:

• Gartner says that by 2020, a corporate no-cloud policy will be as rare as the no-internet policy today.
• Global Cloud Index (GCI) forecasts that cloud will account for 92% of the data center by 2020, meaning 92% of all data and computing resources will be using cloud by 2020.
• International Data Corporation (IDC) says that today's cloud first strategy is already moving the towards cloud.

AWS is architected to be one of the most flexible and secure cloud environments. It removes most of the security burdens that are traditionally associated with IT infrastructure. AWS ensures complete customer privacy and segregation of customer resources and has scores of built-in security features. Moreover, every customer benefits from the security processes, global infrastructure and network architecture put in place by AWS to comply with stringent security and compliance requirements by thousands of customers across the globe from scores of industries.

As more and more organizations move towards cloud, security in cloud has been more of a paradigm shift for many. Even though for the most part, security that is provided in cloud has most of the same functionalities as security in traditional IT, such as protecting information from theft, data leakage, and deletion.

However, security in the cloud is in fact slightly different to security in an on-premises data center. When you move servers, data and workload to AWS cloud, responsibilities are shared between you and AWS for securing your data and workload. AWS is responsible for securing the underlying infrastructure that supports the cloud through its global network of regions, availability zones, edge locations, end points, and so on, and customers are responsible for anything they put on the cloud such as their data, their application, or anything that they connect to the cloud such as the servers in their data centers. They are also responsible for providing access to their virtual network and resources in cloud, this model is known as AWS shared security responsibility model.

The following figure depicts this model:

In order to master AWS Security, it is imperative for us to identify and understand AWS' share of security responsibilities as well as our share of security responsibilities before we start implementing them. AWS offers a host of different services that can be distributed in three broad categories: infrastructure, container, and abstracted services. Each of these categories has its own security ownership model based on how end users interact with it and how the functionality is accessed:

• Infrastructure Services: This category includes compute services such as Amazon Elastic Cloud Compute (EC2) and associated services, such as Amazon Elastic Block Store (EBS), Elastic Load Balancing, and Amazon Virtual Private Cloud (VPC). These services let you design and build your own secure and private network on cloud with infrastructure similar to your on-premises solutions. This network in AWS cloud is also compatible and can be integrated with your on-premises network. You control the operating system, configure the firewall rules and operate any identity management system that provides access to the user layer of the virtualization stack.

• Container Services: There are certain AWS services that run on separate Amazon EC2 or other infrastructure instances but at times you don’t manage the operating system or the platform layer. AWS offers these services in a managed services model for these application containers. You are responsible for configuring firewall rules, allowing access to your users and systems for these services using AWS Identity and Access Management (IAM) among other things. These services include AWS Elastic Beanstalk, Amazon Elastic Map Reduce (EMR) and Amazon Relational Database Services (RDS).

• Abstracted Services: These are AWS services that abstract the platform or management layer. These are messaging, email, NoSQL database, and storage services on which you can build and operate cloud applications. These services are accessed through endpoints by using AWS APIs. AWS manages the underlying service components or the operating system on which they reside. You share the underlying infrastructure that AWS provides for these abstracted services. These services provide a multi-tenant platform which isolates your data from other users. These services are integrated with AWS IAM for secure access and usage. These services include Simple Queue Service, Amazon DynamoDB, SNS, Amazon Simple Storage Service (S3), and so on.

Let us look at these 3 categories in detail along with their shared security responsibility models:

AWS global infrastructure powers AWS infrastructure services such as Amazon EC2, Amazon VPC and Amazon Elastic Block Storage (EBS). These are regional services; that is, they operate within the region where they have been launched. They have different durability and availability objectives. However, it is possible to build systems exceeding availability objectives of individual services from AWS. AWS provides multiple options to use various resilient components in multiple availability zones inside a region to design highly available systems.

The following figure shows this model:

Building on the AWS secure global infrastructure, similar to your on-premises data centers, you will install, configure, and manage your operating systems and platforms in the AWS cloud. Once you have your platform, you will use it to install your applications and then you will store your data on that platform. You will configure the security of your data such as encryption in transit and at rest. You are responsible for managing how your applications and end users consume this data. If your business requires more layers of protection due to compliance or other regulatory requirements, you can always add it on top of those provided by AWS global infrastructure security layers.

These layers of protection might include securing data at rest by using encryption, or securing data in transit or by introducing additional layer of opacity between AWS services and your platform. This layer could includes secure time stamping, temporary security credentials, data encryption, software and passing digital signature in your API requests and so on.

AWS provides tools and technologies that can be used to protect your data at rest and in transit. We'll take a detailed look at these technologies in Chapter 4, Data Security in AWS.

When you launch a new Amazon Elastic Cloud Compute (EC2) instance from a standard Amazon Machine Image (AMI), you can access it using the secure remote system access protocols, such as Secure Shell (SSH) for a Linux instance or Windows Remote Desktop Protocol (RDP) for a Windows instance. To configure your EC2 instance as per your requirements and to access it, you are required to authenticate at the operating-system level. Once you have authenticated at the operating system level, you'll have secure remote access to the Amazon EC2 instance. You can then set up multiple methods to authenticate operating systems such as Microsoft Active Directory, X.509 certificate authentication, or local operating system accounts.

AWS provides Amazon EC2 key pairs that consist of two different keys, a public key and a private key. These RSA key pairs are the industry standard and used for authentication to access your EC2 instance. When you launch a new EC2 instance, you get an option to either create a new key pair or use an existing key pair. There is a third option available as well to proceed without a key pair, but that is not recommended for securing access to your EC2 instance. The following figure 3 shows the EC2 key pairs option while launching an EC2 instance. You can create as many as 5000 key pairs for your EC2 instances in your AWS account. EC2 key pairs are used only for accessing your EC2 instances and cannot be used to login to AWS Management Console or to use other AWS services. Moreover, users can use different key pairs to access different EC2 instances:

You can either have AWS generate the EC2 key pairs for you, or you can generate your own Amazon EC2 key pairs using industry standard tools like OpenSSL. When you choose the first option, AWS provides you with both the public and private key of the RSA key pair when you launch the instance. You need to securely store the private key; if it is lost you can't restore it from AWS, and you will then have to generate a new key pair.

When you launch a new Linux EC2 instance using a standard AWS AMI, the public key of the Amazon EC2 key pair that is stored within AWS is appended to the initial operating system user’s ~/.ssh/authorized_keys file. You can use an SSH client to connect to this EC2 Linux instance by configuring the SSH client to use the EC2's username such as ec2-user and by using the private key for authorizing a user.

When you launch a new Windows EC2 instance using the ec2config service from a standard AWS AMI, the ec2config service sets a new random administrator password for this Windows instance and encrypts it using the corresponding Amazon EC2 key pair’s public key. You will use the private key to decrypt the default administrator's password. This password will be used for user authentication on the Windows instance.

Although AWS provides plenty of flexible and practical tools for managing Amazon EC2 keys and authentication for accessing EC2 instances, if you require higher security due to your business requirements or regulatory compliance, you can always implement other authentication mechanisms such as Lightweight Directory Access Protocol (LDAP) and disable the Amazon EC2 key pair authentication.

The AWS shared responsibility model is applicable to container services as well, such as Amazon EMR and Amazon RDS. For these services, AWS manages the operating system, underlying infrastructure, application platform, and foundation services. For example, Amazon RDS for Microsoft SQL server is a managed database service where AWS manages all the layers of the container including the Microsoft SQL server database platform. Even though AWS platform provides data backup and recovery tools for services such as Amazon RDS, it is your responsibility to plan, configure and use tools to prepare for your high availability (HA), fault tolerance (FT), business continuity and disaster recovery (BCDR) strategy.

You are responsible for securing your data, for providing access to your data and for configuring firewall rules to access these container services. Examples of firewall rules include RDS security groups for Amazon RDS and EC2 security groups for Amazon EMR.

The following figure shows this model for container services:

AWS offers abstracted services such as Amazon DynamoDB and Amazon Simple Queue Service, Amazon S3, and so on, where you can access endpoints of these services for storing, modifying and retrieving data. AWS is responsible for managing these services, that is, operating the infrastructure layer, installing and updating the operating system and managing platforms as well. These services are tightly integrated with IAM so you can decide who can access your data stored in these services.

You are also responsible for classifying your data and using service-specific tools for configuring permissions at the platform level for individual resources. By using IAM, you can also configure permissions based on role, user identity or user groups. Amazon S3 provides you with encryption of data at rest at the platform level, and, for data in transit, it provides HTTPS encapsulation through signing API requests.

The following figure shows this model for abstracted services:

AWS is responsible for securing the global infrastructure that includes regions, availability zones and edge locations running on the AWS cloud. These availability zones host multiple data centers that house hardware, software, networking, and other resources that run AWS services. Securing this infrastructure is AWS’s number one priority and AWS is regularly audited by reputed agencies all over the world to meet necessary security and compliance standard requirements. These audit reports are available to customers from AWS as customers can't visit AWS data centers in person.

The following figure depicts the broader areas of security that fall under AWS' responsibility:

Customer data and workloads are stored in AWS data centers, these data centers are spread across geographical regions all over world. These data centers are owned, operated and controlled by AWS. This control includes physical access and entry to these data centers and all networking components and hardware, and all other additional data centers that are part of AWS global infrastructure.

Let us take a closer look at other responsibilities that AWS owns for securing its global infrastructure:

So, the very first thought that would strike anybody considering moving their workload to cloud is where is my data actually stored? Where are those physical servers and hard drives located that I provisioned using AWS cloud? And how are those hardware resources secured and who secures them? After all cloud simply virtualizes all resources available in a data center but those resources are present somewhere physically. So, the good news is AWS is completely responsible for physical and environmental security of all hardware resources located in its data centers across the globe.

AWS has years of experience in building, managing, and securing large data centers across the globe through its parent company Amazon. AWS ensures that all of its data centers are secured using the best technology and processes such as housing them in nondescript facilities, following least privilege policy, video surveillance, two-factor authentication for entering data centers and floors.

Personnel are not allowed on data center floors unless they have a requirement to access a physical data storage device in person. Moreover, AWS firmly implements segregation of responsibilities principle, so any personnel having access to the physical device won't have the root user access for that device so he can't access data on that physical device.

This is a very critical part of a shared security responsibility model where AWS does all the heavy lifting instead of you worrying about the physical and environmental security of your data centers. You do not have to worry about monitoring, theft, intrusion, fire, natural calamities, power failure, and so on for your data centers. These things are taken care of by AWS on your behalf and they constantly upgrade their security procedures to keep up with increasing threats.

AWS will initiate a decommissioning process when a storage device has reached the end of its useful life. This process ensures that customer data is not exposed to unauthorized individuals. This hardware device will be physically destroyed or degaussed if it fails decommissioning using the standard process followed by AWS.

AWS keeps your data and other resources in the data centers in various geographical locations across the globe; these locations are known as regions. Each region has two or more availability zones for high availability and fault tolerance. These availability zones are made up of one or more data centers. All of these data centers are in use and none are kept offline; that is, there aren't any cold data centers. These data centers house all the physical hardware resources such as servers, storage, and networking devices, and so on, that are required to keep all the AWS services up and running as per the service level agreement provided by AWS. All AWS core applications such as compute, storage, databases, networking are deployed in an N+1 configuration, so that, in the event of a data center failure due to natural calamity, human error or any other unforeseen circumstance, there is sufficient capacity to load-balance traffic to the remaining sites.

Each availability zone is designed as an independent failure zone so that the impact of failure is minimum and failure can be contained by other availability zone(s) in that region. They are physically separated within a geographical location and are situated in the lower risk flood plains.

Depending on the nature of your business, regulatory compliance, performance requirements, disaster recovery, fault tolerance, and so on, you might decide to design your applications to be distributed across multiple regions so that they are available even if a region is unavailable.

The following figure demonstrates typical regions with their availability zones:

AWS employs multiple methods of external and internal communication to keep their customers and global AWS communities updated about all the necessary security events that might impact any AWS service. There are several processes in place to notify the customer support team about operational issues impacting customer experience globally, regionally or for a particular AWS service. AWS provides a Service Health Dashboard at https://status.aws.amazon.com that provides updates about all AWS services.

It also has an option to notify AWS about any issue customers are facing with any AWS service. The AWS Security center is available to provide you with security and compliance details about AWS. There are 4 support plans available at AWS:

• Basic
• Developer
• Business
• Enterprise

These support plans give you various levels of interaction capabilities with AWS support teams such as AWS technical support, health status and notifications, and so on. However, 24/7 access to customer service and communities is available to all AWS customers irrespective of the support plan subscription.

The following figure shows the AWS Service Health Dashboard for all North America, you can also get information for service health in other geographies such as Asia Pacific, Europe, and so on:

The AWS network has been architected to allow you to configure the appropriate levels of security for your business, your workload, and your regulatory compliance requirements. It enables you to build geographically dispersed, highly available, and fault-tolerant web architectures with a host of cloud resources that are managed and monitored by AWS.

AWS has network devices such as a firewall to monitor and control communications at the external and key internal boundaries of the network. These network devices use configurations, access control lists (ACL) and rule sets to enforce the flow of information to specific information system services. Traffic flow policies or ACLs are established on each managed interface that enforces and manage traffic flow. These policies are approved by Amazon information security. An ACL management tool is used to automatically push these policies, to help ensure these managed interfaces enforce the most up-to-date ACLs.

AWS monitors network traffic and inbound and outbound communications through strategically placed access points in the cloud; these access points are also known as API endpoints. They allow secure HTTP access (HTTPS) through API signing process in AWS, allowing you to establish a secure communication session with your compute instances or storage resources within AWS.

You can connect to an AWS access point through HTTP or HTTPS using Secure Sockets Layer (SSL). AWS provides customers with VPC, their own virtual network in cloud dedicated to the customer's AWS account. VPC is helpful for customers who require additional layers of network security. VPC allows communication with customer data centers through an encrypted tunnel using an IPsec Virtual Private Network (VPN) device.

AWS ensures a high level of service performance and availability by employing multiple automated monitoring systems. These tools monitor unauthorized intrusion attempts, server and network usage, application usage, and port scanning activities. AWS monitoring tools watch over ingress and egress communication points to detect conditions and unusual or unauthorized activities. Alarms go off automatically when thresholds are breached on key operational metrics to notify operations and management personnel. To handle any operational issues, AWS has trained call leaders to facilitate communication and progress during such events collaboratively. AWS convenes post operational issues that are significant in nature, irrespective of external impact, and Cause of Error (COE) documents are created so that preventive actions are taken in future, based on the root cause of the issue.

The AWS production network is logically segregated from the Amazon corporate network and requires a separate set of credentials. It uses a complex set of network segregation and security devices for isolating these two networks. All AWS developers and administrators who need to access AWS cloud components for maintenance are required to raise a ticket for accessing AWS production network. In order to access the production network, Kerberos, user IDs, and passwords are required by Amazon corporate network. The AWS production network uses a different protocol; this network mandates the usage of SSH public-key authentication through a computer in a public domain often known as bastion host or jump box for AWS developers and administrators.

AWS Security has established a credentials policy with the required configurations and expiration intervals. Passwords are regularly rotated once every 90 days and they are required to be complex.

AWS shares security responsibilities with customers for all its offerings. Essentially, the customer is responsible for security of everything that they decide to put in cloud such as data, applications, resources, and so on. So network protection and instance protection for IaaS services and database protection for container services are areas that fall under customer security responsibilities. Let us look at customer security responsibilities for these three categories:

For AWS infrastructure services, the customer is responsible for the following:

• Customer data
• Customer application
• Operating system
• Network and firewall configuration
• Customer identity and access management
• Instance management
• Data protection (transit, rest, and backup)
• Ensuring high availability and auto scaling resources

For AWS container services, the customer is responsible for the following:

• Customer data
• Network VPC and firewall configuration
• Customer identity and access management (DB users and table permissions)
• Ensuring high availability
• Data protection (transit, rest, and backup)
• Auto scaling resources

For AWS abstract services, the customer is responsible for the following:

• Customer data
• Securing data at rest using your own encryption
• Customer identity and access management

So essentially when we move from AWS infrastructure services towards AWS abstract services, customer security responsibility is limited to configuration, and operational security is handled by AWS. Moreover, AWS infrastructure services gives you many more options to integrate with on-premises security tools than AWS abstract services.

All AWS products that are offered as IaaS such as Amazon EC2, Amazon S3, and Amazon VPC are completely under customer control. These services require the customer to configure security parameters for accessing these resources and performing management tasks. For example, for EC2 instances, the customer is responsible for management of the guest operating system including updates and security patches, installation and maintenance of any application software or utilities on the instances, and security group (firewall at the instance level, provided by AWS) configuration for each instance. These are essentially the same security tasks that the customer performs no matter where their servers are located. The following figure depicts customer responsibilities for the AWS shared security responsibilities model:

AWS provides a plethora of security services and tools to secure practically any workloads, but the customer has to actually implement the necessary defenses using those security services and tools.

At the top of the stack lies customer data. AWS recommends that you utilize appropriate safeguards such as encryption to protect data in transit and at rest. Safeguards also include fine-grained access controls to objects, creating and controlling the encryption keys used to encrypt your data, selecting appropriate encryption or tokenization methods, integrity validation, and appropriate retention of data. Customer chooses where to place their data in cloud, meaning they choose geographical location to store their data in cloud. In AWS, this geographical location is known as region, so customer has to choose an AWS region to store their data. Customers are also responsible for securing access to this data. Data is neither replicated to another AWS Region nor moved to other AWS Region unless customer decides to do it. Essentially, customers always own their data and they have full control over encrypting it, storing it at a desired geographical location, moving it to another geographical location or deleting it.

For AWS container services such as Amazon RDS, the customer doesn't need to worry about managing the infrastructure, patch update or installation of any application software. The customer is responsible for securing access to these services using Amazon IAM. The customer is also responsible for enabling Multi-Factor Authentication (MFA) for securing their AWS account access.

As a customer, you get to decide on security controls that you want to put in place based on the sensitivity of your data and applications. You have complete ownership of your data. You get to choose from a host of tools and services available across networking, encryption, identity and access management, and compliance.

The following table shows a high-level classification of security responsibilities for AWS and the customer:

Now that we are clear with the shared security responsibilities model, let us deep dive into the resources provided by AWS to secure your AWS account and resources inside your AWS account from unauthorized use. AWS gives you a host of tools for securing your account such as MFA, several options for credentials that can be used to access AWS services and accounts for multiple use cases, secure endpoints to communicate with AWS services, centralized logging service for collecting, storing and analyzing logs generated for all user activities in your AWS account by your resources in your AWS account and logs from all your applications running in your AWS account. Along with these features, you also have AWS Trusted Advisor that performs security checks for all AWS services in your AWS account. All of these tools are generic in nature and they are not tied to any specific service; they can be used with multiple services.

This is the account that you create when you first sign up for AWS. It is also known as a root account in AWS terminology. This root account has a username as your email address and password that you use with this username. These credentials are used to log into your AWS account through the AWS Management Console, a web application to manage your AWS resources. This root account has administrator access for all AWS services, hence AWS does not recommend using root account credentials for day-to-day interactions with AWS; instead, they recommend creating another user with the required privileges to perform those activities. In some cases, your organization might decide to use multiple AWS accounts, one for each department or entity for example, and then create IAM users within each of the AWS accounts for the appropriate people and resources.

Let us look at the following scenarios for choosing strategies for AWS account creation:

Having multiple AWS accounts also helps in decreasing your blast radius and reducing your disaster recovery time. So if there is something wrong with one AWS account, the impact will be minimal on running business operations, as other accounts will be working as usual along with their resources. Having multiple AWS accounts also increases security by segregating your resources across accounts based on the principle of least privilege.

AWS uses several types of credentials for authentication and authorization as follows:

• Passwords
• Multi-factor authentication
• Access keys
• Key pairs
• X.509 certificates

We will have a detailed look at these credentials in Chapter 2, AWS Identity and Access Management.

AWS provides a centralized web service called AWS IAM for creating and managing individual users within your AWS Account. These users are global entities. They can access their AWS account through the command line interface (CLI), through SDK or API, or through the management console using their credentials. We are going to have a detailed look at IAM in the next chapter.

AWS provides API endpoints as a mechanism to securely communicate with their services; for example, https://dynamodb.us-east-1.amazonaws.com is an API endpoint for AWS DynamoDB (AWS NoSQL service) for us-east-1 (Northern Virginia) region. These API endpoints are URLs that are entry points for an AWS web service. API endpoints are secure customer access points to employ secure HTTPS communication sessions for enabling better security while communicating with AWS services. HTTPS uses Secure Socket Layer (SSL) / Transport Layer Security (TLS) cryptographic protocol that helps prevent forgery, tampering and eavesdropping. The identity of communication parties is authenticated using public key cryptography.

Logging is one of the most important security feature of AWS. It helps with auditing, governance and compliance in cloud. AWS provides you with AWS CloudTrail that logs all events within your account, along with the source of that event at 5 minute interval, once it is enabled. It provides you with information such as the source of the request, the AWS service, and all actions performed for a particular event.

AWS CloudTrail logs all API calls such as calls made through AWS CLI, calls made programmatically, or clicks and sign-in events for the AWS Management Console.

AWS CloudTrail will store events information in the form of logs; these logs can be configured to collect data from multiple regions and/or multiple AWS accounts and can be stored securely in one S3 bucket. Moreover, these events can be sent to CloudWatch logs and these logs could be consumed by any log analysis and management tools such as Splunk, ELK, and so on.

Amazon CloudWatch is a monitoring service that has a feature CloudWatch log that can be used to store your server, application and custom log files and monitor them. These log files could be generated from your EC2 instances or other sources such as batch processing applications.

We are going to have a detailed look at the logging feature in AWS along with AWS CloudTrail and Amazon CloudWatch in the subsequent chapters.

The AWS Trusted Advisor customer support service provides best practices or checks across the following four categories:

• Cost optimization
• Fault tolerance
• Security
• Performance

Let us look at alerts provided by the AWS Trusted Advisor for security categories. If there are ports open for your servers in cloud, that opens up possibilities of unauthorized access or hacking; if there are internal users without IAM accounts, or S3 buckets in your account are accessible to the public, or if AWS CloudTrail is not turned on for logging all API requests or if MFA is not enabled on your AWS root account, then AWS Trusted Advisor will raise an alert. AWS Trusted Advisor can also be configured to send you an email every week automatically for all your security alert checks.

The AWS Trusted Advisor service provides checks for four categories; these is, cost optimization, performance, fault tolerance, and security for free of cost to all users, including the following three important security checks:

• Specific ports unrestricted
• IAM use
• MFA on root account

There are many more checks available for each category, and these are available when you sign up for the business or enterprise level AWS support. Some of these checks are as follows:

• Security groups-Unrestricted access
• Amazon S3 bucket permissions
• AWS CloudTrail logging
• Exposed access keys

The following figure depicts the AWS Trusted Advisor checks for an AWS account. We will take a deep dive into the Trusted Advisor security checks later in this book:

AWS Config is a continuous monitoring and assessment service that records changes in the configuration of your AWS resources. You can view the current and past configurations of a resource and use this information to troubleshoot outages, conduct security attack analysis, and much more. You can view the configuration at time and use that information to reconfigure your resources and bring them into a steady state during an outage situation.

Using Config Rules, you can run continuous assessment checks on your resources to verify that they comply with your own security policies, industry best practices, and compliance regimes such as PCI/HIPAA. For example, AWS Config provides managed Config rules to ensure that encryption is turned on for all EBS volumes in your account. You can also write a custom Config rule to essentially codify your own corporate security policies. AWS Config send you alerts in real time when a resource is wrongly configured, or when a resource violates a particular security policy.

The following figure depicts various rule sets in AWS Config; these could be custom rules or rules provided out of the box by AWS:

AWS VPC is an IaaS that allows you to create your own VPN in the cloud. You can provision your resources in this logically isolated network in AWS. This network can be configured to connect to your on-premise data center securely. You can configure firewalls for all your resources in your VPC at instance level and/or subnet level to control traffic passing in and out of your VPC. VPC has a VPC flow log feature that enables you to collect information regarding IP traffic of your VPC.

AWS KMS is a service that helps you manage keys used for encryption. There are multiple options for KMS that include bringing your own keys and having them managed by KMS along with those generated by AWS. This is a fully managed service and integrates with other AWS Services such as AWS CloudTrail to log all activities for your KMS services. This service plays an important role in securing the data stored by your applications by encrypting them.

AWS shield protects your web applications running on AWS from managed Distributed Denial of Service (DDoS) attacks. It is a fully managed service and has two variants, standard and advanced. AWS shield standard is offered to all customers free of charge and provides protection from most common attacks that target your applications or websites on AWS. AWS shield advanced gives you higher levels of protection, integration with other services such as web application firewalls, and access to the AWS DDoS response team.

AWS Config is a service that lets you audit and evaluates the configuration of your AWS resources. You can visit the historical configuration of your AWS resources to audit any incident. It helps you with compliance auditing, operational troubleshooting, and so on. You will use this service to make sure your AWS resources stay compliant and configured as per your baseline configuration. This service enables continuous monitoring and continuous assessment of configuration of your AWS resources.

This service gives you all compliance related documents at the click of a button. AWS Artificat is a self service, on-demand portal dedicated to compliance and audit related information along with select agreements such as business addendum and non disclosure agreement, and so on.

AWS allows you to conduct penetration testing for your own EC2 and Relational Database Service (RDS) instances; however, you have to first submit a request to AWS. Once AWS approves this request, you can conduct penetration testing and vulnerability scans for EC2 and RDS instances in your AWS account. We'll take a detailed look at penetration testing in subsequent chapters.

AWS provides several resources to help you secure your workload on AWS. Let us look at these resources.

This is one of the best resources available for developers, system administrators, and IT executives alike. It is free, comprehensive, and covers all AWS services including software development kits for various languages and all AWS toolkits. You can find the AWS documentation at https://aws.amazon.com/documentation.

AWS has case studies specific to industry, domain, technology, and solutions. They have more than a million active customers across the globe and there are scores of case studies to help you with your use case, irrespective of your industry, or size of your organization. These case studies are available at https://aws.amazon.com/solutions/case-studies.

AWS has numerous events such as AWS Summit, AWS Re:Invent, and so on throughout the year around the globe. There are sessions on security at these events where customer AWS and AWS partners share tips, success stories, ways to secure the network, data, and so on. These videos are uploaded to the AWS channel on YouTube. This is a treasure trove for learning about AWS services from the best in the business. There are multiple channels for various topics and multiple languages. You can subscribe to the AWS YouTube channels at https://www.youtube.com/channel/UCd6MoB9NC6uYN2grvUNT-Zg.

AWS has blogs dedicated to various topics such as AWS Security, AWS big data, AWS DevOps, and so on. There are blogs for countries as well such as, AWS blog (China), AWS blog (Brazil), and so on. There are blogs for technologies such as AWS .NET, AWS PHP, and so on. You can subscribe to these blogs at https://aws.amazon.com/blogs/aws.

When you require external help to complete your project on AWS, you can reach out to professionals on the AWS Partner Network. These are organizations authorized by AWS as consulting or technology partners. They can provide professional services to you for your AWS requirements such as security, compliance, and so on. You can find more information about them at https://aws.amazon.com/partners.

AWS marketplace is an online store where 3500+ products are available that integrate seamlessly with your AWS resources and AWS services. Most of these offer a free trial version of their products and these products are available for security as well as other requirements. We'll have a detailed look at the AWS marketplace in the subsequent chapters. You can visit AWS Marketplace at https://aws.amazon.com/marketplace.

Let us recap what we have learnt in this chapter:

We learnt about the shared security responsibility models of AWS. We found that AWS does the heavy lifting for customers by taking complete ownership of the security of its global infrastructure of regions and availability zones consisting of data centers, and lets customers focus on their business. We got to know that AWS offers multiple services under broad categories and we need to have different security models for various services that AWS offers, such as AWS infrastructure services, AWS container services, and AWS abstract services.

AWS has a different set of security responsibilities for AWS and the customer for the above three categories. We also learnt about physical security of AWS, global infrastructure, network security, platform security, and people and procedures followed at AWS. We looked at ways to protect our AWS account. We went through a couple of AWS services such as AWS Trusted Advisor's and AWS Config and saw how they can help us secure our resources in cloud. We briefly looked at security logs and AWS CloudTrail for finding the root causes for security related incidents. We'll look at logging features in detail in the subsequent chapters later in this book.

In subsequent chapters, we'll go through services that AWS offers to secure your data, applications, network, access, and so on. For all these services, we will provide scenarios and solutions for all the services. As mentioned earlier, the aim of this book is to help you automate security in AWS and help you build security by design for all your AWS resources. We will also look at logging for auditing and identifying security issues within your AWS account. We will go through best practices for each service and we will learn about automating as many solutions as possible.

In the next chapter, AWS Identity and Access Management, we will deep dive into AWS IAM that lets you control your AWS resources securely from a centralized location. IAM serves as an entry point to AWS Security where AWS transfers the security baton to customers for allowing tiered access and authenticating that access for all your AWS resources. We are going to see how we can provide access to multiple users for resources in our AWS account. We will take a look at the various credentials available in detail. We will deep dive into AWS identities such as users, groups and roles along with access controls such as permissions and policies.