
# IAM (Identity and Access Management)
**IAM (Identity and Access Management)** is the AWS service that controls *who can access what* within your AWS account.  
It’s like the **security brain** of AWS — defining identities (people or services) and assigning them permissions (what they can or can’t do).

---

## The Four Core IAM Concepts

### 1. User
A **user** represents a person or program that interacts with AWS.  
Each user has **login credentials** (for the console) or **access keys** (for CLI/SDK).

### 2. Group
A **group** is a collection of users sharing the same permissions.  
Groups simplify permission management — assign a policy once, and all users in that group inherit it.  
> Note: Groups **cannot contain other groups**.

### 3. Role
A **role** is a temporary identity that AWS services (like EC2, Lambda) can assume to perform actions.  
Roles do not have long-term credentials; instead, they grant **temporary permissions**.

### 4. Policy
A **policy** is a JSON document defining what actions are allowed or denied.  
Policies are attached to **users**, **groups**, or **roles** to grant permissions.

---

## IAM Policy

An **IAM Policy** defines the allowed or denied actions within AWS.  
It uses a JSON structure with one or more **statements**, each specifying:

- **Effect**: `Allow` or `Deny`  
- **Action**: What AWS operations can be performed  
- **Resource**: The AWS resources the action applies to  

Example policy:
```js
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:Describe*",
      "Resource": "*"
    }
  ]
}
```
---

## The Principle of Least Privilege

> Always grant the **minimum permissions** necessary — nothing more.

By following this principle, you minimize security risks:
- Prevent unintended access
- Reduce damage if credentials are compromised
- Enforce clearer, safer security boundaries

---

## IAM Roles — Permissions for AWS Services

AWS services like **EC2**, **Lambda**, or **ECS** often need to perform actions on your behalf (e.g., uploading files to S3).  
Instead of embedding credentials in your code (which is insecure), you use **IAM Roles**.

### Example Scenario

You launch an **EC2 instance** that uploads logs to **S3**.

❌ Bad practice: Embed your access keys in code.  
✅ Good practice: Attach a **role** to the EC2 instance with an S3 write policy.

The EC2 instance automatically receives **temporary credentials** from AWS STS (Security Token Service) and can securely upload logs to S3.

---

## How Users Access AWS

IAM users can interact with AWS in **three main ways:**

### 1. AWS Management Console
- Accessed via username + password  
- Can enable **MFA (Multi-Factor Authentication)** such as **DUO** for extra security.

### 2. AWS CLI (Command Line Interface)
- Authenticate using **Access Keys**  
- Useful for scripting and automation.

### 3. AWS SDK
- Programmatic access for applications  
- Uses **Access Keys** to call AWS APIs via SDKs (Python, JavaScript, Java, etc.)


AWS Notes

# Introduction to Next.js

 **Next.js**, a powerful React framework that enables both *server-side rendering (SSR)* and *static site generation (SSG)*. Coming from a pure React background, I was amazed by how efficiently Next.js handles routing, data fetching, and SEO optimization — all out of the box.

---

## Why Chose Next.js
Unlike traditional React apps that rely on **client-side rendering**, Next.js pre-renders pages by default. This not only improves performance but also makes web pages more visible to search engines.

- **File-based routing** — simply drop a component into `/pages` and it becomes a route.
- **API routes** — building backend endpoints without leaving the framework.
- **Incremental Static Regeneration (ISR)** — update static pages *after deployment* without rebuilding the entire site.

---

## CSR vs. SSR vs. SSG — Understanding the Core Rendering Strategies in React and Next.js

While learning **React** and **Next.js**, one of the most eye-opening topics for me was understanding the different **rendering strategies**.  
They directly affect **performance**, **SEO**, and **user experience** — especially how fast the user sees meaningful content.

---

### Client-Side Rendering (CSR)

> The traditional rendering method used by plain React apps.

**How it works:**
1. The browser requests an HTML page.  
   → The server returns an almost empty HTML shell (no actual data).  
2. The browser downloads the React JavaScript bundle.  
3. JavaScript executes and triggers a `fetch()` call to get data.  
4. Once the data arrives, React renders the page on the client.

**Characteristics:**
- The first paint is delayed because the page depends on JS execution and data fetching.  
- Users might see a blank screen until everything loads.  
- Works best for highly interactive single-page apps where SEO isn’t a priority.

---

### Server-Side Rendering (SSR)

> The core feature that makes Next.js powerful — pre-rendering on the server.

**How it works:**
1. The browser requests a page.  
2. The server executes the React components (including any `fetch()` calls).  
3. The server generates a **fully rendered HTML page with data included**.  
4. The browser receives this complete HTML and immediately displays it.  
5. Meanwhile, React scripts load in the background and perform **hydration** —  
   the process that turns static HTML into an interactive React app.

**What is Hydration?**  
Hydration is the process of “binding” the server-rendered static HTML with React’s client-side logic.  
Before hydration, the page is static. After hydration, it becomes interactive — buttons work, inputs respond, etc.

**Advantages:**
- **Faster first contentful paint (FCP)** — users instantly see meaningful content.  
- **SEO-friendly** — search engine crawlers can read the page content directly,  
  unlike CSR where the crawler only sees an empty HTML shell.

---

### Static Site Generation (SSG)

> Another form of pre-rendering offered by Next.js.

- During the **build process**, Next.js executes the React components and generates static HTML files.  
- When users visit the site, the server simply returns the pre-generated HTML without running React again.  
- Ideal for blogs, documentation, and other content that doesn’t change frequently.





All Posts

AWS Notes

Next.js Notes