Amazon Bedrock API キーの保護: 実装と管理のベストプラクティス

本ブログは 2025 年 10 月 17 日に公開された AWS Blog “Securing Amazon Bedrock API keys: Best practices for implementation and management” を翻訳したものです。

2026 年 7 月 1 日: この記事を更新し、Mantle エンドポイントで Amazon Bedrock を使用するためのガイダンスを追加しました。

AWS では、Amazon Bedrock API を呼び出すための Amazon Bedrock API キーが利用可能です。この記事では、Amazon Bedrock へのこのアクセス方法を効果的に実装、監視、管理するための実践的なセキュリティガイダンスを紹介し、API キーを保護する包括的な戦略の構築を支援します。また、サービス固有の認証情報全般についても解説します。これにより、必要に応じて AWS CodeCommit や Amazon Keyspaces (Apache Cassandra 向け) の実装も強化できます。

注: 以降、この記事ではサービス固有の認証情報と API キーを同じ意味で使用します。

Amazon Bedrock へのアクセスに最適な仕組みの選択

AWS では、可能な限り AWS Security Token Service (AWS STS) が提供する一時的なセキュリティ認証情報を認証方法として優先的に使用することをお勧めします。

ユースケースの都合で一時的な AWS STS 認証情報を使用できない場合は、API キーを使用できます。代表的な例として、HTTP ベアラートークンによる API キー認証を必須とし、一時的な AWS STS 認証情報による SigV4 署名を使用するよう設定できないサードパーティ製ソフトウェアやパッケージソフトウェアを使用する場合が挙げられます。

API キーを使用する必要がないと判断した場合は、サービスコントロールポリシー (SCP) を使用して、API キーの作成と使用を拒否することを検討してください。

ユースケース上 API キーが必要だと判断した場合は、次の 2 種類の API キーのどちらを使用するか検討してください。

短期 API キー: AWS STS 認証情報を使用できない場合は、短期 API キーの使用を検討してください。短期 API キーには有効期限の仕組みが組み込まれており、指定した期間が経過すると自動的に失効します。そのため、漏洩した場合でも認証情報が無期限に使用されることを防げます。
長期 API キー: 長期 API キーは、AWS STS 認証情報も短期の認証情報も使用できない場合にのみ使用してください。例えば、長期間有効な静的 API キーを前提としており、変更できないパッケージソフトウェアや SDK を使用する場合などです。

この記事で紹介するコントロールを実装すれば、API キーに関するセキュリティ上の懸念のほとんどに対処できます。ただし、セキュリティは継続的なプロセスであることを忘れないでください。包括的なセキュリティ戦略の一環として、引き続き AWS のセキュリティに関するベストプラクティスに従い、セキュリティポスチャを定期的に見直してください。

サービス固有の認証情報について

サービス固有の認証情報は、特定の AWS サービスへの直接アクセスを提供する専用の認証情報です。他の AWS セキュリティ認証情報 (アクセスキー、シークレットアクセスキー、セッショントークンなど) とは異なり、特定の AWS サービスで使用するように設計されています。

サービス固有の認証情報の主な特徴は次のとおりです。

各認証情報は特定の AWS サービスに関連付けられています
AWS Identity and Access Management (IAM) プリンシパルに関連付けられています
AWS マネジメントコンソールと AWS コマンドラインインターフェイス (AWS CLI) の両方で管理できます
AWS CloudTrail で監視できます
サービス固有の認証情報 ID のプレフィックスは ACCA です
組織は SCP を使用して、サービス固有の認証情報の作成と使用を制御できます

それでは、サービス固有の認証情報と、それを Amazon Bedrock で使用する方法について詳しく見ていきましょう。

Amazon Bedrock API キー

Amazon Bedrock API キーは、Amazon Bedrock への直接アクセスを提供するサービス固有の認証情報です。アクセス許可 bedrock:CallWithBearerToken を付与すると、これらのトークンを使用して Amazon Bedrock API アクションを実行できるようになります。同様に、アクセス許可 bedrock-mantle:CallWithBearerToken を付与すると、これらのトークンを使用して Amazon Bedrock Powered by AWS Mantle API アクションを実行できるようになります。

キーの種類と特徴

API キーには 2 種類あり、それぞれ次の特徴があります。

短期 API キー

事前署名された SigV4 認証を使用します
クライアント側で生成されるため、短期 API キーの作成は CloudTrail に記録されません
認証情報レポートや AWS CLI の呼び出しでは取得できません
有効期間は、API キーを生成した IAM セッションの有効期間と 12 時間のうち、短い方です
キーの生成に使用したロールと同じアクセス許可を持ちます
パターン: bedrock-api-key-YmVkcm9jay5hbWF6b25hd3MuY29tLz9BY3Rpb249Q2FsbFdpdGhCZWFyZXJUb2tlbiZYLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsP[A-Za-Z0-9\\]+={0,2}

長期 API キー

Amazon Bedrock コンソールから Amazon Bedrock の長期 API キーを作成すると、AWS は BedrockAPIKey-xxx という命名規則の専用 IAM ユーザーを自動的に作成し、マネージドポリシー AmazonBedrockLimitedAccess をアタッチします
Amazon Bedrock コンソールから作成された IAM ユーザーでは、コンソールアクセス、コンソールパスワード、アクセスキー、多要素認証 (MFA) のいずれも有効化または設定されていません
一方、IAM コンソールから Amazon Bedrock の長期 API キーを作成する場合は、Amazon Bedrock のサービス固有の認証情報を既存の IAM ユーザーに直接関連付けることができます
各 IAM ユーザーは最大 2 つの長期 API キーを持つことができます
有効期間は 1 日から無期限までの範囲で設定できます
有効期間は、Amazon Bedrock の API キーを管理するための新しい条件キーの 1 つである iam:ServiceSpecificCredentialAgeDays を使用して制御できます。SCP の例を参照してください。
パターン: ABSKQmVkcm9ja0FQSUtleS[A-Za-z0-9+\/]+={0,2}
長期 API キーが作成されると、次の例のように CloudTrail にイベントが記録されます。AWS CLI を使用して長期 API キーを特定することもできます。

{
    "eventTime": "2025-07-23T17:39:08Z",
    "eventSource": "iam.amazonaws.com",
    "eventName": "CreateServiceSpecificCredential",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "203.0.113.1",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:139.0) Gecko/20100101 Firefox/139.0",
    "requestParameters": {
        "userName": "BedrockAPIKey-0g21",
        "serviceName": "bedrock.amazonaws.com",
        "credentialAgeDays": 36500
    },
    "responseElements": {
        "serviceSpecificCredential": {
            "createDate": "Jul 23, 2025, 5:39:08 PM",
            "expirationDate": "Oct 7, 2125, 5:39:08 PM",
            "serviceName": "bedrock.amazonaws.com",
            "serviceCredentialAlias": "BedrockAPIKey-1234-56-EXAMPLE",
            "serviceCredentialId": "ACCA123456789EXAMPLE",
            "userName": "BedrockAPIKey-0g21",
            "status": "Active"
        }
    }
}

識別

API キーを扱う際に理解しておくべき重要な点がいくつかあります。短期 API キーはクライアント側で生成されるため、ListServiceSpecificCredentials などの AWS API で既存の認証情報を一覧表示しても、短期 API キーは含まれません。

長期 API キーは短期 API キーより可視性が高く、複数の方法で管理できます。長期 API キーが関連付けられているプリンシパルは、Amazon Bedrock コンソールまたは IAM コンソールで特定できます。また、AWS CLI コマンドまたは AWS SDK を使用すると、指定したユーザーのサービス固有の認証情報を一覧表示できます。

防御

Amazon Bedrock では、AWS 環境における API キーの使用をより適切に制御、保護するための 4 つの条件キーが導入されました。

条件キー iam:ServiceSpecificCredentialServiceName を使用すると、プリンシパルによるサービス固有の認証情報の作成を許可する AWS サービスを指定できます。
条件キー iam:ServiceSpecificCredentialAgeDays を使用すると、長期 API キーの作成時に最大有効期間を設定して、セキュリティのベストプラクティスを適用できます。
条件キー bedrock:BearerTokenType を使用すると、Amazon Bedrock で、特定の種類 (短期または長期) の API キーの使用を拒否または許可できます。
条件キー bedrock-mantle:BearerTokenType を使用すると、同様に Amazon Bedrock Powered by AWS Mantle で、特定の種類 (短期または長期) の API キーの使用を拒否または許可できます。

これらの条件キーは、短期 API キーと長期 API キーそれぞれのセキュリティ特性の違いを管理するうえで重要な役割を果たします。セキュリティチームはこれらを利用して、AWS Organizations レベルの SCP で組織のポリシーとセキュリティのベストプラクティスを適用できます。詳細については、これらの SCP の適用例を紹介している GitHub リポジトリを参照してください。

短期 API キーには有効期限が組み込まれているため、潜在的なセキュリティリスクにさらされる期間を抑えられます。ただし、これらのキーは署名に使用したプリンシパルのアクセス許可を継承するため、Amazon Bedrock 以外のアクセス許可も含まれる場合がある点に注意してください。包括的な監視は、「検知」セクションで説明する方法で実装できます。

長期 API キーは有効期間を長く設定できるため、長時間実行されるアプリケーションには便利です。ただし、認証情報が悪用されうる期間が長くなる分、それを補うためのコントロールと監視の仕組みに特に注意を払う必要があります。

組織の環境で Amazon Bedrock API キーが不要と判断した場合は、SCP を実装して、サービス固有の認証情報の作成 (iam:CreateServiceSpecificCredential) と、Amazon Bedrock でのベアラートークンの使用 (bedrock:CallWithBearerToken および bedrock-mantle:CallWithBearerToken) をブロックできます。

注: IAM ポリシーで条件 iam:ServiceSpecificCredentialServiceName を使用せずに iam:CreateServiceSpecificCredential を拒否すると、AWS CodeCommit や Amazon Keyspaces (Apache Cassandra 向け) など、他のサービスの API キーの作成も拒否されます。

こちらの SCP の例では、Amazon Bedrock のサービス固有の認証情報の作成と、Amazon Bedrock での API キーの使用を拒否しています。これにより、組織内のビルダーが新しい API キーを作成できなくなり、不正なキー作成のリスクを軽減できます。このアプローチは、認証方法を厳格に管理したい組織や、サービス固有の認証情報を必要とするビジネス上の理由がない組織に有効です。また、aws:PrincipalArn に指定したプリンシパルを対象とする条件 ArnNotLikeIfExists を SCP に追加すれば、特定のロールを許可リストに登録して、サービス固有の認証情報を作成できるようにすることもできます。

API キー保護の一環として、最小権限の原則に沿ってアクセス許可を定期的に見直し、調整してください。Amazon Bedrock コンソールから長期 API キーを作成すると、AWS はマネージドポリシー AmazonBedrockLimitedAccess がアタッチされた IAM ユーザーを自動的に作成します。このポリシーは、Amazon Bedrock、AWS Key Management Service (AWS KMS)、IAM、Amazon Elastic Compute Cloud (Amazon EC2)、AWS Marketplace のさまざまなアクションへのアクセスを許可します。長期 API キーと短期 API キーのどちらについても、プリンシパルがユースケースに必要な範囲を超えるアクセス許可を持っていないか評価してください。過剰なアクセス許可が見つかった場合は、ポリシー AmazonBedrockLimitedAccess を、アクセス許可の範囲を絞り込んだカスタムポリシーに置き換えてください。

検知

API キーには、種類に応じて異なる監視アプローチが必要です。短期 API キーはクライアント側で生成されるため作成を検知できませんが、長期 API キーの作成は CloudTrail イベントで監視できます。Converse、ConverseStream、InvokeModel、InvokeModelWithResponseStream への推論呼び出しは、管理イベントとして CloudTrail に記録されます。CloudTrail に記録されるこれらのイベントを通じて、短期 API キーと長期 API キーのどちらについても、その使用を検知できます。長期 API キーは有効期間が長いため不正使用されやすく、包括的な監視が不可欠です。組織は、次のような厳格な監視コントロールを実装する必要があります。

CreateUser イベントのうち、ユーザー名に BedrockAPIKey- プレフィックスが付いているものを監視します。Amazon Bedrock コンソールからユーザーが作成された場合、イベントは次のようになります。

{
    "eventTime": "2025-07-23T17:39:08Z",
    "eventSource": "iam.amazonaws.com",
    "eventName": "CreateUser",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "203.0.113.1",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:139.0) Gecko/20100101 Firefox/139.0",
    "requestParameters": {
        "userName": "BedrockAPIKey-0g21"
    },
    "responseElements": {
        "user": {
            "path": "/",
            "userName": "BedrockAPIKey-0g21",
            "userId": " AIDACKCEVSQ6C2EXAMPLE",
            "arn": "arn:aws:iam::111122223333:user/BedrockAPIKey-0g21",
            "createDate": "Jul 23, 2025, 5:39:08 PM"
        }
    }
}

CreateServiceSpecificCredential イベントのうち、requestParameters.serviceName = bedrock.amazonaws.com を満たすものを追跡します
API キーがアクティブに使用されていることを示す次の指標を監視します
- additionalEventData.callWithBearerToken = true
- eventSource = bedrock.amazonaws.com

{
    "eventVersion": "1.11",
    "userIdentity": {
        "type": "IAMUser",
        "principalId": " AIDACKCEVSQ6C2EXAMPLE",
        "arn": "arn:aws:iam::user/BedrockAPIKey-0g21",
        "accountId": "",
        "userName": "BedrockAPIKey-0g21"
    },
    "eventTime": "2025-07-23T17:39:37Z",
    "eventSource": "bedrock.amazonaws.com",
    "eventName": "Converse",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "",
    "userAgent": "curl/8.11.1",
    "requestParameters": {
        "modelId": "us.anthropic.claude-3-5-haiku-20241022-v1:0"
    },
    "responseElements": null,
    "additionalEventData": {
        "callWithBearerToken": true,
        "inferenceRegion": "us-west-2"
    }
}

監視すべきイベントの一覧については、「Security Playbook for Responding to Amazon Bedrock Security Events」を参照してください。

Amazon EventBridge ルール

Amazon EventBridge ルールを実装すると、CreateServiceSpecificCredential などの Amazon Bedrock API キーのライフサイクルイベントを検知してアラートを送信できるため、セキュリティ監視を強化できます。

EventBridge ルールを使用した監視は、次の 4 つのコンポーネントで構成されます。

EventBridge ルール: CreateServiceSpecificCredentialRule と BearerTokenUsageRule が、認証情報の作成とベアラートークンの使用を CloudTrail で監視します
SNS トピック: BedrockAlertsTopic が、暗号化されたセキュリティアラートを E メールで配信します
KMS キー: SNSEncryptionKey が SNS メッセージを暗号化します
IAM ロール: サービスの運用に必要なアクセスを提供します

前述の EventBridge ルールは、eventName (実行されているアクション)、eventSource (アクションの実行主体または対象となるサービス)、additionalEventData (レスポンスの詳細を含むブロック) をキーとして、CloudTrail ログ内の特定のパターンを監視します。

次のルールは、CloudTrail イベント CreateServiceSpecificCredential をチェックします。

        source:
          - aws.iam
        detail-type:
          - AWS API Call via CloudTrail
        detail:
          eventSource:
            - iam.amazonaws.com
          eventName:
            - CreateServiceSpecificCredential

API キーを使用して実行されたアクション (BearerToken = true) を検索するには、次のルールを使用します。

        detail-type:
          - AWS API Call via CloudTrail
        detail:
          additionalEventData:
            callWithBearerToken:
              - true

EventBridge ルールのデプロイ

CloudFormation テンプレートを使用すると、サービス固有の認証情報の作成とその後の使用の両方を自動で監視するよう設定できます。このテンプレートは、前述の CloudTrail イベントが検知されたときに E メール通知を送信するよう EventBridge を設定するため、環境内の API キー操作をリアルタイムで把握できます。詳細については、GitHub リポジトリにあるこのソリューションの説明と CloudFormation テンプレートを参照してください。

コンプライアンスのための AWS Config ルール

AWS Config ルールを使用して、IAM ユーザーがアクティブなサービス固有の認証情報を持っていないかを監視することで、セキュリティポリシーへの準拠を維持しやすくなります。

AWS Config ルールは、次の手順を実行します。

AWS Config ルールが 24 時間ごとに Lambda 関数をトリガーし、この関数がアカウント内の IAM ユーザーを列挙します
関数は、ユーザーごとにアクティブなサービス固有の認証情報の有無を確認します
1. サービス固有の認証情報を持つユーザーは NON_COMPLIANT としてマークされます
2. アクティブな認証情報を持たないユーザーは COMPLIANT としてマークされます
結果は、レポートと必要に応じた修復のために AWS Config に送信されます

AWS Config ルールのデプロイ

この AWS Config ルールは、AWS Config RDK を使用して、CloudShell またはローカルの CLI からデプロイできます。

git clone https://github.com/awslabs/aws-config-rules.git
cd aws-config-rules/python-rdklib
git fetch && git checkout IAM_USER_NO_SERVICE_SPECIFIC_CREDENTIALS
pip install rdk rdklib
rdk deploy IAM_USER_NO_SERVICE_SPECIFIC_CREDENTIALS
aws configservice start-config-rules-evaluation --config-rule-names "IAM_USER_NO_SERVICE_SPECIFIC_CREDENTIALS"

対応と復旧

インシデント対応計画は、いずれも準備フェーズから始まります。準備フェーズの一環として、API キーの所有者と使用状況を明確に記録し、どのアプリケーションやチームがどのキーを使用しているかを文書化してください。また、長期 API キーが必要な場合は、AWS Secrets Manager などの安全なストレージの使用を検討してください。

API キーに関連するセキュリティインシデントが疑われる場合は、直ちに行動することが重要です。最初のステップは、CloudTrail ログを確認して API キーの作成と使用を承認済みの変更リクエストと照合し、侵害の可能性を検証することです。これにより、不正なキーの作成や使用を特定できます。さらに、これらのログに記録された送信元 IP アドレスとユーザーエージェント文字列を分析すれば、アクセス元が承認済みの場所やアプリケーションなのか、悪意のある可能性がある送信元なのかを判断できます。

インシデント対応のアプローチは、キーの種類によって大きく異なります。短期 API キーの場合、有効期限が最大 12 時間であるため潜在的な被害は限定されますが、有効期限切れを待たずに直ちに対処することが重要です。セキュリティチームは、侵害された短期 API キーを使用しているアプリケーションやシステムを特定し、IAM ロールセッションを取り消すか、アイデンティティに対して bedrock:CallWithBearerToken および bedrock-mantle:CallWithBearerToken のアクセス許可を拒否する必要があります。

進行中のセキュリティイベントに Amazon Bedrock の長期 API キーが関与している場合、セキュリティチームはコンソールまたは AWS CLI を使用して直ちに対処できます。コンソールでは、IAM コンソールを使用して長期 API キーをすばやく無効化または削除できます。対応手順を自動化している組織向けには、AWS CLI にキー管理用のコマンドが用意されています。

AWS CLI を使用した対応

API キーに関するイベントに対応するには、次の手順を実行します。

サービス固有の認証情報を特定します。

aws iam list-service-specific-credentials --user-name <user name> --service-name bedrock.amazonaws.com

直ちに封じ込めるには、前の手順で取得した認証情報 ID を使用して認証情報を無効化します。

aws iam update-service-specific-credential --service-specific-credential-id <credential ID> --user-name <user name> --status Inactive

イベントを評価した後、関連付けられた API キーを完全に削除できます。

aws iam delete-service-specific-credential --service-specific-credential-id <credential ID> --user-name <user name>

復旧フェーズでは、適切な設定で安全な新しいキーを作成し、アプリケーションの設定を更新するとともに、影響を受けるすべての継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインと開発チームに変更を確実に通知することに重点を置いてください。

Amazon Bedrock API キーに関する対策の概要

次の表は、Amazon Bedrock API キーに関連するさまざまな要素を、NIST CSF 2.0 のコア機能に対応付けてまとめたものです。

種類

識別

防御

検知 (CloudTrail のイベントを使用)

対応

短期 API キー

短期 API キーはクライアント側で生成されるため、AWS API では一覧表示されません。

作成: 短期 API キーはクライアント側で生成されるため、作成をブロックすることはできません。

使用: 使用を防ぐには、アクション bedrock:CallWithBearerToken と bedrock-mantle:CallWithBearerToken を拒否します。

長期および短期の Amazon Bedrock API キーのアクセス許可を変更する

作成: クライアント側で行われるため、CloudTrail にイベントは記録されません。

使用: additionalEventData.callWithBearerToken = true を含む CloudTrail イベント

API キーの使用を検知して通知するための EventBridge ルールと SNS。

IAM ロールセッションの取り消し、またはアイデンティティに対するアクセス許可の拒否

長期 API キー

AWS CLI または SDK を使用した IAM のアクション ListServiceSpecificCredentials

作成: アクション iam:CreateServiceSpecificCredential を拒否すると、Amazon Bedrock を含むすべてのサービスでサービス固有の認証情報の作成をブロックできます。

使用: 使用を防ぐには、アクション bedrock:CallWithBearerToken と bedrock-mantle:CallWithBearerToken を拒否します。

長期および短期の Amazon Bedrock API キーのアクセス許可を変更する

作成: eventName が CreateServiceSpecificCredential の CloudTrail イベント。Amazon Bedrock コンソールを使用した場合は、CreateUser イベントも対象です。

使用: additionalEventData.callWithBearerToken = true を含む CloudTrail イベント

API キーの作成と使用を検知して通知するための EventBridge ルールと SNS。

AWS Config ルール

コンソールまたは AWS CLI を使用して、長期 API キーをすばやく無効化または削除します

Amazon Bedrock 以外のサービス固有の認証情報

Amazon Bedrock の API キーのほかにも、AWS CodeCommit や Amazon Keyspaces などの AWS サービスがサービス固有の認証情報をサポートしています。

この記事で紹介したセキュリティ対策は、これらのサービスにも適用できます。次の表は、これらのサービス固有の認証情報の一般的なユースケースを示しています。

サービス

ユースケース

iam:ListServiceSpecificCredentials のレスポンスに含まれるサービス名

推奨される代替手段

AWS CodeCommit の Git 認証情報

AWS CodeCommit リポジトリ内のファイルのアップロード、追加、編集に使用

codecommit.amazonaws.com

SSH 認証やフェデレーション認証などの方法があります。詳細については、「AWS CodeCommit: 他の方法を使用したセットアップ」を参照してください

Apache Cassandra 向けの Amazon Keyspaces 認証情報

Apache Cassandra 互換のアクセスに使用

cassandra.amazonaws.com

SigV4 認証プラグインを利用できます。このプラグインは複数のプログラミング言語をサポートしており、IAM ロールやフェデレーティッドアイデンティティによる認証を可能にします。詳細については、「IAM ロールと SigV4 プラグインを使用して Amazon Keyspaces に接続するための一時的な認証情報を作成する」を参照してください

まとめ

長期 API キーがもたらす影響とその管理方法を理解しておくと、Amazon Bedrock API キーの実装戦略について、十分な情報に基づいた判断を下せます。重要なのは、強固なセキュリティポスチャを維持しながら、セキュリティコントロールをリスク選好度と運用要件に合わせることです。

AWS は、可能な限り AWS STS 認証情報を主要な認証方法として使用することを強く推奨しています。AWS STS 認証情報を使用できない場合は、有効期限の仕組みが組み込まれた短期 API キーを検討してください。長期 API キーは、AWS STS 認証情報も短期の認証情報も選択肢にならない場合にのみ実装してください。API キーを実装する際に組織として重点を置くべき点は、次のとおりです。AWS CLI と CloudTrail ログを使用して API キーを識別すること、SCP などの予防的コントロールで API キーの作成と使用を管理して防御すること、CloudTrail イベント、EventBridge、AWS Config ルールによる包括的な監視で API キーのアクティビティを検知すること、そして明確なインシデント対応手順を整備し、侵害された可能性のある API キーに迅速に対応することです。

ベストプラクティスは、最小権限の原則に基づく適切なアクセスコントロールを維持しながら、これらのコントロールを実装することです。この多層的なアプローチにより、開発ニーズに合わせて API キーを効果的に活用しつつ、強固なセキュリティポスチャを維持できます。

この記事に関するご質問は、AWS サポートにお問い合わせください。

本ブログは Security Solutions Architect の中島章博が翻訳しました。

Amazon Web Services ブログ