エンジニアとして日々新しい知識をインプットしています。現在の職場には、毎日の終業時に日報を提出する文化があり、その中に「本日発見したこと・気づいたこと」を記載する欄が設けられています。私はこの欄を、業務で得た新しい知見や、業務外の自己学習で学んだことを記録するアウトププットの場として活用しています。この記事は、その日々の学びを知識として定着させ、いつでも振り返れる資産にするために、1ヶ月分をまとめたものです。
2025-8-1
TerraformでPolicy as Codeを実現するための主要なツールの１つである Terraform Cloud/Enterprise (Sentinel) について知ることができました。
・Sentinelは、HashiCorpが開発した独自のポリシー記述言語およびフレームワーク
・Terraform Cloud および Terraform Enterpriseの有償プランに組み込まれており、Terraformの実行ライフサイクルに深く統合されている
特徴① きめ細かな制御：terraform plan や terraform apply の実行中、特定のタイミングでポリシーを評価可能。例えば「コストが月額$500を超えるリソースの作成を禁止する」といったコストに基づいた制御や「特定のインスタンスタイプ以外は許可しない」といった構成内容の制限が可能
特徴② 柔軟なポリシー言語：Sentinelは独自の言語を採用しており、プログラミング言語のように変数や関数、ループを使って複雑なロジックを記述できる
特徴③ 実行モード：ポリシー違反時に警告のみを出す「Advisory（助言）モード」、実行を完全に停止する「Hard-mandatory（強制）モード」、管理者の承認があれば続行できる「Soft-mandatory（柔軟な強制）モード」など、柔軟な強制レベルを設定できる
ユースケース
・組織全体のセキュリティポリシー（例：特定のポートを開放しない、暗号化が有効になっているか確認）の強制
・コスト管理（例：高価なリソースタイプの使用制限）
・コンプライアンス遵守（例：特定のリージョンでのみリソース作成を許可）
2025-8-4
TerraformでPolicy as Codeを実現するための主要なツールの１つである tflint について知ることができました。
・tflint は、Terraformのコード（.tfファイル）を静的に解析するためのlinterツール
・OSSとして提供されており、CI/CDパイプラインの早い段階で問題を検知するのに役立つ
特徴① ベストプラクティスとエラーの検知：非推奨の構文、未使用の変数宣言、プロバイダー固有の潜在的なエラー（例：存在しないインスタンスタイプを指定）などを検出する
特徴② プラグインによる拡張性：AWS、Azure、Google Cloudなど、各クラウドプロバイダー向けのルールセットがプラグインとして提供されており、必要なルールを追加できる。またカスタムルールを自作することも可能。
特徴③ 導入の容易さ：バイナリをダウンロードして設定ファイル（.tflint.hcl）を記述するだけで、ローカル環境やCI/CDですぐに利用を開始できる
ユースケース
・コーディング規約の統一（例：命名規則のチェック）
・意図しないエラーの早期発見
・クラウドのベストプラクティスに沿っているかの確認
2025-8-5
TerraformでPolicy as Codeを実現するための主要なツールの１つである Open Policy Agent (OPA) について知ることができました。
・OPAとは、Cloud Native Computing Foundation (CNCF) の卒業プロジェクトであり、汎用的なポリシーエンジン
・Terraformに限定されず、Kubernetesやマイクロサービスなど、さまざまなシステムでポリシーを統一的に管理できる
特徴① 汎用性と宣言的な言語：Regoという宣言型のクエリ言語を使用してポリシーを記述する。Terraformのplan結果をJSON形式に変換し、そのJSONデータを入力としてOPAが評価を行う
特徴② デカップリング：ポリシー決定ロジック（OPA）と、ポリシーを強制するシステム（Terraform）が分離されている。これにより、ポリシーを組織全体で一元管理しやすくなる
特徴③ 柔軟な連携：terraform plan -out=tfplan.binary でプランをファイルに出力し、terraform show -json tfplan.binary でJSONに変換後、opa eval コマンドで評価するのが一般的な連携方法
ユースケース
・複数の技術スタック（Terraform, Kubernetesなど）で一貫したポリシーを適用したい場合
・Rego言語による標準化されたポリシー管理を目指す組織
・特定のタグが付与されているかを全リソースで強制するなど、組織横断的なルールを適用したい場合
2025-8-6
SSM Run Commandの対象は、EC2インスタンスに限定されないことを知りました。
以下の環境にあるサーバーも管理対象にできる
① オンプレミスサーバー：自社のデータセンターなどで稼働している物理サーバーや仮想サーバー
② 他のクラウドプロバイダー上の仮想マシン：例えば、AzureやGoogle Cloud Platform上で動作しているVM
これらのEC2インスタンス以外のサーバーをSSMで管理するためには、SSM Agentというソフトウェアを対象サーバーにインストールし、AWSと通信できるように設定する必要がある。この設定が完了すれば、それらのサーバーは「マネージドインスタンス」として認識され、Run Commandの実行対象となる。
2025-8-7
ECSサービスのAuto Scalingは、高負荷によるスケールアウトだけではなく、コスト削減に向けた低負荷によるスケールイン（タスク削減）の試みも行うことを知りました。
2025-8-8
AWS SESのサンドボックス環境について知ることができました。
AWS SESのサンドボックス環境とは、すべての新規ユーザーが最初に配置される制限付きの利用環境。これはスパムや不正行為を防ぎ、AWSの高い送信レピュテーション（信頼性）を維持するために設けられている。サンドボックス環境では、本番環境と同等の機能をお試しで利用できるが、メールの送信にはいくつかの重要な制限がある。
サンドボックス環境の主な制限は下記の通り。
制限① 送信先の制限：検証済みのEメールアドレスまたはドメインにのみメールを送信可能。具体的には、事前にSESで所有権を確認したアドレスやドメイン以外には送信できない。Amazon SESのメールボックスシミュレーターも利用可能
制限② 送信数の上限：24時間あたり200通までしかメールを送信できない。この上限はローリング方式で計算される
制限③ 送信レートの上限：1秒あたりに送信できるメッセージは1通まで
これらの制限により、サンドボックス環境のままでは、不特定多数のユーザーへのメールマガジン配信などの本番運用は事実上不可能。サンドボックスとは「IPレピュテーションスコアが低い（または未知の）状態から始まり、適切な運用とユースケースをAWSに提示することで、徐々に信頼を得て、いざ本番環境でグローバルにメールを送信できるようになる」ためのステップ。
2025-8-12
CICD環境で使い回す依存パッケージなどは、キャッシュしておくことで毎回のワークフロー実行時に都度インストールする必要がなくなり、ワークフロー実行時間の短縮などのメリットがあるかと思います。このときキャッシュキーにランナーOS情報を含めておくと、キャッシュがOS別管理となるため良いみたいですが、では具体的にどういった点で良いのか気になったので調べてみました。
1. プラットフォーム差異：パス区切り、改行コード、シンボリックリンク、実行ビット、ファイル属性などがOSごとに異なるため、Windowsのvendor/をLinuxで使うといったことは壊れやすい
2. ネイティブ依存の混入回避：例えばPHP自体はバイトコード配布が中心でも、パッケージ内にプラットフォーム依存のバイナリ／スクリプトが含まれる場合があり得る（ツール類、PHARの実行属性、ビルド成果物など）。OS混在は不具合の温床。
3. 将来の拡張にも強い：今は PHP だけでも、同一ワークフローで node_modules や OS 依存のビルド物もキャッシュしたくなることがある。OS 分離は普遍的なベストプラクティス
2025-8-13
AWS App Meshについて知ることができました。
AWS App Meshとは、マイクロサービス間の通信を標準化し、監視・制御を容易にするサービスメッシュ。アプリケーションのコードを変更することなく、通信の信頼性と可観測性を向上させることができる。Amazon ECS、Amazon EKS、AWS Fargate、Amazon EC2など、様々なコンピューティングサービス上で動作するアプリケーションに対応している。アプリケーションの横に配置される「Envoy」という軽量なプロキシを通じて、主に下記3つの機能を提供する
① トラフィック制御：リクエストのルーティングを柔軟に制御する
（具体例）
・カナリアリリースやA/Bテストのための重み付けルーティング
・リクエストのパスやヘッダーに基づいたルーティング
・障害発生時に自動的に通信を遮断するサーキットブレーカー
② 可観測性：サービス間の通信に関するメトリクス、ログ、トレースを一元的に収集する
（具体例）
・各サービスのエラー率やレイテンシーなどのメトリクスを収集し、Amazon CloudWatchで可視化
・AWS X-Rayと連携し、リクエストの処理経路をトレース
・詳細なアクセスログの出力
③ セキュリティ：サービス間の通信を保護する
（具体例）
・mTLS（相互TLS）による通信の暗号化
・AWS Certificate Manager (ACM) と連携し、証明書の管理を自動化
2025-8-14
AWS App Mesh の仕組み、利点、ユースケースについて知ることができました。
仕組み
・App Meshは、各マイクロサービス（コンテナやEC2インスタンス）にEnvoyプロキシをサイドカーとしてデプロイする
・このEnvoyプロキシが、サービス間のすべての通信を仲介する
・App Meshは、これらのEnvoyプロキシを一元的に管理・設定するコントロールプレーンとして機能する
・開発者はアプリケーションのビジネスロジックに集中でき、通信制御や監視といった機能はApp MeshとEnvoyプロキシに任せることができる
利点
・アプリケーション開発の簡素化：通信制御のための複雑なライブラリをアプリケーションコードに組み込む必要がなくなる
・高い可観測性：アプリケーション全体で一貫した方法でログやメトリクスを収集できるため、問題の特定やトラブルシューティングが容易になる
・柔軟なデプロイ戦略：トラフィックを細かく制御できるため、新機能のリリースリスクを低減できる
・セキュリティの向上：mTLSによって、サービス間の通信を簡単に暗号化できる
・マネージドサービス：AWSがコントロールプレーンを管理するため、運用負荷が軽減される
ユースケース
・マイクロサービスアーキテクチャを採用しているアプリケーションの通信管理
・カナリアリリースやA/Bテストの実施
・サービス間の依存関係や通信状況の可視化
・障害発生時の原因究明と迅速な対応
2025-8-15
Terraform から cloudformationスタックそのものを作成、更新できることを知りました。
aws_cloudformation_stack / stack_set を使えば、Terraform から cloudformationスタックそのものを作成、更新できる。Terraform が追跡するのは スタック単位。スタック内の個々のリソース差分は cloudformation 側の領分。二重管理はNG。同じ実体を cloudformation（SAM/CDK 含む）と Terraform 個別リソースで 併用管理しない。責務は明確に分ける。連携方法として、cloudformation の Outputs/Exports を Terraform の data source（aws_cloudformation_stack / aws_cloudformation_export）で参照すると安全。
2025-8-19
Terraformへの移行に関して、まずはどこから手をつけるべきか不明でしたが、まずはS3バックエンドの用意から進めるのが良いことを知りました。
最初はローカル backend で tfstate 用 S3 バケットを Terraform で作成。その後 terraform init -migrate-state で S3 backend へ移行（DynamoDB ロック不要／use_lockfile=true を使う）。
2025-8-20
下記を知ることができました。
・.terraform/ はローカルキャッシュ
・.terraform.lock.hcl はプロバイダ版固定＋ハッシュ
・S3に置くのは state だけ
2025-8-21
Terraformにおいて、outputブロックを使った値の出力と取得について理解することができました。
・terraform output で取り出せるのは、ルートモジュールで宣言した output だけ
・値は AWS へ問い合わせず、state（tfstate）に保存された output 値を表示する
・output は apply時に評価され、state の outputs に記録される
・子モジュールの出力はルート側で再露出が必要
2025-8-22
S3オブジェクトを使ったTerraformのロック機構について知見を深めることができました。
・S3のリーガルホールドやバケットロック機能ではなく、stateと同じキーに対する隣接ロックファイル（例：staging/bootstrap.tfstate.tflock）をTerraformが自動で作成＆削除して排他制御を行う。
・stateファイル単位でのロック。staging/bootstrap.tfstateのロックは、その隣の staging/bootstrap.tfstate.tflock によって制御される。バケット全体をロックするわけではない。stateファイル単位でのロックのため、他の.tfstateには影響しない。
・他の実行がロックを取りに来たときは、Terraform が S3への原子的なPut（存在しない時のみ作成）を試み、既に .tflock があれば 待機→再試行（またはタイムアウト）する。
・コマンドが正常終了/失敗で抜けると、Terraform が .tflock を自動削除＝ロック解放をする。
・途中クラッシュ等でロックが残った場合のみ、terraform force-unlock
・Terraform本体がコマンド実行時に自動でロックを取得, 待機, 解放をやってくれる。AWSがコマンド実行を検知してロックするわけではない。
・plan / apply / state 系コマンド（state を扱う操作）は、基本ロックを取りに行く（競合を避けるため）。取得できない場合は、待機または失敗する（ -lock-timeout=30s などで待機時間は延ばせる）。強制スキップは -lock=false だが、非推奨（競合・破損のリスク）
2025-8-25
.tfstate はGitで無視するのが一般的であることを知りました。理由は２つ。
1. 機密の混入リスク：state にはリソースIDやARN、出力値、時に機微情報（パスワード等の属性値）が含まれることがある
2. 単一の真実源：state は リモートバックエンド（S3 等）で一元管理するのがベストプラクティス。Git に置くと分岐・衝突・破損の温床になる。
2025-8-26
.tfファイル と .tfvarsファイルそれぞれの自動読み込みについて知ることができました。
.tfファイルについて：ルートモジュール直下の全ての *.tf / *.tf.json が自動で読み込まれる。ファイル名や分割は自由。
.tfvarsファイル：ルートモジュール直下の terraform.tfvars、*.auto.tfvars（複数可、辞書順で読み込み）、それぞれの .json版（ terraform.tfvars.json / *.auto.tfvars.json ）が自動で読み込まれる。それ以外のファイル名（例：staging.tfvars ）は自動で読み込まれない（読み込みたいときは、-var-file=staging.tfvars を付ける）。
優先度（上ほど強い）
1、CLI の -var / -var-file（最優先、複数指定時は後からの指定が優先）
2、*.auto.tfvars / *.auto.tfvars.json（辞書順で後勝ち）
3、terraform.tfvars / terraform.tfvars.json
4、環境変数 TF_VAR_
5、変数の default 値（ variables.tf ）
2025-8-27
Terraformにおいて、ドリフトを検知する方法を知ることができました。
1、手元で（スポット）
# 通常の差分検出（実環境を読み直し）
terraform plan -detailed-exitcode
# exit code: 0=差分なし / 2=差分あり / 1=エラー
# 「実環境→state だけ更新」（構成は一切変えない）
terraform plan -refresh-only -out=drift.plan
terraform show -no-color drift.plan # 何がズレているか一覧
-refresh-only は “変更を加えず、stateを最新の実態に合わせる” モード。
この後 terraform apply -refresh-only を実行すると state だけ更新（クラウドへは何もしない）。
その上で、コードを直すのか、実環境を戻すのかを決めると見通しが良い。
2. CIで（継続）
・毎日/毎時間に plan -refresh-only -detailed-exitcode を実行 → exit 2 で通知（Slack/メール）。
・PR時は通常どおり plan を出してレビュー（差分が見える）。
2025-8-28
Terraformにおいて、ドリフト発生後のケース毎の適切な対応を知ることができました。
1、属性が手で変えられた → コードを正として戻すなら terraform apply（実環境をコードへ収束）。手の変更を採用するなら HCLを修正 → plan で0に。
2、新しい手作成リソースが増えた → HCLを追加して import（未管理 → 管理下へ）
3、管理中のリソースが手動で削除 → 再作成が正なら apply（再作成）。不要になったなら HCLを削除して apply（破棄）or terraform state rm（追跡だけ外す）
2025-8-29
今後、IaC（Terraform）でインフラリソースを管理していくにあたって、コンソール操作によるドリフトを起こさない仕組みの例を知ることができました。
IAM/SCPでガード
・「特定のロール経由（CIロール）以外は更新不可」にする（例：SCP で Deny except aws:PrincipalArn が CI ロール など）
・ReadOnly 権限の運用者ロールを配布、更新は PR→CI のみに集約
可視化＆警報
・CloudTrail + EventBridge：更新APIを検知して Slack 通知（例：s3:PutBucket*, iam:UpdateRole* など重要系）
・AWS Config：ポリシーから外れた設定を検出（公開バケット等）
プロセス
・すべての変更は PR → plan レビュー → main マージ → apply（承認付き） を徹底