AWS 個人的豆知識集

仕事を通じて得た学びを
言語化を通じた質の向上/備忘 を兼ねて編集する

CloudWatchのMetricsの体系図

• Namespace、Dimensions、MetricName の3つで構成される
• この3要素の組み合わせによって、はじめて1つのメトリクス（Metric）が一意に定義される
• 管理画面では以下のような階層構造で確認できる

CloudWatch
└── Namespace（例: AWS/EC2）
    ├── Dimensions（例: InstanceId=i-abc123）
    │    ├── MetricName: CPUUtilization
    │    │    └── Datapoints（平均/最大/合計など）
    │    │    └── Alarm（しきい値超過で発火）

各要素がもつ意味合い

要素	意味（ざっくり）	ニュアンス・例え
Namespace	メトリクスのグループ名。どのシステム・サービスで発生したデータかをまとめる箱。	「どの世界の話か」例：AWS/EC2,
Dimensions	メトリクスを区別するタグ。どのリソース・条件・環境のデータかを特定する。	「何を軸に分けるか」例：InstanceId=i-1234,
MetricName	測っている項目そのもの。数値データの種類を示す。	「何を測っているか」例：CPUUtilization, Latency, ErrorRate

注意点

• 自分で定義したメトリクス（＝カスタムNamespace）は、CloudWatch上でどのような条件で記録されているかを直接確認することはできない。
• そのため、メトリクスの**トレーサビリティ（追跡性）**を担保するには、以下のような工夫が必要。
  • Namespace や Dimensions に リソースや環境名などの識別情報 を含める。
    例: Custom/MyApp, Env=prod, Service=api
  • CloudTrail で PutMetricData イベントの記録を有効にし、
    どのIAMユーザー・ロール・アプリがメトリクスを送信したか追跡できるようにする。

セキュリティにおけるWAFvsSG

想定シナリオ
あるAPIサーバーを以下のようにホスティングしている→ https://hogehoge//api

R53 -> (WAF) -> ALB(sg_alb) -> ECS(sg_ecs)
※ WAFは必須ではない

各防御層の役割

• WAF: botやDoS攻撃を防ぐ
• sg_alb: リソースの特定のプロトコルとポートだけ許可する
• sg_ecs: 内部からの通信のみ許可する

防御イメージ

• botからのhttps://hogehoge//apiへのrequest -> WAFが防ぐ
• XXX....(ALBの実アドレス):3000へのrequest → sg_albが防ぐ
• 不正侵入されたVPCリソースからのrequest -> sg_ecsが防ぐ

Memo

WAFはつけているだけでは効果がない
→ マネージドのルールをつけないとbotやDoS対策は機能しない

WAFでのちょっとした認証
waf では header の中身の基づいた制御ができる。
つまり、 header に　Bearer xxxx を含んだら Allow
みたいな制御をすれば簡易的な Basic 認証となる

SGの構成

• inbound_rulesとoutbound_rulesからなる
• 一致する通信だけを許可する。一致しないものは暗黙的にブロックする
• ruleの構成要素: Source, (Type), Protocol, Port Range

例
InboundでSource: 0.0.0.0/0, Protocol: TCP, Port Range: 80の場合
0.0.0.0/0(全世界)からのTCP: 80の通信を許可する。という動作になる

IAMユーザー vs IAMロール

IMMユーザーは人間に対して紐づける
IAMロールはリソースに対して紐づける

IAMユーザーは恒久的なアイパスがある。ロールはない。
IAMユーザーの恒久的なアイパスを使用した認証認可は原則するべきでない

IAMロールは、どのIAMユーザーが自分をAssumeするか(trust policy)指定できる
IAMユーザーは、自分がどのロールをAssumeするか(permission policy)宣言できる
(Assume: 引き受ける)

IAMユーザー vs SSOユーザー

(SSO: Single Sign On)

SSOユーザーは外部IdP(+MFA)で認証し、 Identity Center経由でログインする。

ロールを通してAWSを使う。恒久的なアイパスはない。

代わりにPermission Setがある。
Permisson Set は ReadOnly/PowerUser/AdministratorAccess などがあり、
ログイン時は Permission Set に基づいたロールを Identity Center が生成(SSOロール)し、
ログインしたユーザーは SSOロール を Assume する

SSOロールが Assume できる IAMロールは、
IAMロール側の “trust policy” が「このSSOロールを信頼します」
と宣言することで決まる。

SSOロールが私はこのIAMロールを Assume できます。
と宣言することはない。

具体例

あるローカルのリソース(コンテナ等)に認証情報を注入して
AWSのリソースに対して何某かをしたい

梅:

手順

• IAMユーザーの認証情報を.aws/credentialや.envに保存する
• ファイルの認証情報をリソースに注入する

特徴

• ファイル(長期キー)が漏洩すると即死

---

竹(IAMユーザー):

手順

• IAMユーザーの認証情報を.aws/credentialや.envに保存する
• sts:GetSessionTokenで短期クレデンシャルを生成
• 一時クレデンシャル(IAMユーザー)をリソースに注入

特徴

• 長期キーを漏洩するリスクが梅より低い
• 一時クレデンシャル漏洩時のリスクが大きい

---

松(IAMユーザー)

事前準備

• 要件に対して最小権限をもつIAMロール(read-only)を作成
• ユーザーとロールの信頼関係(Assume)を適切に設定

手順

• IAMユーザーの認証情報を.aws/credentialや.envに保存する
• IAMユーザーが read-only を AssumeRole
• 一時クレデンシャル(IAMロール)をリソースに注入

特徴

• 一時クレデンシャル漏洩時のリスクが小さい

---

竹(SSOユーザー)

手順

• SSOでログイン
• ログインに伴い、PermissionSetの基づいたロール(SSOロール)のSTSが発行される
• 自動生成されるSTS(SSOロール)をリソースに注入する

特徴

• 長期キーが存在しない
• STSが漏洩時のリスクが大きい

---

松(SSOユーザー)

手順

• SSOでログイン
• 専用のロール(Read-only)をAssume
• 生成されたSTS(Read-onlyロール)をリソースに注入する

特徴

• 長期キーが存在しない
• STSが漏洩しても最小の権限しかもってない

実行例

竹(IAMユーザー)

aws sts get-session-token --profile my-user
docker run ...

---

松(IAMユーザー)

aws sts assume-role --role-arn xxxx --profile xxx
docker run -e ...

---

竹(SSOユーザー)

aws sso login --profile userA
docker run ...

---

松(SSOユーザー)

aws sso login --profile userA

creds=$(aws sts assume-role \
  --role-arn arn:aws:iam::123:role/read-only-role \
  --profile userA \
  --query "Credentials" \
  --output json)

docker run \
  -e AWS_ACCESS_KEY_ID=$(echo $creds | jq -r ".AccessKeyId") \
  -e AWS_SECRET_ACCESS_KEY=$(echo $creds | jq -r ".SecretAccessKey") \
  -e AWS_SESSION_TOKEN=$(echo $creds | jq -r ".SessionToken") \
  my-container

aws event bridge vs config

有効化のしかた

• event bridge: 飛んでくる大量のイベントの中から、どれを扱うか『ルールでフィルタ宣言』する。と宣言する
• config: このregionのイベントを管理します。と宣言する

よって

• EventBridge には証跡（イベント）がある
• Config には証跡（構成履歴）がない

という事象が生じうる

実例として、Cloudfrontに紐づいているipsetsの更新について
(regionが自動でus-eastになる)
EventBridge にはログがあるが、Config にはない。
とういう状況になっていた

管理する情報の違い

• EventBridge: 監査系に近い。誰が何をしたか
• AWS Config: イベントの詳細や構成

目的	EventBridge	AWS Config
何を見たい？	誰が / いつ / どの API を実行した？（操作ログ）	リソースの構成がどう変わった？（構成ログ）
ログの種類	イベント（API の実行通知）	Configuration Item（リソースの状態）
更新された時に分かること	イベントが実行された事実	イベントの詳細や差分
有効化	基本自動（CloudTrail連携でイベントが飛んでくる）	リージョンごとに手動で ON が必要