エンジニアとして日々新しい知識をインプットしています。現在の職場には、毎日の終業時に日報を提出する文化があり、その中に「本日発見したこと・気づいたこと」を記載する欄が設けられています。私はこの欄を、業務で得た新しい知見や、業務外の自己学習で学んだことを記録するアウトププットの場として活用しています。この記事は、その日々の学びを知識として定着させ、いつでも振り返れる資産にするために、1ヶ月分をまとめたものです。
2025-11-4
Terraform でルートテーブルを管理する際、local ルートはTFで管理する必要がないことを知りました。
localルートは以下の理由から、Terraformの管理対象外となる。
1. AWSによる自動管理： local ルートは、ルートテーブルが作成されると同時にAWSによって自動的に追加される。Terraformが作成する必要がない
2. 変更・削除が不可能： AWSの仕様として、この local ルートは変更も削除も許可されていない。Terraformはリソースの状態をコードと一致させようとするが、localルートに関してはTerraformが介入できる余地がない
3. 宣言的インフラの性質：Terraform は「あるべき姿」を宣言する。VPC内の通信はVPCの基本的な機能であり、localルートはその機能を担保するためにAWSが「常にあるべきもの」として強制している。そのため、ユーザーがTerraformで「localルートがあるべき」と宣言するまでもなく、すでに存在が保証されている
localルートは、AWSによって自動的に作成され、変更・削除が許可されていない暗黙的なルートである。
2025-11-5
Terraform の count メタ引数について知ることができました。
count メタ引数とは、そのリソース（またはモジュール）のインスタンスをいくつ作成するかを制御する
・count = 0: Terraformは0個のインスタンスを作成する。つまり、リソースは作成されない
・count = 1: Terraformは1個のインスタンスを作成する。
コード例
resource “aws_network_acl” “this” {
count = var.is_default ? 0 : 1
vpc_id = var.vpc_id
tags = local.tags
}
2025-11-6
cloudformation において、AWS::ApplicationAutoScaling::ScalableTarget 内 の ScheduledActions プロパティに関して知見を得ることができました。
・これは、指定した時刻にスケーラブルターゲットの Min/Max（許容レンジ）を切り替える仕組み
・Min=Max にすると desiredCount をその数に固定、Min≦Max ならターゲットトラッキング等がその範囲で自動調整される
・スケジュールは cron/rate/at で書き、既定は UTC（必要に応じて Timezone: Asia/Tokyo などを指定）
・アクション名は重複不可
・実運用では、日中は Min=4, Max=10（必要なら伸ばす）／夜間は Min=Max=1（固定）のように時間帯でレンジを切り替えるのが有効
2025-11-7
Gateway型VPCエンドポイントとルートテーブルの関連付けは、VPCエンドポイントリソース側で管理する必要があることを知りました。
– aws_vpc_endpointリソースのroute_table_idsパラメータと、aws_vpc_endpoint_route_table_associationリソースは併用できない
– 両方を同時に使用すると競合が発生し、Terraformが意図しない変更を試みる
– VPCエンドポイントをimportする際、route_table_idsが空だとAWS上の既存の関連付けを削除しようとする
– 既存のaws_vpc_endpoint_route_table_associationをTerraform管理していた場合、terraform state rmでstateから削除する必要がある
– AWS公式ドキュメントでも、Gateway型エンドポイントはroute_table_idsでの管理が推奨されている
– この設計により、VPCエンドポイント1つのリソース定義で関連付けを一元管理でき、よりシンプルになる
2025-11-12
下記モジュール分離の方針を知ることができました
1. DB Subnet Group は独立した小さなモジュールを作成
理由
・DB Subnet Group はクラスター・インスタンスとは独立したライフサイクルを持つ
・複数のクラスターで共有される可能性がある
・ネットワーク系リソース（subnet）への依存があるが、RDS 特有のロジックは少ない
2. RDS Cluster と Instance は別の大きなモジュールを作成
理由
・Cluster と Instance は密接に関連しているため、同一モジュール内で管理
・Parameter Group もクラスターと一緒に管理するのが自然
2025-11-13
Terraform における dynamic ブロックについて理解することができました。
・dynamic ブロックとは、Terraform で繰り返し構造を動的に生成するための機能
・同じ種類のネストされたブロックを複数作りたい場合に使う
2025-11-14
EFS のファイルシステム、アクセスポイント、マウントターゲットは、1つのモジュールにまとめるべき理由について知ることができました。
・強い依存関係：マウントターゲットとアクセスポイントはファイルシステムなしでは存在できない
・ライフサイクルの一致：同時に作成・削除されることが多い
・設定の一貫性：1箇所で全ての設定を管理できる
・シンプルさ：RDSのようにインスタンスを独立管理する必要がない
2025-11-17
EFSのマウントターゲットに関して、下記を知ることができました。
・AZ毎に1つずつマウントターゲットを設置
・各AZ内に複数サブネットがあっても、代表的な1つのサブネットにマウントターゲットを配置すれば良い
・VPCのルーティングによって、マウントターゲットが配置されていない同じAZ内の他のサブネットからも、１つのマウントターゲット経由でアクセス可能
2025-11-18
AWS EFS の creation_token について知ることができました。
・creation_token とは、同じリクエストを何度送ってもファイルシステムが重複して作られないようにするための一意な文字列（トークン）
・EFS を API / CLI / SDK から作成するときに指定する。コンソールから作る場合は裏側で AWS が自動的に生成してくれる
（役割）
creation_token の一番の役割は冪等性の保証。同じ AWS アカウント + 同じリージョンで CreateFileSystem を同じ creation_token で呼び出すと、
・まだ対応するファイルシステムがなければ → 新しく 1 個作成
・すでにそのトークンで作られたものがあれば → 新規作成せず、既存のファイルシステム情報を返す
そのため、ネットワーク再送やリトライ処理をしても、意図せず EFS が 2 個作成されるという事故を防げる
（一意性のルール）
・アカウント + リージョンの組み合わせの中で一意である必要がある
・一般的には UUID を使うのが鉄板
（一度作ったあとの扱い）
creation_token は、ファイルシステム作成時にだけ使う値で、作成済み EFS の設定画面で見たり編集したりする項目ではない。「後から変える」ということもできない（そもそも用途的に不要）
2025-11-19
Terraform におけるデフォルトネットワークACLリソース（aws_default_network_acl）とカスタムネットワークACLリソース（aws_network_acl）で扱える属性が異なることを知りました。
属性 aws_default_network_acl aws_network_acl
ingress 存在（インライン定義可） 存在しない
egress 存在（インライン定義可） 存在しない
subnet_ids 存在（インライン定義可） 存在しない
つまり、aws_network_acl は NACL 本体のみを作成でき、ルールは必ず別途 aws_network_acl_rule リソースで定義する必要がある。また、サブネットの関連付けに関しても、必ず aws_network_acl_association で定義する必要がある。
2025-11-20
AWS CloudWatch の複合アラームについて知ることができました。
複合アラームとは、複数の CloudWatch アラームを組み合わせて「条件式」で判定するアラームのこと
（普通のアラームとの違い）
・通常のアラーム
・1つのメトリクス（例：CPU使用率、Lambdaのエラー数、HTTP 5xx数など）に対して「80%以上が5分続いたらアラーム」みたいな単体条件で動く
・複合アラーム
・既存のアラームを部品として組み合わせる
（メリット）
１、ノイズ削減（本当にやばいときだけ通知）
・CPUだけ高い、5xxだけ出ている…などの「一時的な・軽い異常」には反応せず、「複数の重要アラームが同時に鳴っているときだけ」Slack / SNS に通知、などの運用をとれる
・例：「EC2 CPU使用率 > 80% で発火するアラームA」、「ALB の 5xx > 10 で発火するアラームB」が存在する状況で、ALARM_A AND ALARM_B という条件の複合アラームC
２、複雑な論理条件が書ける
・AND / OR / NOT を組み合わせて条件式を作れる
３、運用設計がしやすくなる
・致命的インシデント時だけ PagerDuty で起こす、軽微なアラートはログだけ残す、という感じで通知先・エスカレーションの分離がしやすい
・メンテナンス中はアラート抑制とかもできる（メンテナンス中を示すダミーのアラームを組み合わせる）
（注意点）
・複合アラームはメトリクスを直接見るのではなく、「他のアラームの状態」を見る。なので、まず元になる通常アラームを正しく作る必要がある
・アクション（SNS通知など）は基本的に「複合アラーム側」に設定する
・元アラームが多くなりすぎると条件が分かりづらくなるので、命名と設計ルールを決めておくと良い
2025-11-27
KMS > AWSマネージド型キーは、Terraformのリソースとして管理すべきではなく、dataソースで参照するのがベストプラクティスであることを知りました。
Terraformのリソースとして管理すべきではない理由
・管理不可能：AWSマネージド型キーは、ローテーション, 削除, キーポリシーの変更などができないため、Terraformのリソース（resource “aws_kms_key”）として定義しても意味がない
・所有者はAWS：これらのキーはAWSサービスが自動的に作成・管理するもので、ユーザー側で制御できない
・ライフサイクル管理不可：Terraform destroyやapplyでキーを削除・再作成することもできない
推奨アプローチ：dataソースで参照
・AWSマネージド型キーは、エイリアス名を使って動的に参照するのがベストプラクティス
dataソースのメリット
・可読性向上：ARNをハードコードするより意図が明確
・リージョン間の移植性：別リージョンにデプロイする際もARNを変更不要
・マルチアカウント対応：異なるAWSアカウントへの展開が容易
・保守性：エイリアス名の方が何のキーか理解しやすい
・テスト環境での柔軟性：開発環境では別のキーを使うなどの切り替えが容易
2025-11-28
AWS DocumentDB では、インスタンス用の個別のDBパラメータグループは存在しないことを知りました。（クラスターパラメータグループのみ）