AWS Tips

 

---

⭐ Design Secure Access to AWS Resources  

🔹 Root User Security 

• The root user has full, unrestricted access to the AWS account.
• Should be used only for initial setup tasks, such as:
  • Creating the first IAM admin user
  • Setting up billing
  • Enabling MFA
• After initial setup:
  • Lock it away
  • Enable MFA immediately
  • Never use it for daily operations

---

🔹 IAM Users (Daily Operational Identities)

• Represent individual people or applications needing AWS access.
• Used for day‑to‑day operations, not administrative bootstrap tasks.
• Each user should have:
  • Unique credentials
  • Permissions based on job role
  • MFA enabled

---

🔹 Key IAM Security Best Practices

1. Principle of Least Privilege

• Grant only the permissions required for the task.
• Avoid broad permissions like AdministratorAccess unless absolutely necessary.

2. Multi‑Factor Authentication (MFA)

• Mandatory for:
  • Root user
  • All IAM users
• Adds a second authentication factor (authenticator app, hardware key).
• Protects against compromised passwords.

3. Strong Password Policies

• Enforce:
  • Minimum length
  • Complexity (uppercase, lowercase, numbers, symbols)
  • Regular rotation
• Prevents weak password vulnerabilities.

4. Regular Credential Rotation

• Rotate IAM access keys frequently.
• Never embed access keys in code.
• Use IAM roles for EC2, Lambda, ECS, etc.

5. Monitor Activity

• Use AWS CloudTrail to log all API calls.
• Detect suspicious or unauthorized activity.
• Enable CloudTrail in all regions.

---

⭐ Designing a Flexible Authorization Model (IAM Users, Groups, Roles, Policies)

🔹 IAM Users

• Represent individual identities.
• Can have policies attached directly, but:
  • Hard to manage at scale
  • Not recommended for large teams

---

🔹 IAM Groups

• Collections of IAM users.
• Simplify permission management:
  • Attach policies to groups
  • Users inherit group permissions
• Best practice for teams with similar job functions.

---

🔹 IAM Roles

Roles provide temporary credentials via AWS STS.
Used by:

1. AWS Services

• EC2, Lambda, ECS tasks, etc.
• Preferred method for applications to access AWS resources.
• Eliminates need for embedded credentials.

2. Federated Users

• Users from corporate directories (AD, Okta, Azure AD).
• Access AWS without creating IAM users.
• Improves security and centralizes identity management.

3. Cross‑Account IAM Users

• Users in Account A can access resources in Account B.
• Achieved by:
  • Creating a role in the resource account
  • Adding a trust policy
  • Allowing the principal to assume the role

---

🔹 IAM Policies

Policies define permissions in JSON format.

Policy Components

• Actions — what actions are allowed (e.g., s3:GetObject)
• Resources — which resources the actions apply to
• Effect — Allow or Deny

Types of IAM Policies

1. AWS Managed Policies

• Predefined by AWS
• Good starting point
• Updated automatically by AWS

2. Customer Managed Policies

• Created and managed by you
• Recommended for specific business requirements
• Reusable and version‑controlled

3. Inline Policies

• Embedded directly in a user, group, or role
• Deleted when the entity is deleted
• Not reusable
• Use only for one‑off, tightly‑scoped permissions

---

⭐ Example Scenario (Fully Detailed)

1. Users

   • Each developer has an IAM user.

2. Group

   • All developers added to a Developers IAM group.

3. Policy

   • Create a customer‑managed policy named DevAccess with permissions to:
     • Deploy code to specific S3 buckets
     • Start/stop EC2 instances in a specific environment
     • Access CloudWatch logs

4. Group Attachment

   • Attach DevAccess policy to the Developers group.

5. Role

   • Create an IAM role EC2AppRole for EC2 instances to read configuration from an S3 bucket.

6. Instance Profile

   • Associate EC2AppRole with an instance profile.
   • Attach the instance profile to EC2 instances.

---

 

⭐ S3 IMMUTABILITY — ULTRA‑CRISP EXAM TIPS

---

S3 Retrieval Time Table  

Storage Class	Retrieval Time	Simple Meaning
S3 Standard	Milliseconds	Fast — real‑time access
S3 Standard‑IA	Milliseconds	Fast but cheaper — for infrequent access
S3 Intelligent‑Tiering	Milliseconds	Always fast — auto‑moves data
S3 Glacier Instant Retrieval	Milliseconds	Cold storage but still instant
S3 Glacier Flexible Retrieval	Minutes to hours	Slow — for occasional restores
S3 Glacier Deep Archive	12–48 hours	Very slow — long‑term archive

AWS study Manual