AWS DOPの学習（設定管理と IaC編）

2024年7月21日 15:23

はじめに

本記事は個人の備忘録として、DOPに向けた学習の中で理解が不十分だった部分や間違えた問題の内容をまとめたものになります。
サービスの全体像を解説した記事ではないため、ご了承ください。

本記事は以下のサイトを大いに参考にしています。
とてもわかりやすくまとめられているため、DOPを受験される方はご一読することをお勧めします。
https://qiita.com/tech4anyone/items/b06f88035d27c6ef13b2

Cloud Formation

Cloud FormationはAPIを使用してリソースの更新を行うため、VPC内のリソースを更新する際もインターフェースエンドポイントに依存しない。

スタック外で依存リソースが変更された場合や、ロールの権限が不足している場合に、CloudFormationでロールバックに失敗する。

プロビジョニングが必要な頻度とデプロイが必要な頻度は一致しないため、デプロイとプロビジョニングのパイプラインは分離推奨。

実プロジェクトでCloudFormationを使う際には、アーキテクチャが決まった段階でAWS公式のResources一覧を確認し、CloudFormationにできるものは例外なくCloudFormationテンプレートにおこすことがベストプラクティス

テンプレートはS3にアップロードしてCloudFormationを実行することでスタックが作成される。(現在は直接Gitと連携することも可能)

テンプレートファイル

AWSの環境（VPC、EC2等のコンポーネント）の情報を記述したテキストファイル。
記述形式はJSON形式またはYAML形式
※スタック名はアカウントのリージョンごとに一意にしておかないと、古いスタックが更新されてしまう。

テンプレートの構成要素

Resources(必須)
作成するコンポーネントの情報
Parameters
環境変数となる値をCloudFormationの冒頭にParametersとしてまとめて宣言することが可能。
Parametersに書いた値はDefault指定をしておくことで、CloudFormation実行時に書き換えが可能(パラメータ入力)
AllowedValuesを設定することで、事前に許可するパラメータを制限することが可能。
AWS::AccountIdやAWS::Regionなどデフォルトで設定されているパラメータもある。
Mappings
開発環境と本番環境など、環境ごとに切り替える値の設定などに使用
Outputs
他のCloudFormation Stackで利用したい値の出力に使用
クロススタック参照をする場合にはOutputsの中にExportの記載が必要
Conditions
条件に基づいて、作成するリソースやOutputsの生成を制御するために使用(if文的なもの)

SSM Parameter Store,SecretsManagerからの変数の取得

AMI IDのように頻繁に変わるかつ様々なCloudFormationテンプレートから参照したい値や、パスワードやクレデンシャル情報などのパラメータの中に記述すべきで名はない値を動的に取得する際に使用する。
AWS::SSM::Parameter::Value：
SSM Parameter Storeに格納されているプレーンテキスト用

CustomResource

SNSまたはLambdaを処理をバックエンドとして利用して、公式に提供されていないリソースの作成や、特定の処理をCloudFormationで実行する際に使用する。
S3バケットはオブジェクトがある状態では削除できないため、CustomResourceを利用してS3バケットを空にするLambdaの処理を実行するのによく利用される。

CloudFormationヘルパースクリプト

CloudFormationを使用したEC2構築時のインスタンスの初期設定に使用。
CloudFormationヘルパースクリプトの場合、スクリプトが失敗するとCloudFormation自体も失敗するのに対して、EC2のUser Dataで初期設定を行うと、処理が失敗してもCloudFormationは成功してしまうため、
CloudFormationヘルパースクリプトの使用が推奨される。

変更セット

変更セットを使用すると、スタックの変更案が実行中のリソースに与える可能性がある影響を変更前に確認できる。変更セットの実行を確定したときのみ AWS CloudFormation によってスタックが変更されるため、更新を行うことなく、更新後のリソースの状態を確認することができる。

スタックセット

複数のアカウントおよびリージョンのスタックを 1 度のオペレーションで、作成、更新、削除できるようにするスタックの拡張機能。
複数のAWSアカウントを利用する時にAWS ConfigやCloudTrailなど、全てのAWSアカウントに共通で有効にしたいサービスをまとめて設定する際などに使用する。
Deleteは各スタックごとで可能だが、Updateは全スタックに対して実行されるので注意。

スタックセットの権限は以下の２種から選択して設定する。

自己管理型権限（Self-Managed Permissions）

自己管理型権限では、スタックセットの実行に必要な権限をユーザーが自ら管理する。ユーザーは、スタックセットが操作する各アカウントに対して適切なIAMロールを作成および管理する必要がある。

サービス管理型権限（Service-Managed Permissions）

サービス管理型権限では、AWS Organizationsを使用してスタックセットの権限を管理する。AWS CloudFormationがAWS Organizationsの管理ポリシーを使用してスタックセットの操作に必要な権限を自動的に管理する。

サービス管理型のスタックセットを作成するには以下の設定が必要。
1.AWS Organizations のすべての機能を有効にする
2.管理アカウントのアカウント管理者がAWS Organizations で信頼できるアクセスをアクティブ化する

StackSetsをOrganizationと統合すると、Organizationに新しいAWSアカウントが追加されたときにStackインスタンスを自動的にデプロイできる。
また、AWSのメンバーアカウントにStackSetsの管理を委任することも可能。
前提として、Organizationとの信頼されたアクセスを有効にする必要があるが、委任された管理者はOrganizationが管理するアカウントにStackインスタンスをデプロイできるようになる。

クロススタック参照

CloudFormationテンプレートの値を別のCloudFormationテンプレートから参照すること。
あるCloudFormationテンプレートのOutputsでExportした値をFn::ImportValueで参照することができる。
※すべての参照が削除されない限り、基礎となるスタックを削除することはできない点に注意。相互参照を行うと危険。
テンプレートを分割する際は参照が一方向になるよう意識する。

ネストされたスタック

他のスタックの一部として作成されたスタック
AWS::CloudFormation::Stack リソースを使用して別のスタック内に作成する。
ざっくり言うと、
AスタックのテンプレートではBスタックとCスタックを作成。
BスタックのテンプレートではVPCとSubnetを作成。
CスタックのテンプレートではEC2とSecurityGroupを作成。
するよう設定されている中で、
Aスタックを作成するとVPC、Subnet、EC2、SecurityGroupの全てをデプロイ、管理できるというもの

AWSのベストプラクティスはネストスタックを活用し、可能な限りテンプレートの再利用を行う

DeletionPolicy（削除ポリシー）

AWS CloudFormationテンプレートでリソースが削除されるときの動作を指定するためのプロパティ。
削除ポリシーは、CloudFormationスタックの削除時のリソースの扱いをDelete、Retain、Snapshotで制御する。
これにより、重要なデータが誤って削除されるのを防ぐことができる。

※S3はDeleteionPolicyがDeleteになっていてもバケット内にファイルが存在する場合はS3の削除が行えず、スタックの削除にも失敗する。
スタック削除前にDependsOn属性とIAMロールを持つLambdaによりRequestTypeがDeleteの時バケットから全てのオブジェクトを削除するように設定する。または、CustomResourceを使用してバケット内を空にする。

ドリフト検出機能

CloudFormationスタックが管理するAWSリソースの設定が、スタックテンプレートの定義と一致しているかどうかを確認するための機能。
スタック外で直接変更されたリソース（ドリフト）を検出し、インフラストラクチャの整合性を保つことができる。

AWS Config は CloudFormation のドリフト検出を開始でき、ユーザーは AWS Config ルールに自動修復アクションを追加できる。CloudFormation がリソースプロパティを追跡してドリフトを判断するには、プロパティ値がデフォルト値であっても明示的に指定する必要がある。

スタック更新をする際には、念のためDriftを実行するのがベストプラクティス

NoEcho

NoEchoプロパティは、スタックの出力やリソースプロパティ値として機密情報を扱う場合に使用されるオプション。NoEchoプロパティを使用することで、CloudFormationテンプレートやスタックイベント出力で機密情報が表示されるのを防ぐことができる。これにより、パスワードやAPIキーなどの機密情報が漏洩するリスクを軽減できる。

サービスロール

実行者のIAMユーザーの権限ではなく、サービスに委譲したIAMロールに紐づいた権限でスタック作成が行われる様にするための機能。
Service RoleはCloudFormationにスタックリソースを作成/更新/削除することを許可するIAMロール。
IAMユーザにCloudFormationの細かい権限を設定するのではなく、CloudFormationというサービスがどういう権限を持つかを設定する。

Stack Policy

Stack PolicyはCloudFormationのスタック更新でアップデートを許可/禁止するリソースを定義するためのポリシーです。
CloudFormationのスタック更新について、デフォルトではすべてのリソースに対するすべてのアクションが許可されている。
特定のリソースだけは絶対に更新されたくない、という場合にStack Policyで該当リソースの更新を禁止できる。

AWS SAM

サーバーレスアプリケーションの構築、テスト、デプロイ、管理を簡単にするためのオープンソースフレームワークです。SAMは、Amazon API Gateway、AWS Lambda、Amazon DynamoDBなど、AWSのサーバーレスリソースを定義、デプロイ、管理するためのテンプレートベースのアプローチを提供する。

サーバーレスアプリケーションの作成にはAWS SAM を使用することがベストプラクティス。SAM のテンプレートは、AWS CloudFormation テンプレートの拡張機能のため、サーバーレスでないインフラストラクチャをSAMテンプレートで起動することも可能。

AWS SAMでは段階的な AWS Lambda デプロイメントを提供する。わずか数行の設定で、AWS SAM は次のことを実行する。

Lambda 関数の新しいバージョンをデプロイし、新しいバージョンを指すエイリアスを自動的に作成する。
期待どおりに動作すると確信できるまで、顧客トラフィックを徐々に新しいバージョンに移行する。更新が正しく動作しない場合は、変更をロールバックできる(カナリアリリース)。
新しくデプロイされたコードが正しく構成され、アプリケーションが期待どおりに動作することを確認するためのトラフィック前およびトラフィック後のテスト関数を定義する。
CloudWatch アラームがトリガーされた場合、デプロイメントを自動的にロールバックする。

上記の理由からサーバレスアプリケーションのデプロイ失敗時の影響を最小限にしてデプロイするにはSAMを用いると良い。

AWS SAMを用いたLambdaのデプロイはCodeDeployと統合されています。

SAMテンプレート

CloudFormationテンプレートをラッピングしたもの。
扱えるリソースがサーバレスアプリケーションで使うものに特化している代わりにCloudFormationよりも短く直感的な書き方でテンプレートを作ることができる。

SAM CLI

SAM CLIはAWS CLIと比較してSAMに特化したCLIです。
SAM CLIを利用する際にはAWS CLIとは別に、SAM CLIをインストールする必要がある。

SAM CLIはSAMテンプレートのバリデーションチェックだけではなく、SAMテンプレートのひな型生成やアプリケーションのビルド、デプロイなど多くの操作を行うことが可能。

また、開発者のローカル環境でLambdaやAPIのエンドポイントを起動し、実行テストが可能。

AWS CDK

AWS CDKとは高水準言語(Typescriptやpython)でインフラストラクチャを記述できるサービス。
CloudFormationはYAMLかJSONでテンプレートを記述する必要がある。
AWS CDKを用いると高水準言語のTypeScript、Python、Java、.NET、C#および Goでインフラストラクチャを定義することが可能。

これにより、アプリケーションのコードとインフラストラクチャのコードを同じ言語で記述可能となる。
特にLambdaやECS/EKSを用いたアプリケーションを構築する際には開発者に求められるなスキルセットが最小限で済むようになる。

AWS CDKでアプリケーションを構築する際は、アプリケーション本体、スタック、エントリポイントの3つが必要。

AWS Service Catalog

AWS上で承認されたAWSサービスのカタログを作成、管理できるサービス。
AWS Service Catalogを使用すると、事前に定義された製品（テンプレート）を使用して一貫した環境を簡単にデプロイすることができる。
これにより、AWSの利用に不慣れな人でも簡単にAWS環境を用意することができる。
試験の際にはガバナンス/コンプライアンス/一貫性を強化するために、という文脈で登場することが多い。

Product

1つまたは複数のAWSリソースから構成されるリソースのテンプレート。
実体はCloudFormationテンプレート

Portfolio

Productとその設定情報が複数集まったもの。
Productをどういった設定でだれがローンチできるかを決める。

Elastic Beanstalk

EC2上へのアプリのデプロイと管理をターゲットとしており、
サーバレスサービスへのデプロイは対象外
アプリケーションのデプロイはS3上にzipを格納することで実施可能。

アプリケーション:
アプリケーションバージョンと環境の情報を束ねるEBの論理単位。
1つのアプリケーションにつき複数の環境やアプリケーションバージョンを持つことができる。例えば開発環境と本番環境の2つの環境を1つのアプリケーションで管理することが可能。
アプリケーションバージョンはデプロイ可能なコードを指し、S3上でバージョン管理される。
環境ごとに異なるアプリケーションバージョンをデプロイすることが可能。

環境はインフラストラクチャ部分の設定でウェブサーバ環境とワーカー環境の2種類が存在する。
Web環境：ウェブアプリケーション用
ワーカー環境：バッチアプリケーション用

デプロイメントオプション

All at once
ローリング
追加バッチによるローリング
デプロイ時の実行台数を減らしたくない時に使用
イミュータブル
新しくAutoScalingGroupを作りEC2インスタンス起動後、既存のAutoScalingGroupにインスタンスを移動して更新
トラフィック分割
新しくAutoScalingGroupを作りトラフィック切り替えを行い更新
ALBが必須。
新旧それぞれに流すトラフィックの割合を制御することができる。
Canaryリリースを実行するにはトラフィック分割を利用する。

※Blue/GreenはElastic BeanstalkのデプロイメントオプションにはないBlue/Greenを実現したい場合にはRoute53を用いたURLのスワップ(CNameの入れ替え)が必要(Route53の機能)

Step Function

ステート

Step Functionsの基本的な構成要素。
ステートは単一のタスクや処理を表し、それが成功した場合、次にどのステートに進むかを定義する。
ステートはAWS Lambda関数、Amazon ECSタスク、Amazon SNS通知など、様々なAWSサービスを実行することができ、異なるサービスの統合が容易になり、柔軟性が向上する。

ステートマシン

ステートはステートマシンによって組み合わせられ、ワークフロー全体を形成する。
ステートマシンはステートの継続フローを制御し、成功や失敗などのイベントに基づいて次に実行するステートを決定する。
これにより、複雑なワークフローを階層的かつ柔軟に構築できる。

ベストプラクティス

1.スモールステップの利用
各ステートを単純で小さなタスクに分割することで、可読性とメンテナンス性が向上し、ワークフローの理解を容易にできる。

2.トランザクショナルなパターンの採用
ステートの実行中にエラーが発生した場合のリトライやエラーハンドリングを適切に設定することで、データの整合性を確保する。

AWS Systems Manager

AWS Systems Managerは「SSM」と呼ばれていて、SSMのエージェントは「SSMエージェント」と呼ばれる

AWS Systems Managerは、VPCエンドポイントを通じて内部ネットワークを使用して通信を行う。インターネットを経由せずにVPC内で通信することで、セキュリティが向上する。

対象インスタンスにSSMエージェントをインストールすることで、マネージドインスタンスとして、Systems Managerの各種機能を使えるようになる

EC2をSSMのマネージドインスタンスに設定するには
1.EC2にインスタンスプロファイルを設定
（インスタンスプロファイルとはEC2がIAMロールを引き受けるためのコンテナ）
2.リージョンにSSM用のVPCエンドポイントを作成
3.EC2にSSMエージェントをインストール
4.Systems Manager エンドポイントへの HTTPS (ポート 443) アウトバウンドトラフィックを許可するSGを設定。
の4つが必要

リソースグループ

Tagを用いて複数のリソースを1つのグループのように扱う概念。
複数のリソースをグルーピングできるため、AWS内で操作対象をまとめて指定することが可能。

Document

Systems Manager がマネージドインスタンスで実行するアクションを定義したもの。
SystemsManagerの各種サービスは作成したドキュメントをもとに実行される。

Session Manager

SSHやSCPなどのセキュアなリモートシェルアクセスを提供するサービス。
SSHと比較してアクセス用のポートの穴をあける必要がなくなるためNW観点でのセキュリティが向上する。
Session ManagerはIAMロールやポリシーを使用してアクセスを管理し、セッションログを自動的に記録する。
これにより、踏み台の管理をなくしながらもセキュリティと監査レベルの維持が可能

Run Command

EC2内部でコマンド実行するための機能。
SSH不要で使えるため、SSHを用いたコマンド実行よりもNW観点でのセキュリティが向上する。
EventBridgeを起点にコマンドを実行できるので、定期実行のみではなくイベント駆動でのコマンド実行も可能。
コマンドの出力はS3やCloudWatchLogsに送れるのでコマンド結果の解析も可能。
EC2内部でコマンド実行したい際にはRun Commandを使うのがベストプラクティス。

Patch Manager

セキュリティ関連とその他のアップデートの両方でノードにパッチ適用するプロセスを自動化する。

パッチマネージャーによるスキャン(およびインストール)を実行する際のターゲットの指定の仕方として以下の3種がある

インスタンスID指定
タグ指定
パッチグループ指定

パッチグループ指定以外の方法でターゲットを指定し、ターゲットがどのパッチグループにも所属していない場合、使用されるパッチベースラインはOSごとのデフォルトベースラインとなる
パッチグループ指定の場合、パッチグループが登録しているパッチベースラインが選択される
パッチベースラインとのずれがパッチグループ単位に適用される。

パッチ適用の方法はパッチワークベースラインに対して自動適用あるいは、承認済みのパッチのみ適用の2つの方法を選ぶことができる。
パッチの適用タイミングはオンデマンドあるいはMaintenance Windowsを用いたスケジュール適用を選ぶことが可能。
Patch Managerはパッチの適用だけではなく、ノードをスキャンして不足しているパッチの洗い出しも可能。

パッチベースライン

インスタンスにパッチ適用を行う際のルールを定義するものである
OSごとに事前定義済みのパッチベースラインが存在する
事前定義済みのパッチベースラインは変更できないが、カスタムベースラインを作成することができる
OSごとにデフォルトのベースラインを設定できる
1つのパッチベースラインに複数のパッチグループをアタッチすることができる

パッチグループ

インスタンスと特定のパッチグループの関連付けを行うためのコンポーネントである
1つのパッチグループには複数のOSのEC2インスタンスを所属させることができる
1つのパッチグループを複数のパッチベースラインにアタッチすることができるが、OSごとに1つまでである
パッチグループにEC2インスタンスを所属させない状態も取りうる
どのパッチベースラインにも登録しない状態でパッチグループを作成することはできない
1台のインスタンスを複数のパッチグループに所属させることはできない

Maintenance Windows

予定されたパッチ適用やリソースの保守作業を自動化するためのサービス
指定された時間帯に、指定したリソースグループに対して一括でアクションを実行できる。
基本的にはPtachManagerとセットで使用する。

Automation

EC2やほかのAWSリソースに対する運用やデプロイ作業を自動化するための機能
Automationを使うときにはRunbookと呼ばれるDocumentsを作成する
Run CommandはEC2内部でのコマンド実行を行うが、
Automation RunbookはAWSのAPIの実行も可能。
自動化だけではなく定型作業をRunbookに記載しておき、必要な時にはAutomationを実行するという使い方も可能。

AWS Systems Manager Hybrid Activations

オンプレミスや他のクラウドプロバイダで実行されているサーバーや仮想マシン（VM）を、AWS Systems Managerで管理できるようにするための機能。
この機能により、AWS以外の環境にあるインスタンスも、AWSのインスタンスと同様に管理、監視、および運用することが可能になる。

Hybrid Activationsを設定する流れ
1. AWS上でのHybrid Activationを作成する
2. 対象サーバへSystems Managerエージェントをインストールする
3.SSM Agentをインストールした後、アクティベーションIDとアクティベーションコードを使用してサーバーをSystems Managerに登録する

StatusCheckFailed_System

AWSの基盤に問題があり発生
システムステータスチェックの失敗の原因となる問題の例を次に示します。

・ネットワーク接続の喪失

・システム電源の喪失

・物理ホストのソフトウェアの問題

・ネットワーク到達可能性に影響する、物理ホスト上のハードウェアの問題

StatusCheckFailed_Instance

ユーザー側で行った操作や設定が原因で発生している問題が検出
インスタンスステータスチェックの失敗の原因となる問題の例を次に示します。

・失敗したシステムステータスチェック

・正しくないネットワークまたは起動設定

・メモリの枯渇

・破損したファイルシステム

・互換性のないカーネル

procstatプラグイン

指定したプロセスの監視を行いそのメトリクスをCloudwatchに送信する。

Tag Editor

AWSリソースにタグを一括で付与、編集、削除するためのツール。タグはリソースの分類や管理、コスト配分のために重要なメタデータである。Tag Editorを使用することで、複数のリソースに対して効率的にタグを操作することができる。

この記事が気に入ったらサポートをしてみませんか？