Aws

AWS Lambda is a versatile serverless compute service that enables you to run code without provisioning or managing servers. It automatically scales your applications in response to incoming requests or events, and you pay only for the compute time you consume. 


AWS Lambda use cases

DATA-CHAIN

(emphasizes flow of data + intelligence across systems)

D → Data Warehousing & ETL

A → Automated Backups and Scheduled Tasks

T → Transformation (File and Data)

A → API Backends and Web Applications

C → Compliance & Security Monitoring

H → High-Performance Computing

A → AI (Generative + ML)

I → Intelligent Event-Driven Architectures

N → Natural Language Processing & Chatbots

---

🔄 1. Real-Time Data Processing

AWS Lambda is ideal for processing real-time data streams from sources like IoT devices, clickstreams, or social media feeds. It can analyze, transform, and filter data on the fly, enabling immediate insights and actions.

· Examples:
  · IoT Telemetry: Process sensor data from IoT devices for real-time monitoring and alerts.
  · Clickstream Analysis: Analyze user behavior on websites or apps to optimize experiences.
  · Social Media Feeds: Filter and process social media data for trends or sentiment analysis.

---

📂 2. File and Data Transformation

Lambda can be triggered by file uploads to Amazon S3, making it perfect for automating file processing tasks.

· Examples:
  · Image/Video Processing: Resize images, add watermarks, or transcode videos upon upload.
  · Document Conversion: Convert files (e.g., HTML to PDF) in real-time based on user requests.
  · Data Validation: Validate and cleanse data before storing it in databases or data warehouses.

---

🌐 3. API Backends and Web Applications

Lambda integrates seamlessly with Amazon API Gateway to build scalable and cost-effective serverless API backends for web and mobile applications.

· Examples:
  · Serverless Websites: Host static frontends on S3 and use Lambda for dynamic backend logic.
  · Mobile Backends: Handle authentication, user management, and business logic for mobile apps.
  · Microservices: Implement specific functionalities (e.g., user registration, payment processing) as independent functions.

---

🤖 4. Chatbots and Natural Language Processing (NLP)

Lambda can power chatbots and NLP applications by processing user inputs and generating responses in real-time.

· Examples:
  · Customer Support Chatbots: Handle common queries and route complex issues to human agents.
  · Voice Assistants: Process voice commands and integrate with services like Alexa.
  · Text Analysis: Perform sentiment analysis or keyword extraction from text data.

---

⚙️ 5. Automated Backups and Scheduled Tasks

Lambda can execute scheduled tasks (e.g., via CloudWatch Events) for routine maintenance and automation.

· Examples:
  · Database Backups: Automate daily backups of databases like RDS or DynamoDB.
  · Log Cleanup: Archive or delete old logs to save storage costs.
  · Report Generation: Generate and email daily/weekly reports automatically.

---

🔐 6. Security and Compliance Monitoring

Lambda can monitor logs and events in real-time to enhance security and compliance.

· Examples:
  · Security Alerts: Scan CloudTrail or CloudWatch logs for suspicious activities and trigger alerts.
  · Compliance Checks: Validate configurations against compliance policies (e.g., GDPR, HIPAA).
  · Automated Remediation: Fix security issues automatically (e.g., revoke unauthorized access).

---

📊 7. ETL and Data Warehousing

Lambda can perform Extract, Transform, Load (ETL) operations to prepare data for analytics and reporting.

· Examples:
  · Data Ingestion: Process data from various sources and load it into data warehouses like Redshift.
  · Real-Time ETL: Transform streaming data before storing it in databases.
  · Data Enrichment: Augment data with additional information from external APIs.

---

🚀 8. Event-Driven Architectures

Lambda excels in event-driven architectures, where functions are triggered by events from AWS services like SNS, SQS, or DynamoDB Streams.

· Examples:
  · Order Processing: Handle e-commerce orders by processing payments, updating inventory, and sending confirmations.
  · Notifications: Send emails or SMS alerts based on system events (e.g., order shipped, outage detected).
  · Workflow Orchestration: Use Step Functions to coordinate multi-step processes across Lambda functions.

---

🤖 9. Generative AI and Machine Learning

Lambda can serve as a backend for generative AI applications, handling distributed, event-driven workflows securely at scale.

· Examples:
  · AI Model Inference: Run lightweight machine learning models for predictions or classifications.
  · Prompt Processing: Process prompts for AI models and manage responses efficiently.
  · Data Preprocessing: Prepare data for training or inference in AI pipelines.

---

📈 10. High-Performance Computing (HPC)

With support for up to 10 GB memory and 6 vCPUs, Lambda can handle heavy workloads like scientific simulations or financial modeling.

· Examples:
  · Financial Modeling: Run risk analysis or Monte Carlo simulations.
  · Media Rendering: Render graphics or videos for short-duration tasks.
  · Scientific Computations: Process large datasets for research purposes.

---

💡 Key Benefits of AWS Lambda:

· Cost Efficiency: Pay only for compute time used (per millisecond/microsecond), with no idle charges.
· Automatic Scaling: Handles from zero to millions of requests without manual intervention.
· Serverless Management: No infrastructure to provision or maintain.
· Broad Integration: Works with over 200 AWS services and external tools.
· Flexibility: Supports multiple programming languages and custom runtimes.

---

⚠️ Limitations to Consider:

· Execution Timeout: Functions cannot run for more than 15 minutes.
· Cold Starts: Initial invocation may experience latency if the function is idle.
· Resource Constraints: Limited to 10 GB memory and 6 vCPUs per function instance.
· Stateless Nature: Functions are ephemeral; persistent state must be stored externally (e.g., in DynamoDB or S3).

---

💎 Conclusion:

AWS Lambda is a powerful tool for building scalable, cost-effective, and event-driven applications. Its versatility makes it suitable for a wide range of use cases, from real-time data processing and API backends to AI workflows and automation. By leveraging Lambda, developers can focus on writing code rather than managing infrastructure, accelerating innovation and reducing operational overhead.

For more details, you can explore the AWS Lambda Documentation or refer to customer case studies on the AWS website.




Core Services

Amazon EC2 provides resizable virtual servers, offering complete control over computing resources and the ability to scale capacity as needed.
Amazon S3 is a durable and highly available object storage service designed to store and retrieve any amount of data from anywhere, forming the backbone for data lakes, 
static websites, and backups. Understanding the global infrastructure is key; AWS Regions are geographic locations containing multiple, isolated Availability Zones, 
which are physical data centers with redundant power and networking to ensure high availability and fault tolerance for deployed applications.

Security & Identity

 AWS Identity and Access Management (IAM) is the core service for controlling secure access to AWS resources by managing users, groups, roles, and their permissions through policies. 
This is underpinned by the AWS Shared Responsibility Model, which delineates that AWS is responsible for the security of the cloud, meaning the infrastructure, while the customer is responsible
for security in the cloud, encompassing customer data, IAM configuration, and operating system and network security.

Architecture & Design

AWS Lambda enables serverless computing by allowing code execution without provisioning servers, scaling automatically and charging only for compute time consumed. For network isolation,
Amazon VPC is used to launch AWS resources into a logically defined virtual network, giving the developer control over IP ranges, subnets, route tables, and gateways. Furthermore, a critical operational
distinction is between stopping and terminating an EC2 instance; stopping is akin to shutting down a computer where the instance can be restarted, preserving the root volume, while terminating is equivalent to destruction, where the instance is permanently deleted and its attached storage may be lost unless configured for persistence.


Of course\! Here are some interview questions with answers, syntax, and examples tailored for an AWS Senior Developer role at a company like ITC Infotech. These questions focus on practical application, design patterns, and best practices rather than just definitions.

The questions are designed to test not just *what* you know, but *how* you apply it to solve real-world problems related to scalability, security, and cost-efficiency.

-----

### \#\# 1. Core AWS & Architecture

#### **Question:** You have an application running on EC2 instances in a private subnet that needs to access external APIs over the internet, but you don't want the instances to be directly accessible from the internet. How do you achieve this, and what are the key components involved?

**Answer:**
The standard solution is to use a **NAT (Network Address Translation) Gateway**. It allows instances in a private subnet to initiate outbound traffic to the internet while preventing inbound traffic from being initiated from the internet.

**Key Components:**

1.  **VPC:** Your network foundation.
2.  **Public Subnet:** A subnet with a route to an Internet Gateway. The NAT Gateway will reside here.
3.  **Private Subnet:** Where your EC2 instances are located. This subnet should *not* have a direct route to the Internet Gateway.
4.  **Internet Gateway (IGW):** Attached to the VPC to allow communication with the internet.
5.  **NAT Gateway:** Deployed in the public subnet. It needs an Elastic IP address.
6.  **Route Tables:**
      * The **public route table** (associated with the public subnet) has a route `0.0.0.0/0` pointing to the IGW.
      * The **private route table** (associated with the private subnet) has a route `0.0.0.0/0` pointing to the NAT Gateway.

**Example (AWS CLI Syntax):**

This shows how you'd update the private route table to direct all internet-bound traffic to the NAT Gateway.

```bash
# Assume you have:
# - A route table ID: rtb-012345abcdef
# - A NAT Gateway ID: nat-fedcba543210

aws ec2 create-route \
    --route-table-id rtb-012345abcdef \
    --destination-cidr-block 0.0.0.0/0 \
    --nat-gateway-id nat-fedcba543210
```

This configuration ensures any EC2 instance in the private subnet can `curl https://api.example.com` but no external user can SSH into or ping that instance directly from the internet.

-----

### \#\# 2. Serverless & Application Modernization

#### **Question:** You have a Lambda function that processes S3 object uploads. Sometimes, the function fails due to transient errors in a downstream service. How would you design a resilient system to handle these failures without losing data?

**Answer:**
The best practice is to configure a **Dead-Letter Queue (DLQ)** for the Lambda function. When a function fails after all its automatic retries (2 by default for asynchronous invocations), the event payload is sent to the configured DLQ, which is typically an **SQS queue** or an **SNS topic**.

This decouples the failure handling from the main processing logic. You can then have a separate process to inspect the failed messages in the SQS queue, trigger alerts, or attempt to re-process them later.

**Key Concepts:**

  * **Asynchronous Invocation:** S3 triggers Lambda asynchronously, which has built-in retries.
  * **DLQ:** A "catch-all" for events that fail processing completely.
  * **Decoupling:** Prevents failed events from being lost and allows for separate, focused error handling.

**Example (AWS SAM Template Syntax):**

Here's how you'd define a Lambda function and its DLQ using the AWS Serverless Application Model (SAM).

```yaml
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2.0
Resources:
  # SQS Queue to act as the Dead-Letter Queue
  MyFunctionDLQ:
    Type: AWS::SQS::Queue

  # The Lambda Function itself
  MyS3ProcessorFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs18.x
      # Important: Configure the DeadLetterQueue
      DeadLetterQueue:
        Type: SQS
        TargetArn: !GetAtt MyFunctionDLQ.Arn
      Policies:
        # Policy to allow Lambda to send messages to the SQS queue
        - SQSSendMessagePolicy:
            QueueName: !GetAtt MyFunctionDLQ.QueueName
      Events:
        S3Upload:
          Type: S3
          Properties:
            Bucket: my-upload-bucket
            Events: s3:ObjectCreated:*
```

In this setup, if `MyS3ProcessorFunction` fails after its retries, the original S3 event notification is safely stored in the `MyFunctionDLQ` SQS queue for later analysis.

-----

### \#\# 3. Infrastructure as Code (IaC)

#### **Question:** You are building a system using CloudFormation. You need to provide a database password to an RDS instance and an API key to a Lambda function. How do you manage these secrets securely without hardcoding them in your template?

**Answer:**
Hardcoding secrets in templates is a major security risk. The correct approach is to use **AWS Secrets Manager** or **AWS Systems Manager (SSM) Parameter Store** (SecureString type).

1.  **Store the Secret:** Create a secret in AWS Secrets Manager containing the database password or API key.
2.  **Reference the Secret:** Use dynamic references in your CloudFormation template to securely fetch the value at deployment time. CloudFormation resolves these references without ever exposing the secret value in its logs or console.

**Why this is better:**

  * **Security:** Secrets are encrypted at rest and managed outside of your source code.
  * **Lifecycle Management:** Secrets Manager supports automatic secret rotation, which is crucial for database credentials.
  * **IAM Control:** Access to these secrets is tightly controlled via IAM policies.

**Example (CloudFormation Dynamic Reference Syntax):**

Here's how you would reference a secret stored in Secrets Manager for an RDS instance's master password.

```yaml
Resources:
  MyDatabase:
    Type: AWS::RDS::DBInstance
    Properties:
      DBName: "mydatabase"
      Engine: "mysql"
      MasterUsername: "admin"
      # Dynamic reference to fetch the secret value
      # The 'Secret-Name' is the name of your secret in Secrets Manager
      # The 'password' is the key within the secret's JSON structure
      MasterUserPassword: "{{resolve:secretsmanager:MyDatabaseSecret:SecretString:password}}"
      # ... other properties
```

Similarly, for a Lambda function's environment variable:

```yaml
  MyLambdaFunction:
    Type: AWS::Lambda::Function
    Properties:
      Handler: index.handler
      Runtime: python3.9
      Environment:
        Variables:
          API_KEY: "{{resolve:secretsmanager:MyExternalAPISecret:SecretString:apikey}}"
      # ... other properties
```

-----

### \#\# 4. Security & IAM

#### **Question:** An application in **AWS Account A** needs to read objects from an S3 bucket in **AWS Account B**. What is the most secure way to grant this cross-account access without using long-lived credentials?

**Answer:**
The most secure method is to use an **IAM Role**. This involves creating a trust relationship between the two accounts.

**Steps:**

1.  **In Account B (the resource owner):**

      * Create an **IAM Role** (e.g., `S3ReadRoleFromAccountA`).
      * Attach a policy to this role that grants the necessary permissions (e.g., `s3:GetObject`) to the specific S3 bucket.
      * Configure the role's **Trust Policy** to allow principals (like an EC2 role or a Lambda role) from Account A to assume it.

2.  **In Account A (the application owner):**

      * Grant the IAM identity (e.g., the EC2 instance's role) permission to call the `sts:AssumeRole` action on the role created in Account B.
      * The application code will use the AWS SDK to assume the role in Account B, which provides temporary security credentials. These temporary credentials are then used to access the S3 bucket.

**Example (IAM Trust Policy in Account B):**

This JSON policy is attached to `S3ReadRoleFromAccountA` in Account B. It explicitly trusts the IAM role `AppRoleForEC2` from Account A (`111111111111`).

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:role/AppRoleForEC2"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

This method avoids static access keys and uses short-lived, automatically rotated credentials, which is the AWS best practice.

-----

### \#\# 5. Scenario-Based Design 🧑‍💻

#### **Question:** Design a highly available and scalable architecture for a web application that receives user-uploaded images, resizes them into thumbnails, and serves both the original and the thumbnail images to users with low latency.

**Answer:**
This is a classic serverless design pattern that leverages managed services for scalability and cost-efficiency.

**Architecture Components:**

1.  **User Upload:** Users upload images directly to an **S3 Bucket** (`originals-bucket`), preferably using S3 pre-signed URLs generated by the backend. This offloads the upload traffic from our servers.
2.  **Trigger:** Configure **S3 Event Notifications** on `originals-bucket`. For every new object created (`s3:ObjectCreated:*`), it will trigger a **Lambda Function**.
3.  **Processing:**
      * The **Lambda function** receives the S3 event, downloads the original image, resizes it into a thumbnail (using a library like `sharp` for Node.js or `Pillow` for Python), and uploads the thumbnail to a different S3 bucket (`thumbnails-bucket`).
      * To handle processing failures, the Lambda should be configured with a **DLQ (SQS queue)**.
4.  **Metadata (Optional but recommended):** A **DynamoDB** table can store metadata about the images, such as the original key, thumbnail key, upload time, status, etc. The Lambda function would update this table.
5.  **Content Delivery:** Use **Amazon CloudFront** as a CDN, with two origins pointing to the `originals-bucket` and `thumbnails-bucket`. This caches the images at edge locations globally, drastically reducing latency for end-users. It also reduces S3 data transfer costs.

**Flow:**
`User -> (gets pre-signed URL) -> S3 Upload -> S3 Event -> Lambda -> S3 (thumbnail) -> CloudFront -> End User`

**Why this design is good:**

  * **Scalable:** S3, Lambda, and DynamoDB all scale automatically. You don't manage any servers.
  * **Highly Available:** These are managed AWS services with high built-in availability and redundancy.
  * **Cost-Effective:** You only pay for the compute time used by Lambda, the storage in S3/DynamoDB, and the data transfer through CloudFront (pay-as-you-go).
  * **Decoupled:** The upload, processing, and delivery steps are fully decoupled, making the system resilient.


When to Use Merge vs. Rebase

Use Merge when:

· You are merging a feature branch into the main branch (e.g., main or develop). This preserves the exact history of your development process, which can be useful.
· The branch is public and shared with other developers. Merging is safe.
· You want a clear record of when a specific feature was integrated.

Use Rebase when:

· You are working on a local feature branch and want to incorporate the latest changes from main to keep your branch up-to-date. This is the most common use case.
  · Instead of git merge main, do git rebase main. This puts your neat feature work on top of the latest main code, avoiding a merge commit.
· You want to clean up and simplify your local commit history




AWS BEDROCK






Here's a summary and key points from the course content.

## Summary

This is the first lesson in a four-course AWS/Amazon learning path on building generative AI applications with Amazon Bedrock. It introduces what Bedrock is, its core capabilities, the AWS IAM permissions needed to use it, and walks through creating your first Bedrock client connection using Python's boto3 SDK. The lesson assumes basic Python and cloud/API familiarity, and sets up the foundation for later lessons covering knowledge bases, agents, and production deployment.

## Key Points

**Learning Path Structure**
- Four courses total: (1) Foundation Models with Bedrock, (2) Data/Knowledge Bases with RAG, (3) Building agents with Strands Agents, (4) Deploying agents with Bedrock AgentCore
- End goal: build, deploy production-ready AI apps with natural language understanding, external knowledge retrieval, task execution, and conversational memory
- Prerequisites: Python (functions, OOP, error handling), cloud computing basics, some API experience

**What is AWS Bedrock**
- A serverless "AI marketplace" providing access to foundation models from Anthropic, AI21 Labs, Cohere, Meta, and Amazon
- No infrastructure management or model training required
- Pay-as-you-go pricing based on token usage
- Removes traditional barriers to AI adoption for developers/businesses

**Core Capabilities**
- Text generation (content, emails, marketing copy)
- Conversational AI (chatbots, virtual assistants with context)
- Text analysis (summarization, sentiment, document processing)
- Multimodal features (image generation/analysis, code assistance)

**AWS IAM (Identity and Access Management)**
- Security foundation controlling who can access what
- Built on users, roles, and policies
- Operates on **principle of least privilege** — grant only minimum necessary permissions
- Determines both service access and which models/operations are permitted

**Credentials Setup**
- Pre-configured automatically in the course's CodeSignal environment — no action needed
- On personal machines: must configure via AWS Console, CLI, or environment variables
- SDK auto-detects credentials from standard locations

**Key Permissions for Bedrock**
- `bedrock:InvokeModel` — essential permission to send requests/receive responses
- `bedrock:GetFoundationModel` — optional, for retrieving model metadata
- **Model access is separate from IAM** — must be explicitly enabled per-model in the Bedrock console under "Model access"
- Not all models are enabled by default (especially newer/more powerful ones)
- Region choice affects model availability — **us-east-1 (N. Virginia)** has the broadest model selection

**First Bedrock Connection (Code)**
```python
import boto3
client = boto3.client("bedrock-runtime")
```
- "bedrock-runtime" = API for actual model inference (distinct from management/admin APIs)
- Client automatically pulls credentials from the environment (CLI config, env variables, or IAM roles)




PRACTICAL EXAMPLE

import boto3

# Create a Bedrock Runtime client with your default region (us-east-1)
client = boto3.client("bedrock-runtime")

# Define a Bedrock model ID
MODEL_ID = "us.anthropic.claude-sonnet-4-20250514-v1:0"

# Create the user message asking for AWS compute recommendations
messages = [
    {
        "role": "user",
        "content": [
            {
                "text": (
                    "Explain to a beginner what is AWS Bedrock."
                )
            }
        ],
    },
]

try:
    # Call Bedrock model using the converse method
    response = client.converse(
        modelId=MODEL_ID,
        messages=messages
    )

    # TODO: Extract the output message from the response
    # TODO: Get the content parts from the message
    # TODO: Extract text from each content part and join them
    # TODO: Print the AI's response
    
except Exception as e:
    print(f"Error: {e}")
    
    # Get the output message from response
output_message = response.get("output", {}).get("message", {})

# Get the content parts from the message
parts = output_message.get("content", [])

# Extract text from each content part
text_chunks = [part.get("text", "") for part in parts if isinstance(part, dict)]

# Join all text chunks into a single response
full_response = "".join(text_chunks).strip()

# Print the AI's response
print(full_response)


output: # AWS Cloud Computing: A Beginner's Guide

## What is Cloud Computing?

Imagine you need a powerful computer to run your business, but instead of buying expensive hardware and keeping it in your office, you "rent" computing power over the internet. That's essentially what cloud computing is - using someone else's computers and servers through the internet to store data, run applications, and perform computing tasks.

## What is AWS?

**Amazon Web Services (AWS)** is like a giant digital toolbox owned by Amazon. It's the world's largest cloud computing platform that offers hundreds of different services to help businesses and individuals build and run applications online.

Think of AWS as a massive digital infrastructure that you can access from anywhere in the world, just like how you can access your email from any device with internet.

## Key Benefits of AWS Cloud Computing

### 1. **No Upfront Costs**
- Instead of buying expensive servers (which can cost thousands), you pay only for what you use
- Like renting a car vs. buying one - you get what you need without the huge initial investment

### 2. **Scalability**
- If your business grows and you need more computing power, you can get it instantly
- If you need less, you can scale down - you're never stuck with unused resources

### 3. **Reliability**
- AWS has data centers worldwide with backup systems
- If one server fails, others automatically take over

### 4. **Global Reach**
- Your applications can be available worldwide in minutes
- Users get faster performance because data is served from nearby locations

## Common AWS Services (Simplified)

- **EC2**: Virtual computers you can rent by the hour
- **S3**: Digital storage space for files, photos, videos, etc.
- **RDS**: Managed databases to store and organize information
- **Lambda**: Run code without managing servers

## Real-World Example

Let's say you want to start an online photo-sharing app:

**Traditional Way**: Buy servers ($10,000+), hire IT staff, set up security, manage backups
**AWS Way**: Rent virtual servers for $10/month, use AWS's built-in security and backup systems, scale up as you get more users

## Who Uses AWS?

- **Startups**: Get enterprise-level technology without huge costs
- **Large Companies**: Netflix, Airbnb, NASA use AWS
- **Developers**: Build and test applications quickly
- **Students**: Learn technology skills with free tiers

## Getting Started

AWS offers a "Free Tier" that lets beginners explore many services at no cost for 12 months - perfect for learning!

The key takeaway: AWS makes powerful computing technology accessible to everyone, whether you're building the next big app or just learning about technology.




It looks like this message came without any new content attached — I have the same Bedrock course document from before. Here's the summary and key points for it again:

## Summary

This is the first lesson in a four-course AWS/Amazon learning path on building generative AI applications with Amazon Bedrock. It introduces what Bedrock is, its core capabilities, the AWS IAM permissions needed to use it, and walks through creating your first Bedrock client connection using Python's boto3 SDK. The lesson assumes basic Python and cloud/API familiarity, and sets up the foundation for later lessons covering knowledge bases, agents, and production deployment.

## Key Points

**Learning Path Structure**
- Four courses total: (1) Foundation Models with Bedrock, (2) Data/Knowledge Bases with RAG, (3) Building agents with Strands Agents, (4) Deploying agents with Bedrock AgentCore
- End goal: build, deploy production-ready AI apps with natural language understanding, external knowledge retrieval, task execution, and conversational memory
- Prerequisites: Python (functions, OOP, error handling), cloud computing basics, some API experience

**What is AWS Bedrock**
- A serverless "AI marketplace" providing access to foundation models from Anthropic, AI21 Labs, Cohere, Meta, and Amazon
- No infrastructure management or model training required
- Pay-as-you-go pricing based on token usage
- Removes traditional barriers to AI adoption for developers/businesses

**Core Capabilities**
- Text generation (content, emails, marketing copy)
- Conversational AI (chatbots, virtual assistants with context)
- Text analysis (summarization, sentiment, document processing)
- Multimodal features (image generation/analysis, code assistance)

**AWS IAM (Identity and Access Management)**
- Security foundation controlling who can access what
- Built on users, roles, and policies
- Operates on **principle of least privilege** — grant only minimum necessary permissions
- Determines both service access and which models/operations are permitted

**Credentials Setup**
- Pre-configured automatically in the course's CodeSignal environment — no action needed
- On personal machines: must configure via AWS Console, CLI, or environment variables
- SDK auto-detects credentials from standard locations

**Key Permissions for Bedrock**
- `bedrock:InvokeModel` — essential permission to send requests/receive responses
- `bedrock:GetFoundationModel` — optional, for retrieving model metadata
- **Model access is separate from IAM** — must be explicitly enabled per-model in the Bedrock console under "Model access"
- Not all models are enabled by default (especially newer/more powerful ones)
- Region choice affects model availability — **us-east-1 (N. Virginia)** has the broadest model selection

**First Bedrock Connection (Code)**
```python
import boto3
client = boto3.client("bedrock-runtime")
```
- "bedrock-runtime" = API for actual model inference (distinct from management/admin APIs)
- Client automatically pulls credentials from the environment (CLI config, env variables, or IAM roles)