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

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

nslookup -type=ns example.com

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

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

CLIで確認する方法

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

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

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

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

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

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

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

Cloud Watch Logs

簡単な検索方法

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

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

Tips

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

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

API Gateway

REST API と HTTP API の違い

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

重要ポイント

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

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

AWS SAM

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

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もあるが、記述が簡略な分、何をやっているのかわかりにくい。ドキュメントがしょぼくて使いにくいとの噂を聞いた。

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

作図について

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

利用規約

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

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

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

AWS Organizations

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