[自分用]AWS DVA試験用備忘録

## デプロイ
* GraphQL：速度・柔軟性のあるクエリ言語・ランタイム（実行システム）。AWSではAppSyncが提供している。
* IAMでAPIに対するメソッド承認は、「署名バージョン4」を使ってAPIリクエストに署名する
* cognitoユーザープール：ユーザー情報のディレクトリ
* 暗号化したAouroraは、暗号化の無効化はできない
* KMSマスターキーやAouroraは他リージョンでは使用不可
* Lambdaレイヤーに、依存関係のあるライブラリや外部モジュールを置くことで、複数の関数で共有できる。
* デプロイパターン

|デプロイパターン|特徴|
|:-----------|:------------|
|In-Place|稼働中の環境に新しいアプリケーションのみを更新する。問題があったときにデプロイを再度するまで解決できない|
|Linear|毎分10%ずつ,など新環境の割合を増やしていく|
|Canary|最初は試験的に10%、数分後に全てリリース。障害を最低限に抑えることが目的 |
|Blue/Green|別で新バージョンの環境を構築し、リクエスト送信先を切り替える|
|Rolling|複数の稼働中のサーバーの一部を切り離してデプロイして、再びオンラインに戻す。ダウンタイムが無いが、キャパシティが足りなくなる可能性・新旧バージョンが混在するデメリットがある。キャパシティ問題をカバーしたのが”Rolling with additional batch”|
| immutable| 新バージョンに問題がなければ、古いバージョンを削除して完全に切り替える。ダウンタイムが無いが、新旧バージョンが混在するデメリットがある|
|AllatOnce| 全てのサーバーを一度に切り替える。ダウンタイムが発生するが、一番早いデプロイ方法|

https://dev.classmethod.jp/articles/elastic-beanstalk-deploy-policy/
* codestarはcodecommit, codebuild, codedeplpy,codepipelineのパイプラインを素早く構築できる
* CodeCommitはSSHとHTTPS（AWS CLI)のプロトコルを使用できる
* CodePipelineは、リソースベースのポリシーをサポートしていないので、IAMポリシーで管理する
* codebuildローカルエージェントで、開発環境でのテストができる
* cloudformationテンプレートのセクション

|セクション名|説明|
|:-----------|:------------|
|Resources|AWSのリソースを指定する。必須項目。|
|Parameters|実行時にテンプレートに渡す値|
|Outputs|スタック構築後に情報を出力できる。（割り当てられたURLなど）Export/Importで、ネットワークスタックのサブネットIDをExportして、アプリケーションスタックでImportしIDを参照できる|
|Mappings|複数リージョンのAMIのIDを予め記載して、実行時にその範囲であればAMIから起動できる|
|Conditions|条件を定義して、リソース制御ができる（開発、本番で分けられる）|

* Elastic Beanstalkで、Cloudformationスタック、起動設定、オートスケーリング（cloudwacthアラームも）、セキュリティグループ、ALBが作成される
* Elastic Beanstalkで拡張ヘルスステータスを使うには、許可するIAMロールをアタッチする必要がある
* Elastic BeanstalkにはS3に保存されるバージョンライフサイクル機能がある。削除する際はS3側も削除設定する。
* Elastic Beanstalkでは、Webアプリケーションの他にワーカー環境も作成できる。長期間/長時間実行するタスクに使える。cron設定もできる。Auto Scaling グループ、1 つ以上の Amazon EC2 インスタンス、および IAM ロール、SQSが作成される。
* SAMはサーバーレスアプリケーションを構築できるフレームワーク。cloudformationの拡張機能。専用CLIがある。
* CLI,SDKを使うクライアントのリージョンはリクエスト実行に影響しない
* CodeDeployの「Hooks]はイベント管理する機能
* サーバーレスアプリケーションの作成にSAMを使用する場合、Lambda デプロイのためのCodeDeployが組み込まれていて、ロールバックも可能
* CloudFormation変更セットは、実装前に変更分をテストする機能


## セキュリティ
* VPCエンドポイントはS3,DynamoDB。インターフェイスエンドポイントは多数のAWSリソース。
* AWD CLIのprofileを使って、複数IAMユーザー認証が設定できる
* CodecommitからSSHでクローンするには、キー作成と.ssh/congfigにHost登録をする
* インラインポリシーは、「ポリシー」単体では存在できず、プリンシパルエンティティと1対1の関係にある。
* カスタマー管理ポリシーは、「ポリシー」単体として存在できて、複数のプリンシパルエンティティにつけたり外したりできる。ロールバック可能。
* 共有キューを使用するときはSQSリソースベースのキューポリシーを使用する
* IAMロール設定には'GetRole'と'PassRole'権限が必要
* マネジメントコンソールからEC2用のIAMロールを作成すると、インスタンスプロファイル（インスタンスとIAMロールを結びつけるための箱）とAssumeRole（IAM ロールに設定された権限を引き受けることができる）が設定される
* SystemManagerパラメータストアのSecureString形式で機密情報が保存できる
* Certificate Manager（ACM)で証明書を発行して、CNAME認証を使うと1年毎の自動更新が可能
* SAML認証はIdP（Identity Provider）とSP（Service Provider）の2つの間で認証情報をやり取りする認証方式
* KMSで暗号化されたデータキーはCMK（カスタマーマスターキー）によって暗号化される。
* KinesisはFIFO形式。シャードごとにシーケンスを維持した状態で提供。シャード全体の順序は維持なし。
* Kinesis datestreamはサーバー側暗号化できて、KMSを使用して、データ保管前に暗号化できる


* S3の暗号化の方法
暗号化することで、データ送受信をする転送時や、S3に格納された状態の保管時に、より安全に保護できる
それぞれ方法が大きく２種類に分類される。

▶︎ クライアントサイド暗号化:暗号化してからアップロードする方法

|暗号化の種類|説明|
|:-----------|:------------|
|CSE-KMS|S3格納前に、ユーザの手元でKMSの暗号化鍵を使ってオブジェクトを暗号化|
|CSE-C|S3格納前に、ユーザの手元でユーザ自身が用意した暗号化鍵を使ってオブジェクトを暗号化|

▶︎ サーバーサイド暗号化:S3に保管されるデータの暗号化。データ書き込み時に暗号化、アクセス時に複合化

|暗号化の種類|説明|
|:-----------|:------------|
|SSE-S3|S3がキーの生成・管理・保存を行う。利用は無料ですがS3バケットへのリクエスト料金がかかる。透過的に複合できることから、保存しているS3にアクセスできる人はオブジェクトも復号化できるため注意が必要。**キーの個別管理、追跡監査要件がなければ選択する。** |
|SSE-KMS|KMS がキーの生成・管理・保管を行う。任意のキーが作れる。 **1年毎の自動ローテーションもキーの種類によっては可能。** 暗号化・復号化のたびにKMSAPIが呼び出されるので、**AWS CloudTrailによる追跡が可能。** **キーポリシーにより、暗号化・復号化できるユーザを制御。** 有料（標準のS3バケットへのリクエスト料金＋AWS KMSへの暗号化・復号化のリクエスト料金）。SSE-S3と同じく透過的に複合できるので注意が必要。|
|SSE-C|ユーザ自身がキーの生成・管理・保管を行う。S3バケットへのリクエスト料金がかかる。CLIなどを利用する必要がある。**アクセスキーの流出や不正アクセスに強い。** オンプレで作成されたキーを使用することもできる。|

* RDSインスタンスはKMSと連携して暗号化可能。スナップショットも暗号化される。
* 複数のサーバーで共通のサーバーへ接続する際、共有の接続情報の保存は**Systems Managerパラメーターストア** を使う。パラメーターストアは文字列を扱う。パスワードなどの機密情報は、**KMSと連携してSecureStringタイプで暗号化** して保存できる。
* ALBでCloudFront経由以外のアクセス制限を行うときは、WAFのWebACLでブロックする
* AES256は安全な暗号化でSSE-S3を指している
* EC2にIAMロールをアタッチするにはインスタンスプロフィル（中にはIAMポリシーをアタッチしたIAMロール）が必要
* Lambdaオーソライザーはlambdaによる認証
![スクリーンショット 2022-09-16 23.11.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2841868/e3f2d75d-f834-4741-ba56-478a9d4a5e62.png)
参考：https://blog.cloud-partner.jp/api-gateway-lambda-authorizer/
* 一時的なアクセスはIDフェデレーション。他Webサービスを使い、IAMでトークンを発行して、アシュームロールでAWSリソースへアクセス。S3などに使われることが多い。

## 開発
* S3プレフィックス＝フォルダ
* S3selectは、保存したオブジェクトに対し、SQL文を用いてデータの一部分を取り出すことができるサービス
* S3のオブジェクトロック
   -　コンプライアンスモード　：　全てのユーザーが、オブジェクトのバージョンの上書きや削除、ロック設定を変更ができない
   -　ガバナンスモード　：アクセス許可を持たない限り、オブジェクトのバージョンの上書きや削除、ロック設定を変更ができない
 ※自動的にバージョニングも有効になり、停止不可
* S3の既存オブジェクトのメタデータは追加できないので、Copyで実行する
* S3 オプション
   - アクセスコントロールリスト(ACL):バケット所有者やオブジェクト所有者の権限を付与できる
   - CORS　：　オリジン間リソース共有
   - MD５チェックサム　：　S3オブジェクトのアップロード前後で整合性を確認（途中で壊れてないかなどを確認）
* Dynamoのパーティンションキー、ソートキーのデータ型は、文字列・数値・バイナリ。
* Dynamo 1WCUは最大１KBの項目を1秒間に1回書き込む。１RCUは最大４KBの項目を強い整合性で１秒間に1回読みこむ。結果整合性では2回読み込める。
* Dynamoでパーティンションキーを使用して、ソートキー以外で範囲選択する場合は、マルチインデックスを使用する。
* Dynamoでパーティンションキーで指定しているUserIDに一致するUserIDのアクセス制限を作るには、IAMポリシーでConditionを追加してleadingkeysを含める
* Dynamoで一部のパーティションに読み書きが集中することを「ホットパーティション」という。その場合、「ランダムなサフィックス」を追加し、ワークロードを分散させる（パーティション:１→1~100)
* API Gatewayで使用量プランを使うと、紐づけたAPIごとに制限回数を設定できる。顧客ごとにAPIキーを配布することで、顧客ごとの制限値管理も可能。
* API GatewayはREST(ステートレス、キャッシュ機能、リソースポリシー、カナリアリリース、WAF連携、X-ray連携)とWebSocket（サーバークライアントとサーバーの双方向通信、ステートフル）
* APIGatewayの認証は、IAM署名４、Lamdaオーソライザー、Cognitoオーソライザーの３つ
* `Cache-Control "max-age=秒数"`でレスポンスが生成されてから指定秒数の間は新鮮、という意味
* lambdaでは、1回実行しても何度実行しても結果が同じになる”冪等性（べきとうせい）”を実装する
* デプロイパッケージを50MB超えるlambda関数のデプロイはS3からアップロードする
* S3のイベント通知。lambda、SQS、SNSと連携できる。
* lambdaの関数ログについて。テストして出力確認はCloudWatch logs、運用後はCloudWatch + x-rayでモニタリングする。
    - オブジェクトの作成/削除/復元イベント
    - 低冗長化ストレージ (RRS) オブジェクト消失イベント
    - レプリケーションイベント
* CloudwatchLogを入れたSDKでLambdaを作成・実行することでログ出力することも可能
* Lambdaはエイリアス(porod,devなど）で、本番用、開発用など分けることが可能。またバージョニングを組み合わせることで、ロールバックとリリースが容易にできる。
* Lambdaの同時実行数は1000。実行数の予約（プロビジョニング）することもできる。lambdaはトリガーイベントが発生してから実行環境が作成され、そのことをコールドスタートという。コンパイルの有無などによってスタート時間が異なるが、予約しておくことでコールドスタートの時間を短縮できる。
* ElasticCache キャッシュ戦略
    - 遅延読み込み：キャッシュを確認して、無ければDBに取りに行って、キャッシュに書き込む。キャッシュで読み込んだデータが古い可能性がある。
    - ライトスルー：DBに書き込みが発生したら毎回キャッシュにも書き込まれる。常に新しいデータ。全てのデータをキャッシュに書き込めず、一杯一杯になってしまう。
*ECSの組み合わせ

|種類|説明|
|:-----------|:------------|
|Codepipeline * ECS|CodePipeline のデプロイに対して、ECS を選択できる|
|Fargate * ECS| サーバーレスでコンテナ環境を実行。オートスケーリング可能。パブリックIPアドレスが固定できない。|
|Route53 * ECS| サポートディスカバリによって、好きなDNS名をつけてコンテナ間の通信をしやすくする|
|NLB * ECS| 高いネットワークトラフィック処理が可能|
|ALB * ECS| ECSクラスターやタスクに対するトラフィック制御を実行。ALBのターゲットにポート番号を指定することも可能|
* ECSコンテナのインスタンス内にECSコンテナエージェントが入っていて、動作を調整している。
* Cognitoストリームは保存しているデータのコントロールと洞察ができる。Kinesisにリアルタイムでデータを送る。さらにKinesisから分析をするためRedshiftを使うことも可能
* CognitoイベントはCognito Sync（デバイスが変わっても同期的なデータ状態になる仕組み）でのイベント対応としてlambdaを呼び出せる
* lambdaには一時的にファイルを置ける/tmpディレクトリがある
* 大規模のSQSメッセージを管理するには、S3と、Java 用 Amazon SQS拡張クライアントライブラリを使用。２GBまで。
* Amazon S3 Transfer Acceleration は、クライアントと S3 バケットの間で長距離にわたるファイル転送を高速、簡単、安全に行えるようにするバケットレベルの機能
* APIGatewayでは、異なるプロトコルでもマッピングテンプレートを使用してJSONに変換してメソッドリクエスト⇄統合リクエストのやりとりができる。
* lambda呼び出し方法
    - 同期呼び出し：1回でlambdaを実行する
    - 非同期呼び出し：タイムアウトを避けるため、イベントに対してlambda①でレスポンスを返して、並行してlambda②で処理を行う（実行時間は15分以内）
* DynamoのScanAPIは通常全体スキャンをかけるが、大規模データの場合は1MBずつ読み込んでいく処理になるので時間がかかる。なのでデータを分割して、並列に読み込んでいく「並列スキャン」を活用するとスピードUPする
* Amazon Simple Workflow Service (SWF) は、タスクを1回だけ割り当てるので、重複することがない


・オブジェクト永続性モデル？
・lambda関数実行ポリシーとリソースポリシー



# トラブルシューティング
* エクスポネンシャルバックオフは、再試行（リトライ）処理のアルゴリズム。SDKに実装されている。通常のリトライ処理と異なり、処理の間隔を指数関数的に徐々に長くしてリクエストの成功率を上げる。
* OpsWorksの実行ログは、インスタンス内のログで確認する
* Codebuildの実行後はビルド履歴から確認できる。詳細なログはCloudWatchLogsに出力される
* CLIで人間が読めないエラーメッセージが出力された際は、STSポリシーにデコード許可を追加し、sts decode-authorization-messageコマンドを叩く
* AWS CLIでコマンドに’dry run’オプションをつけると、許可権限が正しいか判別してくれる

# モニタリング
* CloudWatchはデフォルトで標準解像度で1 分ごと。高度解像度だと1 分未満でメトリクスが取れる。