AWS Cloud Practitioner Essentials

Chapter 6 : Security
Video 1 : Introduction:
Security is one of the core foundations of AWS. Before diving into the specific services, it’s essential to
understand how security works in the AWS Cloud. The first key concept to understand is the Shared
Responsibility Model.

• In AWS, security is a shared responsibility between AWS and the customer (you).

• AWS is responsible for "security of the cloud" — this includes the infrastructure that runs all the
services (like physical data centers, networking, and hardware).

• The customer is responsible for "security in the cloud" — this includes how you configure your
services, secure your applications, manage user access, and protect your data.

So, in short:

• AWS secures what they provide (hardware, software, networking).

• You secure what you create (apps, data, access controls).

This module introduces AWS's various security services and mechanisms designed to help you manage and
maintain a secure environment.

Video 2 : AWS Shared Responsibility Model

The shared responsibility model divides responsibilities between AWS and the customer.

How It Works

Imagine you live in a house:

• The builder (AWS) is responsible for making sure the house is strong and secure: solid walls, locking
doors, secure wiring.

• You (customer) are responsible for locking the doors, setting up your alarm, and not giving strangers
a copy of your keys.

The same applies to AWS services like EC2 (virtual servers):

• AWS secures the data centers, the physical servers, the network, and the hypervisor that runs
virtual machines.

• The customer secures the operating system, the applications, patches, configurations, and the data
stored.

Key Points

• The physical layer (buildings, security guards, surveillance) is 100% managed by AWS.

• The network and hypervisor layers are also AWS-managed.

 • Once you choose an Operating System (OS) for your EC2 instance, everything above that layer
becomes your responsibility:

o Managing users and permissions

o Installing patches and updates

o Securing applications

o Encrypting and controlling access to your data

Security Tip:

AWS has no access to your operating system or data. They cannot and will not ask for your credentials. If
someone claims to be AWS and asks for access to your system or key, it's a red flag.

Video 3 : User Permissions and Access

Imagine running a coffee shop. Employees like Rudy and Blaine have specific jobs and should only access
the tools they need.

In AWS, the same principle applies using a service called IAM (Identity and Access Management).

Types of IAM Identities

1. Root User:

o Created when you first create an AWS account.

o Has full administrative access to all services and resources.

o Should only be used for initial setup and emergency actions.

o Enable Multi-Factor Authentication (MFA) immediately for extra security.

2. IAM Users:

o Created for individuals within your organization.

o Have no permissions by default.

o Permissions must be granted explicitly using IAM policies.

3. IAM Groups:

o A collection of IAM users.

o Policies attached to the group apply to all members.

o Example: Add all cashiers to a "Cashiers" group and assign permissions once.

4. IAM Roles:

o Designed for temporary access.

o Used by users, applications, or even AWS services.

 o No login credentials; they are "assumed" to gain access.

o Example: Blaine switches roles based on his task for the day.

IAM Policies:

• JSON documents that define what actions are allowed or denied.

• Contain elements like:

o Effect: Allow or Deny

o Action: API calls like s3:ListBucket

o Resource: The AWS resource (e.g., a specific S3 bucket)

Principle of Least Privilege:

Always grant the minimum permissions necessary for a user or role to perform their job.

Video 4 : AWS Organizations

As your cloud usage grows, you may manage multiple AWS accounts.

Why Use AWS Organizations?

• Centralized account and billing management

• Separate accounts for different teams, environments, or functions

• Avoid permission overlaps or mismanagement ("account spaghetti")

Key Features

• Centralized Management: Manage all accounts from a single location.

• Consolidated Billing: One invoice for all accounts and eligibility for volume discounts.

• Organizational Units (OUs):

o Group accounts based on business units or environments.

o Example: Dev OU, Finance OU, Compliance OU

• Service Control Policies (SCPs):

o Restrict which services/accounts can access which AWS actions.

o Acts as a guardrail for member accounts.

Video 5 : Compliance
In regulated industries (finance, healthcare, etc.), you must comply with certain standards.

AWS and Compliance:

• AWS meets many compliance standards: GDPR, HIPAA, SOC, PCI-DSS.

• You inherit AWS's secure foundation but must build your own compliant systems.

• Select an AWS Region to control where data is stored (important for data sovereignty).

Tools for Compliance:

• AWS Artifact: Access audit reports and compliance documents.

• AWS Compliance Center: One-stop shop for compliance resources and whitepapers.

Reminder:

• You own your data in AWS.

• Use encryption, access control, and proper configurations to ensure compliance.

Video 6 : Denial-of-Service Attacks

A DDoS attack tries to overload your application to make it inaccessible to real users.

🌪 Types of Attacks:

• UDP Flood: Overwhelms servers by spoofing requests that generate large responses.

• HTTP Flood: Looks like normal traffic, but sends massive repeated requests.

• Slowloris: Holds connections open to exhaust resources slowly and stealthily.

AWS Defense Mechanisms:

• Security Groups: Act like firewalls to control inbound/outbound traffic.

• Elastic Load Balancing (ELB): Absorbs large traffic and forwards clean traffic.

• AWS Shield: DDoS protection service (standard and advanced versions).

• AWS WAF (Web Application Firewall):

o Detects and filters malicious requests.

o Uses Machine Learning and pattern matching.

Best Practice:

A well-architected app with these built-in services can handle most DDoS threats without extra cost or
configuration.
Video 7 : Additional Security Services
Data Encryption

• Encryption at Rest:

o Data stored and not actively moving.

o Example: DynamoDB encryption using AWS KMS.

• Encryption in Transit:

o Data moving between services or users.

o Example: Use SSL/TLS for secure communication (e.g., Redshift to SQL client).

Monitoring & Detection Tools:

1. Amazon Inspector:

o Scans EC2 for vulnerabilities and deviations from best practices.

o Generates detailed reports and remediation suggestions.

2. Amazon GuardDuty:

o Detects anomalies and threats using:

▪ VPC Flow Logs

▪ DNS Logs

▪ AWS CloudTrail events

o Uses ML and threat intelligence.

o Works independently from your apps.

3. AWS Security Hub:

o Aggregates alerts from different services.

o Centralizes your security dashboard.

Video 8 : Summary
In chapter 6, you learned about the following concepts:

• The shared responsibility model

• Features of AWS Identity and Access Management
• Methods of managing multiple accounts in AWS Organizations
• AWS compliance resources
• AWS services for application security and encryption

👍 Key Takeaways:

• Shared Responsibility:
o AWS secures infrastructure; customers secure their configurations and data.
• IAM:
o Root user, IAM users, groups, roles
o Policies define permissions
o Use MFA, and follow least privilege
• Organizations:
o Manage multiple accounts efficiently
o Use consolidated billing and SCPs
• Compliance:
o Use AWS Artifact and Compliance Center
o You are responsible for your application-level compliance
• Security Services:
o GuardDuty, Inspector, WAF, Shield, KMS
o Secure data at rest and in transit
• Design for Security:
o Use encryption, access controls, monitoring, and logging
o Apply the principle of least privilege and enforce MFA

Security is a shared and ongoing effort. With the right AWS tools and awareness, you can build a highly
secure cloud environment that scales with your needs.