AWS Essentials

By reading these notes, you will gain knowledge tailored to your role, whether you are a beginner or practitioner focusing on AWS Cloud technology foundations.

Note – This page contains a complete summary of the topics. To learn more about each topic, click on the (Expand), Topic-Heading, Image, or ‘Click Here’ hyperlink.

Before reading this document, please read Cloud Technology Essentials.

AWS is like a giant digital supermarket. You can “rent” everything from computers (EC2) and storage (S3) to databases (RDS). However, in DevSecOps, we don’t just want to “use” these services; we want to use them safely.

Shared Responsibility Model

Every DevSecOps engineer must understand this:

• AWS is responsible for the Security “OF” the Cloud (Physical servers, data centers, hardware).
• YOU are responsible for Security “IN” the Cloud (Your data, OS patching, firewall settings, IAM).

AWS Cloud Services – Category wise

Compute Services (Secure Processing)

In the world of DevSecOps, Compute is where your code actually “lives” and “runs.” If your compute layer is weak, a hacker can take control of your entire application. Instead of just looking at these as “servers,” look at them as Security Boundaries. Our goal is to ensure that:

1. Every action is recorded and monitored (Auditability).
2. No server is left unpatched (Automation).
3. No code has more power than it needs (Least Privilege).

1. Shifting Security “Left” in Compute
   • Don’t wait for the server to be running to check for security. Use Infrastructure as Code (IaC) templates (like Terraform or CloudFormation) and scan them for open ports (like port 22 or 3389) before they are even deployed.
2. The “Golden Image” Strategy
   • Instead of fixing servers one by one, DevSecOps gurus use EC2 Image Builder to create “Golden Images.” These are pre-secured, pre-patched OS images that every team must use. This ensures a standard security baseline across the whole company.
3. Vulnerability Management
   • manual scanning is dead. Security must be continuous. Amazon Inspector is your primary tool for automated vulnerability management.
     • Always-On: Automatically scans EC2 instances, Lambda functions, and ECR container images the moment they are created or updated.
     • Network Reachability: Detects if a server is accidentally exposed to the public internet.
     • CVE Detection: Identifies software vulnerabilities (Common Vulnerabilities and Exposures) in your OS and application libraries.

2. Storage Services – Data Protection & Integrity

In DevSecOps, storage is not just a “folder” to keep files. It is the most targeted area for data breaches. A single misconfigured S3 bucket can lead to a global scandal. We follow the “Data-at-Rest Encryption” and “Zero Trust” principles here.

1. S3 Bucket Policies vs. IAM Policies
   • As a Guru, you must know the difference. IAM Policies say “Who can do what,” but S3 Bucket Policies say “Who can access this specific bucket.” Always use both for a “Double-Lock” security system.
2. Macie: The “PII” Scanner
   • Mention Amazon Macie in your storage notes. It uses Machine Learning to scan your S3 buckets and find “Sensitive Data” like Credit Card numbers or Aadhaar details that developers might have accidentally uploaded.
3. Object Lock (WORM)
   • WORM (Write Once, Read Many) model. Once you “Lock” a file in S3 with Object Lock, nobody (not even a hacker with admin access) can delete it until the timer expires. This is the ultimate defense against data-wiping attacks.

3. Database Services – Secure Data Management

In DevSecOps, we follow the principle of “Least Privilege” for database access. We move away from “Master User” passwords and towards IAM-based authentication and Automated Secret Rotation.

1. The “Passwordless” Future (IAM Auth) – Most beginners use a username and password to connect to RDS. A DevSecOps Guru uses IAM Roles. This means:
   • No passwords to leak in the code.
   • Access is temporary (15-minute tokens).
   • Permission is managed centrally in IAM.
2. Secrets Manager Integration – Explain that AWS Secrets Manager is the “Vault” for your database.
   • Auto-Rotation: It can automatically change your RDS password every 30 days without you doing anything.
   • Application-Friendly: Your application just asks Secrets Manager, “Give me the current password,” so the app never breaks when the password changes.
3. VPC Security Groups for Databases – Never, ever make a database publicly accessible.
   • Place your RDS/Aurora in Private Subnets.
   • Configure the Security Group to only allow traffic from your Application’s Security Group (this is called “Referencing Security Groups”).
4. Database Activity Streams (DAS) – For sensitive databases (like Finance or Health), mention DAS. It sends a real-time stream of all database activity to Kinesis. Security teams use this to detect abnormal “SELECT *” queries that look like a data exfiltration attempt.
5. Compliance as Code – Use AWS Config Rules (like rds-storage-encrypted) to automatically check if every database in your account has encryption turned on. If it’s not encrypted, Config can notify the security team immediately.”

4. Networking & Content Delivery – The Secure Perimeter

For a DevSecOps Guru, the network is not just a “pipe” for data; it is the Perimeter Defense. In 2025, networking has shifted from simple connectivity to “Identity-Aware Networking” and “Zero Trust Architecture.”

In DevSecOps, we follow the “Deny by Default” rule. We use the network to isolate workloads so that even if one server is hacked, the attacker cannot move “East-West” to other parts of your infrastructure.

1. Micro-Segmentation: – should not have one giant subnet. Instead, use Micro-segmentation:
   • Public Subnet: Only for Load Balancers and NAT Gateways.
   • Private Subnet: For App Servers (No public IP).
   • Data Subnet: For Databases (No internet access at all).
2. Security Groups vs. NACLs
   • Security Groups (The Bouncer): Stateful. If you let a guest in, they can also leave. Operates at the Instance level.
   • NACLs (The Gate): Stateless. You must explicitly allow the guest to enter and explicitly allow them to leave. Operates at the Subnet level.
3. VPC Flow Logs + Athena = Threat Hunting – A DevSecOps engineer doesn’t just “enable” logs; they analyze them.
4. The “Security Hub” Pattern – For large companies, we use a Transit Gateway to send all traffic to a “Scanning VPC.” This VPC contains AWS Network Firewall or specialized appliances (like Palo Alto or Fortinet) to scan for viruses and malware inside the network packets.

5. Security, Identity & Compliance – The Shield & Guard

In DevSecOps, we move from “Manual Security” to “Security as Code.” We don’t wait for an audit to find a mistake; we use these tools to block mistakes before they happen.

1. Identity-First Security – the Network Perimeter is gone. Identity is the new perimeter.
   • Role-Based Access Control (RBAC): Never give “AdministratorAccess” to a developer. Create custom roles for “ReadOnly” or “DeveloperAccess” with Permission Boundaries.
   • OIDC for CI/CD: When using GitHub Actions or GitLab, never use static IAM Access Keys. Use OIDC (OpenID Connect) to get temporary tokens for your pipeline.
2. The “Automated Remediation” Cycle – Doesn’t just “detect” a problem; they “fix” it automatically.
   • If GuardDuty detects an EC2 instance talking to a malicious IP, it can trigger an EventBridge rule, which calls a Lambda function to automatically shut down that instance or change its Security Group. This is DevSecOps automation.
3. Shift-Left Vulnerability Scanning
   • It scans ECR Images as soon as they are pushed.
   • It scans Lambda code for insecure libraries.
   • Integrate these findings into your CI/CD pipeline so the “Build Fails” if a critical vulnerability is found.
4. Compliance-as-Code – AWS Security Hub plus AWS Config allows to stay “Always Compliant.” Instead of a manual audit once a year, get a “Security Score” every hour. If someone turns off S3 encryption, your score drops, and you get an alert.

6. Application Integration – The Secure Nervous System

1. The “Poison Pill” Defense (SQS/SNS) – In a DevSecOps world, a hacker might send a “Malicious Message” designed to break your backend code.
   • Set up a Dead Letter Queue (DLQ). If a message fails to process 3 times, it is moved to the DLQ. then analyze it safely in a “Sandbox” environment to see if it was an attack attempt.
2. EventBridge: –
   • Real-time Remediation: If AWS Config detects an S3 bucket has become “Public,” it sends an event to EventBridge and triggers a Lambda function that immediately flips the bucket back to “Private.” This is called Self-Healing Infrastructure.
3. SNS Data Protection – SNS now has Message Data Protection policies.
   • Set a policy that says: “If this message contains a Credit Card number or a PAN card number, block it from being sent to an Email or SMS endpoint.” This prevents accidental data leaks by developers.
4. Step Functions for Incident Response – Instead of a human manually responding to a hack, build a Step Function Playbook.
   • Step 1: Revoke the compromised IAM user’s sessions.
   • Step 2: Attach a “Deny All” policy to the user.
   • Step 3: Send a message to the #security-alerts Slack channel.

7. Management, Monitoring & Governance

Management & Governance is about having Visibility and Control.

In DevSecOps, we use these tools to create Guardrails. Think of guardrails like the boundaries on a highway: they allow developers to drive fast (deploy code quickly) but prevent them from driving off the cliff (making a security mistake).

1. The “Golden Rule” of CloudTrail – CloudTrail must be turned on in ALL regions.
   • Use Log File Integrity Validation to ensure the hacker hasn’t modified the logs to hide their tracks.
2. Service Control Policies (SCPs) – In a large company, you cannot trust everyone.
   • SCPs are “Super-Powers”: Even if a developer has “FullAdmin” access in their account, an SCP from the Organization level can stop them from deleting security logs. It is the ultimate “No-Go” zone.
3. Real-time Security Alarms – Don’t wait for the monthly bill. Use CloudWatch Alarms linked to SNS:
4. AWS Config Conformance Packs – Instead of checking rules one by one, use Conformance Packs. These are collections of AWS Config rules and remediation actions (e.g., “The PCI-DSS Pack”) that keep your entire cloud environment compliant with international security standards automatically.

8. DevOps, Developer Tools & IaC

In DevSecOps, the CI/CD pipeline is like an Automated Security Scanner. Every time a developer saves code, these tools should automatically check for passwords, vulnerabilities, and misconfigurations.

1. Static vs. Dynamic Scanning (SAST & DAST) –
   • SAST (Static): Scans the source code inside CodeBuild. It looks for bad coding habits.
   • DAST (Dynamic): Scans the running application after CodeDeploy. It acts like a hacker trying to find open doors.
2. SSM: The End of Bastion Hosts – In the old days, we used “Jump Boxes” or “Bastion Hosts” to access servers.
   • Use AWS Systems Manager Session Manager. It allows you to access your EC2 instances via the browser. You don’t need to manage SSH keys, and every command a developer types is logged in CloudTrail for auditing.
3. Infrastructure as Code (IaC) Security
   • Never deploy a CloudFormation or CDK template without scanning it. Tools like Checkov or Tfsec can be integrated into CodeBuild to fail the build if a developer accidentally creates a “Public S3 Bucket.”
4. Secret Management in Pipelines –
   • Pull your sensitive keys from AWS Secrets Manager or SSM Parameter Store during the build phase. This way, your secrets never appear in your logs or your code repository.

Good to know services. Advance Services

9. Analytics, Big Data & ETL

10. Machine Learning & AI

11. Migration & Transfer