http://hx3w4xvvlq4b48mkncgi.duckdns.org
# 2023年前期
2022年に行ったVue.jsを使用して、aws上にサーバレスアーキテクチャの考えのものOSを意識しないシステムの構成を考える。
そのため必要となる各AWSのサービスを調査し、その後に実演を行う。

## サーバレスアーキテクチャ
### 概要
サーバレスアーキテクチャは、クラウドコンピューティングの一形態で、**アプリケーションの開発、運用がサーバの管理なし**に行われることを指します。このアーキテクチャの主な特徴は、開発者がサーバのプロビジョニング、管理、スケーリングといったインフラストラクチャの管理から解放される点にあります。代わりに、クラウドサービスプロバイダーがこれらのインフラストラクチャの管理を担当し、開発者はアプリケーションのコード記述に集中できます。

#### 主な特徴と利点
* 自動スケーリング: アプリケーションの需要に基づいて、リソースが自動的にスケーリングされます。利用が少ない時はリソースが縮小され、コストを節約できます。
* イベント駆動: 多くのサーバレスプラットフォームはイベント駆動型であり、特定のイベント（例えば、ファイルのアップロード、データベースの更新など）がアプリケーションの実行をトリガーします。
* 支払いモデル: 実際に使用したリソースに対してのみ料金を支払います。サーバを24時間稼働させる従来のモデルと比較して、コスト効率が高い場合があります。

#### 利用シナリオ
サーバレスアーキテクチャは、以下のようなシナリオで特に有効です。
* マイクロサービスベースのアプリケーション: 独立した小規模なサービスが特定の機能を提供します。
* イベント駆動アプリケーション: ユーザーのアクションやシステムイベントに応答するアプリケーション。

スパイクが予測されるアプリケーション: プロモーションやイベントによる急激なトラフィック増加に柔軟に対応できます。

### サーバレスアーキテクチャをAWS環境上で実現するためには
#### FaaS
FaaS (Function-as-a-Service)とは、サーバレスでアプリケーション開発ができるクラウドサービスのカテゴリのことです。クラウドプロバイダーがサーバのプロビジョニング、管理、スケーリングの責任を負うため、開発者はアプリケーションのビジネスロジックの開発に集中できます。

##### AWSで使用するサービス
* AWS Lambda: サーバレスコンピューティングを提供する主要サービスで、コードの実行環境を管理することなく、コードを実行できます。
* Amazon API Gateway: RESTful APIやWebSocket APIを簡単に作成、公開、維持、監視、保護できるサービスです。
* Amazon S3 (Simple Storage Service): ウェブサイトの静的ファイルやLambda関数のコードなど、大量のデータを保存するためのオブジェクトストレージサービス。
* Amazon DynamoDB: 完全マネージド型のNoSQLデータベースサービスで、高速かつ予測可能なパフォーマンスを提供します。
* AWS IAM: AWSリソースへのアクセスを安全に制御するためのサービスです。→ 説明あり
* CloudFront: フロントエンドを配信するには必須 → 説明あり
* Amplify: 必須ではないが、FaaS開発を行う場合は非常に強力なサービス → 説明あり
* Cognito(認証): ログイン機能を入れる場合は必須 → 説明あり

## aws サービス
### Amplify
#### Amplifyの概要
AWS Amplifyは、開発者がフルスタックのウェブアプリケーションとモバイルアプリケーションを簡単に構築、デプロイ、ホスティングできます。これには、認証、データベースの操作、APIの作成、ファイルストレージの統合が含まれます。

#### Amplifyの利用料金
・静的ウェブホスティング
Amplify Console ではビルドとデプロイ、ホスティング機能に対して従量課金が発生します。

ビルド&デプロイ費用 : ビルド 1 分あたり 0.01USD
ストレージ費用 1GB あたり : 0.023USD/月
ホスティングサービス 1GB あたり : 0.15USD
https://aws.amazon.com/jp/amplify/pricing/?nc=sn&loc=3

#### 特徴
AWSには他にもアプリケーション開発とデプロイメントをサポートするサービスがありますが、Amplifyは特にフロントエンド開発者に焦点を当てており、以下の点で異なります。
* 統合性:
Amplifyはフロントエンドとバックエンドの開発を一元化するサービスであり、AWS内の他のサービス（例: AWS Lambda, Amazon DynamoDB）との統合が容易です。
* 開発の迅速化:
Amplifyは、ユーザー認証やデータベース接続などの一般的なアプリケーション機能を迅速に実装するための高レベルの抽象化を提供し、開発時間を短縮します。
※ 詳細は「**開発の迅速化**」で説明します。
* デプロイとホスティングの簡素化
Amplify Consoleを通じて、CI/CDパイプラインを用いた自動ビルドとデプロイが可能であり、他のAWSサービスと比較してより直感的なユーザー体験を提供します。

#### Amplifyと連携する主なAWSサービス
* 静的サイトの配信
Amplifyで開発された静的サイトは、デプロイ時に自動的にAWS CloudFrontを通じて配信されます。
* 認証
Amazon Cognitoを利用して、セキュアなユーザー認証と認可機能をアプリケーションに追加できます。
* API
GraphQLまたはREST APIを簡単に作成し、AWS AppSyncやAmazon API Gatewayを通じてデータを効果的に管理し、アプリケーションに統合できます。
* データストア
オフライン対応のデータ同期機能を提供し、アプリケーションのデータを自動的にクラウドと同期させることができます。
* ファイルストレージ
Amazon S3を使用して、アプリケーション内でのファイルアップロード、ダウンロード、操作を簡単に実装できます。
* アナリティクス
Amazon PinpointやAmazon Kinesisを活用して、アプリケーションのユーザー行動を追跡し、分析することができます。
* AI/ML
Amazon AIサービスを簡単に統合し、アプリケーションに機械学習機能を追加できます。

#### 開発の迅速化
1. 高レベルの抽象化
Amplifyは、バックエンドサービス（認証、データベース操作、ファイルストレージなど）のセットアップと管理を抽象化し、簡素化します。この抽象化により、開発者は複雑なインフラストラクチャの設定や管理に時間を費やすことなく、アプリケーションのコア機能の開発に集中できます。
2. プリセットとプリビルドのコンポーネント
Amplifyは、認証フロー、APIの通信、データモデリングなどのためのプリセットやプリビルドのコンポーネントを提供します。これらを使用することで、一般的な機能の開発に必要なコードを大幅に減らし、開発プロセスを加速できます。
3. CLIとGUIツール
Amplify CLI（コマンドラインインターフェース）とAmplify Studio（グラフィカルユーザーインターフェース）を使用すると、バックエンドリソースの作成、構成、更新が容易になります。これらのツールは直感的な操作を提供し、バックエンドサービスのセットアップを迅速化します。
4. 統合された開発フロー
Amplifyは、フロントエンドとバックエンドの開発をシームレスに統合します。Amplify Consoleを使用したCI/CDパイプラインにより、ソースコードの変更が自動的に検出され、ビルド、テスト、デプロイが行われます。これにより、手動でのデプロイメントプロセスが不要になり、開発サイクルを短縮できます。
5. インスタントフィードバックとプロトタイピング
Amplify Studioを使用すると、データモデルをビジュアルに構築し、即座にフロントエンドのプロトタイプを生成できます。このプロセスにより、アイデアの検証とフィードバックの収集が迅速に行え、開発プロセスの初期段階で時間を節約できます。
6. クラウドサービスとの緊密な統合
AWSの他のサービス（Lambda、DynamoDB、S3など）との緊密な統合により、これらのリソースをアプリケーションに簡単に組み込むことができます。開発者は、これらのサービスを利用して高度な機能を追加できますが、Amplifyが提供する抽象化とツールにより、その過程が大幅に簡素化されます。

#### 具体的な開発ステップ
AWS Amplifyを使用した開発プロセスは、簡潔で直感的なステップに分かれており、開発者が迅速にフルスタックのウェブやモバイルアプリケーションを構築できるように設計されています。

1. 環境のセットアップ
Amplify CLIのインストール: 最初のステップとして、Amplify Command Line Interface (CLI)をインストールします。これにより、コマンドラインからAmplifyの機能にアクセスし、プロジェクトのセットアップや管理を行えます。

    Copy code
    npm install -g @aws-amplify/cli

プロジェクトの初期化: 新しいプロジェクトディレクトリを作成し、その中でamplify initコマンドを実行して、新しいAmplifyプロジェクトを初期化します。このプロセスでは、プロジェクト名、環境名、エディター、プログラミング言語、フレームワークなどの基本的な設定を行います。

2. 機能の追加
* 認証の追加
amplify add authコマンドを使用して、アプリケーションにユーザー認証機能を追加します。このステップでは、Amazon Cognitoを背後で使用して、サインアップ、サインイン、パスワードリセットなどの認証フローを簡単に実装できます。
* APIの追加
GraphQLまたはREST APIをamplify add apiコマンドで追加します。API GatewayとLambda（RESTの場合）やAppSync（GraphQLの場合）を使用して、バックエンドロジックやデータベースとの連携を設定します。
* ストレージの追加
amplify add storageコマンドを使用して、ファイルストレージ（S3）やデータベースストレージ（DynamoDB）をアプリケーションに組み込みます。

3. ビルドとデプロイ
変更のプッシュ: amplify pushコマンドを実行して、追加または変更された機能をAWSにデプロイします。このコマンドにより、クラウドリソースが作成または更新され、アプリケーションのバックエンドが構築されます。
* フロントエンドの開発
Amplifyライブラリをフロントエンドプロジェクトに組み込み、APIや認証などのサービスをフロントエンドコードと統合します。Amplify JavaScriptライブラリを使用すると、React、Angular、Vueなどのフレームワークでこれらの機能を簡単に利用できます。

* Amplify Consoleを使用したデプロイ
Amplify Consoleを使用してフロントエンドとバックエンドの両方をデプロイし、CI/CDパイプラインを設定します。GitHub、GitLab、Bitbucketなどのリポジトリにコードをプッシュするだけで、自動的にビルド、テスト、デプロイが行われます。

4. モニタリングと分析
分析の追加: amplify add analyticsコマンドを使用して、アプリケーションにユーザー行動分析機能を追加します。Amazon PinpointやAmazon Kinesisを利用して、アプリケーションの使用状況やユーザー行動を追跡し、改善点を特定できます。

### Cognito
#### 概要
Amazon Cognitoは、ウェブやモバイルアプリケーションのユーザー認証、認可、ユーザー管理を簡単に追加できるサービスです。AWS (Amazon Web Services) が提供するこのサービスは、開発者がセキュアなユーザー認証プロセスを迅速に実装するのを助けます。
Cognitoは、サインアップ、サインイン、アクセスコントロールなどの機能を提供し、ユーザーがソーシャルサインイン（Facebook、Google、Amazonなど）を使用してアプリケーションにログインできるようにします。
※ AWS公式では「ソーシャルサインイン」ではなく、「フェデレート もしくは フェデレーション」という単語が使用されています。しかし、Facebook、Googleなどでは「ソーシャル」という単語が使用されていたため、前者の「ソーシャル」に統一しています。
意味は正確には違いますが、「サービス間で身元を確認し、アクセスを容易にする技術や概念」という意味で使用されている場合のみ置換しています(フェデレーション認証等の置き換えができないものに関してはそのままとしています)。

* ユーザープール（User Pools）
ユーザープールは、アプリケーションユーザーの認証情報を管理するためのユーザーディレクトリです。ユーザープールを使用すると、開発者はサインアップとサインインサービスをアプリケーションに簡単に追加できます。また、ソーシャルサインイン（Google、Facebook、Amazonなどのソーシャルアイデンティティプロバイダーを介したサインイン）や企業のSAMLベースのアイデンティティプロバイダーを介した認証もサポートしています。
フェデレーション認証を使用するユーザーでも、ローカル（Cognitoユーザープールに直接サインアップした）ユーザーと同様に、ユーザープール内にユーザープロファイルが作成されます。これにより、アプリケーションはフェデレーションユーザーとローカルユーザーを区別することなく、統一されたユーザー管理を行うことができます。各ユーザープロファイルには、ユーザーの属性や認証状態など、アプリケーションがユーザーを識別し管理するのに必要な情報が含まれています。

* アイデンティティプール（Identity Pools）
アイデンティティプールは、ユーザーまたはゲストに割り当てて一時的な AWS 認証情報を受け取ることを許可する一意の識別子 (ID) の集まりです。SAML 2.0、OpenID Connect (OIDC)、または OAuth 2.0 ソーシャル ID プロバイダー (IdP) からの信頼できるクレームという形でアイデンティティプールに認証証明書を提示すると、ユーザーをアイデンティティプールの ID に関連付けます。アイデンティティプールがアイデンティティ用に作成するトークンは、AWS Security Token Service (AWS STS) から一時的なセッション認証情報を取得できます。
※ OAuth 2.0の詳細はCognitoの認可を理解する上で必須であるため、「OAuth2.0」で別途説明を行います。

#### 主な機能
1. ユーザー認証とサインアップ
ユーザープールを使用して、アプリケーションのユーザー認証情報を管理します。ユーザーは、ユーザーネームとパスワード、ソーシャルアイデンティティプロバイダー（Google、Facebook、Amazonなど）、または企業の既存のアイデンティティシステムを通じてサインアップおよびサインインできます。
カスタマイズ可能なサインインフローとセキュリティ機能（マルチファクタ認証、アカウントリカバリーなど）を提供します。
2. セキュアなアクセス制御と認可
IAMロールとポリシーを利用して、認証されたユーザーに対する細かなアクセス制御を行います。アイデンティティプールを通じてユーザーに一時的なAWSクレデンシャルを発行し、指定されたIAMポリシーに基づいてAWSリソースへのアクセスを許可または拒否します。
OAuth 2.0スコープをサポートし、アプリケーション内でユーザーが実行できるアクションの範囲を限定します。これにより、アプリケーションはユーザーの代わりに特定のリソースにアクセスするための許可を安全に管理できます。
3. ソーシャルおよびエンタープライズアイデンティティ統合
ソーシャルログインやSAMLベースのアイデンティティプロバイダを通じて、ユーザーにシームレスな認証体験を提供します。これにより、アプリケーションは既存のアイデンティティプロバイダーを活用して、ユーザー管理を簡素化できます。
4. カスタマイズと拡張性
ユーザー登録、認証プロセス、アカウントリカバリーをカスタマイズできます。Lambdaトリガーを使用して、認証イベントにカスタムロジックを追加し、アプリケーションのニーズに合わせてビジネスロジックを統合できます。
5. スケーラビリティと信頼性
AWSのグローバルインフラストラクチャ上で構築されており、大規模なユーザーベースを持つアプリケーションに対しても、セキュアなユーザー管理と認証サービスを提供します。
6. AWSサービスとの統合
Amazon S3、Amazon DynamoDB、Amazon Lambdaなど、他のAWSサービスと緊密に統合されています。これにより、開発者はAWSのリソースを活用し、アプリケーションの開発と運用をシームレスに行うことができます。

### OAuth2.0
#### 概要
OAuth 2.0は、**インターネットユーザーがサードパーティアプリケーションに対してリソースへのアクセス権を安全に委任するためのプロトコル**です。このプロトコルは、ウェブやモバイルアプリで広く使用されています。特に、ソーシャルログインや外部アカウントとの連携機能は、OAuthを利用した応用例の一つとして重要な役割を果たします。例えばユーザーは、FacebookやGoogleなどのアカウントを使用して他のアプリケーションやサービスにログインすることができます(ソーシャルログイン)。これにより、異なるサービス間でのアカウント情報の共有が容易になり、ユーザー体験が向上します。

重要なのは、OAuth 2.0が本質的に「**アクセス権を安全に委任するためのプロトコル**」として設計されたことです。ソーシャルログインは、このプロトコルを活用した一例であり、OAuth 2.0の柔軟性と有用性を示すものです。その主な目的は、ユーザーが自分のデータへのアクセスを信頼できるサードパーティに限定して許可することにあります。これにより、ユーザーのプライバシーとセキュリティが保護され、サービス提供者とユーザー双方にメリットをもたらします。

#### 特徴
OAuthは、「リソースへのアクセス権を安全に委任するためのプロトコル」として設計されており、特にサードパーティアプリケーションがユーザーの代わりにリソースにアクセスする際に重要な役割を果たします。この点で類似技術としてBasic認証があります。この技術と比較を行い、OAuthが持つ特徴的な部分を以下に説明します。

##### Basic認証
Basic認証は、ユーザー名とパスワードをBase64エンコードした形式でHTTPヘッダーに含めることにより、クライアントの身元をサーバーに証明するシンプルな認証方法です。
##### Basic認証の特徴
* シンプルさ: Basic認証は非常に単純で、実装が容易です。
* セキュリティの制約: ユーザー名とパスワードをHTTPヘッダに含める関係上、中間者攻撃に対して脆弱です。
* ステートレス性: Basic認証はステートレスなので、クライアントはリクエストごとに認証情報を送信する必要があります。
* 限定的な機能性: ユーザーに細かなアクセス権を与えたり、アクセス権を限定的に設定したりすることはできません。

##### OAuthの特徴
* トークンベースのアクセス制御: OAuthでは、ユーザーの資格情報（ユーザー名とパスワード）を直接サードパーティに提供する代わりに、アクセストークンが使用されます。これにより、資格情報の露出リスクが減少し、セキュリティが強化されます。
* 限定的なアクセス許可: ユーザーはサードパーティアプリケーションに対して、必要なリソースへの限定的なアクセスのみを許可できます。例えば、写真のアップロードのみを許可するが、他のデータにはアクセスさせない、といった制御が可能です。
* ユーザーの同意が必要: OAuthプロセスでは、ユーザーがアクセス許可を明示的に与える必要があります。これにより、ユーザーは自分のデータに対するコントロールを保持できます。

##### Basic認証との比較
* 認証情報の露出: Basic認証では、ユーザー名とパスワードがHTTPリクエストを介して直接サーバーに送信されます。これに対して、OAuthではアクセストークンが使用され、資格情報自体がサードパーティに露出することはありません。
* セキュリティレベル: OAuthはBasic認証よりも高いセキュリティを提供します。特に、アクセストークンは短期間で有効期限が切れるため、長期間にわたるセキュリティリスクが軽減されます。
* アクセス権の柔軟性: Basic認証では、一度認証を通過すれば、ユーザーがアクセス可能な全てのリソースにアクセスできます。OAuthでは、アクセス権をより細かく制御し、特定のリソースへのアクセスのみを許可できる点が異なります。

| 特徴 | Basic認証 | OAuth |
|----------------------|---------------------------------------|------------------------------------------|
| 認証情報の露出 | ユーザー名とパスワードを直接送信 | アクセストークンを使用、資格情報は露出しない |
| セキュリティレベル | 比較的低い（HTTPSとの併用推奨） | 高い（トークンベースでセキュリティが強化されている） |
| アクセス権の制御 | 限定的（全アクセス許可または拒否） | 柔軟（特定のリソースへのアクセス許可のみ可能） |
| ユーザーの同意要否 | 不要 | 必要（ユーザーがアクセス許可を明示的に与える） |
| ステートレス性 | ステートレス（リクエストごとに認証情報を送信） | 依存する認証サーバーの実装による |

このように、OAuthはサードパーティアプリケーションとの連携において、よりセキュアで柔軟なアクセス制御を提供するプロトコルです。ユーザーのプライバシー保護とデータのセキュリティに重点を置き、ユーザーが自身のリソースへのアクセスを安全に委任することを可能にします。

#### 構成要素と処理内容
##### 構成要素
* リソースオーナー（Resource Owner）: 通常、ユーザーを指します。リソースオーナーは自分のアカウント情報やリソースにアクセスする権限を、第三者に与えることができます。
* リソースサーバー（Resource Server）: リソースオーナーが保持しているリソース（データやサービスなど）をホストするサーバーです。このサーバーは、適切なアクセストークンを持つクライアントにのみリソースへのアクセスを許可します。
* クライアント（Client）: リソースオーナーのリソースにアクセスを求めるアプリケーションやサービスを指します。クライアントはリソースオーナーからアクセストークンを取得し、それを使用してリソースサーバーからリソースへのアクセスを要求します。
* 認可サーバー（Authorization Server）: アクセストークンを発行するサーバーです。クライアントは、リソースオーナーの承認を受けた後、このサーバーからアクセストークンを取得します。認可サーバーはリソースオーナーの認証と承認を処理し、これらのプロセスが完了すると、適切なアクセストークンをクライアントに発行します。
* アクセストークン（Access Token）: クライアントがリソースサーバーへアクセスする際に必要な認証情報です。このトークンは、リソースオーナーの承認に基づいて認可サーバーによって発行され、クライアントがリソースサーバーに対して自分が承認されたことを証明するために使用されます。

##### 処理内容

1. クライアント(APサーバ)からOAuth処理の開始をリソースオーナーへ要求
2. 認可サーバへ認可リクエストを送信。その後、パスワード認証を行う
3. 認証処理完了後、認証サーバからリソースオーナーへ認証コードが返却される
4. 認可コードを付与した状態でクライアントへとリダイレクト処理を行う
5. リダイレクト処理に付与されていた認可コードを使用し、認可サーバからアクセストークンを取得する（本質的なソーシャルログイン処理はこの状態で完了している）
6. 取得したアクセストークンを使用し、リソースサーバから権限内で情報を取得することができる

##### ユースケース図

@startuml
actor リソースオーナー as User
participant "クライアント" as Client
participant "認可サーバー" as AuthServer
participant "リソースサーバー" as ResourceServer

alt 認可コード取得処理
    User -> Client: 1. 認証の開始を要求

    Client -> AuthServer: 2. 認可リクエスト

    AuthServer -> User: 3. 認証を要求 (ログイン画面)

    User -> AuthServer: 4. ユーザー認証情報を提供

    AuthServer -> User: 5. 認証コードをリダイレクト経由で発行
    note over User, AuthServer
      認証コードはリダイレクトURIを通じてクライアントに戻される
    end note
end

alt OAuth2.0 認証処理
    User -> Client: 6. 認証コードを提供

    Client -> AuthServer: 7. 認証コードとクライアント情報を使用してアクセストークン要求
    note right of Client
      クライアントは認証コードの他にクライアントIDとクライアントシークレットを使用
    end note

    AuthServer -> Client: 8. アクセストークンを発行
    note right of AuthServer: アクセストークンはクライアントに渡される

    Client -> ResourceServer: 9. アクセストークンを使用してリソース要求

    ResourceServer -> Client: 10. 保護されたリソースを提供
end
@enduml

1. 認証の開始を要求
2. 認可リクエスト
3. 認証を要求 (ログイン画面)
4. ユーザー認証情報を提供
5. 認証コードをリダイレクト経由で発行
6. 認証コードを提供
7. 認証コードとクライアント情報を使用してアクセストークン要求
8. アクセストークンを発行
9. アクセストークンを使用してリソース要求
10. 保護されたリソースを提供

##### 実演
###### 画面

###### リソースオーナー
###### 各種サーバ
* client-1: クライアント
* auth-server-1: 認可サーバ
* resource-server-1: リソースサーバ

※ サンプルソース: https://github.com/hagiwara0305/oauth2-tutorial

##### 実演 (認証サーバをAWS Cognitoに変更した場合)
1. シナリオ1: Cognito HostedUIを使用

@startuml

actor "リソースオーナー" as User
participant "クライアント" as Client
participant "認可サーバ (AWS Cognito)" as AuthServer
participant "リソースサーバ" as ResourceServer

User -> Client: アクセス要求
Client -> User: 認証要求\n (CognitoのHostedUIへのリダイレクト要求)

User -> AuthServer: 認証ページへアクセス\n(ログイン)
AuthServer -> User: 認証成功\n(認可コード付きリダイレクト)

User -> Client: 認可コードを提供
Client -> AuthServer: 認可コードと\nクライアントシークレットを使用して\nアクセストークン要求

AuthServer -> Client: アクセストークンが含まれたJWTが返却 \n(および、リフレッシュトークン、IDトークン)

Client -> ResourceServer: JWTを送信
ResourceServer -> ResourceServer: JWTを解析し、改ざんがないかを確認
ResourceServer -> Client: 要求されたリソース

@enduml

* ログインフォームへの画面遷移

* CognitoのHostedUIへ画面遷移


※ サンプルコード: https://github.com/hagiwara0305/oauth2-tutorial-to-cognito-replacement

https://auth0.com/resources/ebooks/oauth-openid-connect-professional-guide?utm_content=japanengenericauthentication-oauth-oauthopenidconnectprofessionalguide&utm_source=google&utm_campaign=apac_japan_jpn_all_ciam-all_dg-ao_auth0_search_google_text_kw_utm2&utm_medium=cpc&utm_id=aNK4z0000004IYXGA2&utm_term=oauth-t&gad_source=1&gclid=Cj0KCQjwtJKqBhCaARIsAN_yS_loKP0Sb6ytUursWaqkVVb8f3-xjDd_JKcC-KudplJMB5gnVbvp7GYaAr5WEALw_wcB

### Clouf Front
AWS CloudFrontは、コンテンツデリバリーネットワーク（CDN）サービスであり、高速で安全なコンテンツの配信を可能にします。ユーザーに対して高い性能と低遅延のコンテンツアクセスを提供するために、容易にコンテンツを配信実現できます。

以下はAWS CloudFrontの主な特徴や概念についての説明です：
1. コンテンツデリバリーネットワーク（CDN）:
静的および動的なコンテンツ（画像、動画、HTML、JavaScriptなど）を世界中のエッジロケーションにキャッシュして配信します。これにより、ユーザーにとってより迅速かつ高品質なコンテンツアクセスが可能となります。
2. エッジロケーション:
エッジロケーションとは、CDN（コンテンツデリバリネットワーク）などで、閲覧者へのコンテンツ配信のために分散配置された拠点および設備のことです。Clouf Frontは世界中に分布するエッジロケーションにコンテンツをキャッシュし、ユーザーからのリクエストに最も近いエッジロケーションからコンテンツを提供します。これにより、レイテンシを低減し、ユーザーエクスペリエンスを向上させます。
3. オリジン:
コンテンツの元となるリソースを取得するためのオリジンと呼ばれるサーバー、S3バケット、Elastic Load Balancerなどと連携します。これらのオリジンからコンテンツを取得して、エッジロケーションにキャッシュします。
4. ディストリビューション:
CloudFrontディストリビューションは、特定のコンテンツまたはウェブアプリケーションの配信設定を定義します。ディストリビューションは、オリジンとエッジロケーションのマッピング、キャッシュ設定、セキュリティポリシーなどを含みます。
5. キャッシュ制御:
CloudFrontは、キャッシュ制御を通じて、コンテンツのキャッシュ時間、キャッシュ制御ヘッダー、キャッシュの動作を管理します。これにより、コンテンツの効率的なキャッシュと更新が可能となります。

## Amplifyで管理をしたサーバレスアーキテクチャの実演
### システム構成図

### Amplify上で追加したリソース
* Hosting: Amplifyでサービスを提供するためのリソース(CloudFron, S3バケット)
* Function: WebAPIとして使用するLambda(認証の可否は追加するタイミングに決める)
* Api: FunctionをWebAPIとして機能させるAPI Gateway
* Auth: 認証機能を追加するためのCongitoユーザプール

### ローカル環境からAWSへのデプロイと実演
ローカル環境上で「amplify publish」コマンドを実行。「Deployment complete!」のログが表示されればAWSへのデプロイ作業が完了。

AWSコンソール上でデプロイができていることを確認。

Amplifyから自動生成されたURL「https://dev.d1n5omzs71j1db.amplifyapp.com」へアクセス。ログインをしていないので「/login」ページへ自動的に遷移が行われる。

Cognitoユーザプールに事前に設定していたユーザを元にログイン。各APIが機能していることを確認。

サインアウト後、一般公開用のページ「/routing」へ移動し再度APIへアクセス。一般公開されているAPIのみアクセスができることを確認。