In this chapter, we're diving into one of the most important concepts in AWS development: authentication and authorization.

In AWS, absolutely nothing happens unless access is explicitly granted. That's not just a best practice—it's how the system works by design.

As a developer, you're responsible for ensuring that your apps only get the access that they actually need. Every service called in AWS must be authenticated to verify who or what is making the request and whether that person or service is authorized to do it.

This isn't just about protecting your cloud account. It's about controlling how your applications interact with AWS services behind the scenes.

Think of a Lambda function writing to an S3 bucket. That cannot happen unless you grant specific permission to that Lambda to write to that specific bucket. This is the foundation of secure, reliable applications in the cloud, and AWS gives you fine-grained tools to control it.

IAM Core Concepts

Let's break down some critical terms that show up both in real life and on the exam:

• Principal: the entity making a request. It could be a user or a service like a Lambda function;
• Action: what the principal wants to do. For instance, uploading a file to S3;
• Resource: what the principal wants to access;
• Policy: a set of rules that define who can do what and under what conditions;
• Role: an identity with a defined set of permissions, usually assumed by services like Lambda or EC2.

These are the building blocks of AWS security. Every service interaction is evaluated against them.

Users vs Services

So that covers how services talk to services, but what about real people? This is where Amazon Cognito comes in.

Cognito handles user authentication and identity. With it, you can build login functionality for your application that connects to Google, Facebook, or your own identity provider.

• Cognito User Pools: manage usernames, passwords, and sign-in flows.
• Cognito Identity Pools: grant temporary AWS credentials to users after login so they can safely interact with AWS services like S3 or DynamoDB, but only with the permissions you define.

Cognito acts as the bridge between your frontend and the AWS backend.

Real World Example

Suppose you have a Lambda function that needs to upload images to an S3 bucket.

1. Create the IAM Role
   This IAM role can be assumed by the Lambda function. You provide a role name (e.g., LambdaS3WriteRole) and a trust policy document that defines:

   • Effect: Allow
   • Principal: lambda.amazonaws.com
   • Action: sts:AssumeRole

2. Attach a Policy
   Use the iam put-role-policy command, specifying:

   • Role name (e.g., LambdaS3WriteRole)
   • Policy name (e.g., WriteToS3)
   • Policy document (e.g., s3-write-policy.json)

   This policy allows s3:PutObject to a specific bucket like classical-music-xyz. It does not allow deleting or accessing other buckets.

This enforces the principle of least privilege.

Security Best Practices

1. Least Privilege
   Always grant only the permissions that are needed and nothing more.

2. Use Temporary Credentials
   Avoid long-term credentials like access keys. Use services like:

   • STS (Security Token Service)
   • Amazon Cognito
   • Identity Federation

   These provide temporary, scoped credentials that are safer.

3. Prefer Roles Over Users
   Roles are temporary, scoped, and better aligned with secure architecture than long-lived IAM users.

These practices reduce risk, increase auditability, and are core to AWS's security model.

Recap

• IAM roles and policies control what AWS services and applications can do;
• Cognito manages user identities and grants them safe, temporary access to AWS resources.

Understanding these tools is essential for secure development.

In the next section, we'll dive into Infrastructure as Code — how to automate AWS setup with code instead of clicks.