0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@ysit

AWSクレデンシャルはどこから読まれる？ - 取得元と優先順位

0
Posted at

はじめに

「aws s3 ls を実行したら、なぜか別のアカウントに繋がってしまった」
「環境変数で AWS_ACCESS_KEY_ID を設定したのに、なぜか .aws/credentials の値が使われている」

こんな経験はありませんか？

AWS CLIやSDKは、コマンド実行時に複数の場所からクレデンシャルを探索し、決められた優先順位に従って使用します。この仕組みを「Credential Provider Chain（クレデンシャルプロバイダーチェーン）」と呼びます。

本記事では、AWS CLIの公式ドキュメントに基づき、クレデンシャルがどこから、どの順序で読み込まれるのかを徹底解説します。

本記事は AWS CLI v2 および Boto3 (Python SDK) の動作を基に解説しています。他のSDK（JavaScript、Java等）も基本的に同じ優先順位ですが、詳細は各SDKのドキュメントをご確認ください。

クレデンシャルプロバイダーチェーンとは

AWS CLIやSDKがクレデンシャルを必要とする際、以下の10箇所を順番に探索します。

1. コマンドラインオプション
   ↓
2. 環境変数
   ↓
3. IAMロール引き継ぎ（assume-role）
   ↓
4. Webアイデンティティを使用したロール引き継ぎ
   ↓
5. IAM Identity Center（旧AWS SSO）
   ↓
6. クレデンシャルファイル（~/.aws/credentials）
   ↓
7. カスタムプロセス（credential_process）
   ↓
8. 設定ファイル（~/.aws/config）
   ↓
9. コンテナクレデンシャル（ECS Task Role）
   ↓
10. EC2インスタンスプロファイル（IMDSv2）

最初に見つかったクレデンシャルが使用され、それ以降の探索は行われません。

優先順位の詳細

1. コマンドラインオプション【最優先】

コマンド実行時に直接指定するオプションが最も優先されます。

# プロファイルを明示的に指定
aws s3 ls --profile production

# リージョンを上書き
aws ec2 describe-instances --region us-east-1

# 複数オプションの組み合わせ
aws s3 cp file.txt s3://my-bucket/ --profile dev --region ap-northeast-1
オプション 説明 例
--profile 使用するプロファイル名 --profile dev
--region リージョン指定 --region ap-northeast-1
--output 出力形式 --output json

ユースケース: 本番環境で誤操作を防ぐため、明示的にプロファイルを指定する場合。

重要: コマンドラインオプションは環境変数よりも優先されますが、認証情報そのもの（アクセスキー）は指定できません。プロファイル名やリージョンの指定に限定されます。

2. 環境変数

シェルの環境変数に設定されたクレデンシャルが次に優先されます。

主要な環境変数

環境変数 説明 例
AWS_ACCESS_KEY_ID アクセスキーID AKIAIOSF...
AWS_SECRET_ACCESS_KEY シークレットアクセスキー wJalrXUtnFEMI/K7M...
AWS_SESSION_TOKEN セッショントークン（一時認証情報） IQoJb3JpZ2luX2...
AWS_PROFILE 使用するプロファイル名 production
AWS_DEFAULT_REGION デフォルトリージョン ap-northeast-1
AWS_CONFIG_FILE 設定ファイルのカスタムパス /custom/path/config
AWS_SHARED_CREDENTIALS_FILE クレデンシャルファイルのカスタムパス /custom/path/credentials

設定例

# Linux/macOS
export AWS_ACCESS_KEY_ID=AKIAIOSF...
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7M...
export AWS_DEFAULT_REGION=ap-northeast-1

# Windows (PowerShell)
$env:AWS_ACCESS_KEY_ID="AKIAIOSF..."
$env:AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7M..."
$env:AWS_DEFAULT_REGION="ap-northeast-1"

# Windows (コマンドプロンプト)
set AWS_ACCESS_KEY_ID=AKIAIOSF...
set AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7M...

ユースケース: CI/CDパイプライン（GitHub Actions、GitLab CI等）でシークレット管理機能を使ってクレデンシャルを注入する場合。

環境変数にアクセスキーを設定する方法は、シェル履歴に残る可能性があるため、本番環境では推奨されません。一時的なテストやCI/CD環境での利用に限定してください。

3. IAMロール引き継ぎ（assume-role）

~/.aws/config で role_arn と source_profile を指定することで、別のIAMロールの権限を引き継ぐことができます。

設定例

~/.aws/credentials

[base-account]
aws_access_key_id = AKIAIOSF...
aws_secret_access_key = wJalrXUtnFEMI/K7M...

~/.aws/config

[profile production-admin]
role_arn = arn:aws:iam::123456789012:role/ProductionAdminRole
source_profile = base-account
region = us-east-1

使用方法

aws sts get-caller-identity --profile production-admin

ユースケース: マルチアカウント環境で、1つの基盤アカウントから複数の本番アカウントにスイッチロールする場合。

MFAを要求する場合

[profile production-admin]
role_arn = arn:aws:iam::123456789012:role/ProductionAdminRole
source_profile = base-account
mfa_serial = arn:aws:iam::999999999999:mfa/your-user
region = us-east-1

初回実行時にMFAトークンの入力が求められます。

4. Webアイデンティティを使用したロール引き継ぎ

OIDC（OpenID Connect）プロバイダー経由でIAMロールを引き継ぐ方法です。アクセスキーを発行せずに、外部サービスからAWSリソースに安全にアクセスできます。

主な利用シーン

シーン プロバイダー 用途
GitHub Actions GitHub OIDC CI/CDパイプライン
GitLab CI/CD GitLab OIDC CI/CDパイプライン
EKS Pod Identity Kubernetes ServiceAccount コンテナアプリケーション
Google Workspace Google OIDC 外部ID連携
Azure AD Microsoft OIDC 外部ID連携

GitHub Actions での設定例

1. AWS側の設定（IAMロール作成）

# GitHub OIDCプロバイダーを作成（初回のみ）
aws iam create-open-id-connect-provider \
  --url https://token.actions.githubusercontent.com \
  --client-id-list sts.amazonaws.com \
  --thumbprint-list 6938fd4d98bab03faadb97b34396831e3780aea1

# 信頼ポリシーを作成
cat > trust-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:yourorg/yourrepo:*"
        }
      }
    }
  ]
}
EOF

# IAMロールを作成
aws iam create-role \
  --role-name GitHubActionsRole \
  --assume-role-policy-document file://trust-policy.json

2. GitHub Actions ワークフロー

# .github/workflows/deploy.yml
name: Deploy to AWS

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest

    # OIDC トークン発行に必要な権限
    permissions:
      id-token: write
      contents: read

    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
          aws-region: ap-northeast-1
          # オプション: セッション名をカスタマイズ
          role-session-name: GitHubActions-${{ github.run_id }}

      - name: Deploy to S3
        run: |
          aws s3 sync ./dist s3://my-bucket/
          aws cloudfront create-invalidation --distribution-id E1234567890ABC --paths "/*"

GitLab CI/CD での設定例

# .gitlab-ci.yml
deploy:
  stage: deploy
  image: amazon/aws-cli:latest
  id_tokens:
    GITLAB_OIDC_TOKEN:
      aud: https://gitlab.com
  before_script:
    - >
      export $(printf "AWS_ACCESS_KEY_ID=%s AWS_SECRET_ACCESS_KEY=%s AWS_SESSION_TOKEN=%s"
      $(aws sts assume-role-with-web-identity
      --role-arn arn:aws:iam::123456789012:role/GitLabRole
      --role-session-name "GitLab-${CI_PIPELINE_ID}"
      --web-identity-token $GITLAB_OIDC_TOKEN
      --duration-seconds 3600
      --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]'
      --output text))
  script:
    - aws s3 sync ./dist s3://my-bucket/

EKS Pod Identity での設定例

# Kubernetes ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: default
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/MyAppRole

---
# Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    spec:
      serviceAccountName: my-app-sa
      containers:
      - name: app
        image: my-app:latest
        # アプリケーション内でaws-sdkを使用すると自動的にIAMロールを使用

ユースケース:

  • GitHub Actions/GitLab CI: アクセスキーをシークレットに保存せず、CI/CDからAWSにアクセス
  • EKS Pod Identity: Kubernetes Pod に IAM ロールを付与
  • 外部ID連携: Google Workspace や Azure AD のアカウントで AWS にアクセス

OIDC連携のメリット

  1. アクセスキー不要 - 長期的な認証情報を管理する必要がない
  2. 自動ローテーション - トークンが短期間で自動的に期限切れになる
  3. 最小権限の原則 - リポジトリやブランチ単位で権限を制限可能
  4. 監査性の向上 - CloudTrailでセッション名からどのパイプラインが実行したか追跡可能

5. IAM Identity Center（旧 AWS SSO）

複数のAWSアカウントに対して、ブラウザ経由でシングルサインオン（SSO）を行う仕組みです。

初期設定

aws configure sso

対話的に以下を入力します：

  • SSO開始URL（例: https://my-company.awsapps.com/start）
  • SSOリージョン（例: us-east-1）
  • アカウントIDとロール名

設定ファイル例

~/.aws/config

[profile dev]
sso_session = my-sso
sso_account_id = 111122223333
sso_role_name = DeveloperRole
region = ap-northeast-1

[profile prod]
sso_session = my-sso
sso_account_id = 444455556666
sso_role_name = ReadOnlyRole
region = us-east-1

[sso-session my-sso]
sso_region = us-east-1
sso_start_url = https://my-company.awsapps.com/start
sso_registration_scopes = sso:account:access

ログイン

# 初回ログイン（ブラウザが起動）
aws sso login --profile dev

# コマンド実行
aws s3 ls --profile dev

ユースケース: 大規模組織で複数のAWSアカウントを管理し、統一されたID基盤（Azure AD、Okta等）でアクセス制御する場合。

6. クレデンシャルファイル（~/.aws/credentials）

aws configure で設定される、最も一般的なクレデンシャル保存場所です。

ファイルの場所

OS パス
Linux/macOS ~/.aws/credentials
Windows C:\Users\USERNAME\.aws\credentials

ファイル形式

[default]
aws_access_key_id = AKIAIOSF...
aws_secret_access_key = wJalrXUtnFEMI/K7M...

[dev]
aws_access_key_id = AKIAI44Q...
aws_secret_access_key = je7MtGbClwBF/2Zp9...

[prod]
aws_access_key_id = AKIAIXAK...
aws_secret_access_key = Xk8G/9vN2Fg5Hj4Kl...

プロファイルの使い分け

# デフォルトプロファイル（[default]）を使用
aws s3 ls

# 特定のプロファイルを指定
aws s3 ls --profile dev

# 環境変数でプロファイルを指定
export AWS_PROFILE=prod
aws s3 ls

ユースケース: 個人の開発環境で、複数のAWSアカウント（開発・検証・本番）を切り替えながら作業する場合。

セキュリティ上の注意

  • ファイルのパーミッションを 600（所有者のみ読み書き可能）に設定してください。 
    chmod 600 ~/.aws/credentials
  • 絶対にGitリポジトリにコミットしないでください。 .gitignore に .aws/ を追加することを推奨します。

7. カスタムプロセス（credential_process）

外部プログラムを実行してクレデンシャルを取得する仕組みです。

設定例

~/.aws/config

[profile custom]
credential_process = /opt/bin/awscreds-custom-retriever
region = ap-northeast-1

外部プログラムの要件

JSON形式で以下を出力する必要があります：

{
  "Version": 1,
  "AccessKeyId": "ASIAIOSFODNN7EXAMPLE",
  "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
  "SessionToken": "IQoJb3JpZ2luX2...",
  "Expiration": "2026-02-15T12:00:00Z"
}

ユースケース:

  • 1Password CLI、AWS Vault、Leapp等のクレデンシャル管理ツールと統合
  • 企業独自のシークレット管理システムと連携

実例: aws-vault

# aws-vaultでプロファイルを設定
aws-vault add myprofile

# ~/.aws/config
[profile myprofile]
credential_process = aws-vault exec myprofile --json

8. 設定ファイル（~/.aws/config）

クレデンシャルファイルで認証情報が見つからない場合、~/.aws/config からも読み取りを試みます。

ファイル形式

[default]
region = ap-northeast-1
output = json

[profile dev]
region = us-west-2
output = yaml
aws_access_key_id = AKIAI44Q...
aws_secret_access_key = je7MtGbClwBF/2...

credentials と config の使い分け

ファイル 用途 セクション名
~/.aws/credentials 認証情報専用 [default], [dev]
~/.aws/config 設定全般（認証情報も可） [default], [profile dev]

ベストプラクティス: 認証情報は credentials に、リージョンや出力形式は config に分けて管理することを推奨します。

9. コンテナクレデンシャル（ECS Task Role / EKS Pod Identity）

コンテナ環境で実行されるアプリケーションに、自動的にIAMロールを付与する仕組みです。

9-1. ECS Task Role（Amazon ECS）

Amazon ECS（Elastic Container Service）のタスク定義で指定したIAMロールから、自動的にクレデンシャルを取得します。

仕組み
  1. ECSタスク定義で taskRoleArn を指定
  2. コンテナ起動時に環境変数 AWS_CONTAINER_CREDENTIALS_RELATIVE_URI が自動設定される
  3. AWS SDKが http://169.254.170.2 + URI からクレデンシャルを取得
タスク定義例（JSON）
{
  "family": "my-app",
  "taskRoleArn": "arn:aws:iam::123456789012:role/MyAppTaskRole",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "networkMode": "awsvpc",
  "containerDefinitions": [
    {
      "name": "app",
      "image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest",
      "memory": 512,
      "cpu": 256,
      "essential": true,
      "portMappings": [
        {
          "containerPort": 8080,
          "protocol": "tcp"
        }
      ]
    }
  ],
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512"
}
タスク定義例（Terraform）
resource "aws_ecs_task_definition" "app" {
  family                   = "my-app"
  network_mode             = "awsvpc"
  requires_compatibilities = ["FARGATE"]
  cpu                      = "256"
  memory                   = "512"

  # アプリケーション用のIAMロール（S3、DynamoDB等へのアクセス権限）
  task_role_arn      = aws_iam_role.app_task_role.arn

  # ECS実行用のIAMロール（ECRプル、CloudWatchログ書き込み権限）
  execution_role_arn = aws_iam_role.ecs_task_execution_role.arn

  container_definitions = jsonencode([
    {
      name      = "app"
      image     = "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest"
      essential = true
      portMappings = [
        {
          containerPort = 8080
          protocol      = "tcp"
        }
      ]
    }
  ])
}
確認方法
# ECSコンテナ内で実行
echo $AWS_CONTAINER_CREDENTIALS_RELATIVE_URI
# 出力例: /v2/credentials/abc123-def456-ghi789

# クレデンシャルを取得（通常はSDKが自動実行）
curl http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI

# 現在のロールを確認
aws sts get-caller-identity
出力例
{
  "AccessKeyId": "ASIAIOSF...",
  "SecretAccessKey": "wJalrXUtnFEMI...",
  "Token": "IQoJb3JpZ2luX2...",
  "Expiration": "2026-02-15T12:30:00Z"
}

9-2. EKS Pod Identity（Amazon EKS）

Amazon EKS（Elastic Kubernetes Service）で、Kubernetes PodにIAMロールを付与する仕組みです。

仕組み（IRSA - IAM Roles for Service Accounts）
  1. Kubernetes ServiceAccount に IAM ロールを紐付け
  2. Pod 起動時に環境変数 AWS_WEB_IDENTITY_TOKEN_FILE と AWS_ROLE_ARN が自動設定される
  3. AWS SDKがトークンファイルを読み込み、AssumeRoleWithWebIdentity を実行
ServiceAccount + Deployment の設定例
# ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: default
  annotations:
    # EKSが自動的にこのIAMロールを使用
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/MyAppRole

---
# Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      serviceAccountName: my-app-sa  # 重要: ServiceAccountを指定
      containers:
      - name: app
        image: my-app:latest
        ports:
        - containerPort: 8080
        env:
        - name: AWS_REGION
          value: ap-northeast-1
IAMロール設定（Terraform）
# OIDCプロバイダーのデータソース
data "aws_eks_cluster" "cluster" {
  name = "my-eks-cluster"
}

data "tls_certificate" "eks" {
  url = data.aws_eks_cluster.cluster.identity[0].oidc[0].issuer
}

resource "aws_iam_openid_connect_provider" "eks" {
  url             = data.aws_eks_cluster.cluster.identity[0].oidc[0].issuer
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = [data.tls_certificate.eks.certificates[0].sha1_fingerprint]
}

# ServiceAccount用のIAMロール
resource "aws_iam_role" "my_app_role" {
  name = "MyAppRole"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Principal = {
          Federated = aws_iam_openid_connect_provider.eks.arn
        }
        Action = "sts:AssumeRoleWithWebIdentity"
        Condition = {
          StringEquals = {
            "${replace(data.aws_eks_cluster.cluster.identity[0].oidc[0].issuer, "https://", "")}:sub" = "system:serviceaccount:default:my-app-sa"
            "${replace(data.aws_eks_cluster.cluster.identity[0].oidc[0].issuer, "https://", "")}:aud" = "sts.amazonaws.com"
          }
        }
      }
    ]
  })
}

# S3アクセス権限を付与
resource "aws_iam_role_policy_attachment" "my_app_s3" {
  role       = aws_iam_role.my_app_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess"
}
確認方法
# Pod内で実行
kubectl exec -it my-app-pod -- /bin/bash

# 環境変数を確認
echo $AWS_ROLE_ARN
# arn:aws:iam::123456789012:role/MyAppRole

echo $AWS_WEB_IDENTITY_TOKEN_FILE
# /var/run/secrets/eks.amazonaws.com/serviceaccount/token

# トークンファイルの内容を確認
cat $AWS_WEB_IDENTITY_TOKEN_FILE

# 現在のロールを確認
aws sts get-caller-identity

ユースケース:

  • ECS Fargate/EC2: コンテナアプリケーションにS3、DynamoDB、SQS等へのアクセス権限を付与
  • EKS Pod: Kubernetes環境でアプリケーションにIAMロールを付与
  • マイクロサービス: サービスごとに異なるIAMロールを割り当て、最小権限の原則を実現

Task Role vs Execution Role（ECS）

ロール 用途 権限例
Task Role アプリケーションが使用 S3、DynamoDB、SQS等へのアクセス
Execution Role ECSサービスが使用 ECRからイメージをプル、CloudWatchにログを書き込み

必ず両方を設定してください。

10. EC2インスタンスプロファイル（IMDSv2）

EC2インスタンスに紐付けられたIAMロールから、メタデータサービス経由でクレデンシャルを取得します。

仕組み

  1. EC2起動時にインスタンスプロファイル（IAMロール）を指定
  2. インスタンスメタデータサービス（IMDS）がクレデンシャルを提供
  3. AWS CLIやSDKが自動的に http://169.254.169.254/ にアクセス

IMDSv2での取得方法

# 1. トークンを取得（セキュリティ強化版）
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# 2. ロール名を取得
ROLE_NAME=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/)

# 3. クレデンシャルを取得
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME

出力例

{
  "Code": "Success",
  "LastUpdated": "2026-02-15T06:30:00Z",
  "Type": "AWS-HMAC",
  "AccessKeyId": "ASIAIOSF...",
  "SecretAccessKey": "wJalrXUtnFEMI/K7M...",
  "Token": "IQoJb3JpZ2luX2...",
  "Expiration": "2026-02-15T12:45:00Z"
}

ユースケース: EC2インスタンス上でアプリケーションを動かす際、アクセスキーを管理せずにAWSリソースにアクセスする場合。

IMDSv1 vs IMDSv2

バージョン 特徴 セキュリティ
IMDSv1 トークン不要、GETリクエストのみ SSRF攻撃のリスクあり
IMDSv2 トークンベース認証、PUTでトークン取得 セキュアな設計（推奨）

2024年以降、IMDSv2の使用が強く推奨されています。

優先順位の一覧表

順位 取得元 設定方法 主な用途
1 コマンドラインオプション --profile, --region 一時的な上書き
2 環境変数 AWS_ACCESS_KEY_ID 等 CI/CD、一時的なテスト
3 IAMロール引き継ぎ role_arn, source_profile マルチアカウント環境
4 Webアイデンティティ OIDC連携 GitHub Actions、EKS
5 IAM Identity Center aws configure sso 大規模組織のSSO
6 クレデンシャルファイル ~/.aws/credentials 個人開発環境
7 カスタムプロセス credential_process 外部ツール統合
8 設定ファイル ~/.aws/config リージョン設定等
9 コンテナクレデンシャル ECS Task Role ECS Fargate/EC2
10 EC2インスタンスプロファイル IMDS EC2上のアプリケーション

クレデンシャル設定コマンドの解説

AWS CLIには、クレデンシャルを設定・管理するための複数のコマンドがあります。これらのコマンドがクレデンシャルプロバイダーチェーンのどこに影響するかを理解することが重要です。

aws login - Console認証情報を使用したログイン【NEW】

AWS CLI v2.32.0以降で追加された新しいコマンドです。AWS Management Consoleの既存の認証情報を使用して、ローカル開発環境に一時的な認証情報を自動生成します。

特徴

  • 長期アクセスキーが不要 - Console認証のみで一時認証情報を取得
  • 自動リフレッシュ - 最大12時間有効（15分ごとに自動更新）
  • シンプルな操作 - aws configure での事前設定が不要
  • セキュア - 一時認証情報のみを使用

前提条件

要件 内容
AWS CLI バージョン v2.32.0 以上
IAMユーザーの場合 SignInLocalDevelopmentAccess マネージドポリシーが必要
ルートユーザーの場合 追加の権限設定不要

基本的な使用方法

# デフォルトプロファイルでログイン
$ aws login

# ブラウザが自動的に開き、Consoleの認証画面が表示される
# サインイン後、リージョンを選択
AWS Region [us-east-1]: ap-northeast-1

# ログイン成功

プロファイル指定でのログイン

# 特定のプロファイルでログイン
$ aws login --profile dev

# リージョンを直接指定
$ aws login --profile dev --region ap-northeast-1

リモート環境での使用（SSH接続時など）

# ローカルブラウザが使えない環境
$ aws login --remote

# 以下のような出力が表示される
To sign in, use a web browser to open the page:
https://device.sso.us-east-1.amazonaws.com/

And enter the code: ABCD-1234

# 別のデバイスでURLを開き、コードを入力

生成される設定ファイル

~/.aws/config

[default]
login_session = arn:aws:iam::123456789012:user/alice
region = ap-northeast-1

[profile dev]
login_session = arn:aws:iam::123456789012:user/bob
region = us-east-1

キャッシュの保存場所

OS パス
Linux/macOS ~/.aws/login/cache/
Windows %USERPROFILE%\.aws\login\cache\

環境変数 AWS_LOGIN_CACHE_DIRECTORY で変更可能。

ログアウト

# デフォルトプロファイルからログアウト
$ aws logout

# 特定のプロファイルからログアウト
$ aws logout --profile dev

# すべてのプロファイルからログアウト
$ aws logout --all

クレデンシャルチェーンでの位置付け

  • 影響する優先順位: 新しい認証方式として追加
  • ~/.aws/login/cache/ に一時認証情報を保存
  • 優先順位は6番目（クレデンシャルファイル）と同等または近い位置
  • 環境変数より優先順位が低く、aws configure で設定したクレデンシャルと同様に扱われる

aws sso login との違い

項目 aws login aws sso login
認証方式 AWS Console の認証情報 IAM Identity Center（旧SSO）
前提条件 Consoleアクセス権限 IAM Identity Centerの設定
ユースケース 個人開発者、小規模チーム 大規模組織、統合ID基盤
事前設定 不要（初回から使える） aws configure sso が必要
キャッシュ場所 ~/.aws/login/cache/ ~/.aws/sso/cache/
最大有効期間 12時間（自動更新） 通常8～12時間
追加ライセンス 不要 IAM Identity Center必要

使用シーン

✅ aws login が適している場合:

  • 個人開発者や小規模チーム
  • 既にConsoleにアクセスできる環境
  • 長期アクセスキーを使いたくない
  • シンプルな認証フローを好む

✅ aws sso login が適している場合:

  • 大規模組織（数十～数百アカウント）
  • Azure AD、Okta等の統合ID基盤を使用
  • 複数AWSアカウントへの統一的なアクセス管理
  • コンプライアンス要件が厳しい環境

実践例

1. 初めてAWS CLIを使う開発者

# 従来の方法（aws configure）は不要
# 直接 aws login でスタート
$ aws login

# すぐに使える
$ aws s3 ls
$ aws ec2 describe-instances

2. 複数アカウントの使い分け

# 開発アカウント
$ aws login --profile dev-account
$ aws s3 ls --profile dev-account

# 本番アカウント
$ aws login --profile prod-account
$ aws s3 ls --profile prod-account

3. CI/CD環境での一時的な検証

# リモートサーバーでの検証作業
$ ssh ec2-user@dev-server
$ aws login --remote
# コードを入力してログイン
$ aws cloudformation validate-template --template-body file://template.yaml

aws configure - 基本的なクレデンシャル設定

最も基本的なクレデンシャル設定コマンドです。

使用方法

# デフォルトプロファイルの設定
aws configure

# 特定のプロファイルを設定
aws configure --profile dev

対話的な設定フロー

$ aws configure --profile dev
AWS Access Key ID [None]: AKIAI44Q...
AWS Secret Access Key [None]: je7MtGbClwBF/2Zp...
Default region name [None]: ap-northeast-1
Default output format [None]: json

生成されるファイル

~/.aws/credentials

[dev]
aws_access_key_id = AKIAI44Q...
aws_secret_access_key = je7MtGbClwBF/2Zp...

~/.aws/config

[profile dev]
region = ap-northeast-1
output = json

クレデンシャルチェーンでの位置付け

  • 影響する優先順位: 6番目（クレデンシャルファイル）と 8番目（設定ファイル）
  • 環境変数やコマンドラインオプションより優先順位が低い
  • ローカル開発環境での利用が主な用途

aws sso login - IAM Identity Center へのログイン

IAM Identity Center（旧 AWS SSO）にブラウザ経由でログインし、一時的な認証情報を取得します。

前提条件

先に aws configure sso でSSO設定を完了している必要があります。

初期設定（初回のみ）

$ aws configure sso
SSO session name (Recommended): my-sso
SSO start URL [None]: https://my-company.awsapps.com/start
SSO region [None]: us-east-1
SSO registration scopes [sso:account:access]: sso:account:access

# ブラウザが起動し、認証完了後にアカウント選択
There are 3 AWS accounts available to you.
> DeveloperAccount, dev@example.com (111122223333)
  StagingAccount, staging@example.com (444455556666)
  ProductionAccount, prod@example.com (777788889999)

Using the account ID 111122223333
There are 2 roles available to you.
> DeveloperRole
  ReadOnlyRole

CLI default client Region [ap-northeast-1]:
CLI default output format [json]:
CLI profile name [DeveloperRole-111122223333]: dev

# 設定完了

生成される設定

~/.aws/config

[profile dev]
sso_session = my-sso
sso_account_id = 111122223333
sso_role_name = DeveloperRole
region = ap-northeast-1
output = json

[sso-session my-sso]
sso_region = us-east-1
sso_start_url = https://my-company.awsapps.com/start
sso_registration_scopes = sso:account:access

ログインコマンド

# 特定のプロファイルでログイン
aws sso login --profile dev

# 出力例
Attempting to automatically open the SSO authorization page in your default browser.
If the browser does not open or you wish to use a different device to authorize this request, open the following URL:

https://device.sso.us-east-1.amazonaws.com/

Then enter the code:

ABCD-1234

Successfully logged into Start URL: https://my-company.awsapps.com/start

生成される一時認証情報の保存場所

~/.aws/sso/cache/ ディレクトリ内にJSON形式で保存されます。

ls ~/.aws/sso/cache/
# 例: abc123def456.json

ファイルの内容例:

{
  "accessToken": "eyJraWQiOiJrZXktaWQiLCJhbGciOiJIUzI1...",
  "expiresAt": "2026-02-15T18:00:00UTC",
  "region": "us-east-1",
  "startUrl": "https://my-company.awsapps.com/start"
}

ログアウト

# SSOセッションからログアウト
aws sso logout

# または特定のプロファイルでログアウト
aws sso logout --profile dev

クレデンシャルチェーンでの位置付け

  • 影響する優先順位: 5番目（IAM Identity Center）
  • 環境変数より優先順位が低く、クレデンシャルファイルより高い
  • 大規模組織での利用が推奨される方式

aws sts get-session-token - MFA認証による一時認証情報の取得

MFA（多要素認証）を使って一時的な認証情報を取得します。

使用方法

# MFAトークンコードを指定して一時認証情報を取得
aws sts get-session-token \
  --serial-number arn:aws:iam::123456789012:mfa/alice \
  --token-code 123456 \
  --duration-seconds 43200

出力例

{
    "Credentials": {
        "AccessKeyId": "ASIAIOSF...",
        "SecretAccessKey": "wJalrXUtnFEMI/K7M...",
        "SessionToken": "IQoJb3JpZ2luX2VjEH8aCXVzLWVhc3QtMSJIMEYCIQD...",
        "Expiration": "2026-02-15T18:30:00Z"
    }
}

一時認証情報を設定ファイルに保存

# 手動で ~/.aws/credentials に追加
[prod-mfa]
aws_access_key_id = ASIAIOSF...
aws_secret_access_key = wJalrXUtnFEMI/K7M...
aws_session_token = IQoJb3JpZ2luX2VjEH8aCXVzLWVhc3QtMSJIMEYCIQD...

# 使用
aws s3 ls --profile prod-mfa

自動化スクリプト例

#!/bin/bash
# mfa-login.sh

MFA_SERIAL="arn:aws:iam::123456789012:mfa/alice"
PROFILE="prod-mfa"

echo "Enter MFA token code:"
read TOKEN_CODE

# 一時認証情報を取得
CREDENTIALS=$(aws sts get-session-token \
  --serial-number $MFA_SERIAL \
  --token-code $TOKEN_CODE \
  --duration-seconds 43200 \
  --output json)

# 認証情報を抽出
ACCESS_KEY=$(echo $CREDENTIALS | jq -r '.Credentials.AccessKeyId')
SECRET_KEY=$(echo $CREDENTIALS | jq -r '.Credentials.SecretAccessKey')
SESSION_TOKEN=$(echo $CREDENTIALS | jq -r '.Credentials.SessionToken')

# ~/.aws/credentials に保存
aws configure set aws_access_key_id $ACCESS_KEY --profile $PROFILE
aws configure set aws_secret_access_key $SECRET_KEY --profile $PROFILE
aws configure set aws_session_token $SESSION_TOKEN --profile $PROFILE

echo "MFA session established for profile: $PROFILE"
echo "Session expires at: $(echo $CREDENTIALS | jq -r '.Credentials.Expiration')"

クレデンシャルチェーンでの位置付け

  • 影響する優先順位: 6番目（クレデンシャルファイル）
  • 取得した一時認証情報を ~/.aws/credentials に保存して使用
  • MFA必須の環境で、手動実行時に利用

コマンドの比較表

コマンド 設定対象 認証方法 有効期限 クレデンシャルチェーン順位 主な用途 AWS CLIバージョン
aws login ~/.aws/login/cache/ Console認証情報 最大12時間（自動更新） 6番目付近 個人開発者、小規模チーム v2.32.0以上
aws configure ~/.aws/credentials 長期アクセスキー 無期限（手動ローテーション） 6番目 個人開発環境（レガシー） すべて
aws configure sso ~/.aws/config ブラウザ認証（SSO） 設定のみ（認証情報は取得しない） - SSO初期設定 v2.0以上
aws sso login ~/.aws/sso/cache/ IAM Identity Center 通常8～12時間 5番目 大規模組織 v2.0以上
aws sts get-session-token 手動で ~/.aws/credentials に保存 MFA + 既存認証情報 1～36時間（指定可） 6番目 MFA必須環境 すべて

推奨フロー

個人開発者（小規模）- 2026年推奨

# AWS CLI v2.32.0以上を使用している場合
# 新しい aws login を使用（推奨）

# 1回のみ or 12時間ごと: ログイン
aws login --profile dev
aws login --profile prod

# 日常的な使用（セッション有効期間中は再ログイン不要）
aws s3 ls --profile dev
aws s3 ls --profile prod

# ログアウト
aws logout --all

個人開発者（レガシー）- 従来の方法

# AWS CLI v2.32.0未満、または aws configure を使い続ける場合

# 1回のみ: 基本設定
aws configure --profile dev
aws configure --profile prod

# 日常的な使用
aws s3 ls --profile dev
aws s3 ls --profile prod

大規模組織（IAM Identity Center使用）

# 1回のみ: SSO設定
aws configure sso

# 日常的な使用（1日1回程度ログイン）
aws sso login --profile dev
aws s3 ls --profile dev

# セッション有効中は再ログイン不要
aws ec2 describe-instances --profile dev

MFA必須の本番環境

# 1回のみ: 基本プロファイル設定
aws configure --profile prod-base

# 本番作業時（MFAトークンで一時認証情報を取得）
aws sts get-session-token \
  --serial-number arn:aws:iam::123456789012:mfa/alice \
  --token-code 123456 \
  --duration-seconds 43200 \
  --profile prod-base \
  > /tmp/session.json

# 一時認証情報を設定（手動またはスクリプト）
aws configure set aws_access_key_id $(jq -r '.Credentials.AccessKeyId' /tmp/session.json) --profile prod-mfa
aws configure set aws_secret_access_key $(jq -r '.Credentials.SecretAccessKey' /tmp/session.json) --profile prod-mfa
aws configure set aws_session_token $(jq -r '.Credentials.SessionToken' /tmp/session.json) --profile prod-mfa

# 本番操作（セッション有効期間中）
aws s3 ls --profile prod-mfa

実際の動作確認方法

現在使用中のクレデンシャルを確認

# 使用中の認証情報を確認
aws sts get-caller-identity

# 出力例
{
    "UserId": "AIDACKCE...",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/alice"
}

設定の優先順位を表示

# すべての設定値と取得元を表示
aws configure list

# 出力例
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
access_key     ****************MPLE shared-credentials-file
secret_key     ****************MPLE shared-credentials-file
    region           ap-northeast-1      config-file    ~/.aws/config

特定のプロファイルの設定を確認

# プロファイル "dev" の設定を表示
aws configure list --profile dev

デバッグモードで詳細なログを出力

# クレデンシャル取得の詳細ログ
aws s3 ls --debug 2>&1 | grep -i credential

# Boto3（Python）の場合
import boto3
boto3.set_stream_logger('botocore.credentials', level='DEBUG')

Boto3（Python SDK）の優先順位との違い

Boto3（Python SDK）は12段階の優先順位を持ちます。AWS CLIとの主な違いは以下の通りです。

Boto3の完全な優先順位リスト

順位 取得元 説明
1 boto3.client() の直接パラメータ コード内で明示的に指定
2 Session オブジェクトのパラメータ セッション作成時に指定
3 環境変数 AWS_ACCESS_KEY_ID 等
4 Assume Role Provider ~/.aws/config の role_arn
5 Assume Role with Web Identity Provider OIDC連携
6 AWS IAM Identity Center (SSO) aws configure sso
7 共有認証情報ファイル ~/.aws/credentials
8 AWS CLI設定ファイル ~/.aws/config
9 Boto2設定ファイル ~/.boto（レガシー）
10 カスタムプロセス credential_process
11 コンテナ認証情報プロバイダー ECS Task Role、EKS Pod Identity
12 EC2インスタンスメタデータ IAMロール（IMDS）

AWS CLIとの主な違い

項目 Boto3 AWS CLI
最優先 コード内の直接指定 コマンドラインオプション
2番目 Sessionオブジェクト 環境変数
Boto2設定 サポート（順位9） サポートなし
段階数 12段階 10段階

Boto3でのコード例

import boto3

# 方法1: client()メソッドで直接指定（最優先）
s3 = boto3.client('s3',
    aws_access_key_id='AKIAIOSF...',
    aws_secret_access_key='wJalrXUtnFEMI/K7M...',
    region_name='ap-northeast-1'
)

# 方法2: Sessionオブジェクトで指定
session = boto3.Session(profile_name='dev')
s3 = session.client('s3')

# 方法3: 環境変数やファイルから自動取得
s3 = boto3.client('s3')  # デフォルトのチェーンに従う

ユースケース別の推奨パターン

個人開発環境

# 複数アカウントをプロファイルで管理
aws configure --profile dev
aws configure --profile staging
aws configure --profile prod

# 使い分け
aws s3 ls --profile dev
aws s3 ls --profile prod

CI/CDパイプライン（GitHub Actions）

# OIDC連携（推奨）
- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
    aws-region: ap-northeast-1

# または環境変数（レガシー）
- env:
    AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
    AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
  run: aws s3 ls

マルチアカウント環境

# ~/.aws/config
[profile base]
region = ap-northeast-1

[profile dev-admin]
role_arn = arn:aws:iam::111111111111:role/AdminRole
source_profile = base
mfa_serial = arn:aws:iam::999999999999:mfa/alice

[profile prod-readonly]
role_arn = arn:aws:iam::222222222222:role/ReadOnlyRole
source_profile = base
mfa_serial = arn:aws:iam::999999999999:mfa/alice

コンテナ環境（ECS/EKS）

ECS Fargate:

{
  "family": "my-app",
  "taskRoleArn": "arn:aws:iam::123456789012:role/MyAppTaskRole",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "containerDefinitions": [
    {
      "name": "app",
      "image": "my-app:latest",
      "essential": true
    }
  ]
}

EKS Pod（IRSA）:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: default
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/MyAppRole
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    spec:
      serviceAccountName: my-app-sa
      containers:
      - name: app
        image: my-app:latest

EC2インスタンス

# インスタンス起動時にIAMロールを指定
aws ec2 run-instances \
  --iam-instance-profile Name=MyEC2Role \
  ...

# インスタンス内ではクレデンシャル設定不要
aws s3 ls  # 自動的にIAMロールの権限を使用

よくあるトラブルシューティング

問題1: 意図しないアカウントに接続される

症状:

aws s3 ls
# 期待: 開発アカウント
# 実際: 本番アカウント

原因: 環境変数 AWS_PROFILE が設定されている、または ~/.aws/credentials の [default] が本番アカウントになっている。

対処法:

# 現在の設定を確認
aws configure list
env | grep AWS

# 環境変数をクリア
unset AWS_PROFILE
unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY

# プロファイルを明示的に指定
aws s3 ls --profile dev

問題2: EC2で「Unable to locate credentials」エラー

症状:

aws s3 ls
# Unable to locate credentials. You can configure credentials by running "aws configure".

原因: EC2インスタンスにIAMロールが紐付いていない。

対処法:

# インスタンスプロファイルの確認
curl -H "X-aws-ec2-metadata-token: $(curl -X PUT 'http://169.254.169.254/latest/api/token' -H 'X-aws-ec2-metadata-token-ttl-seconds: 21600')" \
  http://169.254.169.254/latest/meta-data/iam/info

# IAMロールを紐付け（停止中のインスタンスのみ可能）
aws ec2 associate-iam-instance-profile \
  --instance-id i-1234567890abcdef0 \
  --iam-instance-profile Name=MyEC2Role

問題3: MFA要求でスクリプトが止まる

症状:

aws s3 ls --profile prod
# Enter MFA code for arn:aws:iam::123456789012:mfa/alice:

原因: プロファイルに mfa_serial が設定されているが、スクリプトで自動入力できない。

対処法:

# 一時認証情報を手動で取得してセッション化
aws sts get-session-token \
  --serial-number arn:aws:iam::123456789012:mfa/alice \
  --token-code 123456 \
  --duration-seconds 43200

# 出力された認証情報を ~/.aws/credentials に保存
[prod-session]
aws_access_key_id = ASIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
aws_session_token = IQoJb3JpZ2luX2...

# セッションプロファイルを使用
aws s3 ls --profile prod-session

自動化ツール: aws-mfa、aws-vault などを活用すると、MFA認証を自動化できます。

問題4: 環境変数とプロファイルの設定が競合

症状:

export AWS_ACCESS_KEY_ID=AKIAI_WRONG_KEY
export AWS_SECRET_ACCESS_KEY=wrong_secret_key
aws s3 ls --profile correct-profile
# AccessDenied エラー（環境変数のキーが優先されてしまう）

原因: 環境変数（優先順位2位）が --profile オプション（優先順位1位だが、認証情報を直接指定できない）より優先される。

重要な理解:

  • --profile オプションは「どのプロファイルを使うか」を指定するだけ
  • 環境変数に AWS_ACCESS_KEY_ID が設定されていると、プロファイル指定より先に環境変数が使われる
  • つまり、--profile < 環境変数 の優先順位

対処法:

# 方法1: 環境変数をクリア
unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY
unset AWS_SESSION_TOKEN
aws s3 ls --profile correct-profile

# 方法2: 新しいシェルで実行（環境変数を引き継がない）
env -i bash -c "aws s3 ls --profile correct-profile"

# 方法3: AWS_PROFILE環境変数を使う
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN
export AWS_PROFILE=correct-profile
aws s3 ls

# 方法4: プロファイルが指す認証情報を確認
aws configure list --profile correct-profile

予防策:

.bashrc または .zshrc
# ~/.bashrc に追加（シェル起動時に警告）
if [ -n "$AWS_ACCESS_KEY_ID" ]; then
  echo "⚠️  WARNING: AWS_ACCESS_KEY_ID is set in environment variables"
  echo "   This will override --profile option"
fi

# エイリアスで明示的にクリアしてから実行
alias aws-dev='unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN; aws --profile dev'
alias aws-prod='unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN; aws --profile prod'

セキュリティベストプラクティス

✅ 推奨される認証方法（優先順）

  1. IAM Identity Center（SSO） - 大規模組織向け
  2. IAMロール（EC2/ECS/EKS） - クラウド環境
  3. OIDC連携（GitHub Actions等） - CI/CD
  4. 一時認証情報（assume-role） - マルチアカウント
  5. 共有クレデンシャルファイル - 個人開発環境（MFA推奨）

❌ 避けるべき方法

方法 リスク
長期的なアクセスキーの利用 漏洩時の影響大、ローテーション忘れ
環境変数に永続的に設定 シェル履歴に残る、誤って共有のリスク
ソースコードにハードコード Gitリポジトリに誤コミット
IMDSv1の使用 SSRF攻撃のリスク

セキュリティ強化策

1. ファイルパーミッションの設定

chmod 600 ~/.aws/credentials
chmod 600 ~/.aws/config

2. Git管理下から除外

# .gitignore に追加
echo ".aws/" >> ~/.gitignore

3. クレデンシャルスキャンツールの導入

# git-secrets（AWS公式）
brew install git-secrets
git secrets --install
git secrets --register-aws

# TruffleHog
docker run -it trufflesecurity/trufflehog:latest github --repo https://github.com/yourorg/yourrepo

4. MFAの有効化

[profile prod]
role_arn = arn:aws:iam::123456789012:role/ProductionRole
source_profile = base
mfa_serial = arn:aws:iam::999999999999:mfa/alice

5. アクセスキーの定期的なローテーション

# 現在のアクセスキーを確認
aws iam list-access-keys --user-name alice

# 新しいキーを作成
aws iam create-access-key --user-name alice

# 古いキーを削除
aws iam delete-access-key --user-name alice --access-key-id AKIAI_OLD_KEY

まとめ

AWS CLIやSDKは、10段階のクレデンシャルプロバイダーチェーンに従ってクレデンシャルを探索します。

重要ポイント

  1. 優先順位を正しく理解する

    • 環境変数 > --profile オプション > ファイル > IAMロール
    • --profile は認証情報を直接指定できない点に注意

  2. 環境に応じた方法を選ぶ

    • 開発環境: ~/.aws/credentials + プロファイル
    • 本番環境（クラウド）: IAMロール（EC2/ECS/EKS）
    • CI/CD: OIDC連携（GitHub Actions、GitLab CI）
    • 大規模組織: IAM Identity Center（SSO）

  3. セキュリティを最優先

    • ❌ 長期アクセスキーの利用を避ける
    • ✅ 一時認証情報やIAMロールを活用
    • ✅ MFAを有効化
    • ✅ 定期的なローテーション

  4. トラブル時の確認手順

    # 現在使用中のクレデンシャルを確認
aws sts get-caller-identity

# 設定の優先順位を表示
aws configure list

# 環境変数を確認
env | grep AWS

# デバッグログで詳細を確認
aws s3 ls --debug 2>&1 | grep -i credential

環境別推奨パターン

環境 推奨方法（2026年版） 従来の方法
個人開発（新規） aws login ✨ ~/.aws/credentials + プロファイル
個人開発（既存） ~/.aws/credentials + プロファイル -
CI/CD OIDC連携（GitHub Actions等） 環境変数（レガシー）
EC2 IAMインスタンスプロファイル -
ECS/EKS Task Role / Pod Identity -
マルチアカウント assume-role + MFA -
大規模組織 IAM Identity Center（aws sso login） -
リモート開発 aws login --remote SSH ポートフォワーディング

2026年の推奨アプローチ

  • 新規開発者: まず aws login を試す（AWS CLI v2.32.0以上）
  • 既存環境: すでに aws configure で設定済みなら移行不要
  • 大規模組織: IAM Identity Center + aws sso login が最適
  • 長期アクセスキー: セキュリティリスクのため、新規作成は避ける

クレデンシャルの仕組みを正しく理解することで、セキュアで効率的なAWS運用が実現できます。

参考資料

AWS公式ドキュメント

ツール・ライブラリ

  • aws-vault - セキュアなクレデンシャル管理ツール
  • aws-mfa - MFA認証自動化
  • Leapp - クレデンシャル管理GUIツール
  • aws-sso-util - IAM Identity Center ユーティリティ
  • git-secrets - クレデンシャル誤コミット防止（AWS公式）
  • TruffleHog - シークレットスキャンツール
  • Gitleaks - Gitリポジトリのシークレット検出

関連記事・チュートリアル

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?