AWS超個人的メモ

# AWS超個人的メモ

---
## Amazon Cloud Watch
### 　監視メトリクス

- ### APIGatewayメトリクス
 - 4XXError：指定された期間に取得されたクライアント側エラーの数。
 - 5XXError：指定された期間に取得されたサーバー側エラーの数。
 - CacheHitCount：指定された期間内に API キャッシュから配信されたリクエストの数。
 - CacheMissCoun：API キャッシュが有効になっている特定の期間における、バックエンドから提供されたリクエストの数。
 - Count：指定された期間内の API リクエストの合計数。
 - IntegrationLatency：API Gateway がバックエンドにリクエストを中継してから、レスポンスを受け取るまでの時間。
 - Latency：API Gateway がクライアントからリクエストを受け取ってから、クライアントにレスポンスを返すまでの時間。  
 
---
## Amazon DynamoDB
- ### 属性サブネットの取得

- ### アトミックカウンター
DynamoDBではUpdateItem用のアトミックカウンターの実装が可能
他のDBサービスではアトミックカウンターの実装は出来ないので注意


~~~
CLIオプション
--projection-expression
~~~

- ###  データの有効期限
TTL（有効期限）を設定することでDynamoDBのテーブルデータを自動的に失効させて、保存されたデータを自動的に削除させることができる。

- ### プライマリキーの最大設定数
DynamoDBのテーブルデータに設定できるプライマリキーは最大で2つ。

- ### API
 - BatchGetItem API
 - BatchWriteItem API

- ### 読み込みキャパシティーユニット（RCU）の計算方法
 1 つの読み込みキャパシティーユニット（RCU）は、最大サイズ 4 KB の項目に対して、1 秒あたり 1 回の強力な整合性のある読み込み、あるいは 1 秒あたり 2 回の結果整合性のある読み込みを実施できます。 例えば、10 ユニットのプロビジョニングされた読み取りキャパシティーでテーブルを作成したとします。これにより、最大 4 KB の項目に対して、1 秒あたり 10 回の強い整合性のある読み込み、または 20 回の結果的に整合性のある読み込みを行えます。
 4 KB を超える項目に対しては、より多くのRCUを消費します。たとえば、8 KB (4 KB × 2) の項目の強い整合性のある読み込みを実施する場合は、2 ユニットのRCUを消費します。同じ項目の結果的に整合性のある読み込みは、RCUを 1 ユニットしか消費しません。
 したがって、10 ユニットのプロビジョニングされたRCUによって 20 回の結果整合性のある読み込み処理を行えるため、10RCUが正しい設定となります。

- ### 書き込みキャパシティーユニット（WCU）の計算方法
 1 つの書き込みキャパシティーユニット（WCU）は、最大サイズが 1 KB の項目に対して、1 秒あたり 1 回の書き込みを表します。
 例えば、10 ユニットのプロビジョニングされたWCUでテーブルを作成します。これにより、1 秒あたり最大でサイズが 1 KB の項目に対して、1 秒あたり 10 回の書き込みが実施できます。
 書き込みの項目サイズは、次の 1 KB の倍数に切り上げられます。たとえば、500 バイトの項目の書き込みは、1 KB の項目の書き込みと同じスループットを消費します。
 したがって、30 ユニットのプロビジョニングされたWCUのテーブルに対して、 1 秒あたり最大でサイズ1 KB の項目対して、1 秒あたり 30 回の書き込みを行えます。

- ### セカンダリインデックス
 - ローカルセカンダリインデックス
 - グローバルセカンダリインデックス
---
## Amazon ECS
- ### タスク配置戦略
 - Binpack  
CPU またはメモリの最小利用可能量に基づいてタスクを配置します。これにより、使用するインスタンス数を最小限に抑えます

 - Random  
タスクをランダムに配置します。

 - Spread  
指定された値に基づいてタスクを均等に配置します。有効な値は instanceId (または同じ効果を持つ host)、または attribute:ecs.availability-zone などのコンテナインスタンスに適用される任意のプラットフォームまたはカスタム属性です。サービスタスクはそのサービスからのタスクに基づいて分散されます。スタンドアロンタスクは、同じタスクグループからのタスクに基づいて分散されます。
---
## Amazon ElastiCache
- ### ElastiCache Memcached

- ### ElastiCache Redis

- ### アプローチ
 - 遅延読み込み戦略  
必要なときにのみキャッシュにデータを読み込むキャッシュ戦略です。

 - 書き込みスルー戦略  
データがデータベースに書き込まれると常にデータを追加するか、キャッシュのデータを更新します。

 - TTL の追加  
有効期限 (TTL) 値を設定することで一定期間でデータ項目を失効させることができます。遅延読み取りはデータが古くなる可能性がありますが、空ノードによる障害は発生しません。書き込みスルーでは常に新しいデータとなりますが、空ノードの障害が発生して、過剰なデータがキャッシュに入力されることがあります。各書き込みに有効期限 (TTL) 値を追加することで、各戦略の利点を得ることができます。同時に、余分なデータでキャッシュが乱雑になることを回避できます。   

 したがって、書き込みスルー戦略では、データがデータベースに書き込まれると常にデータを追加するか、キャッシュのデータを更新することで、古いキャッシュを利用しないように実装ができます。また、各書き込みに有効期限 (TTL) 値を設定することで、古いキャッシュを利用しないようにできます。


---
## Amazon Kinesis Data Stream
- ### デフォルトのデータ保持期間
Kinesisデータストリームのデフォルトのデータ保持期間は24hで設定されている。  
保持期間の最大値は168時間まで設定可能

- ### シャード

---
## Amazon RDS
- ### MYSQLのモニタリングログ
 - 一般ログ：
mysqld の実行内容の一般的な記録です。サーバーは、クライアントが接続または接続解除したときに情報をこのログに書き込み、クライアントから受け取った各 SQL ステートメントをログに記録します。一般クエリーログは、クライアント側でエラーが疑われるとき、クライアントが mysqld に送信した内容を正確に知りたい場合に役立ちます。

 - エラーログ
エラーログには mysqld が開始および停止された時期を示す情報と、サーバーが実行中に発生したあらゆるクリティカルエラーが格納されます。自動的にチェックまたは修復することが必要なテーブルが mysqld で検出された場合、エラーログに警告メッセージが書き込まれます。

 - スロークエリログ
スロークエリーログは、実行に要した時間が long_query_time 秒を超え、少なくとも min_examined_row_limit 行を検査する必要があった SQL ステートメントで構成されます。long_query_time の最小値およびデフォルト値は、それぞれ 0 および 10 です。値はマイクロ秒の精度まで指定できます。ファイルへのロギングの場合、時間はマイクロ秒の部分も含めて書き込まれます。テーブルへのロギングの場合、時間の整数部のみ書き込まれ、マイクロ秒の部分は無視されます。
---
## AWS API Gateway
- ### API Gateway統合タイプ
 - AWS  
AWS統合は、API は AWS のサービスアクションを公開します。AWS 統合では、統合リクエストと統合レスポンスの両方を設定し、メソッドリクエストから統合リクエストへの、また統合レスポンスからメソッドレスポンスへの、データマッピングを設定する必要があります。

 - AWS_PROXY  
AWS_PROXY統合には様々な用途に柔軟に利用できる合理化された統合設定があり、API メソッドを Lambda 関数呼び出しアクションと統合できます。この統合は、統合Lambda 関数との間の直接的なやり取りに依存します。Lambda プロキシ統合とも呼ばれ、ユーザーが統合リクエストまたは統合レスポンスを設定することはありません。API Gateway は、クライアントから受け取ったリクエストをバックエンドの Lambda 関数への入力として渡します。統合 Lambda 関数は、この形式の入力を受け取り、使用可能なすべてのソースからの入力 (リクエストヘッダー、URL パス変数、クエリ文字列パラメータ、該当する本文など) を解析します。その後、こちらの出力形式に従って結果を返します。

 - HTTP  
HTTP統合は、API がバックエンドの HTTP エンドポイントを公開することを可能にします。HTTP 統合 (HTTP カスタム統合とも呼ばれます) では、統合リクエストと統合レスポンスの両方を設定する必要があります。メソッドリクエストから統合リクエストへの、また統合レスポンスからメソッドレスポンスへの、データマッピングを設定する必要があります。   

 - HTTP_PROXY  
HTTP_PROXY統合では、クライアントは 1 つの API メソッドで合理化された統合設定を使用して、バックエンドの HTTP エンドポイントにアクセスできます。ユーザーが統合リクエストまたは統合レスポンスを設定することはありません。API Gateway は、クライアントから受け取ったリクエストを HTTP エンドポイントに渡し、HTTP エンドポイントから送り出されたレスポンスをクライアントに渡します。このようにHTTPエンドポイントを介して対話が行われるため、クライアントとバックエンドがAPI Gatewayの介入なしで直接対話することができます。

 - MOCK  
MOCK統合では、API Gateway はリクエストをさらにバックエンドに送信することなく、レスポンスを返します。このタイプの統合は、バックエンドの使用料金が発生することなく、統合設定のテストに使用したり、API の共同開発に使用したりできるためAPI のテストに活用できます。共同開発では、チームは MOCK 統合を使用して、他のチームが所有する API コンポーネントのシミュレーションを設定することで、自分たちの開発成果を区分することもできます。また、CORS 関連のヘッダーを返して、API メソッドが CORS へのアクセスを許可するようにもできます。

---
## AWS CloudFormation
- ### SAMの利用
CloudFormationテンプレートを利用してLambda関数を利用したサーバーレスアプリケーションのインフラを構成するためには、CloudFormationテンプレートのAWS::Serverless Transformセクションにおいて、AWS SAMのバージョンを指定することが必要です。
---
## AWS CloudTrail

---
## AWS Code Commit
---
### AWS Code Deploy

CodeDeploy は、Amazon EC2 インスタンスやオンプレミスインスタンス、サーバーレス Lambda 関数、または Amazon ECS サービスに対するアプリケーションのデプロイを自動化するデプロイメントサービスです。 CodeDeploy はサーバーで実行され、Amazon S3 バケット、GitHub リポジトリ、または Bitbucket リポジトリに保存されているアプリケーションをデプロイできます。

---
## AWS Elastic Beanstalk
- ### エンドポイントの公開
Elastic Beanstalk環境でHTTPSプロトコルエンドポイントを公開するには
ebextensionファイルを作成してロードバランサーを実行することが求められる。

- ### バージョン更新の自動化？
 - All at once  
新しいバージョンをすべてのインスタンスに同時に展開します。 環境内のすべてのインスタンスは、展開が行われている間、短時間サービスが停止します。 これは、展開に必要な合計時間を最短にする方法です。したがって、オプション３が正解となります。

 - Rolling(ローリング)  
これにより、Elastic Beanstalk は環境の EC2 インスタンスを複数のバッチに分割し、アプリケーションの新しいバージョンを一度に 1 つのバッチにデプロイします。これにより、環境内の残りのインスタンスは古いアプリケーションバージョンを実行した状態になります。つまりローリングデプロイ中は、アプリケーションの古いバージョンでリクエストを処理するインスタンスもあり、新しいバージョンでリクエストを処理するインスタンスも存在します。

 - Rolling with additional batch  
新しいバージョンをバッチで展開しますが、最初にインスタンスの新しいバッチを起動して、展開プロセス中に完全な容量を確保します。

 - Immutable  
変更不可能な更新を実行して、古いバージョンを起動しているインスタンスと並行しながら、別の Auto Scaling グループにあるアプリケーションの新しいバージョンを起動している新しいインスタンスのフルセットを起動します。[Immutable] デプロイは、部分的に完了したローリングデプロイにより発生する問題を防止できます。新しいインスタンスがヘルスチェックをパスしなかった場合、Elastic Beanstalkはそれを終了し、元のインスタンスをそのまま残します。
---
## AWS KMS
- ### KMS APIコール
---
## AWS SAM

---
## AWS Secrets Manager

---
## ELBとALBとCLBとNLB
- ELB(Elastic LoadBalancer)
 - ALB(Application LoadBalancer)
 - ELB(Elastic LoadBalancer)
 - CLB(Classic LoadBalancer)
 - NLB(Network LoadBalancer)


 ELBとは複数サーバでの冗長化構成を構築し、それらに対して負荷分散を行うマネージドサービス


---
## CodePipeline




## Fargate
## Root53
## NLB





## IAM
- ### 認証バージョン

- ### クロスアカウントアクセス
IAM ユーザーには、AWSアカウント内のロール、または所有する他の AWS アカウントで定義されたロールに切り替えるアクセス許可を付与することができます。このようなアクセス許可をクロスアカウントアクセスと呼びます。

## S3
### サーバーアクセスログ

## KCL(Kinesi Client LIbrary)

## AWS Lambda
- ### 環境変数のセキュリティ確保
AWS KMSを使って伝送中の暗号化のためのヘルパーを有効にする事が可能。

- ### ファイルの一次保存
Lambda関数を使用する場合で一時ファイルを保存する際には　　
ロー化rディレクトリ/tmpを利用する。Lambda上では最大512mbまでデータの一時保存が可能。  

- ### 制限
AWS Lamdaはデフォルトでコンピューティングやストレージ量が制限されていて、  
同時実行数に関しては1000までに制限されている。(すべてのLambda関数で共通)  
同時実行数のカウント方法としては(1秒あたりのコール数*平均実行時間)  
デフォルトの制限を超える場合はAWSへの上限緩和申請が必要となる。


## X-Ray SDK
本番環境や分散アプリケーションを分析・デバッグできるサービス。  
アプリケーションやサービスの実行状況を監視してパフォーマンス問題やエラーの根本原因を特定してトラブルシューティングを行うことができる。
- ### AWS X-Ray の環境変数
 デーモンがECSを検出するようにするにはAWS_XRAY_DAEMON_ADDRESS環境変数
 を設定する事が必要。

- ### サンプリング要求値の計算方法
 ＜1秒あたりのサンプリングされた要求の合計を計算するには、次の式を使用できます。＞

 サンプリングリクエスト数　＝　リザーバーサイズ＋（（1秒あたりの着信リクエスト-リザーバーサイズ）*固定レート）   




 300の着信リクエストから毎秒合計260のリクエストをサンプリングする場合、リザーバサイズを250に、固定レートを20％に設定してから、上記の式を使用して計算します。




 = 250 +（（300-250）* 20％）
 = 260リクエスト

 したがって、上記式に合致するのはオプション４となります。




 AWS X-Ray SDKでは、X-Ray API を使用してサンプリングルールの取得、サンプリング結果の報告、およびクォータ取得を行います。サンプリングルールにおけるリザーバサイズは、固定レートを適用する前に記録する 1 秒あたりのトレースの目標数となります。リザーバはすべてのサービスに累積的に適用されるため、直接使用することはできません。ただし、0 以外の場合は、X-Ray がクォータを割り当てるまでリザーバから 1 秒に 1 個トレースを借りることが可能です。クォータを受信する前に、1 秒ごとに最初のリクエストを記録し、追加のリクエストに固定レートを適用します。固定レートは、0～1.00 (100%) の 10 進数です。

## 一般的なITの範囲
- ### CIDRブロック(サイダーブロック)
 クラスレスなIPアドレス空間のアドレス割り当ての仕組み。

 詳細はここ
 https://www.nic.ad.jp/ja/basics/terms/cidr.html