Userアカウントを持っていない人に対して一時的にファイルのダウンロード/アップロードさせたい場合があります。ついての説明はあるものの、その仕組みについて触れたものはほとんどなかったため、記事にまとめました。V2は2019/6/24以降、利用できなくなりますのでご注意ください。RoleをAssumeRole出来る権限が必要です。Credentialsであれば、AccessKey/SecretAccessKey/SessionTokenのセット)を持っている必要があります。Bucketに一時的にアクセスさせることを目的として発行する、一時的なURLといえます。ポイントはTL;DRに上述した通りです。URLそのものに関するドキュメントはあまり多くありません。挙げるとすればこのあたりでしょうか。object.これは、一時的に有効なURLを発行して、ユーザにファイルをアップロードさせることを想定した利用方法です。会員制のWebサービスなどでユーザからのファイルを受け取る場合を想定したものとなります。URLは、一定時間のみ有効です。生成から60秒間有効など、有効期間を短く設定しておくことで、セキュリティ上の脅威も発生しにくくなります。URLを生成することもできます。URLを生成してアクセスしてみます。Roleを利用する場合とで少し違いがありますので、両方試してみます。利用した環境は以下の通りです。]}S3にファイルをアップロードしておきます。内容は何でも構いません。example.json今回は以下のような内容でファイルをアップロードしました。UserのAccessKey/SecretAccessKeyを発行します。CLIがインストールされている適当なLinuxインスタンス(ローカルのVMでもEC2インスタンスでも何でも)で、AccessKeyとSecretAccessKeyの設定をします。ここでは、有効期限は60秒としています。これは「--expires-in」オプションで指定できます。生成されたURLに、先ほど指定したAccessKeyがそのまま入っていることが分かります。s3://investigate-iot-jobs/example.jsonhttps://investigate-iot-jobs.s3.amazonaws.com/example.json?AWSAccessKeyId=****************EREA&Expires=1555228202&Signature=**********************Wqw20%3D生成したURLをもとにHTTPリクエストを行うと、S3上のファイルを取得することができます。Forbiddenが返却され、エラーとなります。Profileを利用して試します。Roleを付与します。ここでは「role-ec2-readonly」という名称にしています。CLIの設定上、AccessKey/SecretAccessKeyが設定されていないことを確認します。RoleをAssumeRoleしたものであることを確認します。先ほどとはうって変わって長いURLが発行されました。※上記URLは一部省略このURLも、先ほどと同様、ファイルをダウンロードすることができます。今度はWebブラウザから試してみますが、同様にコンテンツが表示されます。60秒後、リロードして再度ダウンロードを試みるとやはりエラーとなり参照できなくなります。URLは有効期限付きですが、大きなファイルをダウンロード中に有効期限を過ぎてしまった場合はどうなるでしょうか。結論としては、ダウンロード中に通信が切断されることはありません。URLが有効かどうかのチェックは、AWS側でリクエストを受け付けたタイミングでおこなわれます。その瞬間に有効期限が過ぎていなければ、その後通信が遮断されない限りは、最後までファイルをダウンロードすることが可能です。URLの利用方法についてみてきました。以下から、少しその仕組みを説明します。V2/V4とはAWSは無数のサービスを提供しており、様々な機能がありますが、AWSに対する操作は最終的にはすべてAPIとなります。Referenceにすべてまとめられています。APIに基づくリクエスト/レスポンスで操作します。APIのリクエストを受け付けた際に、以下のようなチェックを行います。リクエストの内容が改ざんされていないこと(Integrity)正統なユーザから発行されたこと(Authenticate)当該ユーザは対象APIを実行する権限があること(Authorize)これらチェックするために、APIリクエスト発行時に署名を付与する必要があります。V2/V4となります。どのように署名を生成・付与するかについては、S3については下記公式ドキュメントに記載があります。V2に基づく説明となります。V2を利用しています。V2は2019/6/24以降、利用できなくなりますのでご注意ください。V4に関する説明は下記あたりを参照すると良いでしょう。Serviceshttps://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html詳細は割愛しますが、概ね以下のような仕組みとなっています。APIを発行する際に、そのリクエスト内容を元に署名を作る。SecretAccessKeyを鍵として用いて署名を作成する。APIに当該署名を付与してリクエストする。当該リクエストを受け取ったAWSは、1と同一の手順で署名を生成し、リクエストに付与されたものと照合する。stringパラメータとして付与することができます。URLとは、後者の手段を活用して、URLに署名を付与することだといえます。下記ドキュメントにもこのような記載があります。V2による署名が生成されます。V4で生成するには予め下記コマンドを実行しておく必要があります。V2/V4を理解することで、理解することができます。Credentialsが、PermanentなものかTemporaryなものか、という違いに起因します。Credentialsには、PermanentなものとTemporaryなものがあります。RoleをAssumeRoleした際などに得られるものは後者となります。APIリクエストに含める必要があります。Credentialsを利用したものとなるのでSessionTokenが必要となり、これをリクエストに含める必要があるため、URLが長くなります。URLの有効期間中であっても、当該URLを利用したアクセスは拒否されます。Entity(User/Role)によるリクエストですので、当然と言えます。Centerの記事にも記載があります。Credentialsの有効期限が切れてしまった場合なども同様の結果になります。APIを発行する1つの手段であると言えます。URLの特性・制約を理解することができます。あと、AWSソリューションアーキテクトの試験(アソシエイト/プロフェッショナルどっちだったかは忘れてしまいましたが)で範囲に入っていたように記憶しているので、当該試験の受験を予定している人は是非ともおさえておきましょう。