AWS Developer Encyclopedia - Full Sidebar

AWS Account Setup — Beginner to Production

What is an AWS account?

An AWS account is the security, billing, and resource boundary for AWS. Every resource belongs to an account and region. For production, do not keep everything in one account. Use multiple accounts for management, security tooling, shared services, development, staging, and production.

Step-by-step setup

1. Create the AWS account with a secure root email.
2. Enable MFA on the root user immediately.
3. Set alternate contacts for billing, operations, and security.
4. Enable billing alerts, AWS Budgets, and Cost Anomaly Detection.
5. Create IAM Identity Center for human access; avoid daily IAM users.
6. Create admin permission set for initial setup, then create least-privilege permission sets.
7. Create baseline CloudTrail, Config, GuardDuty, Security Hub, and centralized logs.
8. Use Organizations/Control Tower for multi-account governance.
9. Use separate accounts/environments for production workloads.

Developer production checklist

Official study links

• AWS Account Management docs
• AWS Organizations docs
• IAM Identity Center docs

Official AWS links for Account Setup Deep

Initial AWS Free Tier Account Setup — Beginner Safe Path

This is the first practical module a new AWS learner should complete before creating EC2, S3, Lambda, RDS, or any other service. The goal is to create the account safely, protect the root user, configure cost protection, create a developer identity, configure CLI access, and understand what can create charges.

1. What is AWS Free Tier in simple words?

AWS Free Tier is an AWS onboarding program for learning and experimentation. Current AWS documentation describes a Free account plan and a Paid account plan. The Free account plan is designed for proof-of-concept learning with credits and limited service access; the Paid account plan gives full access to AWS services and standard pay-as-you-go charges when usage exceeds credits or uses non-covered services.

Beginner recommendation: Use the Free account plan only for learning. Use the Paid plan only when you understand budgets, pricing pages, service quotas, and cleanup.

2. Before creating the account — prepare these items

• Permanent email: Use an email you will not lose. This becomes the root account email and billing/security contact.
• Strong password: Use a password manager and a unique password.
• Phone number: Keep it available for verification and future account recovery.
• Payment/identity details: AWS sign-up may require payment or identity verification depending on country and plan. Keep the billing name/address accurate.
• MFA device: Use an authenticator app or hardware security key. Do not postpone MFA.
• Region choice: Pick one primary learning region, for example us-east-1, us-west-2, or the nearest supported region. Do not create resources in many regions as a beginner.
• Cleanup notebook: Track every resource you create: service, region, name, date, cost risk, cleanup command.

3. Sign-up steps

1. Open the official AWS Free Tier page and choose to create a free account.
2. Enter root email and account name.
3. Verify the email code.
4. Enter contact information accurately.
5. Complete payment/identity/phone verification if requested.
6. Select the appropriate Free Tier plan. For learning, select the Free account plan if available in your region and scenario.
7. Choose the free/basic support option unless you intentionally need a paid support plan.
8. Sign in as root only for initial security and billing setup.

4. Immediately secure the root user

1. Open IAM → Security credentials for the root user.
2. Enable MFA for root.
3. Delete root access keys if any exist.
4. Set alternate contacts: billing, operations, security.
5. Store the root email, MFA recovery codes/process, and account ID securely.

# There is no recommended CLI setup for root daily use.
# Root should not be used for CLI development.
# Use IAM Identity Center/federation or an IAM user only for controlled learning labs.

5. Enable billing visibility and safety

Beginner accounts usually fail because resources are left running. Set cost visibility before deploying anything.

# Example: create a very small monthly cost budget with AWS CLI.
# Replace account email and amount before using.
aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{
    "BudgetName": "BeginnerMonthlyBudget",
    "BudgetLimit": {"Amount": "5", "Unit": "USD"},
    "TimeUnit": "MONTHLY",
    "BudgetType": "COST"
  }' \
  --notifications-with-subscribers '[{
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 80,
      "ThresholdType": "PERCENTAGE"
    },
    "Subscribers": [{"SubscriptionType": "EMAIL", "Address": "you@example.com"}]
  }]'

6. Create developer access safely

For professional use, use IAM Identity Center or federation. For a single beginner lab account, an IAM admin user may be used temporarily, but it should have MFA and should not be shared.

7. IAM admin setup for first learning account

1. Create an administrator identity using IAM Identity Center if possible.
2. If using IAM user for a lab, create a user like student-admin.
3. Attach AdministratorAccess only for initial learning, not production.
4. Enable MFA for that admin identity.
5. Sign out root and sign in with the admin identity for daily work.
6. Create least-privilege roles later for Lambda, EC2, S3, DynamoDB, and pipelines.

8. Install and configure AWS CLI

A developer should know both Console and CLI. Console helps you learn fields visually; CLI helps automate and debug.

# Verify AWS CLI version
aws --version

# Configure a named learning profile.
# Use access keys only for controlled labs; prefer IAM Identity Center where possible.
aws configure --profile learning

# Check who you are
aws sts get-caller-identity --profile learning

# Check your default region
aws configure get region --profile learning

9. First safe test commands

# List S3 buckets. This should not create cost.
aws s3 ls --profile learning

# Check enabled regions/account identity.
aws sts get-caller-identity --profile learning

# List Lambda functions in your chosen region. This should not create cost.
aws lambda list-functions --region us-east-1 --profile learning

# List CloudWatch log groups. This should not create cost by itself.
aws logs describe-log-groups --region us-east-1 --profile learning

10. Beginner services to practice first

11. Services beginners should be careful with

12. Required cleanup habit

Every lab should end with cleanup. A professional developer learns to delete resources by service and region.

# Example cleanup checks by region
aws lambda list-functions --region us-east-1 --profile learning
aws apigateway get-rest-apis --region us-east-1 --profile learning
aws dynamodb list-tables --region us-east-1 --profile learning
aws ec2 describe-instances --region us-east-1 --profile learning
aws elbv2 describe-load-balancers --region us-east-1 --profile learning
aws rds describe-db-instances --region us-east-1 --profile learning
aws logs describe-log-groups --region us-east-1 --profile learning

13. Initial Free Tier production mindset

• Never assume “free” means unlimited. Always check service limits and pricing.
• Use one region for beginner labs unless the lesson is explicitly about global/multi-region design.
• Tag every resource: Project, Owner, Environment, DeleteAfter.
• Set CloudWatch log retention to 1–7 days for labs.
• Prefer serverless beginner labs over always-running servers.
• Use Infrastructure as Code once you understand manual creation.
• Delete everything after practice unless you intentionally need it.

Official AWS links for Initial AWS Free Tier Account Setup

IAM Foundation — Policy, Role, Trust, PassRole

IAM is not optional. Every developer must understand IAM because every SDK/CLI/API request is evaluated by IAM. Most AWS errors in development are either AccessDenied, missing trust policy, wrong resource ARN, missing dependent action, or service control policy restriction.

Policy types

Sample service role trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Sample least-privilege policy pattern

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-app-bucket/uploads/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:us-east-1:123456789012:log-group:/aws/lambda/my-app-*:*"
    }
  ]
}

iam:PassRole

iam:PassRole is required when a developer or pipeline creates a service resource and passes an execution role to that service, for example creating Lambda with a Lambda execution role or EC2 with an instance profile. Restrict it to exact role ARNs and use condition iam:PassedToService.

Official study links

• IAM policies
• IAM roles
• Service Authorization Reference

Official AWS links for IAM Foundation Deep

Explicit AWS Service Directory — No Hidden “More” Items

This section is added because you asked for every listed service name to be shown explicitly. The service lessons included in this HTML are listed by exact name below. Select any service name to jump to that lesson.

Official AWS links for Explicit AWS Service Directory

All AWS Service Index

Use this index to jump to any service. Each service follows the same developer learning template.

Official AWS links for All AWS Service Index

AWS Account Management

1. What is AWS Account Management?

Account setup, root user protection, contacts, alternate contacts, account closure, and account-level security/billing controls.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure AWS Account Management

1. Open the AWS service console.
2. Choose the region.
3. Create the compute resource with a minimal test configuration.
4. Attach a least-privilege role.
5. Configure networking, logging, and tags.
6. Test with a small workload before production.

5. CLI / IaC starter

# Starter developer workflow for AWS Account Management
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for AWS Account Management.

6. Developer code example

// SDK pattern for AWS Account Management
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "account.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "account:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use AWS Account Management as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize account setup & cloud foundations capability across development, testing, and production accounts.
3. Integrate AWS Account Management with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for AWS Account Management

AWS Organizations

1. What is AWS Organizations?

Multi-account governance, organizational units, consolidated billing, service control policies, and delegated administration.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure AWS Organizations

1. Open the AWS service console.
2. Choose the region.
3. Create the compute resource with a minimal test configuration.
4. Attach a least-privilege role.
5. Configure networking, logging, and tags.
6. Test with a small workload before production.

5. CLI / IaC starter

# Starter developer workflow for AWS Organizations
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for AWS Organizations.

6. Developer code example

// SDK pattern for AWS Organizations
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "organizations.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "organizations:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use AWS Organizations as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize account setup & cloud foundations capability across development, testing, and production accounts.
3. Integrate AWS Organizations with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for AWS Organizations

AWS Control Tower

1. What is AWS Control Tower?

Landing zone service for governed multi-account AWS environments.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure AWS Control Tower

1. Open the AWS service console.
2. Choose the region.
3. Create the compute resource with a minimal test configuration.
4. Attach a least-privilege role.
5. Configure networking, logging, and tags.
6. Test with a small workload before production.

5. CLI / IaC starter

# Starter developer workflow for AWS Control Tower
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for AWS Control Tower.

6. Developer code example

// SDK pattern for AWS Control Tower
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "controltower.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "controltower:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use AWS Control Tower as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize account setup & cloud foundations capability across development, testing, and production accounts.
3. Integrate AWS Control Tower with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for AWS Control Tower

IAM Identity Center

1. What is IAM Identity Center?

Central workforce access to AWS accounts and applications using permission sets and federated identities.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure IAM Identity Center

1. Open the AWS service console.
2. Choose the region.
3. Create the compute resource with a minimal test configuration.
4. Attach a least-privilege role.
5. Configure networking, logging, and tags.
6. Test with a small workload before production.

5. CLI / IaC starter

# Starter developer workflow for IAM Identity Center
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for IAM Identity Center.

6. Developer code example

// SDK pattern for IAM Identity Center
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "sso.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "sso:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use IAM Identity Center as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize account setup & cloud foundations capability across development, testing, and production accounts.
3. Integrate IAM Identity Center with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for IAM Identity Center

AWS Billing

1. What is AWS Billing?

Billing console, payment methods, invoices, credits, tax settings, and account billing permissions.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure AWS Billing

1. Open the AWS service console.
2. Choose the region.
3. Create the compute resource with a minimal test configuration.
4. Attach a least-privilege role.
5. Configure networking, logging, and tags.
6. Test with a small workload before production.

5. CLI / IaC starter

# Starter developer workflow for AWS Billing
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for AWS Billing.

6. Developer code example

// SDK pattern for AWS Billing
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "aws-portal.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "aws-portal:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use AWS Billing as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize account setup & cloud foundations capability across development, testing, and production accounts.
3. Integrate AWS Billing with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for AWS Billing

AWS Budgets

1. What is AWS Budgets?

Budget thresholds and alerts for cost, usage, reservation, and savings plans tracking.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure AWS Budgets

1. Open the AWS service console.
2. Choose the region.
3. Create the compute resource with a minimal test configuration.
4. Attach a least-privilege role.
5. Configure networking, logging, and tags.
6. Test with a small workload before production.

5. CLI / IaC starter

# Starter developer workflow for AWS Budgets
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for AWS Budgets.

6. Developer code example

// SDK pattern for AWS Budgets
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "budgets.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "budgets:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use AWS Budgets as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize account setup & cloud foundations capability across development, testing, and production accounts.
3. Integrate AWS Budgets with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for AWS Budgets

AWS Cost Explorer

1. What is AWS Cost Explorer?

Interactive cost and usage analysis, forecasting, filtering, and reports.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure AWS Cost Explorer

1. Open the AWS service console.
2. Choose the region.
3. Create the compute resource with a minimal test configuration.
4. Attach a least-privilege role.
5. Configure networking, logging, and tags.
6. Test with a small workload before production.

5. CLI / IaC starter

# Starter developer workflow for AWS Cost Explorer
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for AWS Cost Explorer.

6. Developer code example

// SDK pattern for AWS Cost Explorer
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ce.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "ce:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use AWS Cost Explorer as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize account setup & cloud foundations capability across development, testing, and production accounts.
3. Integrate AWS Cost Explorer with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for AWS Cost Explorer

AWS Cost and Usage Report

1. What is AWS Cost and Usage Report?

Detailed billing dataset delivered to S3 for analytics, chargeback, and FinOps.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure AWS Cost and Usage Report

1. Open the AWS service console.
2. Choose the region.
3. Create the compute resource with a minimal test configuration.
4. Attach a least-privilege role.
5. Configure networking, logging, and tags.
6. Test with a small workload before production.

5. CLI / IaC starter

# Starter developer workflow for AWS Cost and Usage Report
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for AWS Cost and Usage Report.

6. Developer code example

// SDK pattern for AWS Cost and Usage Report
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "cur.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "cur:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use AWS Cost and Usage Report as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize account setup & cloud foundations capability across development, testing, and production accounts.
3. Integrate AWS Cost and Usage Report with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for AWS Cost and Usage Report

Savings Plans

1. What is Savings Plans?

Flexible pricing model for compute usage commitments.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure Savings Plans

1. Open the AWS service console.
2. Choose the region.
3. Create the compute resource with a minimal test configuration.
4. Attach a least-privilege role.
5. Configure networking, logging, and tags.
6. Test with a small workload before production.

5. CLI / IaC starter

# Starter developer workflow for Savings Plans
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for Savings Plans.

6. Developer code example

// SDK pattern for Savings Plans
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "savingsplans.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "savingsplans:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use Savings Plans as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize account setup & cloud foundations capability across development, testing, and production accounts.
3. Integrate Savings Plans with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for Savings Plans

AWS Compute Optimizer

1. What is AWS Compute Optimizer?

Recommendations for right-sizing compute resources.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure AWS Compute Optimizer

1. Open the AWS service console.
2. Choose the region.
3. Create the compute resource with a minimal test configuration.
4. Attach a least-privilege role.
5. Configure networking, logging, and tags.
6. Test with a small workload before production.

5. CLI / IaC starter

# Starter developer workflow for AWS Compute Optimizer
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for AWS Compute Optimizer.

6. Developer code example

// SDK pattern for AWS Compute Optimizer
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "compute-optimizer.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "compute-optimizer:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use AWS Compute Optimizer as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize account setup & cloud foundations capability across development, testing, and production accounts.
3. Integrate AWS Compute Optimizer with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for AWS Compute Optimizer

AWS Trusted Advisor

1. What is AWS Trusted Advisor?

Best-practice checks for cost, security, fault tolerance, performance, and quotas.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure AWS Trusted Advisor

1. Open the AWS service console.
2. Choose the region.
3. Create the compute resource with a minimal test configuration.
4. Attach a least-privilege role.
5. Configure networking, logging, and tags.
6. Test with a small workload before production.

5. CLI / IaC starter

# Starter developer workflow for AWS Trusted Advisor
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for AWS Trusted Advisor.

6. Developer code example

// SDK pattern for AWS Trusted Advisor
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "trustedadvisor.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "trustedadvisor:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use AWS Trusted Advisor as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize account setup & cloud foundations capability across development, testing, and production accounts.
3. Integrate AWS Trusted Advisor with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for AWS Trusted Advisor

AWS Health

1. What is AWS Health?

Personalized AWS service health events for your account and resources.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure AWS Health

1. Open the AWS service console.
2. Choose the region.
3. Create the compute resource with a minimal test configuration.
4. Attach a least-privilege role.
5. Configure networking, logging, and tags.
6. Test with a small workload before production.

5. CLI / IaC starter

# Starter developer workflow for AWS Health
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for AWS Health.

6. Developer code example

// SDK pattern for AWS Health
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "health.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "health:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use AWS Health as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize account setup & cloud foundations capability across development, testing, and production accounts.
3. Integrate AWS Health with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for AWS Health

AWS Identity and Access Management (IAM)

1. What is AWS Identity and Access Management (IAM)?

IAM is the AWS permission system. It decides who can do what on which AWS resources, under what conditions.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure AWS Identity and Access Management (IAM)

1. Create IAM Identity Center for humans where possible.
2. Create roles for workloads and services.
3. Write policy with exact actions/resources.
4. Add trust policy for who can assume the role.
5. Test access using policy simulator/Access Analyzer.
6. Log all IAM/API activity with CloudTrail.

5. CLI / IaC starter

aws iam create-role --role-name app-readonly-role --assume-role-policy-document file://trust.json
aws iam put-role-policy --role-name app-readonly-role --policy-name readonly --policy-document file://policy.json
aws sts assume-role --role-arn arn:aws:iam::123456789012:role/app-readonly-role --role-session-name test

6. Developer code example

{
  "Version": "2012-10-17",
  "Statement": [
    {"Effect":"Allow","Action":["s3:GetObject"],"Resource":"arn:aws:s3:::my-bucket/reports/*"},
    {"Effect":"Deny","Action":"*","Resource":"*","Condition":{"BoolIfExists":{"aws:MultiFactorAuthPresent":"false"}}}
  ]
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "iam.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "iam:CreateRole",
        "iam:AttachRolePolicy",
        "iam:PutRolePolicy",
        "iam:PassRole",
        "iam:GetRole",
        "iam:ListRoles",
        "sts:AssumeRole"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Secure developer access across multiple teams.
2. Create service execution roles for Lambda, EC2, ECS, Glue, SageMaker, Connect, and CI/CD.
3. Implement governance with permissions boundaries, SCPs, and Access Analyzer.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for AWS Identity and Access Management (IAM)

AWS Key Management Service (KMS)

1. What is AWS Key Management Service (KMS)?

Managed encryption key service for AWS-integrated cryptography and customer managed keys.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure AWS Key Management Service (KMS)

1. Define principals and resources.
2. Create least-privilege policies.
3. Enable audit trails and findings.
4. Test allowed and denied access.
5. Automate remediation where safe.
6. Review permissions regularly.

5. CLI / IaC starter

# Starter developer workflow for AWS Key Management Service (KMS)
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for AWS Key Management Service (KMS).

6. Developer code example

// SDK pattern for AWS Key Management Service (KMS)
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "kms.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "kms:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use AWS Key Management Service (KMS) as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize security, identity & compliance capability across development, testing, and production accounts.
3. Integrate AWS Key Management Service (KMS) with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for AWS Key Management Service (KMS)

AWS Secrets Manager

1. What is AWS Secrets Manager?

Secure storage, retrieval, and rotation of database credentials, API keys, and secrets.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure AWS Secrets Manager

1. Define principals and resources.
2. Create least-privilege policies.
3. Enable audit trails and findings.
4. Test allowed and denied access.
5. Automate remediation where safe.
6. Review permissions regularly.

5. CLI / IaC starter

# Starter developer workflow for AWS Secrets Manager
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for AWS Secrets Manager.

6. Developer code example

// SDK pattern for AWS Secrets Manager
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "secretsmanager.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "secretsmanager:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use AWS Secrets Manager as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize security, identity & compliance capability across development, testing, and production accounts.
3. Integrate AWS Secrets Manager with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for AWS Secrets Manager

AWS Certificate Manager (ACM)

1. What is AWS Certificate Manager (ACM)?

Provision and manage public/private TLS certificates for AWS-integrated services.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure AWS Certificate Manager (ACM)

1. Define principals and resources.
2. Create least-privilege policies.
3. Enable audit trails and findings.
4. Test allowed and denied access.
5. Automate remediation where safe.
6. Review permissions regularly.

5. CLI / IaC starter

# Starter developer workflow for AWS Certificate Manager (ACM)
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for AWS Certificate Manager (ACM).

6. Developer code example

// SDK pattern for AWS Certificate Manager (ACM)
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "acm.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "acm:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use AWS Certificate Manager (ACM) as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize security, identity & compliance capability across development, testing, and production accounts.
3. Integrate AWS Certificate Manager (ACM) with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for AWS Certificate Manager (ACM)

Amazon Cognito

1. What is Amazon Cognito?

Authentication, authorization, user pools, identity pools, federation, and app user management.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure Amazon Cognito

1. Define principals and resources.
2. Create least-privilege policies.
3. Enable audit trails and findings.
4. Test allowed and denied access.
5. Automate remediation where safe.
6. Review permissions regularly.

5. CLI / IaC starter

# Starter developer workflow for Amazon Cognito
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for Amazon Cognito.

6. Developer code example

// SDK pattern for Amazon Cognito
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "cognito-idp.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "cognito-idp:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use Amazon Cognito as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize security, identity & compliance capability across development, testing, and production accounts.
3. Integrate Amazon Cognito with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for Amazon Cognito

AWS Directory Service

1. What is AWS Directory Service?

Managed Microsoft AD and directory integrations for AWS workloads.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure AWS Directory Service

1. Define principals and resources.
2. Create least-privilege policies.
3. Enable audit trails and findings.
4. Test allowed and denied access.
5. Automate remediation where safe.
6. Review permissions regularly.

5. CLI / IaC starter

# Starter developer workflow for AWS Directory Service
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for AWS Directory Service.

6. Developer code example

// SDK pattern for AWS Directory Service
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ds.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "ds:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use AWS Directory Service as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize security, identity & compliance capability across development, testing, and production accounts.
3. Integrate AWS Directory Service with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for AWS Directory Service

AWS CloudHSM

1. What is AWS CloudHSM?

Dedicated hardware security modules for cryptographic key control.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure AWS CloudHSM

1. Define principals and resources.
2. Create least-privilege policies.
3. Enable audit trails and findings.
4. Test allowed and denied access.
5. Automate remediation where safe.
6. Review permissions regularly.

5. CLI / IaC starter

# Starter developer workflow for AWS CloudHSM
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for AWS CloudHSM.

6. Developer code example

// SDK pattern for AWS CloudHSM
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudhsm.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "cloudhsm:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use AWS CloudHSM as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize security, identity & compliance capability across development, testing, and production accounts.
3. Integrate AWS CloudHSM with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for AWS CloudHSM

AWS WAF

1. What is AWS WAF?

Web application firewall for HTTP/S request filtering and application-layer protections.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure AWS WAF

1. Define principals and resources.
2. Create least-privilege policies.
3. Enable audit trails and findings.
4. Test allowed and denied access.
5. Automate remediation where safe.
6. Review permissions regularly.

5. CLI / IaC starter

# Starter developer workflow for AWS WAF
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for AWS WAF.

6. Developer code example

// SDK pattern for AWS WAF
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "waf.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "waf:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use AWS WAF as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize security, identity & compliance capability across development, testing, and production accounts.
3. Integrate AWS WAF with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for AWS WAF

AWS Shield

1. What is AWS Shield?

DDoS protection for AWS applications.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure AWS Shield

1. Define principals and resources.
2. Create least-privilege policies.
3. Enable audit trails and findings.
4. Test allowed and denied access.
5. Automate remediation where safe.
6. Review permissions regularly.

5. CLI / IaC starter

# Starter developer workflow for AWS Shield
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for AWS Shield.

6. Developer code example

// SDK pattern for AWS Shield
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "shield.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "shield:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use AWS Shield as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize security, identity & compliance capability across development, testing, and production accounts.
3. Integrate AWS Shield with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for AWS Shield

AWS Firewall Manager

1. What is AWS Firewall Manager?

Central management for firewall rules across accounts and resources.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure AWS Firewall Manager

1. Define principals and resources.
2. Create least-privilege policies.
3. Enable audit trails and findings.
4. Test allowed and denied access.
5. Automate remediation where safe.
6. Review permissions regularly.

5. CLI / IaC starter

# Starter developer workflow for AWS Firewall Manager
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for AWS Firewall Manager.

6. Developer code example

// SDK pattern for AWS Firewall Manager
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "fms.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "fms:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use AWS Firewall Manager as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize security, identity & compliance capability across development, testing, and production accounts.
3. Integrate AWS Firewall Manager with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for AWS Firewall Manager

Amazon GuardDuty

1. What is Amazon GuardDuty?

Threat detection service using logs, DNS activity, and ML-based findings.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure Amazon GuardDuty

1. Define principals and resources.
2. Create least-privilege policies.
3. Enable audit trails and findings.
4. Test allowed and denied access.
5. Automate remediation where safe.
6. Review permissions regularly.

5. CLI / IaC starter

# Starter developer workflow for Amazon GuardDuty
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for Amazon GuardDuty.

6. Developer code example

// SDK pattern for Amazon GuardDuty
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "guardduty.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "guardduty:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use Amazon GuardDuty as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize security, identity & compliance capability across development, testing, and production accounts.
3. Integrate Amazon GuardDuty with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for Amazon GuardDuty

AWS Security Hub

1. What is AWS Security Hub?

Central security posture and findings aggregation.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure AWS Security Hub

1. Define principals and resources.
2. Create least-privilege policies.
3. Enable audit trails and findings.
4. Test allowed and denied access.
5. Automate remediation where safe.
6. Review permissions regularly.

5. CLI / IaC starter

# Starter developer workflow for AWS Security Hub
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for AWS Security Hub.

6. Developer code example

// SDK pattern for AWS Security Hub
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "securityhub.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "securityhub:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use AWS Security Hub as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize security, identity & compliance capability across development, testing, and production accounts.
3. Integrate AWS Security Hub with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for AWS Security Hub

Amazon Inspector

1. What is Amazon Inspector?

Automated vulnerability management for EC2, container images, and Lambda.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure Amazon Inspector

1. Define principals and resources.
2. Create least-privilege policies.
3. Enable audit trails and findings.
4. Test allowed and denied access.
5. Automate remediation where safe.
6. Review permissions regularly.

5. CLI / IaC starter

# Starter developer workflow for Amazon Inspector
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for Amazon Inspector.

6. Developer code example

// SDK pattern for Amazon Inspector
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "inspector2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "inspector2:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use Amazon Inspector as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize security, identity & compliance capability across development, testing, and production accounts.
3. Integrate Amazon Inspector with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for Amazon Inspector

Amazon Macie

1. What is Amazon Macie?

Sensitive data discovery and classification for S3.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure Amazon Macie

1. Define principals and resources.
2. Create least-privilege policies.
3. Enable audit trails and findings.
4. Test allowed and denied access.
5. Automate remediation where safe.
6. Review permissions regularly.

5. CLI / IaC starter

# Starter developer workflow for Amazon Macie
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for Amazon Macie.

6. Developer code example

// SDK pattern for Amazon Macie
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "macie2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "macie2:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use Amazon Macie as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize security, identity & compliance capability across development, testing, and production accounts.
3. Integrate Amazon Macie with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for Amazon Macie

Amazon Detective

1. What is Amazon Detective?

Security investigation graphs and behavior analysis.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure Amazon Detective

1. Define principals and resources.
2. Create least-privilege policies.
3. Enable audit trails and findings.
4. Test allowed and denied access.
5. Automate remediation where safe.
6. Review permissions regularly.

5. CLI / IaC starter

# Starter developer workflow for Amazon Detective
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for Amazon Detective.

6. Developer code example

// SDK pattern for Amazon Detective
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "detective.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "detective:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use Amazon Detective as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize security, identity & compliance capability across development, testing, and production accounts.
3. Integrate Amazon Detective with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for Amazon Detective

AWS Audit Manager

1. What is AWS Audit Manager?

Evidence collection and audit assessment automation.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure AWS Audit Manager

1. Define principals and resources.
2. Create least-privilege policies.
3. Enable audit trails and findings.
4. Test allowed and denied access.
5. Automate remediation where safe.
6. Review permissions regularly.

5. CLI / IaC starter

# Starter developer workflow for AWS Audit Manager
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for AWS Audit Manager.

6. Developer code example

// SDK pattern for AWS Audit Manager
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "auditmanager.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "auditmanager:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use AWS Audit Manager as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize security, identity & compliance capability across development, testing, and production accounts.
3. Integrate AWS Audit Manager with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for AWS Audit Manager

AWS Artifact

1. What is AWS Artifact?

On-demand access to AWS compliance reports and agreements.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure AWS Artifact

1. Define principals and resources.
2. Create least-privilege policies.
3. Enable audit trails and findings.
4. Test allowed and denied access.
5. Automate remediation where safe.
6. Review permissions regularly.

5. CLI / IaC starter

# Starter developer workflow for AWS Artifact
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for AWS Artifact.

6. Developer code example

// SDK pattern for AWS Artifact
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "artifact.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "artifact:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use AWS Artifact as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize security, identity & compliance capability across development, testing, and production accounts.
3. Integrate AWS Artifact with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for AWS Artifact

AWS Network Firewall

1. What is AWS Network Firewall?

Managed network firewall for VPC traffic inspection.

2. Concepts you must know

3. Capabilities and when to use them

4. How to create/configure AWS Network Firewall

1. Define principals and resources.
2. Create least-privilege policies.
3. Enable audit trails and findings.
4. Test allowed and denied access.
5. Automate remediation where safe.
6. Review permissions regularly.

5. CLI / IaC starter

# Starter developer workflow for AWS Network Firewall
aws configure sso  # recommended for human access
aws sts get-caller-identity
# Use the service console or CloudFormation/CDK first.
# Check official docs for the exact CLI create command and required parameters for AWS Network Firewall.

6. Developer code example

// SDK pattern for AWS Network Firewall
// Replace ServiceClient and Command with the specific AWS SDK v3 client/command.
// Always catch AccessDenied, Throttling, ValidationException, and networking errors.
async function callAwsService(client, command) {
  try {
    const result = await client.send(command);
    return result;
  } catch (err) {
    console.error('AWS error:', err.name, err.message);
    throw err;
  }
}

7. IAM role design

Create separate permissions for: human developers, CI/CD deployment pipelines, and runtime/service execution. Use IAM Identity Center or federation for humans. Use roles for workloads. Avoid long-lived access keys.

8. Sample trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "network-firewall.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

9. Sample permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceDeveloperAccess",
      "Effect": "Allow",
      "Action": [
        "network-firewall:*"
      ],
      "Resource": "*"
    }
  ]
}

10. Integrations and triggers

• IAM
• CloudTrail
• CloudWatch
• KMS where supported
• AWS CLI/SDK
• CloudFormation/CDK/Terraform

11. Monitoring, metrics, logs, and audit

• CloudTrail: audit who called create/update/delete/list APIs.
• CloudWatch metrics: track service health, errors, throttling, latency, utilization, and custom KPIs.
• CloudWatch Logs or service logs: enable where supported and set retention.
• Alarms: create alarms for errors, throttles, rejected requests, unhealthy resources, and cost anomalies.
• Dashboards: create service-specific views for developers and operations.

12. Security and production design

• Use least privilege IAM and deny risky actions in production.
• Use KMS encryption where the service stores sensitive data.
• Use private networking/VPC endpoints where supported.
• Separate dev/test/prod accounts or environments.
• Use tags for cost, owner, environment, application, and data classification.
• Define backup, restore, retry, DLQ, failover, and incident response procedures.

13. Business use cases

1. Use AWS Network Firewall as a managed service instead of building and operating equivalent infrastructure yourself.
2. Standardize security, identity & compliance capability across development, testing, and production accounts.
3. Integrate AWS Network Firewall with IAM, CloudTrail, CloudWatch, KMS, and IaC to meet production governance requirements.

14. Common mistakes and fixes

15. Beginner-to-expert practice path

1. Beginner: create a demo resource manually and understand every field.
2. Junior developer: repeat the same setup using AWS CLI.
3. Developer: build a small app that uses the service through SDK/API.
4. Production developer: move setup to IaC, add IAM least privilege, logs, metrics, alarms, retries, and runbooks.
5. Expert: design multi-account, multi-region, cost-optimized, compliant architecture with failure testing.

Official AWS links for AWS Network Firewall

AWS Resource Access Manager (RAM)

1. What is AWS Resource Access Manager (RAM)?

Share AWS resources across accounts or organizations.

2. Concepts you must know