CodeDeploy

EC2のデプロイ

事前にEC2へCodeDeployエージェントをインストールし、動かしておく必要がある。
appspec.ymlのhooksはrootユーザとして実行される。利用可能なhooksはデプロイ対象ごとに異なっている。デプロイ設定の環境変数が自動的に設定される。
https://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/reference-appspec-file-structure-hooks.html

デプロイメントグループ

デプロイ方法の種類

• インプレイス
  • ASG指定
  • インスタンス指定（タグで指定する）
• ブルーグリーン
  • ASG指定

EC2デプロイ設定

• All at Once
• One At Time
• Harf At Once
• カスタマイズ可能（正常稼働何％、何台）

EventBridgeとの提携

EventBridgeでCode Deployを監視できる。Kinesisへストリーム、Lambdaの実行、EC2の再起動などを自動化できる。

CodeDeployのログ

CodeDeployエージェントとCloudWatchLogsエージェントをインストールする必要がある。

通知

デプロイアプリケーションとデプロイグループ単位でそれぞれ設定できる。
CodeDeployのトリガー
SNSに直接パブリッシュにできる。EventBridgeとの違いは「直接パブリッシュできるか」「他のサービスを利用可能か」「設定が必要か」など。

ロールバック

デプロイメントグループで設定する。
https://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html

• CloudWatchAlarmの閾値を用いてロールバック
  事前にCWアラームを作っておくことが必要。
• デプロイが失敗した時にロールバック
  最新の良い状態に戻る。

オンプレミス

CodeDeployエージェントが必要。CodeDeployのコンソールでタグづけして管理できる。デプロイメントグループもタグで指定する。
登録コマンドregister-on-premiss-instanceはオンプレインスタンス自身から実行する必要がある。
オンプレインスタンスの登録方法

• IAMユーザ（インスタンスごと）
  /etc/codedeploy-agent/confファイルにIAM認証情報を記入する。
• IAMロール（セキュリティ的にIAMユーザよりもこちらが良い）

Lambda

デプロイ設定

• Canary（n分間x%でテストした後一気にデプロイ）
• Linear（n分間にx%づつ）
• AllAtOnce

hooksは2つ。それぞれにLambda関数を指定する。

• BeforeAllowTraffic
• AfterAllowTraffic

https://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/reference-appspec-file-example.html#appspec-file-example-lambda

CodeBuild

EventBridgeとの組み合わせ

• 何かのアクションか定期実行でCodeBuildを実行できる
• CodeBuildの実行後にアクションを実行

ビルドログ

• CloudWatchLogsにビルドログを保存できる

実行コマンド

• buildspec.ymlのphasesに処理内容を書く
  • buildspec.yml以外のファイル名でも良い。プロジェクトでファイル名を選択できる。

アーティファクト

• S3にファイルをアーティファクトとして保存できる
• ECRを使う場合や、テストのための使い捨ての場合にはアーティファクトの保存不要
• artifactの保存先S3はプロジェクトで指定する
• buildspec.ymlのartifactsでアーティファクトに含めるファイルを指定する
• buildspec.yml内でartifactを宣言しない場合、Code Pipelineでartifactを指定しても出力されない。

環境変数の指定

• プロジェクトレベルで環境変数を指定することができる
• シークレット情報はSSM Paramater storeかSecrets Manager利用することが可能。IAM権限が必要。

キャッシュ

• buildspec.ymlのcacheで、キャッシュするファイルを指定する

https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/build-spec-ref.html

CodePipeline

トリガー

さまざまなコードソースの変更をトリガーに実行可能。

• CodeCommitの場合
  • EventBridgeによるトリガー
    • ステータスの変更
    • 定期実行
  • 定期ポーリング

ステージとアクション

• 1つのパイプラインには複数のステージを含められる
• 1つのステージには複数のアクション（Build, Deploy, etc）を含むことができる
  • アクションは並列実行、直列実行が可能
  • CLIなどで指定する際は、各アクションにrunOrderを指定する。（ステージ内で順序評価）
    • runOrderの小さい順にアクションを実行する
    • runOrderが同じ数値の場合は並列実行
• 他リージョンのCodeDeployをアクションに設定できる
  →1つのパイプラインで複数リージョンにデプロイが可能

アーティファクト

• 各アクションの出力をアーティファクトとして保存できる
  • アクションの設定でアーティファクト名を指定する
• 他のアクションで出力されたアーティファクトにアクセスできる
  • アクセスする際には各アクションのIAMロールへ権限の付与が必要。
• CodeBuildのアクションの場合
  • CodeBuildで設定されているアーティファクトへの出力先には保存されない
• アーティファクトを別のS3バケットにも保存したい場合、アクションプロバイダーをS3としたアクションを追加する（他リージョンのバケットも指定可能）

手動承認

• アクションの1つに手動承認を追加できる
• 手動承認にはSNSを設定し、アクションが実行されるとトピックに通知を飛ばす
• 本番環境へのデプロイ前にステージ環境にデプロイ。ステージで手動確認→承認→本番デプロイといった運用が可能。

統合サービス

• さまざまなサービスとの統合が可能
  • Lambda
  • ECS
  • EB
  • その他たくさん
  • https://docs.aws.amazon.com/codepipeline/latest/userguide/best-practices.html
• Lambdaによるカスタムフック
  https://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/actions-invoke-lambda-function.html
  Lambdaをトリガーに入れて、デプロイしたページのテストなど、カスタマイズしたアクションを実行できる。
  Lambdaでcodepipelineに成功/失敗を返す関数を設定する。この際、codepipeline:PutJobSuccessResult codepipeline:PutJobFailureResult のIAM権限が必要。

CodeStar

さまざまなプロジェクトのテンプレート。
CodeBuild, CodeDeploy, CodePipeline, Lambda, EBなどを自動で用意してくれる。
各リソースはtemplate.ymlに定義されていてカスタマイズ可能。template.ymlはCloudFormationのような記述形式。

Jenkins on AWS

• Jenkns → OSS CICDツール
• マスターとスレイブのセッティングがある
  • マスターとスレーブは同じEC2で実行可能だが、負荷的に分けた方が良い
  • 各AZにマスターを置く構成にした方が可用性が高い
• マルチAZでEC2上で実行
• Jenkinsfileで設定を記述

ユースケース

• CodePipelineからJenkinsを起動→Jenkinsでビルド（CodeBuildの代わり）
• CodeCommitからJenkinsを起動。ECRからDockerイメージを取得、ビルド、プッシュ、デプロイを実行（Pipelineの代わり）
• Codecommit→Jenkins→セキュリティーチームのCfn→Cfnデプロイ （Pipelineの代わり）

CodePipelineとの統合

アクションにJenkinsを設定可能。
JenkinsのURLを設定する。

プラグイン

プラグインがあればAWSのリソースの操作が楽になる

• EC2のオートスケール
• CodeBuildへの送信、トリガー
• ECSのオートスケール
• CodePipeline
• などなど

CICD ホワイトペーパー

• ブルーグリーンデプロイメント
• Practicing Continuous Integration Continuous Delivery on AWS

CloudFormation

記述詞

• Condition
  状況によって作成するリソース、アウトプットなどを調整できる。

userdata

• Fn:Base64でエンコードする
• userdataのログは/var/log/cloud-init-output.logに保存される
  • エラーが起きた際のデバッグに役立つ

cfn-init

• リソースのメタデータに含める
• EC2の実行
  • EC2のメタデータに実行コマンド、ファイル、サービスなどを指定する
  • userdataでcfn-initコマンドを実行
    • リソース名、スタックIDを指定する
  • ログは/var/log/cfn-init.logに保存されている
  • スタックのリソースが作成完了になっていても、cfn-initのスクリプトは実行中の可能性がある
    →cfn-signalとwait conditionで完了を待つ必要がある

cfn-signalとWaitCondition

実行が完了したことをCloudFormationに伝える。CloudFormationはsignalを受信するまで待機することができる。

• cfn-signalコマンドをユーザデータで実行する
  • スタックID、WaitConditionのリソース名、終了コードを指定する
  • cfnはこれを受信した段階で完了と認識する→cfn-signalコマンドの後に実行されるスクリプトは考慮されない
• WaitConditionでは受診の回数（インスタンス数）とタイムアウトを設定
• シグナルの送信にはEC2がインターネットへの接続が必要
• シグナルがタイムアウトした場合、デフォルトではロールバックしてEC2インスタンスが終了してしまう。デバッグするにはデプロイ失敗時にスタックを残す設定をして、EC2インスタンスを残す。

CreationPolicy 属性

リソースのCreationPolicy属性を設定することで、シグナルを受信するまで、リソースの作成を待つことができる。ASGなどにも有効。
https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-attribute-creationpolicy.html

cfn-hup

cfn-hupデーモンを起動しておくことで、自動的にリソースメタデータの変更を検出し、操作を実行してくれる。
https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/cfn-hup.html

• cfn-hup.confファイル
  • ターゲットとなるスタック名とAWS認証情報を格納
  • メタデータを確認するインターバルを設定
• hooks.confファイル
  • 変更が検出されたら実行するアクションを規定
• hooks.dディレクトリ
  • ディレクトリ以下に任意の追加アクションファイルを設定
  • ファイル形式はhooks.confファイルと同じ

Nested Stack

よく使うスタックのテンプレートをS3にアップロードしておき、新しいスタックからそのスタックを参照できる。

• ネストしたスタックの値もアウトプットに含めることができる
• ネストしたスタックに渡すパラメータも呼び出し元のスタックで指定できる
• 共有するのはテンプレートなので、複数のスタックが作成されても、スタックは別物になる

Deletion Policy

• リソースを削除するときにどうするかの設定
• Retain, Snapshot, Deleteの３種類
  • S3バケットはDeleteにした場合でも、オブジェクトが残っている場合には削除できない

削除保護

• スタックの削除保護設定が可能

SSMパラメータストア、Secrets Managerの統合

• ParametersでパラメータストアおよびSecrets Managerの値を取得することができる
• 下記のように、AWSが提供しているパラメータを指定することも可能

  Parameters:
    LatestLinuxAmiId:
      Type: 'AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>'
      Default: '/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2'
  

  • リソース内でSSMパラメータストア、Secrets Managerの値を参照することも可能
    https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/dynamic-references.html

Lambda

• Cfnテンプレート内に直接記述
  • 記述子を使って直接記述可能。
  • 4000文字まで。
• zipファイルをアップロードする方法
  • Lambdaコードのzipファイルを、先にS3にアップロードしておく
  • cfnテンプレート内でCode記述子を使ってS3のファイルを指定
  • S3に新しいコードをアップロードした場合
    • Cfnはコードの変更を検出できない
    • テンプレート内のCode.ObjectVersionを指定する

カスタムリソース

• Lambdaを使用して任意のアクションを実行できる
  • Cfnが対応していないサービス
  • オンプレリソース
  • S3の削除前にバケットを空にする
  • AMIのIDを取得する
  • その他何でも
• create, update, deleteのタイミングで実行可能（どのトリガーで実行するかはLambda側で制御）

スタックのステータス

• UPDATE_COMPLETE_CLEANUP_IN_PROGRESS
  アップデートは完了し、既存リソースの削除などを行なっている状態
  e.g. 新しいEC2インスタンスを起動し、古いインスタンスを削除中
• UPDATE_ROLLBACK_COMPLETE_CLEANUP_IN_PROGRESS
  リソースのロールバックは完了し、継続処理を行っている状態。不要リソースの削除など。

Insufficient Capabilities Exception

IAMリソースを作成するときには承認をする必要がある。
承認していない場合、エラーになる

スタックポリシー

• スタック内の更新できるリソースを設定する
• スタックに対して適用
• jsonで記述
  • Effect、Action、Principal、Resource、Conditionで指定
  • 更新時に上書きすることで、一時的に変更することができる（そのアップデートのみに適用される）

StackSets

• マルチリージョン、マルチアカウントでCfnを展開可能
• マルチアカウントの場合はターゲットアカウントでAssumeRoleできるIAMロールを作成する必要がある
• 同時実行アカウント数、ロールバックのための失敗数を指定できる

Elastic Beanstalk

ソースコードのアーカイブ

ソースコードは自動作成されたS3に保存される。デプロイごとにzipファイルが作成される。

保存された設定

• eb コマンドでリソースの設定の保存が可能（eb config save dev-env --cfg initial-configuration）
• ebコマンドから設定に環境変数などを追加することができる（eb setenv ENABLE_COOL_NEW_FEATURE=true）
• 保存した設定ファイルから環境設定を変えることができる
• アップロードした設定ファイルを使ってEB環境を変更できる（eb config dev-env --cfg prod）

.ebextensions

• 保存された設定のファイルの代わりに、.ebextensionsディレクトリ配下のファイルでリソースの設定ができる
  • 優先順位 直接設定 > 保存された設定 > .ebextensions > デフォルト値
• 自由にAWSリソースを追加できる
  • Cfnのようにリソースを記述する
  • option_settingsの項目でCfnのリソースを参照することで、ソフトウェアに設定できる。EC2からはコマンドを使って参照できる。

    option_settings:
      aws:elasticbeanstalk:application:environment:
        # these are assigned dynamically during a deployment
        NOTIFICATION_TOPIC: '`{"Ref" : "NotificationTopic"}`'
        DYNAMODB_TABLE: '`{"Ref" : "DynamoDBTable"}`'
        AWS_REGION: '`{"Ref" : "AWS::Region"}`'
    

• commandsはアプリケーションやウェブサーバのセットアップとバージョンファイルの抽出前に実行されるコマンド
• container_commandsはアプリケーションやウェブサーバのセットアップとバージョンファイルの抽出後に実行される。デプロイよりは前に実行される。
  • leader_onlyオプションは１度だけ実行（1つのインスタンスだけで実行）するというオプション。commandsコマンドにはこのオプションはない。

アプリケーションバージョン

• アプリケーションバージョンは1000までしか残しておけない
• ライフサイクルを設定可能
  • カウント数か日にちを設定
  • 「S3に保存されたオブジェクトとの紐付けを削除」か「S3のオブジェクトも削除」が選べる
• アクションを行うためにIAMロールの設定が必要

デプロイ

• All at once
• Rolling
  • バッチサイズ（パーセントorインスタンス数）を指定して、その分づつアップデートする
• Rolling with additional batches
  • rollingに追加のインスタンスを追加して行う
  • 全インスタンスのアップデートが完了したら
• Immutable
  • 新しいASGを作る
  • 1つのインスタンス作成が成功したら残りのインスタンスを作成する
  • 新しいインスタンスを元のASGに移動
  • 旧インスタンスを削除
• Blue / Green（with Route53）
  • Route53を使う
  • 新しいEB環境を作成→Route53のルーティングを変える

ワーカー環境

• SQSを作成
• 既存のSQSの使用も可能
• cronジョブを実行可能

Docker

• 単一コンテナか複数コンテナを指定
• アプリケーションの標準化が可能
• 複数コンテナ
  • Dockerrun.aws.jsonファイルでアプリケーションの動作を設定する
  • ECS on EC2を作成

その他

• rebuildはリソースを削除して再作成する
• Manage Update: 時間を指定してパッチ当てなどを行なってくれる

設定変更

• ESの設定変更を行うと、リソース（LB, EC2インスタンス, ASGなど）に変更を伝える
  • 起動設定等でインスタンスを置き換える場合は、ローリング更新とイミュータブルな更新の２種類がある
    • ローリング更新は「時間にもとづく（バッチ間に一定の時間間隔を割り当てて更新）」と「ヘルスにもとづくローリング（ヘルシーになったら次のインスタンスを更新）」がある
    • イミュータブルな更新はイミュータブルデプロイと同様に、一時的なASGを作成して新しいインスタンスを立ち上げる
    • https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/environments-updating.html

プラットフォームフック

ビルド、デプロイの前後にシェルスクリプトを実行できる。シェルスクリプトは.platform/hooksディレクトリ内に保存する
https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/platforms-linux-extend.html

Lambda

バージョニング

• Latestは最新バージョンを指す
• 特定のバージョンを示すエイリアスを作成可能
  • LATESTを示すことも可能
  • 加重エイリアスも可能（配分先は2つまで）

SAM

• Cfnの拡張
  • Cfnようなyaml（template.yml）でリソースを定義する
  • Lambdaのデプロイが容易
  • Cfnの全てのリソースが利用可能
• Dockerを利用してLambda、APIGatewayのローカル利用が可能
• lambdaコードのS3アップロード、CloudFormationテンプレートの作成を１コマンドで行える（sam package）
• sam packageで作成したコード、テンプレートをsam deployでデプロイ
  • capabilities CAPABILITY_IAMの指定（CfnにIAMリソースの作成を許可）をしないとデプロイに失敗する可能性がある
• CodeDeployと統合可能
  • 新しいデプロイにエイリアスを自動作成
  • 段階的なデプロイが可能
  • デプロイ前後にバリデーション関数を実行可能
  • CWAlarmによるロールバックが可能
  • template.ymlの記述
    • AutoPublishAlias, DeploymentPreferenceを追加→CodeDeployリソースが作成される

API Gateway

• エッジ、リージョナル、プライベートの３種類
• 統合先は Lambda, HTTP, Mock, AWS サービス, VPC リンク
• Lambdaのエイリアスを使って加重ルーティングが可能
• 他リージョンのLambda, AWSサービスを指定可能
• リクエストボディ、リクエストヘッダー、クエリパラメータを API Gateway 上でチェックする機能がある。指定を満たさなければ400レスポンスを返す
• メソッドごとにAWSリソース呼び出しのためのIAMロールを設定

デプロイステージ

• 各ステージは独自の設定パラメータを持っている
• 履歴を持っているため、ロールバック可能
• APIごとにURLを持つ。ステージごとにパスが変わる
• ステージ変数を持つ
  • contextに残るので、Lambdaで参照可能
• ステージごとにカナリアデプロイメントが可能

スロットリング

• デフォルトではステージごとに10000 req/s と、アカウントごとに5000reqのバーストがある。超えた場合は429が帰る
• 使用量プラン
  • スロットリング値を決める（max and burst, quota）
  • 複数のAPI(not ステージ)をまたぐことができる
  • メソッドごとにも設定可能
  • API Keyを紐付けてカスタマーごとに制限を可能
  • Lambda関数とAPIステージの制限があることも忘れずに

Step Functionsとの統合

• IAMロールが必要
• arn, inputが必要
• API GatewayはStep Functionsを実行するだけ。完了は待たない。

ECS

• タスク定義の中に複数のコンテナを設定する
  • コンテナはDocker Hubのものも、ECRのものも設定可能（IAM権限が必要）
• サービス
  • サービスでデプロイ先のクラスタ、デプロイするタスク定義を指定する
  • タスク数も定義する
  • サービスタイプは「レプリカ」と「デーモン」
    • レプリカは1つのEC2上に同じタスク定義をデプロイする
    • デーモンは1つのEC2に対して1つのタスク定義をデプロイする
  • 2つ以上のタスクを同じインスタンス上に起動する場合、ポートをずらす必要がある
  • ポートをランダムにするにはタスク定義のホストポートを空にする

用語

• クラスター
  • EC2、ネットワークを管理
  • サービスを複数もつ
• サービス
  • 複数のタスク定義を用いて、コンテナをクラスター上にデプロイ
• タスク定義
  • 複数のコンテナを定義
  • 同じタスク定義に設定されたコンテナは、同じインスタンス上にデプロイされる

ロードバランサー

• ALBを使ってダイナミックフォワーディングができる
  • EC2のセキュリティグループは全てのポートをALBのSGから許可する
• サービス作成時のみ指定可能
• ヘルスチェックの設定

Fargate

• タスク定義を行うだけ
• FargateとEC2のタスク定義は違う。Serviceでは互換性のある方しか選べない

Elastic Beanstalk（Multi -container）

• ECSクラスター、EC2インスタンス、ロードバランサー、タスク定義などを作成
• 先にDockerイメージを作成し、ECRに登録する必要あり

IAM

• クラスター
  • EC2の操作やECRへの接続を行うロール
  • クラスターの操作に必要
• タスクロール
  • コンテナにアタッチするポリシー
    • S3へのアクセス
    • DynamoDBへのアクセス

ASG

• サービスの設定でオートスケーリングを設定する
• ターゲット追跡とステップスケーリングが設定できる

ログ

• CWLogsにログを送信できる
• ログの送信はタスク定義で行う
  • エージェントのインストールは不要（EC2に入っている？）
  • IAMロールは必要
• クラスターレベルとサービスレベルで取得可能
• コンテナーインサイトを有効化できるが、追加料金がかかる

OpsWorks

chef

• アプリケーションインスタンスの管理を行う
• cookbooksという設定ファイルを使用
  • HTTP or S3からファイル参照
• IAMロールを付与
• レイヤー
  • ロードバランス
  • アプリケーション
  • データベース
• OpsWorksのコンソールからインスタンスの管理をできる
  • インスタンスの設定（ネットワーク、IAM、ストレージ、etc）
    • タイムベース
      • 起動する時間帯（n時〜m時、曜日ごと）
    • ロードベース
      • インスタンスの負荷が幾つになったら起動・終了
      • オートスケールのように柔軟ではない
      • インスタンス数を柔軟に変化できない（1つのインスタンスごとに設定）
  • アプリケーションコード
    • どこからアプリケーションコードをインストールするか
  • 全てのインスタンスでコマンドを実行可能
• cookbookのコマンドログを確認可能
• ライフサイクルイベント
  • Setup, Configure, Deploy, Undeploy, Shutdown
  • Configureイベントのみは全てのインスタンスで実行される
    • 既存インスタンス４、新1つのインスタンス１の場合、合計５のインスタンスで実行される
    • データ（レイヤー全てのインスタンス情報）が全てのインスタンスに送信される
    • アプリケーションが互いに認識し合うサービスに有効
• オートヒーリング
  • 各インスタンスではOpsWorksのエージェントが動いている。５分間信号がない場合は失敗と判定する
  • 失敗となった場合、インスタンスを再起動（停止→起動）する
• EventBridgeでイベント検知可能

CloudTrail

• イベントタイプ
  • 管理イベント（書き込み・読み込み）
  • データイベント
  • インサイトイベント
• 暗号化
  • kmsで暗号化可能（or S3キー）
• S3バケットポリシーでcloudtrailからの書き込みを許可する必要がある
• 内容
  • 時刻、プリンシパル、イベントタイプ、リクエスト、etc
• 最大15分の遅延あり
  • リアルタイム対処にはEventBridgeを使用
• S3には一時間に1回　ダイジェストファイルを作成される
  • CLIを使って検証可能
• 複数アカウントのcloudTrailから1つのアカウントのs3バケットに集約可能。バケットポリシーで許可するだけ。

Kinesis

• 自動で3AZにレプリケート

Kinesis Stream

• 制限
  • 保持期間は1~365日
  • 1シャードごとに1MB/s or 1000message/sの書き込み
  • １シャードごとに2MB/s or 5req/sの取り出し
    • GetRecordsで10MBまでの取り出しが可能だが、その後5秒間は例外が発生する
      https://docs.aws.amazon.com/ja_jp/streams/latest/dev/service-sizes-and-limits.html
• CWLogsからKinesis Streamに転送可能
• ターゲット
  • Lambda, Firehose, Spark, ライブラリなど
• KCLはDynamoDBを使用

Kinesis Firehose

• ソース
  • Kinesis Stream, CWlogs, CWEventsなど
• ターゲット
  • ES, S3, Redshiftなど
• 1分〜15分
• 1~128MB
• Lambdaを使ってデータ整形が可能
• IAMロールを付与可能

CW metrics

• EC2に標準モニタリングは5分毎、詳細モニタリングは1分毎
• 15ヶ月まで保持可能
• 時間が経つにつれて、詳細度が下がっていく
• 全データを保持するにはESを使う
• EC2のメトリクス項目
  • CPU、ディスク（インスタンスストアのインスタンスのみ）、ネットワーク、CPUクレジットなど。RAMはない
• EBSのメトリクス項目
  • R/Wバイト、スループット、キューサイズ、アイドル時間、バーストバランスなど。空きボリュームサイズはない
• ASG
  • Min/Max グループサイズ、InServiceインスタンス数
• ロードバランサ
  • リクエスト数、エラー数（4xx 5xxそれぞれ）、アクティブコネクション数、他コネクション数など
• RDS
  • 色々。ディスク容量も取れる。
• カスタムメトリクス
  • 標準 1分毎
  • 高頻度 1秒毎に指定
• APIコールでメトリクスをエクスポートできる
  • S3やESに保存したい場合
  • 期間が大きすぎるとエラー
  • 自動化のためにEventBridge, Lambdaを使用したりする
  • 現在はメトリクスストリームを使ってKinesis firehose経由でS3に保存可能
    https://dev.classmethod.jp/articles/202104-breaking-cloudwatch-metric-stream/

CW Alarm

• メトリクスに閾値をつける
• 複数のメトリクスを組み合わせてアラームを作成することはできない
• 状態毎（in Alarm, OK, Insufficient data）にトリガーc
  • SNS・メールアドレス・オートスケール（ECS, ASG）、EC2アクション（停止、終了、再起動など）
• EventBridgeでもアラーム状態変化を取得可能
• コストに対してアラームを設定可能
  • メトリックデータはバージニア北部のみ
  • サービス毎に設定可能（AWS Budgetsでも可能）

CW logs

• ロググループ→ログストリーム→ログの構造
• 保持期間はロググループ単位で設定
• メトリックフィルター
  • グループレベルで設定
  • メトリックを作成する
    • e.g. サーバのアクセスログから404を含むメトリクスを作成する。アラームを作成すると監視が楽になる。
• S3へのエクスポート
  • 期間・プレフィックスを指定
  • 送信先のS3バケットポリシーでCWLogsからのPutを許可する必要あり
  • EventBridge＆Lambdaで定期実行可能
• サブスクリプションによるリアルタイム処理
  • ターゲットはKinesis stream, Kinesis Firehose, Lambdaなど
  • ESをターゲットに設定できるが、Lambdaが作成される
  • フィルターをかけられる（なしでもOK）
    • エラーログだけ送信なども可能
  • Kinesis firehoseなどを使う場合はfirehoseにIAMロールのアタッチが必要
  • サブスクリプションはロググループ単位でのみ設定可能
• 自動収集ログ
  • ALB, NLB, CLBのログはS3へ
  • API GatewayのログはCW Logsへ
  • CloudTrailのログはS3とCW Logsへ
  • VPC Flow LogsはS3とCW Logsへ
  • Route53はCW Logsへ
  • S3 Access LogsはS3へ
  • CLoudFront Access LogsはS3へ

Unified CloudWatch Agent

• EC2上でUnified CW Agentをインストールする（コマンド）
• コマンドでインタラクティブに設定
  • 取得するメトリクス、間隔
    • CPU, Disk, RAM, Network, Processe, Swap
  • CWLogsに送信するログファイル
  • 設定内容はjson形式のファイルに保存される
  • 設定内容はSSMパラメータストアに保存可能
  • パラメータストアに保存されている設定内容からエージェントを起動できる
• 適切なロールの設定が必要

EventBridge

• イベントタイプ
  • AWS API Call via CloudTrailとEventBridge規程のものがある
• S3イベント通知 vs EventBridge
  • S3イベント通知はSQS, SNS, Lambdaのみ。EventBridgeは対応サービスどれでも。
  • S3イベント通知はオブジェクトレベルのみ。EventBridgeはバケットレベルも可能。

CW Dashboard

• メトリクスをいろんな形式で表示可能
• ダッシュボードはマルチリージョン。各項目にどのリージョンのどのメトリクスを表示するか選択する。
• サービスダッシュボードを参考にできる

X-Ray

• トレース内容の詳細を確認できる（１リクエストが何にどれだけ時間を使ったのか、エラーは起きなかったか、など）
• 定期監視
  • EventBridgeでLambdaを定期実行。LambdaがX-RayのAPIをコール。エラーがある場合は何かしらの処理を実行（例えばEventBridgeからCWAlarmをアラートにする。通知を飛ばす。など）

ElasticSearch

• ESのためのKibanaはリアルタイムダッシュボード。CW dashboardsの代わり
• Logstashはログエージェント
• ユースケース
  • DynamoからDynamoDB Stream、LambdaをつかってESにインデックス
    • データはDynamoDBに保存、検索はESを使う
  • CWLogs→サブスクリプションフィルター→Lambda or Kinesis Firehose→ES
    • ログの検索
  • Lambdaに与えるIAMロールが必要

SSM

• EC2インスタンスおよびオンプレミスインスタンスの管理

オンプレミスのセットアップ

• エージェントをインストール＆起動
• ハイブリッドアクティベーションで起動
  • 1000インスタンスまで。それ以上は申請が必要＆料金が発生。
  • IAMロールを作成。
  • アクティベーションコード＆IDを使ってエージェントを登録する。
• オンプレミスインスタンスにもタグを設定できる

リソースグループ

• Cfnスタックベースかタグベースでインスタンスのグルーピングを行う

Run Command

• SSMによってインスタンスにコマンドを実行する
• ドキュメントで実行内容を定義する
  • ドキュメントはデフォルトのセットとカスタマイズセットがある
• ターゲット
  • タグ、インスタンスの手動選択、リソースグループの３種類から選択
  • 同時実行数の設定が可能
• エラー数による停止設定ができる
• コマンド出力をS3, CWLogsに保存可能
• SNS通知可能
• IAMロールの指定

パラメータストア

• バージョニングされる
• CLIによる取得
  • 暗号化済みのパラメータは、オプションにより複合可能
  • パス指定でパス配下の全てのパラメータを取得可能

Patch Manager

• インスタンスに自動的にパッチを当てる
• パッチベースラインでパッチ内容を指定
  • デフォルト提供のものとカスタマイズしたものがある
    • ルールでパッチを当てるOS, 重要度, 分類（セキュリティ、バグetc）, 自動実行までの時間などを設定
    • 除外パッチを指定可能
• ベースラインを自動適用するためにメンテナンスウィンドウを設定
  • 実行時間（cron形式）
  • 期間
  • メンテナンスウィンドウの残り何時間になったら、タスクの起動を止めるか
  • メンテナンスウィンドウが有効な期間
    e.g. 5月〜8月だけ有効。メンテナンスウィンドウの切り替えなどに便利。
  • メンテナンスウィンドウの対象にするインスタンスを指定
    • タグ、インスタンスの手動選択、リソースグループによる指定が可能
  • Run Commandで、メンテナンスウィンドウ中に、ベースラインを実行するように登録する

SSM Inventory

• インスタンスで実行中の情報を取得する
• ターゲットは全てのインスタンス、タグ指定、手動選択の３種類から指定
• 指定時間間隔で取得する

Automation

• AWS のサービス(EC2, RDS, Redshift, S3, etc)のメンテナンス、修復、デプロイを自動化するサービス。AMIの作成などもできる。
• ドキュメントで実行内容を指定
  • ドキュメントにはインプットパラメータを指定可能
• IAMロールを指定
• EventBridgeとの統合が可能

Session Manager

• SSHを使わずにログイン可能
• 接続履歴が保存される
• 実行内容をS3とCWLogsに保存可能

AWS Config

• 全リージョンを対象にもできる
• S3に設定ファイルを保存可能
  • バケットポリシーで許可をする
• IAMロールを設定
• 各リソースの現状の設定、CloudTrailイベントが見れる
• ルール
  • AWS管理のルールとカスタムルールがある
  • ルールのトリガーは「期間毎(24時間)」と「リソース変更」に設定可能
  • 作成すると現状のリソースも検査してくれる
  • カスタムルールはLamdbaを使用する
  • リソース変更のリソースは「タグ」「リソースタイプ」「すべて」のどれかを選択
• 通知
  • ConfigのSNS通知はルールスコープで設定ができない
  • ルール毎に通知を行いたい場合はEventBridgeを使う
• 修復アクション
  • 違反したリソースに対して修復アクションを実行可能
  • 修復アクションにはSSM Automationが利用されている
• アグリゲーター
  • 複数アカウントにまたがって評価が可能
  • 「個別にアカウントを登録」か「Organizations」を使用する
  • 利用するリージョンを複数指定可能

Service Catalog

• 管理者によって作成されたCfnテンプレート（プロダクト）からプロダクトを起動する
  • 開発者の統制が簡単
• ポートフォリオ
  • 複数のプロダクトをまとめる
  • IAMユーザ、ユーザグループ、ロールでプロダクトを展開できるユーザを制限する
  • Organization内のアカウントや他のAWSアカウントにも共有可能
• 制約
  • ポートフォリオ単位で制約をかけることができる
  • プロダクトの起動に使用するIAMロールを割り当てることができる

Amazon Inspector

• ネットワークアセスメントとホストアセスメント
• EC2インスタンスとECRのイメージに対して検査可能
• ネットワークアセスメント
  • 外部から通信が可能かなど
  • エージェントは不要
• ホストアセスメント
  • SSMエージェント（昔は専用エージェント）のインストールが必要
• スケジュールベースで実行可能（EventBridgeが作成される）
• ターゲット
  • タグで指定
  • SSM Run Commandでエージェントをインストール（IAMロールが必要）
• EventBridgeのターゲットとして実行可能
• SNS通知が可能（アクション毎に設定可能）
• ゴールデンAMIの作成時検証に使える
• 自分でEC2を起動する必要がある（Inspectorが自動で起動してくれるわけではない）

Personal Health Dashboard

• EventBridgeを使ってイベント検出可能

Trusted Advisor

• コスト、セキュリティ、パフォーマンス、信頼性、サービス制限を自動検出してくれる
• EventBridgeで検出可能
  • Trusted Advisorのイベントルールはバージニア北部でのみ作成可能
  • e.g. EC2 低使用→EventBridge→Lambda→インスタンスタイプ変更
  • e.g. exposed access key→EventBridge→Step Functions→対応
• 週次でメールを受信可能（課金、操作、セキュリティ）
• 更新方法
  • ベーシック、開発者プランの場合→手動更新
  • ビジネス、エンタープライズプランの場合→1週間に1回自動更新
  • RefreshTrustedAdvisorCheck APIで更新可能（コンソール or CLI）
    https://docs.aws.amazon.com/ja_jp/awssupport/latest/user/get-started-with-aws-trusted-advisor.html#refresh-check-results

GuardDuty

• AWSアカウント保護のための自動脅威検知
• 入力ログ
  • CloudTrail, VPC Flow Logs, DNS Logsなど
• 検出項目
  • ブルートフォースアタック、EC2を使ったマイニング、etc
• EventBridgeを使ってアクションの実行を可能

Macie

• S3に保存された個人情報データ、プライベートキーなどを検出可能
• 別アカウントのバケットも監査可能

Secrets Manager

• ローテション
  • 最大期間は365日
  • ローテション毎にLambda関数を実行してアクションを行う e.g. 現在アプリケーションで使われているDB認証情報の更新

License Manager

• 外部のライセンス（windowsやoracleなど）を管理
• ライセンスとリソースを紐づける
• 使用率を追跡する
• リソースの紐付け
  • AMI, インスタンス, など
    • AMIの場合はAMIから作成されたインスタンスを紐付けてくれる

コスト配分タグ

• 通常のタグに近いが、コストレポートに使うもの
• AWSによるタグ
  • aws:で始まる
  • ユーザがアクティベートする必要がある
• ユーザ指定タグ
  • user:で始まる
  • 反映まで最大24時間かかる
• コストエクスプローラやBudgetsでフィルターに使える

ASG

• 起動テンプレートを設定
  • 起動テンプレートはバージョニングが可能
    • デフォルトバージョンは自分でどのバージョンにするか設定が必要
• スポットインスタンスとオンデマンドインスタンスの組み合わせが可能
• スケジュールアクション
  • min, max, desired capacityを変更可能
  • Cron形式 or 1回実行が可能
• クールダウン
  • スケーリングアクションが起きたあと、次のスケーリングアクションを許可するまでの時間
• ターゲット追跡スケーリング
  • スケールインを無効にできる
• 新規のインスタンスをメトリクスに追加するまでのウォームアップ時間を設定可能
• ASGのスケーリングポリシーを作成すると、CW Alarmが作成される
• ヘルスチェック
  • EC2のインスタンスチェック、ELBのヘルスチェックどちらも利用可能
  • ELBのヘルスチェックはパスとポートを指定する
• スロースタート期間
  • 新規に作成したインスタンスにすぐに全リクエストを割り振るのではなく、線形に割り振るリクエストを増やしていく
• ALBリスナーでリダイレクト設定をできる（HTTPからHTTPSへなど）
• サスペンデッドプロセス
  • 選択したプロセス（起動、停止、ヘルスチェック、リプレイス、etc）の実行を妨げることができる
  • AlarmNotificationはCWAlarmに基づくスケーリングポリシーを全て停止する
  • AddToLoadBalancerはインスタンスを起動しても、ターゲットグループに追加しない。後からサスペンドを解除しても、起動済みのインスタンスはTGに入らないので注意
  • トラブルシューティングなどに使う
• デタッチ
  • ASG管理下のインスタンスをASGから外すことができる。ELBとの紐付けも解除される
• スタンバイ
  • ASG管理下に置いたままだが、ELBのターゲットから外すことができる
• スケールイン保護
  • スケールインしなくなる（インスタンス毎に設定）
  • 途中で終了してはいけないバッチ処理などを行うインスタンスに設定
• ライフサイクルフック
  • インスタンスの起動から終了までの間に処理を挟める
  • SNS、SQS、EventBridge + Lambdaが使用可能
  • タイムアウト時間とタイムアウトした場合の動作（Abandon or Continue）が選択可能
  • フックを追加した場合、完了の信号を送る必要がある
• 終了ポリシー
  • 複数のポリシーを組み合わせてカスタマイズ可能
  • デフォルトポリシー
    1. 一番インスタンスが多く存在するAZから削除
    2. アロケーション戦略（オンデマンド&スポット）を保つようにする
    3. 起動テンプレート/起動設定の古いもの
  • カスタムポリシーの作成可能（Lambdaを使用）
• ASGとSQSの統合
  • CW alarmでSQSのメッセージ数を監視してスケーリング
• メトリクス
• 通知
  • SNSで起動、停止、起動失敗、終了失敗などの通知を行える
  • EventBridgeで柔軟にトリガー可能
• CloudFoarmation
  • CreationPolicy
    • インスタンスが何個作成されたらASGを作成完了にするか指定可能
    • EC2からcfn-signalを送信
    • タイムアウトを設定可能
  • ASGで参照している起動設定を更新した場合、ASGに設定している起動設定は変わるが、既存のEC2インスタンスはそのまま（旧起動設定で起動されたインスタンスのまま）
  • UpdatePolicy
    • 起動設定などを変更し、ASGが更新された場合に、既存インスタンスの更新が可能
    • AutoScalingRollingUpdateの場合
      • シグナル受信でASG更新の完了を設定可能
    • AutoScalingReplacingUpdateの場合
      • ASG自体を新しい起動設定で作成する
        • CreatetionPolicyが適用される
    • スケジュールアクションが設定されているASGの場合、AutoScallingScheduledAction属性で設定可能
• CodeDeployとの統合
  • ASGにインスタンスが作成された場合、インスタンスがCodeDeployエージェントをインストールした段階でデプロイが行われる（userdataでエージェントをインストールしておくだけで、最新のコードでアプリケーションが立ち上がる）
  • Blue/Greenデプロイメント
    • 新たにASGを立ち上げる
    • 旧インスタンスは残しておくか、一定時間後に削除するか選べる
    • LBが必要（ルーティング先のインスタンスを変更するため）
    • ターゲットグループは1つ
  • CodeDeploy中にスケールアウトした場合、最新のコード（デプロイ中のコードではない）がデプロイされる。スケールアウトしたインスタンスとデプロイされたインスタンスはリビジョンが異なるため、新たにデプロイが必要。回避するにはデプロイ中にASGのインスタンス作成をサスペンドする
• ASGから起動したインスタンスにASGのタグを伝播することができる（タグごとに伝播させるか選択可能）。（PropagateAtLaunchをfalseにすると伝播しない）しかしEBSには伝播しない。EBSへ伝播させるには、起動テンプレートでタグを指定する必要がある。起動テンプレートとASGのタグが衝突した場合にはASGのタグが優先される。
  • https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/ec2-auto-scaling-tagging.html
  • https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/create-launch-template.html

DynamoDB

• DynamoDB Accelerator
  • インスタンスサイズおよびノード数を指定
  • サブネットグループの指定をする
• グローバルテーブル
  • 今は作成時にテーブルが空である必要はない
  • DynamoDB Streamの有効化が必要
  • 読み込みは結果整合性。リージョンを跨いだ強い整合性読み込みはサポートされていない
  • 同時に複数リージョンで書き込みがあった場合、最後に書き込まれたレコードが優先される（リージョン間のデータ差異はない
  • https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/globaltables_HowItWorks.html

Route53

ヘルスチェックはエンドポイントだけでなく、CW Alarmも使用可能

EFS

• EFS to EFS バックアップ
  • https://aws.amazon.com/jp/solutions/implementations/efs-to-efs-backup-solution/
  • AWS Backupが使えるリージョンであればそちらを推奨

オンプレミス

• Amazon Linux 2 AMIを VMとしてダウンロード可能（.isoフォーマット）