amazonaws.com

Amazon Web Services（AWS）は、アプリケーションやその他のワークロードの構築・運用に必要な機能を提供するクラウドサービスの組織です。提供するサービスは、コンピューティング、ストレージ、データベース、分析、アプリケーション統合など、多くの分野にわたります。理解のポイントは、AWSが単一のワークフローを持つ1つのアプリケーションではなく、異なる目的を持つ多数のサービスを提供していることです。

amazonaws.comというドメインは、AWSのサービスエンドポイントの名前空間を表し、ソフトウェアはそこを通じて個々のAWSサービスやリソースに接続できます。AWSの一般向け情報サイトはaws.amazon.comであり、エンドポイント用のドメインとサービス紹介用のホームページは異なる役割を担っています。この違いを理解すると、誰かがAWSのウェブサイトを閲覧していなくても、アプリケーションがamazonaws.comに接続する理由が分かります。

AWSは何の構築・運用に役立つのでしょうか？

AWSは2006年にサービスを開始し、組織がワークロードを構成・運用するために利用できるクラウド機能を提供しています。提示された公式資料では、アプリケーションの実行、情報の保存、データベースの利用、分散システムの接続に使うサービスが説明されています。そのため、AWSを選ぶ際には、ワークロードに必要な機能を特定し、それに対応するサービスを理解する必要があります。

サービスカタログを見ると、その幅広さが分かりますが、すべてのサービスが互いに置き換え可能なわけではありません。EC2は仮想サーバー、S3はオブジェクトストレージ、Lambdaはサーバーやクラスターを管理せずにコードを実行するサービスとして説明されています。これらを使うアプリケーションが同じ広いドメイン群の中でリクエストを送る場合でも、それぞれは異なる構成要素です。

ワークロードの要件	提示されたAWS資料に記載された例	実用上の違い
アプリケーションのワークロードを実行する	EC2とLambda	コンピューティングサービスは、コードを実行するための異なる方法を提供します。
オブジェクトを保存する	S3	オブジェクトストレージは、リレーショナルデータベースとは異なる目的で使われます。
データベースを利用する	RDSとDynamoDB	AWSには、リレーショナルデータベースとNoSQLデータベースのサービスがあります。
アプリケーションの構成要素を接続する	API Gateway、SQS、Step Functions	APIアクセス、メッセージキュー、ワークフローは、それぞれ異なる統合の要件に対応します。
ワークロードを分析・観測する	AthenaとCloudWatch	データのクエリと運用の監視は別々の作業です。

この幅広さにより、AWSは1つのワークロード内で複数のクラウド機能を必要とする開発者にとって有用です。一方で、選定の作業も生じます。組織は、自社のアプリケーションに適したサービス、アクセスモデル、運用上の責任を見極める必要があります。親ドメインがよく知られているからといって、こうした判断が不要になるわけではありません。

amazonaws.comは何に使われるのでしょうか？

AWSのドキュメントでは、エンドポイントをAWSウェブサービスへの入口となるURLと定義しています。多くのエンドポイントは、サービスを識別する情報や、場合によってはAWSリージョンの情報とともに、ホスト名の一部としてamazonaws.comを使っています。ソフトウェアはこれらのアドレスを使って、該当するサービスの入口にアクセスします。

AWSエンドポイントへのリクエストは、意図的にウェブサイトを訪問した結果ではなく、アプリケーションの動作の一部である場合があります。同じ親ドメイン配下でも、リクエストごとにサービス、アカウント、リソース、アクセスモデルが異なることがあります。共通の末尾部分から分かるアプリケーションの背景情報は、リクエスト全体から分かる情報よりも限られています。

サービスエンドポイントの読み取り方

ドキュメントに記載された例であるdynamodb.us-west-2.amazonaws.comには、amazonaws.comだけの場合よりも有用な情報が含まれています。このアドレスはDynamoDBを示し、リージョンコードus-west-2を含んでいます。この情報でサービスの範囲を絞り込めますが、呼び出し元や対象リソースのすべてが分かるわけではありません。

• サービス名： 接続先のAWS機能を特定する手掛かりになります。
• リージョンコード： エンドポイントがリージョン別の命名形式に従っている場合に、リージョンの情報を示します。
• 完全なホスト名： 観測した情報を親ドメインだけに縮めると失われる違いを保持します。
• リクエストパス： リクエストに関する追加情報を示します。その解釈にはサービスのドキュメントが必要です。
• リクエスト元のアプリケーション： 技術的なアドレスと、個人や組織が想定している活動を結び付ける手掛かりになります。

これらの詳細は、まとめて検討する必要があります。サービスのホスト名は接続先についての有用な証拠となり、アプリケーションとリクエストは、その接続先が使われる理由を理解するための背景情報を与えます。サービス名も親ドメインも、それだけでは対象データの用途を確定できません。

一部のAWSアドレスにリージョンが含まれるのはなぜでしょうか？

多くのAWSエンドポイントにリージョンコードが含まれるのは、サービスへのリージョン別の入口を提供しているためです。AWSは、一部のサービスについて汎用エンドポイントやグローバルエンドポイントも文書化しています。エンドポイントの正確な動作は個々のサービスによって決まるため、1つの命名形式をサービスカタログ全体に当てはめるべきではありません。

開発者にとって実用上の確認事項は、選択したサービスのドキュメントで、目的の操作にどのエンドポイントが指定されているかです。リージョンコードを認識できると調査に役立ちますが、別のサービスの命名形式からアドレスを推測しても、確認の代わりにはなりません。AWS全般のリファレンスとサービスエンドポイントのドキュメントが出発点になります。

エンドポイントの種類	提示された調査で確認されていること	さらに確認が必要なこと
リージョン別	多くのホスト名には、サービスコード、リージョンコード、amazonaws.comが含まれます。	選択したサービスとリージョンについて文書化されているエンドポイント。
汎用	一部のサービスには汎用エンドポイントがあります。	そのエンドポイントに送られたリクエストを、該当サービスがどのように処理するか。
グローバル	AWSは一部のサービスについてグローバルエンドポイントを文書化しています。	そのサービスで文書化されている操作とリージョンに関する動作。

サービスごとのエンドポイントの利点は、ルーティングと機能間の区分が明確になることです。一方、ネットワークの活動を確認する人にとっては、*.amazonaws.comのようなワイルドカードで捉えると、その有用な詳細の多くが見えなくなります。目的が大きく異なる可能性のある接続先が、ひとまとめにされるためです。

AWSのアドレスからアプリケーションの運営者は分かるのでしょうか？

amazonaws.comが見えても、特定のリクエストに責任を持つ顧客、ワークロード、アプリケーションの所有者は特定できません。AWSというクラウドサービスの背景は分かりますが、親ドメインはその活動の背後にあるアカウントやリソースを説明しません。また、どのような情報が保存、取得、処理されているかも確定できません。

これは、アプリケーションの活動やネットワークの記録で、見慣れない接続に気付いたときに関わってきます。アドレスはAWSサービスの特定に役立つ場合がありますが、接続を解釈するには、その接続を行っているソフトウェアから得られる証拠が必要です。問うべきなのは、そのアプリケーションが接続先を使って何をしているかです。

確認の際には、次の問いを分けて考えると役立ちます。

1. どのアプリケーションがリクエストを開始したのか？ 接続先を、確認対象のソフトウェアと活動に結び付けます。
2. 完全な接続先は何か？ ドメインの末尾だけでなく、ホスト名とパスを保持します。
3. どのサービスを示しているのか？ アドレスを関連するAWSドキュメントと照合します。
4. どのような操作が想定されているのか？ リクエストとアプリケーションの意図された動作との関係を確認します。
5. どのアクセスモデルが適用されるのか？ そのサービスとリソースに必要な認証情報とアクセス許可を確認します。
6. 何がまだ説明できていないのか？ 得られた背景情報で確定できない場合は、所有者、データの用途、認可の有無を未解決のままにします。

この方法なら、インフラの提供元をアプリケーションの運営主体と同一視せずに済みます。また、調査の焦点も明確になります。あるアプリケーションのリクエストに関する不確実性を、同じ末尾を持つすべての接続先についての結論にするのではなく、そのアプリケーションとサービスについての確認事項として扱えます。

認証情報とアクセス許可はアクセスにどう影響するのでしょうか？

AWSの認証情報とアクセス許可は、それぞれ異なる問いに答えます。認証情報は呼び出し元を認証し、アクセス許可はその呼び出し元が実行できるアクションを認可します。エンドポイントがどのサービスに属するかが分かっても、特定の呼び出し元が特定のリソースを使えるかどうかは確定しません。

正確な要件は、個々のサービスとそのアクセスモデルによって決まります。開発者は、AWSセキュリティ認証情報の概要と、利用するサービスおよび操作のドキュメントを併せて参照する必要があります。エンドポイントが存在するという事実だけでは、そうした要件のすべては分かりません。

アクセスに関する問い	関連する概念	それだけでは確定できないこと
誰がリクエストを送っているのか？	認証情報による認証	呼び出し元が要求したアクションを実行してよいかどうか。
呼び出し元はこのアクションを実行してよいのか？	アクセス許可による認可	無関係なアクションやリソースへのアクセスも許可されているかどうか。
ここではどの要件が適用されるのか？	サービス固有のドキュメント	すべてのAWSエンドポイントに共通するアクセスルール。

責任の検討は提供元の確認だけでは終わりません

AWSは、サービス利用時の責任分担を理解するために、責任共有モデルを公開しています。これは、AWSのホスト名を見分けることとは別の問題です。チームは、提供元が分かればアプリケーションレベルの疑問も解決すると考えるのではなく、サービスのアクセス要件と併せて、自分たちの責任を検討する必要があります。

提示された証拠は、AWSを評価する際の一要素として、この責任分担を説明する根拠になります。ただし、特定の顧客がアプリケーションやリソースをどのように設定しているかを示すものではありません。特定のデプロイ環境を評価するには、その環境についての情報が必要です。

組織はドメイン群全体を許可またはブロックすべきでしょうか？

amazonaws.comには複数のサービスと、互いに無関係である可能性のあるワークロードが含まれるため、ドメイン全体に対する判断は広範囲に影響します。ドメイン群全体をブロックすると、それらの接続先に依存するアプリケーションに支障が出る可能性があります。無差別に許可すると、個々のリクエストの主体や目的が説明されないままになります。

AWSのホスト名が存在するだけで、どちらかの選択が自動的に決まるわけではありません。ネットワーク管理者には、組織のポリシー、リクエスト元のアプリケーションの目的、サービスごとの接続先に関する背景情報が必要です。提示された調査は、適切なアクセス範囲を決める前に、それらの詳細を確認することを裏付けています。

状況	有用な次の手順	利用可能な証拠の限界
既知のアプリケーションがAWSエンドポイントに接続している	接続先を、そのアプリケーションで想定されるサービス利用と照合します。	アプリケーションを知っているだけでは、すべてのリクエストを説明できません。
見慣れないプロセスがamazonaws.comに接続している	プロセスを特定し、リクエストの背景情報を完全に保持します。	親ドメインからは、プロセスの所有者や意図は分かりません。
提案されたルールがすべてのサブドメインを対象にしている	そのルールがどのアプリケーションとサービスに影響するかを評価します。	ワイルドカードは個々の接続先の違いを見えなくします。
リクエストが疑わしく見える	アプリケーション、リソース、関連サービスの背景情報を調査します。	AWSのインフラであることは、安全性の保証にはなりません。

予期しないアドレスを理解しようとする個人にも、同じ考え方が当てはまります。AWSだと認識できればインフラの種類は説明できますが、その接続が適切かどうかは判断できません。中心となるのは、あくまでアプリケーションの動作とリクエストの目的です。

開発者はドキュメント、コミュニティの支援、不正利用の連絡先をどこで見つけられるのでしょうか？

AWSドキュメントの索引は、サービスのガイダンスにアクセスするための総合的な入口です。アドレスやリージョンに関する動作を確認する際には、全般のリファレンスとサービスエンドポイントのページが特に役立ちます。認証情報の概要は、呼び出し元の認証について補足する説明を提供しています。

AWSは、コミュニティの質問・回答サービスとしてre:Postも提供しています。開発者はそこでAWSの利用について質問でき、公式の問い合わせ窓口ではサポートや不正利用の疑いに関する相談ができます。コミュニティでの議論と不正利用の報告は目的が異なるため、それに応じて使い分ける必要があります。

• エンドポイントを特定する： AWS全般のリファレンスとエンドポイントのドキュメントから確認を始めます。
• サービスを理解する： ドキュメントの索引から、該当サービスのガイダンスを探します。
• アクセス要件を明確にする： 認証情報の概要と、そのサービスのアクセス許可に関するドキュメントを併せて読みます。
• 実装について質問する： AWS re:Postコミュニティを利用します。
• 問い合わせや不正利用の報告先を探す： AWSの公式お問い合わせページを参照します。
• AWSのプライバシー情報を確認する： AWSプライバシー通知を参照し、それとは別に、リクエストを行っているアプリケーションを調べます。

AWSは、アプリケーションの実行、情報の保存、構成要素の統合、ワークロードの運用にクラウド機能を必要とする組織や開発者向けのサービスです。証拠に基づくと、amazonaws.comはソフトウェアとそれらの機能をつなぐエンドポイントの名前空間と説明できます。親ドメインだけでは得られないサービス、リージョン、アプリケーション、アクセスの背景情報を保持することを前提に、特定のサービスを評価する読者や、それらを実装する開発者に適しています。