AWSチートシート

# はじめに

メモです。これから細かいテクニックを追記していきます。

## EC2インスタンスにSSH接続する前準備

- VPCのセキュリティグループのインバウント設定で22番ポートを許可する
- EC2 Instance Connectを使用する場合
    - https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-connect-prerequisites.html#ec2-instance-connect-setup-security-group
    - この設定に従う
    - ソースにするIPはここから探す(EC2_INSTANCE_CONNECTで検索、リージョンを合うものを探す)
    - https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/aws-ip-ranges.html#aws-ip-download
    - 
- ローカル環境から接続する場合はソースをマイIPに設定

## Route53

ドメインの紐づけが成功しているか確認するコマンド


```sh
nslookup -type=ns example.com
```

## ECSのデプロイでコケたとき、原因を確認する方法

ECSのサービスから「デプロイとイベント」のタブより、エラー原因が見れる。

CLIで確認する方法

```sh
CLUSTER=<CLUSTER_NAME>
TASK=<TASK_ID>
aws ecs describe-tasks --cluster $CLUSTER --tasks $TASK | jq '.tasks[].stoppedReason'
```

## ALBのアクセスログを有効にする

ログ取得用のS3バケットを作成して、ALBのページから「アクション」>「ロードバランサー属性の編集」>「Monitoring」よりアクセスログを有効化

以降のやり方はここに書いてある。

https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/enable-access-logging.html#attach-bucket-policy

https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/load-balancer-access-logs.html


VPC フローログを用いてもOK。ただしALBのアクセスログの方が接続先のパスや User Agent なども確認できる。

## サブネットをパブリックに変更

「サブネット」>「ルートテーブル」>「ルートテーブルの関連付けを編集」> インターネットゲートウェイを割り当て

## Cloud Watch Logs

簡単な検索方法

以下の手順で選択するとすべてのログストリームから検索できる。

ログ > ロググループで対象のログを選択 > すべてのログストリームを検索

### Tips

ログレベル設計して取り組むと良い。

https://dev.classmethod.jp/articles/lambda-log-level/

Lambdaのログはココ参考に設定すると良い。

https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/lambda-logging-metrics.html

## API Gateway

### REST API と HTTP API の違い

HTTPはヘッダーをすべて共有できるメリットがあるが、セキュリティが弱いので基本的には使わない。

https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/http-api-vs-rest.html

#### 重要ポイント

引き上げられないタイムアウトが存在するため注意が必要。
30秒以内に処理が終了しない場合は、別途対策が必要。

Lambda、Lambda プロキシ、HTTP、HTTP プロキシ、AWS 統合など、すべての統合タイプで 50 ミリ秒〜29 秒。

	

## AWS SAM

buildするときは必ずオプションをつけて高速化させること。

```zsh
sam build --parallel --cached
sam deploy --no-confirm-changeset
```

## Lambda

### 基本的な仕様

API Gatewayには10MB
Lambdaには6MBのペイロード上限がある。
API Gateway + Lambdaの構成をした場合は、6MBのペイロード上限がかけられる。

REST API プロキシ統合では、Header情報がすべて共有されるわけではない。Header情報はHTTP APIにすればすべて共有されるがWAFが使えなくなるので注意。

### Lambdaに関わるログの種類

- Amazon CloudWatch Logs
  - 関数の実行結果、エラーメッセージ、デバッグ情報などが出る(フォーマットに関するドキュメントが存在しない？)
- AWS Lambda関数のログ
  - Lambda関数のコード実行時に標準出力等に出力されるログ
- AWS X-Ray
  - 分散トレーシング使うとき用
- Amazon CloudTrail
  - 操作履歴(意図しない操作が行われたときに調査するためのログ)

ログとは別に、メトリクスもある。メトリクスは統計情報みたいなのを表示するところ。

API Gatewayを使っている場合は、API Gatewayのログから、Lambdaへのリクエストのログを確認できる。

API Gatewayの実行ログには以下の情報等が含まれており、トラブルシューティングに活用できる。

- API が受け取るリクエスト。
- API からの統合バックエンドレスポンス。
- Lambda オーソライザーが提供するレスポンス。
- AWS 統合エンドポイントのための requestId。
- 指定された API キーが承認されたかどうかに関する情報。

### Lambdaのログを確認する(Lambdaの画面から)

Recent invodations から、最近の実行履歴を確認できる。
Most expensive invocations in GB-seconds (memory assigned * billed duration) から、お金がかかっている実行の履歴が確認できる。(コスト計算に使える)

### Lambdaのログを確認する(CloudWatchの画面から)

主に4つの種類がある。

| カテゴリ | 説明 |
|---|---|
| Invocation metrics | 関数の呼び出しに関するバイナリ指標。 |
| Performance metrics | 関数のパフォーマンスに関する指標。 |
| Concurrency metrics | 関数の同時実行数に関する指標。 |
| Asynchronous invocation metrics | イベントソースからの非同期呼び出しに関する指標。 |

Invocation Metrics

| 項目 | 説明 |
|-----|------|
| Invocations | 呼び出し回数 |
| Errors | エラー数 |
| DeadLetterErrors | デッドレターエラー数 |
| DestinationDeliveryFailures | 宛先配信エラー数 |
| Throttles | スロットル数 |
| ProvisionedConcurrencyInvocations | 予約済み同時実行数での呼び出し数 |
| ProvisionedConcurrencySpilloverInvocations | 予約済み同時実行数を超えた標準同時実行数での呼び出し数 |

Performance Metrics

| 項目 | 説明 |
|-----|------|
| Duration | 実行時間 |
| PostRuntimeExtensionsDuration | ランタイム拡張実行時間 |
| IteratorAge | イテレータの年齢 |
| OffsetLag | オフセット遅延 |

Concurrency Metrics

| 項目 | 説明 |
|-----|------|
| ConcurrentExecutions | 同時実行数 |
| ProvisionedConcurrentExecutions | 予約済み同時実行数 |
| ProvisionedConcurrencyUtilization | 予約済み同時実行数の利用率 |
| UnreservedConcurrentExecutions | 予約されていない同時実行数 |

Asynchronous Invocation Metrics

| 項目 | 説明 |
|-----|------|
| AsyncEventsReceived | 受信イベント数 |
| AsyncEventAge | イベント年齢 |
| AsyncEventsDropped | 破棄されたイベント数 |


### Lambdaのメトリクス

CloudWatch > すべてのメトリクス > Lambda > 「関数名」> 見たい項目を選ぶ > グラフ化したメトリクス

グラフ化したメトリクスの注意点。

- Invocation Metricsは合計値で見る。
- Performance Metricsは平均値で見る。

Invocations と Errors をセットで使うとわかりやすい。合計で見るとアクセスが集中している時間帯でどれくらいエラーが出ているのか、平均で見るとエラーの割合がわかる。

#### 一定期間内のLambdaの使用時間の合計を見る方法

CloudWatch > すべてのメトリクス > Lambda > 「関数名」> Durationを選択 > グラフ化したメトリクス > 対象期間から絶対期間を指定 >  統計のカラムで合計を指定、期間のカラムから対象期間より大きい期間を設定

これで合計値を見ることができるようになる。

## Lambdaのログ(料金編)

Lambdaの実行ログ内に課金の情報が含まれている。

```
REPORT RequestId: XXXXXXXXXXXXXXXXXXXXXXXXX	Duration: 500000000 ms	Billed Duration: 600000000 ms	Memory Size: 2048 MB	Max Memory Used: 2048 MB	Init Duration: 100000000 ms
```

- Duration: 実行時間
- Billing Duration: 課金時間
- Memory Size: メモリサイズ
- MB Max Memory Used: 最大メモリ使用量
- Init Duration: 初期化時間

東京リージョンだと 2048MBで1ミリ秒あたり0.0000000333USDなので

600000000 * 0.0000000333 = 19.98USD (2,723円)


## API Gatewayで取得したLambdaのRequestIDから詳細を確認する方法

まずは、ログストリームの特定をする。

### ログストリームの特定方法

CloudWatch > ログのインサイト > 「ロググープを選択」で対象のLambda関数を選択

クエリに以下を入力

```
fields @timestamp, @message, @logStream, @log
| sort @timestamp asc
| filter @message like "【Request ID】"
```

ここで表示される詳細な実行日時とログストリーム名をメモする。

### ログストリームの詳細を確認する方法

右上の検索範囲を、前述の検索でメモした時間帯のみに、さらに限定し、以下のクエリを実行する。

```
fields @timestamp, @message, @logStream, @log
| sort @timestamp asc
| filter @logStream = "【１回目の検索で表示された@logStream】"
```

これで、その時間帯のLambda関数の標準出力、標準エラー出力等が確認できる。

### AWS環境に上げたLambda関数のデバッグテクニック

レスポンスヘッダーのdate属性の時間とCloudWatch LogsのTimestampの時間が一致するので、レスポンスヘッダーを共有してもらえれば、問題特定がスムーズに行く。


## その他

### CI/CDどうするの？

Infrastructure as Codeを実現するにはTerraformを使うのが一般的で知見も溜まっている。

Terraformより後発のAWS CDKもあるが、記述が簡略な分、何をやっているのかわかりにくい。ドキュメントがしょぼくて使いにくいとの噂を聞いた。

以下のサイトが参考になりそう。

https://y-ohgi.com/introduction-terraform/

### 作図について

以下のページにAWSのアーキテクチャ図を作成するのに使える「描画ツールとダイアグラム作成ツール」がまとまっている。

https://aws.amazon.com/jp/architecture/icons/

### 利用規約

サービスをリリースする前に「AWS カスタマーアグリーメント」には目を通しておく。

https://d1.awsstatic.com/legal/aws-customer-agreement/AWS_Customer_Agreement_Japanese_2023-04-20.pdf

コンテンツの節度のページも参考になる。

https://docs.aws.amazon.com/ja_jp/rekognition/latest/dg/moderation.html

`Amazon Rekognition`の機能を使えば、センシティブな文章や、画像のチェックだけではなく、有名人が映像中に写っているかや、マスクをしているか、手袋をしているか、など防犯情報もチェックすることができる。

### AWS Organizations

ひとつのアカウントで複数のサービスを立ち上げることもあると思う。その場合、請求が全てまとまってしまうので、AWS Organizationsで名前空間を分けると良い。

https://aws.amazon.com/jp/organizations/