Posts on 図解わかりやすいAWS

Claude Managed Agents — Anthropicが提供するフルマネージドAIエージェント基盤

Thu, 09 Apr 2026 00:00:00 +0000

何を解決するサービスか

一言で: 「本番AIエージェントに必要なインフラを全部Anthropicがホストしてくれるサービス」

エージェントを本番運用するには、サンドボックス実行環境・状態管理・クレデンシャル管理・スコープ付き権限・エンドツーエンドのトレーシングなど、数ヶ月分のインフラ構築が必要になる。Managed Agentsはこれを丸ごと引き受けて、ユーザーは「エージェントのロジック」だけに集中できるようにする。

2026年4月8日にパブリックベータとして発表された。

具体的な利用イメージ

例: セキュリティアラート分析エージェント

GuardDutyが不審なAPI呼び出しを検知した。このアラートを受けて自動で調査し、レポートを出すエージェントを作りたいとする。

自前で構築する場合（従来）:

Lambda or ECSでエージェントの実行環境を作る
Claude APIを呼ぶエージェントループを自前実装（リトライ、タイムアウト、コンテキスト管理…）
エージェントがaws cliやpythonスクリプトを実行するためのサンドボックスを構築
AWSクレデンシャルの安全な受け渡し機構を実装
エージェントの実行ログ・トレーシングを仕込む
途中で落ちた場合の復旧処理を書く

→ 数ヶ月のインフラ構築

Managed Agentsを使う場合:

# 1. エージェントを定義（1回だけ）
agent = client.beta.agents.create(
 name="Security Analyst",
 model="claude-sonnet-4-6",
 system="""あなたはAWSセキュリティアナリストです。
 アラートを受け取ったら以下の手順で調査してください:
 1. CloudTrailログを分析し、不審なAPI呼び出しの詳細を特定
 2. 関連するIAMユーザー/ロールのアクティビティを確認
 3. 影響範囲を評価
 4. 調査結果をMarkdownレポートとしてまとめる""",
 tools=[
 {"type": "agent_toolset_20260401"}, # bash, ファイル操作等
 {"type": "custom", "name": "send_slack", # Slack通知（自前実行）
 "description": "Slackチャンネルにメッセージを送信",
 "input_schema": {...}},
 ],
)

# 2. 実行環境を定義（aws cli入り）
environment = client.beta.environments.create(
 name="security-env",
 config={"type": "cloud", "networking": {"type": "unrestricted"}},
)

# 3. アラートが来たらセッションを起動
session = client.beta.sessions.create(agent=agent.id, environment_id=environment.id)

# 4. アラート内容を渡す → あとはエージェントが自律的に調査
client.beta.sessions.events.send(session.id, events=[{
 "type": "user.message",
 "content": [{"type": "text", "text": f"以下のGuardDutyアラートを調査してください:\n{alert_json}"}],
}])

エージェントはコンテナ内でaws cliを実行し、CloudTrailを検索し、Pythonでログを集計し、Markdownレポートを生成する。すべてAnthropicのインフラ上で動く。コンテナが落ちてもセッションログから自動復旧する。

→ 数日でデプロイ可能

自前構築との比較

観点	自前構築	Managed Agents
エージェントループ	自分でリトライ・分岐・エラー処理を実装	Anthropicが提供。ツール呼び出しの判断はClaude任せ
実行環境	EC2/ECS/Lambdaを構築・運用	APIで定義するだけ。コンテナはオンデマンド起動
クレデンシャル	Secrets Managerから取得する仕組みを実装	Vault-proxiedで自動管理。サンドボックスに漏れない
障害回復	自前でチェックポイント・リトライ実装	セッションログから自動復旧
監視	CloudWatch等を自前で仕込む	Claude Consoleで全ツール呼び出し・判断を確認可能
スケーリング	Auto Scaling設定	自動。同時セッション数に応じてスケール

要するに、EC2で自分でサーバーを立てるか、Fargateに任せるかの違いに近い。エージェントのロジック（システムプロンプト + ツール定義）だけ書けば、あとはAnthropicが全部やってくれる。

アーキテクチャ — 「脳と手の分離」

Anthropicのエンジニアリングブログで詳述されている設計思想で、ここが技術的に一番面白い部分。

3コンポーネント分離

コンポーネント	役割	AWSで例えると
Brain（脳）	Claude + ハーネス（エージェントループ）	コントロールプレーン
Hands（手）	サンドボックスコンテナ（コード実行・ファイル操作）	データプレーン（ワーカーノード）
Session（セッション）	永続的なappend-onlyイベントログ	CloudWatch Logsのようなイミュータブルログ

核心は、ハーネスがコンテナの中で動かないこと。ハーネスは実行環境を execute(name, input) → string という統一インターフェースでツールとして呼ぶ。つまりコンテナはCattle（使い捨て）であってPet（手塩にかけるサーバー）ではない。

コンテナのオンデマンドプロビジョニング

コンテナはセッション開始時に事前起動するのではなく、provision({resources}) 呼び出しで必要になった時点で初期化される。これにより、推論（Brain側）はコンテナの起動を待たずに開始できる。

実測値:

p50で約60%のTTFT（最初のトークンまでの時間）改善
p95で90%以上の改善

障害回復

EC2のAuto Recoveryと似た発想で、ステートをインスタンス外（セッションログ）に持っているから、どのコンポーネントが死んでも復旧できる。

コンテナ障害 → ハーネスがエラーをキャッチしてClaudeにリトライ判断させる
ハーネス障害 → 新しいステートレスなハーネスが wake(sessionId) でセッションログから復旧
相互依存なし → 各コンポーネントが独立して落ちても連鎖障害にならない

セキュリティ — クレデンシャルがサンドボックスに渡らない

2つのパターンで実現している:

Resource-bundled auth — リポジトリトークンはGitリモートの初期化時にセットアップ。Claudeは push/pull を叩くだけでトークンを直接扱わない
Vault-proxied — OAuthトークンは外部Vaultに保管。プロキシ経由でサーバーサイドがクレデンシャルを取得

IAMロールをEC2に割り当てるのと同じ考え方で、実行環境にクレデンシャルを置かず、インフラ側が仲介する。

4つの核心概念

概念	説明
Agent	モデル + システムプロンプト + ツール + MCPサーバー + スキル。一度定義してIDで使い回す
Environment	コンテナテンプレート。パッケージ（Python, Node, Go等）・ネットワークアクセスルール・マウントファイル
Session	AgentとEnvironmentを組み合わせた実行インスタンス。タスク遂行の単位
Events	アプリとエージェント間のメッセージ（ユーザーターン、ツール結果、ステータス更新）。SSEでストリーム

ビルトインツール

agent_toolset_20260401 を指定すると全ツールが有効になる。個別にON/OFFも可能。

ツール	名前	内容
Bash	`bash`	シェルコマンド実行
Read	`read`	ファイル読み取り
Write	`write`	ファイル書き込み
Edit	`edit`	文字列置換編集
Glob	`glob`	ファイルパターンマッチング
Grep	`grep`	正規表現テキスト検索
Web fetch	`web_fetch`	URL内容取得
Web search	`web_search`	Web検索

カスタムツールも定義可能。JSONスキーマでインターフェースを定義し、実行はアプリ側が担当して結果をイベントで返す。MCPサーバーの接続にも対応（Streamable HTTP推奨）。

APIの使い方（Python SDK）

from anthropic import Anthropic
client = Anthropic()

# 1. Agent定義
agent = client.beta.agents.create(
 name="Coding Assistant",
 model="claude-sonnet-4-6",
 system="You are a helpful coding assistant.",
 tools=[{"type": "agent_toolset_20260401"}],
)

# 2. Environment定義
environment = client.beta.environments.create(
 name="quickstart-env",
 config={"type": "cloud", "networking": {"type": "unrestricted"}},
)

# 3. Session開始
session = client.beta.sessions.create(
 agent=agent.id,
 environment_id=environment.id,
)

# 4. メッセージ送信 + SSEストリーム
with client.beta.sessions.events.stream(session.id) as stream:
 client.beta.sessions.events.send(session.id, events=[{
 "type": "user.message",
 "content": [{"type": "text", "text": "Fibonacci計算スクリプトを作って"}],
 }])
 for event in stream:
 match event.type:
 case "agent.message":
 for block in event.content:
 print(block.text, end="")
 case "agent.tool_use":
 print(f"\n[Using tool: {event.name}]")
 case "session.status_idle":
 print("\n\nAgent finished.")
 break

CLIツール（ant）も提供されており、YAML定義でエージェントを作成できる:

ant beta:agents create <<'YAML'
name: Coding Assistant
model: claude-sonnet-4-6
tools:
 - type: agent_toolset_20260401
 configs:
 - name: web_fetch
 enabled: false
YAML

ベータヘッダー managed-agents-2026-04-01 が必須（SDKは自動付与）。

料金体系

項目	料金
トークン使用量	通常のAPI料金
セッション実行時間	$0.08/セッション時間（アクティブ時間のみ。待機中は課金なし）
Web検索	$10/1,000検索

Anthropicの3つのエージェント提供形態の比較

	Messages API	Agent SDK	Managed Agents
何か	直接モデル呼び出し	自前でエージェントループを組むフレームワーク	フルマネージドエージェントハーネス
向いている用途	カスタムループ、細かい制御	自社インフラで動かしたい場合	長時間実行、非同期タスク
インフラ管理	全部自前	全部自前	Anthropicが全部やる
AWSで例えると	EC2（自分で全部組む）	ECS（コンテナオーケストレーション自前）	Lambda/Fargate（インフラ抽象化）

早期採用企業

企業	活用方法
Notion	ワークスペース内でタスク委譲。エンジニアはコード、ナレッジワーカーはWebサイト・プレゼンを並列生成
Rakuten	製品・営業・マーケ・経理・HRのエージェントをSlack/Teams連携で展開。1エージェントあたり1週間でデプロイ
Asana	AI Teammates（プロジェクト内で人間と協働するエージェント）を構築
Sentry	デバッグエージェント + パッチ作成エージェントを連携。バグ検知→PRまでの期間を大幅短縮
Vibecode	AI-nativeアプリデプロイのインフラ。セットアップ時間10倍短縮

Research Preview機能（アクセス申請が必要）

Multi-agent — エージェントが別のエージェントをスポーンする
Outcomes — 自己評価して目標達成度を測定・反復する
Memory — セッション間で記憶を保持する

参考リンク

AWS SAP サービス別ノート — ユースケースと判断軸で整理する

Sun, 15 Mar 2026 00:00:00 +0000

この記事は、AWS SAP合格記 — Slack DMで作るサービス別ノート勉強法で紹介した「サービス別ノート」を、ユースケースと判断軸ベースで再構成したものです。

SAP試験では「似たサービスの中から最適なものを選ぶ」判断力が問われます。各テーマを 「なぜ複数の選択肢があるのか → どう違うのか → どの条件でどれを選ぶか」 の流れで整理しています。

注: 一部の情報は学習時点（2022〜2023年）のものです。最新情報と異なる可能性がある箇所には注記を入れています。

リアルタイムデータ処理
認証・認可パターン
コンテンツ配信とアクセス制御
データベース選択
ネットワーク設計
セキュリティ
運用管理
サーバーレス / API設計
データ移行・ETL

1. リアルタイムデータ処理

なぜ複数の選択肢があるのか

AWSには「データを受け取って後続に渡す」仕組みが複数ある。Kinesis Data Streams、SQS、Amazon MQの3つが代表的だ。これらは一見似ているが、解こうとしている課題が違う。

Kinesis Data Streams = ストリーミング処理。大量のデータを連続的に受け取り、リアルタイムで処理する
SQS = メッセージキューイング。コンポーネント間の非同期連携。処理の確実な実行が目的
Amazon MQ = 既存のActiveMQ互換サービス。オンプレからの移行用

Kinesis Data Streams vs SQS — 判断軸

判断軸	Kinesis Data Streams	SQS
データの性質	連続的なストリーム（ログ、クリックストリーム等）	個別のメッセージ（ジョブ、通知等）
複数コンシューマー	同じデータを複数アプリで同時に読める	1つのメッセージは1つのコンシューマーが処理
順序性	シャード内で順序保証	標準キューは順序保証なし（FIFOキューは保証あり）
データ保持	デフォルト24時間、最大365日間	最大14日間
レイテンシ要件	リアルタイム（200ms以下も可能）	準リアルタイム
スケーリング	シャード数で手動管理	自動スケール

選択の指針:

関連する複数のレコードを同じ処理系に回したい → Kinesis
複数のアプリケーションが同じストリームを同時に使う → Kinesis
レコードを数時間後に同じ順序で使う → Kinesis
メッセージレベルの確認/失敗を個別に追跡する → SQS
遅延のある個別のジョブをスケジュールする → SQS
負荷の一時的な上昇をバッファしたい → SQS

Kinesis Data Streams の詳細

概念

シャード: スループットの単位。1シャードは1MB/秒のデータ入力、2MB/秒のデータ出力をサポート
- 1秒あたり最大1,000件のPUTレコードをサポート
- 読み取りは1秒あたり最大5件のトランザクション（GetRecordsは1回で最大10MB/10,000レコード）
- データ保持期間: デフォルト24時間、最大365日間まで延長可能
レコード: データの単位。シーケンス番号、パーティションキー、データBLOB（最大1MB）で構成
パーティションキー: レコードを異なるシャードにルーティングするためのキー
シーケンス番号: 各レコードの一意識別子。シャード間では増加しない

参考リンク:

Kinesis Data Streams の主要なコンセプト

データの書き込み

PutRecord / PutRecords: 同期処理でデータを追加
Kinesis Producer Library (KPL): 非同期処理の高度な設定が可能なライブラリ
Kinesis Agent: Linux環境にインストールするJavaアプリケーション。データ収集とストリームへの送信を自動化
容量制限超過時は ProvisionedThroughputExceeded 例外で拒否される

データの読み取り

Kinesis Client Library (KCL): データコンシューマー。ボリュームの変化への適応、負荷分散、耐障害性に対応
- DynamoDBテーブルを自動作成し、リシャーディングイベントやシーケンス番号チェックポイントを追跡
- EC2オートスケーリンググループ上で実行すれば、処理能力を自動スケール可能
Kinesis Connector Library: DynamoDB、Redshift、S3、Elasticsearch等への統合コネクタ（KCLとは別物）
Kinesis Storm Spout: Apache Storm との統合ライブラリ
ApproximateArrivalTimestamp: レコードがKinesisに正常に受信・保存された時刻
容量制限超過時は ProvisionedThroughputExceeded 例外で読み取り拒否

拡張ファンアウト（Enhanced fan-out）

コンシューマーとシャード間に論理的な2MB/秒のスループットパイプを提供するオプション機能。

使うべきケース:

複数コンシューマーがKinesisの性能制限を超えてしまう場合
200ms以下のデータ提供速度を求める場合

利用手順:

コンシューマーをKinesis Data Streamsサービスに登録する
KCL 2.xを使用している場合、登録は自動
登録されたコンシューマーはそれぞれ独自の拡張ファンアウトスループットを持つ
HTTP/2 SubscribeToShard API でデータを取得する

リシャーディング

シャードの分割・結合によりデータストリームをスケールするプロセス。一度に実行できるリシャーディングオペレーションは1つだけ。

セキュリティ

HTTPS（SSLエンドポイント）経由でデータを安全に格納・取得
AWS KMSマスターキー（CMK）によるサーバー側暗号化
クライアント側暗号化も可能（独自の暗号化ライブラリを使用）
VPCエンドポイントでプライベートアクセス

SQS のポイント

デッドレターキュー（DLQ）

キュー処理が失敗した場合にPushされるキュー
未使用の元メッセージとエラーメッセージがセットでプッシュされる
DLQが推奨されないケース: キューの順序性を維持する必要がある場合、無制限にリトライ処理をする場合

Amazon MQ

ActiveMQに互換性のあるマネージドサービス（Pub/Sub型キューイング）
EC2としてVPC内に起動し、ActiveMQのGUIが使える
機能的にはSQS/SNSと同じだが、既存のActiveMQからの移行用として提供されている
AWSとしては、新規構築にはSQSを推奨している

参考: キューイングシステムの比較（MQ/Kafka）— https://qiita.com/mura16/items/0ea2914156b1614201aa

2. 認証・認可パターン

なぜ複数の選択肢があるのか

AWSリソースへのアクセス制御には、「誰が」「どこから」「何の認証情報で」アクセスするかによって最適な方式が変わる。STSの5つのAPIは、それぞれ異なる認証シナリオに対応している。

STS — 一時的なセキュリティ認証情報の5つのAPI

ユーザーIDをAWSの外で管理している場合、IAMユーザーを作成する代わりにIdP（Identity Provider）を利用する。IAMはOpenID Connect（OIDC）またはSAML 2.0と互換性のあるIdPをサポートする。

STSが返す一時的認証情報は以下の3つのセット:

アクセスキー（アクセスキーID + シークレットアクセスキー）
セキュリティトークン
有効期限

API	ユースケース	認証を要求する側	返ってくる認証情報
GetSessionToken	信頼されてない環境のユーザー向け一時認証	IAM User	IAM User
GetFederationToken	カスタムIDブローカー経由のフェデレーション	Federated User	IAM User
AssumeRole	クロスアカウント委任、カスタムIDブローカー経由	IAM User	IAM Role
AssumeRoleWithWebIdentity	OIDC互換IdP経由のフェデレーション	Federated User	IAM Role
AssumeRoleWithSAML	SAML 2.0 IdP経由のフェデレーション	Federated User	IAM Role

選択の指針:

IAMユーザーが一時的に権限を得たい（MFA付き等）→ GetSessionToken
外部ユーザーにIAMユーザー相当のアクセスを与えたい → GetFederationToken
別のAWSアカウントのリソースにアクセスしたい → AssumeRole
GoogleやFacebookログインでAWSリソースにアクセスしたい → AssumeRoleWithWebIdentity
社内のActive Directory（SAML）でAWSにログインしたい → AssumeRoleWithSAML

参考リンク:

https://qiita.com/fkooo/items/a6d71407b2bed42332cc

https://dev.classmethod.jp/articles/getfederetiontoken-assumerole-getsessiontoken/#toc-1

https://blog.serverworks.co.jp/summary-of-getting-security-credentials-from-sts

モバイルアプリの認証 — Cognito vs STS直接呼び出し

モバイルアプリからAWSリソースにアクセスするパターンは主に2つ:

パターン1: Amazon Cognito（推奨）

ユーザープール + IDプールを使い、外部IdP認証またはCognito自体での認証・認可を実装
Cognitoが裏でSTSを呼んでくれるので、アプリ側の実装がシンプルになる

パターン2: AssumeRoleWithWebIdentity API 直接呼び出し

SDKで外部IdPからの認証情報を取得し、それを使ってAWSからIAM Roleを引き受ける
より細かい制御が必要な場合向き

API Gateway の認証 — Lambda オーソライザー

API Gatewayへのアクセスを制御するためにLambda関数を使う機能。OAuthやSAMLなどのベアラートークン認可や、カスタム認証スキームを実装できる。

2種類のオーソライザー:

トークンベース（TOKEN オーソライザー）: JWT や OAuth トークンなどのベアラートークンで発信者IDを受け取る
リクエストパラメータベース（REQUEST オーソライザー）: ヘッダー、クエリ文字列、stageVariables、$context変数の組み合わせで発信者IDを受け取る

3. コンテンツ配信とアクセス制御

なぜ複数の選択肢があるのか

S3に置いたコンテンツを制限付きで配信したい場合、「S3の署名付きURL」と「CloudFront + 署名付きURL」の2つの方法がある。さらにCloudFront側では「署名付きURL」と「署名付きCookie」の選択肢もある。配信の規模、速度要件、アクセス制御の粒度によって使い分ける。

S3署名付きURL vs CloudFront署名付きURL

共通点:

URLを共有すれば誰でもアクセスできる
有効期限を設定できる

判断軸	S3署名付きURL	CloudFront署名付きURL
URLの形式	S3のURL	カスタムドメインを設定可能
キャッシュ	なし	エッジロケーションでキャッシュ
ユースケース	期間限定の単発ファイル配信	大量リクエスト、グローバルアクセス
S3を隠す	できない	可能（自分のドメインにできる）

選択の指針:

少量・一時的なファイル共有 → S3署名付きURL
大量リクエスト、高速配信が必要 → CloudFront署名付きURL
S3のURLを外部に見せたくない → CloudFront署名付きURL
グローバルなアクセスが見込まれる → CloudFront署名付きURL

署名付きURL vs 署名付きCookie

非公開のS3バケットに対して、特定のクライアントにアクセス許可を与える手法。署名は秘密鍵（クライアント側）と公開鍵（サーバー側）で認証と改ざん検知を行い、有効期限を設定できる。

署名付きURL: 個別のファイルへのアクセス制御。ユーザーがコンテンツにアクセスできる日時やIPアドレスを制御可能
署名付きCookie: 複数のファイルへのアクセスを一括制御。サイト全体へのアクセス権を管理したい場合

参考: http://developers.goalist.co.jp/entry/2017/05/11/191628

S3オリジンへのアクセス制御 — OAC（Origin Access Control）

CloudFront経由でS3にアクセスさせる際、S3バケットを非公開にしたまま CloudFrontからのアクセスだけを許可する仕組み。

⚠️ 2024年時点の更新: 従来のOAI（Origin Access Identity）は非推奨となり、OAC（Origin Access Control）が推奨されています。OACはIAMロールベースの制御、短期間の認証情報ローテーション、SSE-KMS暗号化オブジェクトのサポート、全HTTPメソッド（GET/PUT/POST/PATCH/DELETE/OPTIONS/HEAD）のサポートなど、OAIより多くの機能を提供します。

参考: Restrict access to an Amazon S3 origin

地理的なアクセス制限

CloudFrontの地理制限機能: 国単位でホワイトリスト/ブラックリストを設定可能
国より詳細なレベル（都市、IP単位等）で制限する場合は、サードパーティの位置情報サービスが必要

キャッシュの最適化

CloudFrontのキャッシュ制御は、Min TTL/Max TTL/Default TTLとオリジンのヘッダー値を組み合わせて決まる。

参考: CloudFront がコンテンツをキャッシュする期間の管理

TTLを0にした場合の動作:

リクエストの都度Originに更新有無を確認する
更新がなければ304が返り、キャッシュしたコンテンツを利用する
完全にキャッシュ無効にはならず、Originの負荷軽減効果がある

クエリ文字列に対するキャッシュ設定:

クエリ文字列でコンテンツが変わらない場合 → Originに転送せず、クエリ文字列に関係なくキャッシュ
すべてのクエリ文字列パラメータでキャッシュ → クエリが違うと別リクエスト扱い（ヒット率は下がる）
指定したクエリ文字列のみキャッシュ → 上記2つのハイブリッド

参考: https://qiita.com/tmiki/items/be36303e514ce4d012f8

Originのプロトコル設定

HTTP、HTTPS、Match Viewer（クライアントのプロトコルに合わせる）の3つから設定可能。

Lambda@Edge

CloudFrontの拡張機能。エッジロケーションでLambda関数を実行できる。4つのイベントをトリガーにできる:

Viewer Request — クライアント → CloudFront
Origin Request — CloudFront → Origin
Origin Response — CloudFront ← Origin
Viewer Response — クライアント ← CloudFront

4. データベース選択

DynamoDB

基本特性

リージョン内の3つのAZで同期的にレプリケートされ、高可用性・耐久性を提供
デフォルトは結果整合性（最新の書き込みを反映していない可能性がある）
強い整合性読み込み（strongly consistent read）も利用可能
スループットを指定し、それを超えると「スループット超過エラー」になる
- → SQSにキューイングしてバッファとすることで防止可能

キー設計 — DynamoDBの最重要ポイント

プライマリキー: データを一意に識別。パーティションキー単体、またはパーティションキー + ソートキーの複合キー
パーティションキー: データのカテゴライズ。このキーのハッシュ値で保存先パーティションが決まる
- 例: 個人情報テーブルで郵便番号をパーティションキーにすると、同じ郵便番号のデータは同じパーティションに保存される
ソートキー: パーティション内でのデータの並び順を決める
- パーティションキーでカテゴライズし、ソートキーでソートする
GSI（Global Secondary Index）: 元テーブルとは別のパーティションキー+ソートキーでテーブルを再構成
LSI（Local Secondary Index）: パーティションキーはそのまま、ソートキーだけ変える

参考: https://qiita.com/shibataka000/items/e3f3792201d6fcc397fd

FGAC（Fine Grained Access Control）

IAMではテーブル単位のアクセス制御しかできない
FGACを使えばレコード単位、キー単位での細かいアクセス制御が可能
モバイルアプリから直接DynamoDBにアクセスする構成で有用

キャパシティユニット計算

RCU（読み込みキャパシティユニット）:

1RCU = 最大4KBの項目について、1秒あたり1回の強い整合性読み込み、または2回の結果整合性読み込み
4KBを超える項目は追加のRCUを消費する（8KB → 2RCU（強い整合性）or 1RCU（結果整合性））
例: 10RCUのテーブル → 4KB項目を1秒に10回（強い整合性）or 20回（結果整合性）読み込み可能

WCU（書き込みキャパシティユニット）:

1WCU = 最大1KBの項目について、1秒あたり1回の書き込み
書き込みサイズは1KBの倍数に切り上げ（500バイト → 1KB扱い）
例: 30WCUのテーブル → 1KB項目を1秒に30回書き込み可能

キャパシティモード

モード	特徴	パーティション設計
プロビジョニング（手動）	自分でRCU/WCUを設定	必要
Auto Scaling	負荷に応じて自動調整	必要
オンデマンド	完全自動、使った分だけ課金	不要

キャパシティの15%以上を利用する設計なら、プロビジョニングの方がコスト効率が良い。

DynamoDB Streams

DynamoDBへの項目の追加・変更・削除をイベントとして検出する機能
24時間以内の変更の時系列順序を保持
テーブル単位で有効化

DynamoDBトランザクション

複数テーブルへの同時読み取り・書き込みの一貫性を提供
同時に10件のテーブル操作を1つのトランザクションにまとめられる
トランザクション内での同じアイテムに複数操作はできない
グローバルテーブルは非同期のためサポートされない

参考: https://qiita.com/blackcat5016/items/c2af7d3d55093134bac3

Cross-Region Replication

ユースケース: 災害対策（DR）、リージョン移行

RDS Proxy

アプリケーションとRDSの間に配置されるプロキシ。データベースへのコネクションプールを効率的に管理する
フェールオーバー時間を最大66%短縮（Aurora/RDS）
LambdaからRDSに接続する場合は必須級 — Lambdaの同時実行でコネクションが乱立するのを防ぐ

Redshift — Concurrency Scaling（同時実行スケーリング）

エンドポイントを変更せずに、自動で新しいクラスターを追加する機能
メインクラスタのクエリ同時実行数を超過すると、スケーリングクラスタにルーティング
スケーリングクラスタは読み取り専用

参考: Amazon Redshift Concurrency Scaling

5. ネットワーク設計

Global Accelerator

AWSのグローバルネットワークを使い、ユーザーに最も近いエッジロケーションからAWSリソースへのトラフィックを最適化するサービス。

オリジンに利用できるサービス: NLB、ALB、EC2、EIP

標準ルーティング vs カスタムルーティング:

標準ルーティング: 基本的にこちらを利用。AWSが最適なエンドポイントへ自動ルーティング
カスタムルーティング: 特定のEC2に特定のクライアントを紐づけたい場合（ゲームサーバー等）

Direct Connect

オンプレミスとAWSを専用線で接続するサービス。

構築に必要な設定:

VGW（Virtual Private Gateway）の設定とルート伝搬の有効化
オンプレと通信するサブネットのルートテーブルにオンプレ宛のルートを登録

参考: https://dev.classmethod.jp/articles/whitepaper-translate-jpn-vpc-connectivity-options-01/

Transit Gateway Network Manager

Transit Gateway、VPC、VPNのトポロジを可視化して管理するサービス
主な機能は可視化とモニタリング

参考: https://dev.classmethod.jp/articles/transit-gateway-network-manager-vpn/

EC2 プレイスメントグループ

EC2が起動する物理サーバーの配置を指定する設定。3つの戦略がある。

戦略	用途	特徴
クラスター	インスタンス間の低レイテンシ通信	同一ラックに集約
パーティション	Hadoop/Kafka等のクラスタ	低レイテンシ+クラスタ間分散
分散	耐障害性の向上	物理ラックを分散

既存インスタンスをプレイスメントグループに追加する場合:

インスタンスを一度停止
AWS CLIで移動
インスタンスタイプを統一し、グループ全体を再起動

参考: プレイスメントグループ

EC2 インスタンスの選択

主なインスタンスタイプと用途:

T3: バースト可能な汎用タイプ。一時的なCPUスパイクがある中程度の負荷向け
G2: 高度なグラフィック処理。低レイテンシネットワーキング付きGPUサーバー
G4: 最もコスト効率の高いGPUインスタンス。ML推論やグラフィクス向け

EC2 ネットワーク

拡張ネットワーキング:

高帯域幅、低レイテンシーを実現する機能
OSへのモジュールインストールとAWS CLIでの有効化が必要（一部OS/タイプでは最初から有効化済み）
100Gbpsネットワーク対応: C5, M5, R5, P3, T3など多数のインスタンスタイプ

IPv6対応: T3は未対応、T4は対応

インスタンスストア:

EBSより高IOPS、高スループット、低遅延
I3, F1, C5d, M6gdなど d がつくタイプで利用可能
スナップショットは取得不可。再起動ではデータ維持、停止で消失
起動後にマウントが必要

EC2 AutoScaling メトリクス

トリガーとして使えるメトリクス:

CPU/Memory
SQSのキュー長
ネットワークのIN/OUTトラフィック

ELB

トラフィック急増時のメトリクス:

メトリクス名	説明
SurgeQueueLength	ALBで保留中のリクエスト数
SpilloverCount	サージキューが満杯で破棄されたリクエスト数

クライアント証明書を使う場合:

ALBではHTTPSの終端でクライアント証明書を扱えないため、NLBのTCPリスナー（443） でEC2に直接TLSを終端させる

スティッキーセッション: Cookie名は AWSELB（CLBでも同じ）

参考:

NLBとProxy Protocol

S3暗号化

BYOIP（自組織のグローバルIP持ち込み）

自組織が所有するグローバルIPアドレスをAWSに持ち込む手順:

1. ROAオブジェクトの作成

ROA（Route Origination Authorization）: IPアドレスレンジとASNの対応を証明するデータ
RPKIで発行したリソース証明書で署名

2. RDAP用X509証明書の作成

RDAP（Registration Data Access Protocol）: WHOISの後継プロトコル（HTTPS + JSON応答）

3. 署名付き認可メッセージの作成

1|aws|account|cidr|YYYYMMDD|SHA256|RSAPSS

4. AWSへのプロビジョニング

aws ec2 provision-byoip-cidr --cidr address-range --cidr-authorization-context Message="$text_message",Signature="$signed_message"

参考: http://jpopf.net/opf-jp/opm16/jpopm16-08.pdf

RD Gateway Server

インターネットからRDP接続する際に、HTTPS/443でプロキシするための機能
接続先と同じLAN内に配置し、証明書をインストールして利用
クライアント側はRDP接続でRD Gateway経由を選択し、サーバー名とクライアント証明書を指定

参考: https://blog.pfs.nifcloud.com/20191711_RD_Gateway_RemoteDesktopConnection

6. セキュリティ

AWS Shield — Standard vs Advanced

DDoS保護サービス。無料のStandardと有料のAdvancedで保護レベルが大きく異なる。

機能	Standard（無料）	Advanced（有料）
対象レイヤー	L3/L4	L3/L4 + L7
検出	悪意あるトラフィック自動検出	より大規模な攻撃にも対応
緩和	自動緩和	高度なルーティング技術による緩和
可視化	なし	AWSサービス連携で可視化・通知
攻撃履歴	参照不可	レポート・通知が可能
費用保護	なし	DDoS起因の請求増額に対する払い戻し
サポート	なし	24/365の専門サポート

Shield StandardでL7 DDoSを検知するには: AWS WAFを同時利用すれば可能。

参考:

AWS Shield

DDoS対策ホワイトペーパー

CloudHSM vs KMS — 暗号化キーの管理

判断軸	CloudHSM	KMS
ハードウェア	専用（顧客ごとに独立）	共用
コンプライアンス	FIPS 140-2 レベル3	FIPS 140-2 レベル2
コスト	高い	安い
用途	規制要件が厳しいケース	一般的な暗号化

選択の指針:

FIPS 140-2 レベル3が必要 → CloudHSM
専用ハードウェアによるキー管理が要件 → CloudHSM
コスト効率を重視、一般的な暗号化 → KMS

CloudHSMによるSSL/TLSオフロード

CloudHSMでHTTPS（SSL/TLS）の暗号化処理を実行できる。ハンドシェイクの流れ:

クライアントがサーバーにHelloメッセージを送信
サーバーがHelloメッセージと証明書を返す
クライアントが証明書を検証し、プリマスターシークレットをサーバーの公開鍵で暗号化して送信
サーバーがプリマスターシークレットをHSMに送り、HSMの秘密鍵で復号（ここがHSMの役割）
両者がプリマスターシークレットからマスターシークレットを計算
以降の通信はマスターシークレットで暗号化

ログを保存するために、S3 + SSE-S3による暗号化が利用可能（暗号化キーの管理はAWS側）

AWS Organizations — マルチアカウント管理

複数のAWSアカウントのセキュリティと請求をまとめて管理するサービス。

SCP（Service Control Policy）

OU（Organizational Unit） でAWSアカウントをグループ化。OUは階層的に定義可能
OUにSCPを割り当て、許可/拒否するAWSサービスを制御
継承: 上位OUのSCPは下位のOU/アカウントに継承される
記法はIAMポリシーと同じ（暗黙のDeny < 明示Allow < 明示Deny）
ただし、サービスにアタッチされたIAMロールには影響しない

参考: https://dev.classmethod.jp/articles/organizations-scp-inheritance/

2つの機能セット

すべての機能（推奨）: 一括請求 + SCP + 組織全体のAWSサービス管理 + アカウント作成・招待
一括請求機能のみ: 請求とアカウント作成・招待のみ

その他のポイント

アカウント作成時: OrganizationAccountAccessRole（Admin権限）が子アカウントに自動作成される
CloudTrail: マスターアカウントのCloudTrailを有効化すると全メンバーアカウントのログ取得可能。単一S3バケットに集約可能
リザーブドインスタンス共有: Organizations内で共有可能。共有しない設定はマスターアカウントからのみ
子アカウント削除: スタンドアロン動作に必要な設定が事前に必要（支払い権限を持つIAMユーザーで設定変更）

AWS Control Tower

Organizationsの上に構築されたガバナンスサービス。主な機能:

ログ集約
コントロール適用（コンフォーマンスパック）
通知
ID一元管理
AWSアカウントの作成・プロビジョニング

Amazon Inspector

AWSリソースに対するセキュリティ評価サービス。「もしAの攻撃を受けたら問題ないか」という観点でテスト。

ルールパッケージ:

ネットワークの到達可能性: インターネット、VPCピアリング、VPN経由でEC2にアクセス可能かどうか
ホスト評価: EC2自体の脆弱性や問題のある設定をチェック

⚠️ 2024年時点の更新: Inspector v2ではエージェントレス脆弱性スキャンがGA（一般提供）となりました。ハイブリッドスキャンモード（SSMエージェント + エージェントレスの自動切り替え）が新規顧客のデフォルトです。Inspector Classicは2026年にサポート終了予定です。

7. 運用管理

Systems Manager — 統合運用管理プラットフォーム

Systems Managerは多数の機能を持つが、大きく4つのカテゴリに分かれる。

参考:

Systems Manager Black Belt

https://blog.serverworks.co.jp/tech/2020/04/16/systems_manager_yattemiyou/

運用管理

機能	説明
エクスプローラー	運用アイテム情報のダッシュボード
OpsCenter	対応が必要なイベント（運用アイテム）の管理
CloudWatchダッシュボード	CloudWatch用のカスタムダッシュボード
Trusted Advisor / PHD	Trusted AdvisorとPersonal Health Dashboardの統合ビュー

アプリケーション管理

機能	説明
リソースグループ	タグによるサーバー群のグループ管理
AppConfig	アプリケーション設定（機能フラグ等）の管理
パラメータストア	設定パラメータの集中管理用データストア。アプリやコンテナからSDK/APIで取得可能

変更管理

機能	説明
オートメーション	AWS環境全体に対する自動化処理の実行
Change Calendar	実行可否を制御するカレンダー
メンテナンスウィンドウ	自動化処理のスケジュールと順序の管理

ノード管理

機能	説明
コンプライアンス	コンプライアンスの適合状態ダッシュボード
インベントリ	サーバー構成情報のインベントリ閲覧
ハイブリッドアクティベーション	オンプレミスサーバーをSSM管理下に入れる
セッションマネージャー	SSM経由のリモートアクセス
Run Command	サーバー群でのコマンド実行
ステートマネージャー	指定した状態の維持
パッチマネージャー	パッチグループ/パッチベースラインに基づく自動パッチ適用
ディストリビューター	パッケージのインストール

共有リソース — ドキュメント

管理対象インスタンスへの操作を定義したテンプレート。インスタンスの起動/停止/作成/削除やOS内コマンドの実行を事前定義し、オートメーション等で利用する。

有料機能

OpsCenter、AppConfig、パラメータストア、オンプレミスインスタンス管理、ディストリビューター、オートメーション

CloudFormation

DeletionPolicy — スタック削除時のリソース挙動

ポリシー	説明	対象リソース
Snapshot	スナップショットを作成してから削除	EC2::Volume等
Retain	リソースを削除せず保持	すべてのリソースタイプ
Delete	リソースとコンテンツを削除（デフォルト）	すべてのリソースタイプ

CreationPolicy

EC2インスタンスのプロビジョニング時に、ソフトウェアインストールやブートストラップ処理の完了を待ってからスタック作成を続行させる設定。CreationPolicyを指定しないと、インスタンスが起動しただけで（initスクリプト完了前に）スタック作成が続行される。

ヘルパースクリプト

CloudFormationでのEC2作成時に使う拡張ツール:

cfn-init : EC2へのパッケージインストール、ファイル作成
cfn-signal : インストール結果（OK/NG）を他のスタックに連携
cfn-get-metadata : メタデータの取得
cfn-hup : メタデータの更新を検知し次の処理に連携

CloudFormationでのLambda関数デプロイ

AWS::Lambda::Function でLambdaのデプロイパッケージを参照
すべてのランタイムに対して S3 内のオブジェクトの場所を指定可能
依存関係がない場合は、テンプレートに直接Lambda関数コードを記載可能

8. サーバーレス / API設計

API Gateway vs AppSync — いつどちらを使うか

判断軸	API Gateway	AppSync
プロトコル	REST / WebSocket	GraphQL
データ取得	エンドポイントごとに固定レスポンス	クライアントが必要なフィールドを選択
リアルタイム	WebSocket APIで実現	サブスクリプションで組み込み
バックエンド	Lambda, HTTP, AWS Service	DynamoDB, Lambda, Aurora等

API Gateway の詳細

メトリクス

メトリクス	説明
4XXError	クライアント側エラーの数
5XXError	サーバー側エラーの数
CacheHitCount	APIキャッシュから配信されたリクエスト数
CacheMissCount	バックエンドから提供されたリクエスト数
Count	APIリクエストの合計数
IntegrationLatency	API GW → バックエンド → レスポンス受信の時間
Latency	クライアント → API GW → クライアントの全体時間

Lambda統合時の504エラー

API Gatewayはバックエンド処理を含め29秒でタイムアウトし504を返す
INTEGRATION_FAILURE: 統合失敗（デフォルトでDEFAULT_5XX）
INTEGRATION_TIMEOUT: 統合タイムアウト。Lambdaの処理が29秒以上かかった場合
- 普段は正常で、たまに発生する場合はタイムアウトを疑う

AppSync / GraphQL

GraphQLとは:

RESTの課題を解決するためにFacebookが開発したオープンソースのクエリ言語
RESTがアーキテクチャスタイルであるのに対し、GraphQLは標準化された言語・型付け・仕様を持つ
クライアント側から取得したいデータだけを選択して取得できる（RESTではバックエンド改修かクライアント側加工が必要だった）

AppSyncの概要:

サーバーレスでGraphQLのバックエンドを実装できるサービス（GraphQL版のAPI Gateway的な位置づけ）
手順: ①スキーマ定義 → ②リゾルバー作成（VTLでスキーマとデータソースのマッピング） → ③エンドポイント生成

参考:

https://www.webprofessional.jp/rest-2-0-graphql/

https://dev.classmethod.jp/articles/relay-re-introduction-2019-appsync/

Amazon Connect

クラウドベースのコンタクトセンターサービス。

Contact Lens:

通話内容を機械学習で分析する機能
文字起こし、感情分析、キーワードアラート通知に対応

UpdateContactAttributes API:

連絡先の属性（発信者名、電話の理由、サービス品質等）をプログラム的に追加・更新できるAPI
従来は対応フロー内でのみ設定可能だったが、このAPIで通話中・通話後にCRM等からも更新可能に

参考: https://aws.amazon.com/jp/about-aws/whats-new/2018/08/amazon-connect-adds-new-contact-api-to-set-contact-attributes/

9. データ移行・ETL

なぜ複数の選択肢があるのか

データの移動・変換には「何を」「どこからどこへ」「どう加工するか」によって最適なサービスが異なる。

サービス	主な用途	特徴
DataSync	データ転送（移動そのもの）	オンプレ↔AWS間のファイル転送
Glue	ETL（抽出・変換・ロード）	サーバーレスETL、データカタログ
Data Pipeline	ETLワークフロー	マネージドETL ※新規利用停止

AWS DataSync

オンプレ ↔ AWS間のデータ転送サービス
転送先: S3、EFS
オンプレ側のサーバーにエージェントを導入して利用

参考: AWS DataSync とは

AWS Glue

S3、RDS、Redshift等のAWSサービス間のデータ連携を仲介するサーバーレスETLサービス。

主要コンポーネント:

コンポーネント	説明
データカタログ	永続的なメタデータストア。テーブル定義、ジョブ定義、制御情報を保持
クローラ	S3、DynamoDB、RDS、Redshift等をクロールしてデータカタログにメタデータテーブルを作成
ジョブ	ETL処理のビジネスロジック。Apache SparkとPython Shellの2タイプ

ETL処理の流れ:

データソース（CSVファイル等）をクロールし、データカタログにメタデータを作成
データカタログの情報からコンソールでジョブを定義
スケジューラーでジョブの実行タイミングを設定
ジョブを実行し、抽出・変換・書き込みを実施

AWS Data Pipeline

⚠️ 2024年7月に新規顧客へのアクセスが停止されました。既存顧客は引き続き利用可能ですが、新規構築にはGlueやStep Functionsの利用が推奨されます。

マネージドETLサービス
AWS内のデータソースからデータを抽出し、任意の処理を行い、別のデータソースに保存する
例: S3 → Redshift、RDS → S3

付録: その他のサービス

Amazon Managed Blockchain

Hyperledger FabricやEthereumを使って、スケーラブルなブロックチェーンネットワークを作成・管理するフルマネージドサービス
ネットワーク参加には提案→投票→招待のプロセスが必要（投票ルールに基づく）
IAMロールやSTSでの直接参加はできない。必ずネットワーク内の提案・投票プロセスを経る

散歩しながらAWSインフラを整理した話

Sun, 15 Mar 2026 00:00:00 +0000

日曜の夕方、散歩に出た。

特に目的もなく近所を歩いていたのだが、ふと「そういえばAWSアカウント、放置気味だったな」と思い出して、iPhoneに話しかけた。

「AWSのリソース、今どんなのがあるか調べてみて。削除とか絶対しないように」

少し補足すると、自分は趣味で音声AIアシスタントを作っている。自宅のMac miniにFastAPI + Claude CLIを載せたもので、iPhoneのブラウザから音声で話しかけると、バックエンドが動いて結果を返してくれる。名前はJ.A.R.V.I.S.。そう、あの映画のやつだ。

で、散歩しながらこんなやりとりが続いた。

J.A.R.V.I.S.: 確認しました。Elastic Beanstalkの残骸が残っています。S3バケットとアプリ定義、全部2019年のもので完全に使われていません

自分: 消して

J.A.R.V.I.S.: 削除完了です

自分: Terraform stateがローカルなんだけど、S3に移したい

J.A.R.V.I.S.: バケットのセキュリティ設定を先に確認しますね。パブリックアクセスブロック全オン、暗号化あり、バージョニング有効。問題ないので移行します

自分: やって

J.A.R.V.I.S.: 移行完了しました

自分: セキュリティの状況もチェックできない？

J.A.R.V.I.S.: セキュリティグループが2つ、0.0.0.0/0でポートを開けたまま残っています。どちらも未アタッチです。あとCloudTrailが2019年10月から停止中、GuardDutyは未有効化です

自分: セキュリティグループは消して。CloudTrailとGuardDutyのコストってどれくらい？

J.A.R.V.I.S.: このアカウント規模ならどちらもほぼタダです。CloudTrailは最初の1証跡が無料、GuardDutyは月1〜2ドル程度かと

自分: 両方有効にして

J.A.R.V.I.S.: 完了です

自分: 夜間のスケジュールでセキュリティとコストのチェックも入れといて

J.A.R.V.I.S.: 毎晩2時に登録しました

気づいたら、散歩1回分で7つの作業が終わっていた。リソース棚卸し、不要リソース削除、Terraform stateのS3移行、セキュリティグループの掃除、CloudTrailとGuardDutyの有効化、夜間チェックの自動化。ターミナルは一度も開いていない。

普通にやったら1〜2時間はかかる作業だと思う。それが散歩中の会話で終わった。

ここまでの作業を終えて、まだ散歩の途中だった。

「これ、すごいことが起きてないか？」と思った。この感覚を誰かに伝えたくなって、そのまま歩きながら話しかけた。

「今日の体験をブログにして」

ちなみにこのアプリ自体、自分で一からコードを書いたわけではない。インフラエンジニアの自分がやりたいことを日本語で伝えて、AIがコードを書いた。そのAIに今、ブログを書かせている。

お気づきかもしれないが、この記事自体も同じ散歩の中で生まれたものだ。

CloudFrontの署名付きURLの仕組み

Thu, 15 Jun 2023 00:00:00 +0000

なぜ「署名付きURL」が必要なのか

S3に置いた動画や資料を、お金を払ったユーザーだけに見せたい。よくある要件だ。

S3バケットを非公開にすればいい？それだとCloudFront経由でも配信できなくなる。CloudFrontを公開すれば誰でもアクセスできてしまう。つまり「CDNで高速配信したいが、見せる相手は制限したい」という矛盾が生まれる。

署名付きURLは、この矛盾を**「URLそのものに入場券を埋め込む」**というアプローチで解決する。

身近なたとえ: 映画の前売り券

映画館で例えると、こういうことだ:

映画館（CloudFront）は誰でも入れる場所にある
だが上映室のドアには鍵がかかっている（S3は非公開）
前売り券（署名付きURL）を持っている人だけが入れる
前売り券には「3/7の19時の回まで有効」と書いてある（有効期限）
前売り券にはスタッフだけが読める偽造防止マーク（デジタル署名）がある

ポイントは、映画館側は「誰がチケットを買ったか」を知らなくていいこと。チケットが本物かどうかだけ確認すれば済む。これが署名付きURLの設計思想だ。

S3の署名付きURLとの違い

「署名付きURL」はS3にもある。混同しやすいので整理する。

共通する本質:

どちらも「URLに一時的なアクセス権を埋め込む」仕組み
有効期限がある
秘密情報（鍵）を使って署名する

CloudFront版ならではの特徴:

	S3署名付きURL	CloudFront署名付きURL
署名者	IAMユーザーのアクセスキー	RSA秘密鍵（自分で管理）
配信元	S3のエンドポイント直接	CloudFrontエッジ（CDN）
速度	リージョンに依存	エッジから配信（高速）
制御	URL・期限のみ	URL・期限・IP制限・カスタムポリシー

つまりCloudFront版は「CDN配信 + きめ細かいアクセス制御」を両立させたもの。S3版の上位互換と考えていい。

全体像: 3つのフェーズ

署名付きURLの仕組みは、大きく3つのフェーズに分かれる。

フェーズ1: 鍵の準備（事前に一度だけ）

公開鍵暗号を使う。映画館のたとえでいう「偽造防止マークの仕組みを作る」段階。

管理者がRSA鍵ペアを生成する（秘密鍵 + 公開鍵）
秘密鍵は自分で安全に保管する（チケットに署名するための印鑑）
公開鍵はCloudFrontに渡す（偽造防止マークを検証するための情報）

なぜRSAか？署名する場所（アプリサーバー）と検証する場所（CloudFront）が別だから。秘密鍵を渡さずに検証できる公開鍵暗号が必要になる。

フェーズ2: URLの発行（リクエストのたびに）

ユーザーがコンテンツにアクセスしたいとき、アプリケーションサーバーが署名付きURLを生成する。

ポリシーを作る — 「このURLに、この期限まで、このIPからアクセスOK」というJSON
ポリシーをハッシュ化 — SHA-1でダイジェストを作る
秘密鍵で署名 — ダイジェストをRSAで暗号化（=デジタル署名）
URLに全部くっつける — 元のURL + 署名 + キーID + 期限 = 署名付きURL

できあがったURLはこんな形になる:

https://d1234.cloudfront.net/video.mp4
 ?Expires=1686873600
 &Signature=ABCxyz...（Base64エンコードされた署名）
 &Key-Pair-Id=KPID1234

フェーズ3: アクセスと検証（ユーザーがURLを使うとき）

ユーザーが署名付きURLにアクセスする
CloudFrontがURLのパラメータを読む
Key-Pair-Id から対応する公開鍵を取得
公開鍵で署名を検証（改ざんされていないか確認）
ポリシーの条件を確認（有効期限内か、IPは合っているか）
すべてOKなら → S3からコンテンツを取得して配信
NGなら → 403 Forbidden

CloudFrontは署名の正当性だけを確認する。ユーザーが誰かは知らないし、知る必要がない。映画館がチケットの偽造防止マークだけ確認するのと同じだ。

設計のポイント

この仕組みの設計で巧みなのは、責務の分離にある:

アプリケーションが「誰にアクセスさせるか」を判断する（認証・認可）
CloudFrontは「このURLが本物か」だけ判断する（署名検証）

CloudFrontはユーザー管理を一切しない。だからどんな認証基盤とも組み合わせられる。Cognito、Auth0、自前の認証、なんでもいい。「誰に署名付きURLを渡すか」はアプリ側の責任だ。

IAM IDプロバイダー

Thu, 15 Jun 2023 00:00:00 +0000

1. 何を実現するためのサービスか？

AWS IAM IDプロバイダーは、GoogleやFacebookみたいな外部のIDプロバイダーを使って、AWSリソースにアクセスするための認証情報を管理するためのものだよ。これによって、セキュリティを保ちつつ、ログインプロセスを簡単にできるんだ。

2. 類似するサービスとの違い・比較

AWSには他にも認証サービスがあるけど、IAM IDプロバイダーは特に外部の認証情報を使ってAWSリソースにアクセスする点で便利。たとえば、AWS Cognitoはアプリのユーザー管理に特化しているし、AWS STSは一時的なアクセス許可を管理するためのものだよ。

サービス名	主な用途	特徴
IAM IDプロバイダー	外部IDプロバイダーを使用したAWSリソースへのアクセス管理	- 外部の認証情報を使用してAWSリソースにアクセス - OIDCやSAMLをサポート
AWS Cognito	アプリケーションのユーザー認証とユーザー管理	- ユーザープールを通じてアプリ固有のユーザー認証を提供 - ソーシャルログインやユーザー管理機能が豊富
AWS STS	一時的なセキュリティ認証情報の提供	- 一時的なアクセスキーとセッショントークンを提供 - フェデレーションユーザーやアプリケーションに一時的なアクセス権を与える

この表から、各サービスがどのような目的で使われ、どんな特徴があるかがわかるね。IAM IDプロバイダーは、特に企業が既存の認証システムをAWSに統合する際に役立つサービスだよ。

3. 利用方法

まずはAWSの管理コンソールから「IAMダッシュボード」に行って、「IDプロバイダー」を選んで、「新しいプロバイダーを追加」をクリックするんだ。ここで「OpenID Connect」か「SAML」を選んで、必要な情報を入力するよ。

4. 料金の例

このサービス自体には追加料金はかからないけど、IDプロバイダーを通じてアクセスされるAWSサービスの利用によって料金が発生することがあるよ。

5. 利用手順

1. IDプロバイダーの設定:

AWS管理コンソールで「IAMダッシュボード」を開いて、「IDプロバイダー」を選ぶ。「新しいプロバイダーを追加」をクリックして、必要な情報を入力。

2. IAMロールの作成:

「ロール」セクションに移動して、「新しいロールを作成」。トラストポリシーでIDプロバイダーを指定して、フェデレーションユーザーがこのロールを使えるように設定。必要なアクセス権限を持つポリシーをロールに割り当てる。

3. ポリシーの割り当て:

ロールに適切なポリシーを割り当てて、フェデレーションユーザーが必要なAWSリソースにアクセスできるようにする。これで、外部IDプロバイダーを使ってAWSリソースにアクセスする準備が整うよ。これを使えば、会社が既存の認証システムを活用して、AWSで安全にアクセス管理を行えるようになるんだ。

AWS SAP合格記 — Slack DMで作るサービス別ノート勉強法

Sun, 15 Jan 2023 00:00:00 +0000

はじめに — SAP試験は「知っている」では受からない

AWS ソリューションアーキテクトプロフェッショナル（SAP）は、AWSの資格試験の中でも最難関の一つだ。試験範囲が広いだけでなく、「どのサービスをどの条件で選ぶか」という判断力を問われる。似たようなサービスの使い分け、複数のアーキテクチャパターンの中から最適解を選ぶ力が必要になる。

受験時点でのAWS実務経験は約1.5年。仕事をしながらの学習で、まとまった時間の確保が難しかった。平日の通勤時間や昼休みなど、隙間時間を使った勉強がメインという制約があった。

そんな中で編み出したのが「サービス別ノート勉強法」だ。結論として、この方法は合格に効いた。それ以上に、試験後も実務で参照できる「自分だけのリファレンス」が手元に残ったのが大きな副産物だった。

勉強法の核心 — 問題軸ではなくサービス軸で整理する

使った教材は Udemyの模擬試験問題集。これをひたすら解く。ここまではよくある勉強法だと思う。

ポイントはその先にある。正解・不正解を問わず、自分が理解できていない・覚えていない箇所をサービス別に整理・まとめていく。

なぜ「問題別」ではなく「サービス別」なのか。

問題別のまとめ は、「この問題の答えはC」という暗記になりやすい。問題の文言が変わると対応できない
サービス別のまとめ は、そのサービスの仕様・ユースケース・制約を体系的に理解することになる。問題のバリエーションに強い

たとえば、Kinesis Data Streamsの問題を間違えたら、その問題の解説だけでなく「Kinesis Data Streams」というノートにシャードの仕様、SQSとの使い分け、拡張ファンアウトの条件など、関連する知識をどんどん追記していく。

こうすると、同じサービスに関する問題を何度か間違えるうちに、ノートが充実していく。5回目くらいには「ああ、またKinesisか」と、そのサービスの全体像が頭に入っている状態になる。

具体的なやり方 — Slack DMをクロスデバイスメモ帳として使う

ノートの記録先には Slackの自分宛DM を使った。

なぜSlackか:

デスク（PC）でも移動中（スマホ）でも書ける・読める — クロスデバイスで同期される
検索が効く — 「Kinesis」で検索すれば関連メモがすぐ出てくる
書くハードルが低い — きちんとしたドキュメントではなく、メモ書きでいい。箇条書きでポイポイ放り込める
通知がこない — 自分宛DMなので誰にも邪魔されないし、邪魔もしない

やり方はシンプルだ:

Udemyの模擬試験を解く
解説を読みながら、理解が浅い箇所を見つける
Slack DMに「# サービス名」でメッセージを送り、仕様やユースケースをまとめる
同じサービスについて新しい知見があれば、既存のメッセージにスレッドで追記する
隙間時間にスマホで読み返す

とくに4が重要だ。スレッドで追記していくことで、1つのサービスに関する知識が1箇所に集約される。あとから読み返すときに「このサービスのことはここを見ればいい」という状態になる。

振り返り — この方法で得られたもの

この勉強法で得られたのは、単なる合格以上のものだった。

体系的な理解: サービスごとに整理することで、「このサービスは何のために存在し、どんな課題を解決するのか」という設計意図が見えるようになった。たとえばSQSとKinesisの違いは、暗記ではなく「メッセージング vs ストリーミング」という設計思想の違いとして理解できた。

判断力: 似たサービスの使い分けの軸が整理された。「リアルタイム性が要件ならKinesis、順序を問わない非同期処理ならSQS」「S3直接アクセスでいいのか、CloudFront経由にすべきか」のような判断基準が自分の言葉で語れるようになった。SAP試験はまさにこの判断力を問う試験なので、相性が良かったと思う。

試験後も使えるリファレンス: 実務でAWSのアーキテクチャを検討するとき、自分が作ったノートを参照することがある。公式ドキュメントより「自分がつまずいたポイント」が凝縮されているので、効率がいい。

サービス別ノートの全文

学習中にまとめたサービス別ノートの内容を、ユースケースと判断軸ベースで再構成した記事を公開しています。「どのサービスをどの条件で選ぶか」を整理したノートとして、試験対策や実務のリファレンスに使えるはずです。

AWS SAP サービス別ノート — ユースケースと判断軸で整理する

VyOSによるAWS VPN接続

Sun, 20 Nov 2022 00:00:00 +0000

0. Overview

White Paper

https://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-vpc-connectivity-options/aws-managed-vpn.html

Diagram

VyOS Version

vyos@vyos:~$ show version
Version: VyOS 1.4-rolling-202211190627
Release train: current

Built by: autobuild@vyos.net
Built on: Sat 19 Nov 2022 06:27 UTC
Build UUID: 687dfd47-11ca-4c0c-8045-944ed60279be
Build commit ID: cd6f8ab1040139

Architecture: x86_64
Boot via: installed image
System type: KVM guest

Hardware vendor: innotek GmbH
Hardware model: VirtualBox
Hardware S/N: 0
Hardware UUID: 91d658fc-16f6-074b-b5a6-59f4f5c3c14b

Copyright: VyOS maintainers and contributors

1. VyOS initial Settings

Virtual Box

Enable LAN3 as Host Only Adaptor

VyOS Config

//After boot
$ install image //各種設定の後、CDを取り出し再起動。

//SSH Settings
set interfaces ethernet eth2 address '169.254.153.1/16'
set interfaces ethernet eth2 description 'HOST-Only'
set service ssh
set system time-zone 'Asia/Tokyo'

2. Connect to Internet

Virtual Box

Enable LAN1 as NAT

VyOS Config

//ADD
set interfaces ethernet eth0 address 'dhcp'

//Routing Table
vyos@vyos:~$ show ip route
~~
S>* 0.0.0.0/0 [210/0] via 10.0.2.2, eth0, 00:00:11
C>* 10.0.2.0/24 is directly connected, eth0, 00:00:13
C>* 169.254.0.0/16 is directly connected, eth2, 00:07:14

//Ping
vyos@vyos:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=56 time=27.054 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=17.119 ms

3. Configure of IPSEC

VyOS 1.4から諸々設定が変更となっているため注意！

Configration for VyOS IPSec-1

## ESP & IKE
set vpn ipsec esp-group AWS lifetime '3600'
set vpn ipsec esp-group AWS mode 'tunnel'
set vpn ipsec esp-group AWS pfs 'enable'
set vpn ipsec esp-group AWS proposal 1 encryption 'aes128'
set vpn ipsec esp-group AWS proposal 1 hash 'sha1'
set vpn ipsec ike-group AWS dead-peer-detection action 'restart'
set vpn ipsec ike-group AWS dead-peer-detection interval '15'
set vpn ipsec ike-group AWS dead-peer-detection timeout '30'
set vpn ipsec ike-group AWS lifetime '28800'
set vpn ipsec ike-group AWS proposal 1 dh-group '2'
set vpn ipsec ike-group AWS proposal 1 encryption 'aes128'
set vpn ipsec ike-group AWS proposal 1 hash 'sha1'

## vti
set interfaces vti vti0 address '169.254.244.110/30'
set interfaces vti vti0 description 'VPC tunnel 1'
set interfaces vti vti0 mtu '1436'

## IPSec
set vpn ipsec site-to-site peer AWS authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer AWS authentication pre-shared-secret 'YOUR_PRE_SHARED_SECRET'
set vpn ipsec site-to-site peer AWS description 'VPC tunnel 1'
set vpn ipsec site-to-site peer AWS ike-group 'AWS'
set vpn ipsec site-to-site peer AWS local-address '10.0.2.15'
set vpn ipsec site-to-site peer AWS remote-address 'xx.xx.xx.xx'
set vpn ipsec site-to-site peer AWS vti bind 'vti0'
set vpn ipsec site-to-site peer AWS vti esp-group 'AWS'
### for NAT-T
set vpn ipsec site-to-site peer AWS authentication local-id 'yy.yy.yy.yy'
set vpn ipsec site-to-site peer AWS authentication remote-id 'xx.xx.xx.xx'

//BGP Config
set protocols bgp system-as '65000'
set protocols bgp neighbor 169.254.244.109 address-family ipv4-unicast soft-reconfiguration inbound
set protocols bgp neighbor 169.254.244.109 remote-as '64512'
set protocols bgp neighbor 169.254.244.109 timers holdtime '30'
set protocols bgp neighbor 169.254.244.109 timers keepalive '10'
set protocols bgp address-family ipv4-unicast network 10.0.2.0/24

Note

bgp soft reconfigreationの設定がVyOS1.2より変更となっているため注意

VyOS1.2.x系の設定で死ぬほどハマった話
set protocols bgp 65000 neighbor 169.254.233.169 address-family ipv4-unicast soft-reconfiguration inbound
# この事前設定により、ソフトウェアは、アップデートがインバウンド ポリシーによって受け入れられるかどうかに関係なく、受信したすべてのアップデートを変更せずに保存します。
# アップデートの保存は大量のメモリを要するため、可能な限り回避する必要があります。
VyOSでのNATトラバーサル設定

https://changineer.info/network/vyatta/vyatta_ipsec_nat.html

4. AWS Setting

ルートテーブルでルート伝搬（VGWが受信したルートをルートテーブルに反映させる）を有効化

5. 確認

AWS => VyOS

:~/environment/ans-exam (master) $ ping 10.0.2.15
PING 10.0.2.15 (10.0.2.15) 56(84) bytes of data.
64 bytes from 10.0.2.15: icmp_seq=1 ttl=64 time=19.6 ms
64 bytes from 10.0.2.15: icmp_seq=2 ttl=64 time=18.2 ms

VyOS => AWS

vyos@vyos:~$ ping 10.99.31.172 source-address 10.0.2.15
PING 10.99.31.172 (10.99.31.172) from 10.0.2.15 : 56(84) bytes of data.
64 bytes from 10.99.31.172: icmp_seq=1 ttl=254 time=16.3 ms
64 bytes from 10.99.31.172: icmp_seq=2 ttl=254 time=30.0 ms
64 bytes from 10.99.31.172: icmp_seq=3 ttl=254 time=24.4 ms
64 bytes from 10.99.31.172: icmp_seq=4 ttl=254 time=18.3 ms

Posts on 図解 わかりやすいAWS

Claude Managed Agents — Anthropicが提供するフルマネージドAIエージェント基盤

何を解決するサービスか

具体的な利用イメージ

例: セキュリティアラート分析エージェント

自前構築との比較

アーキテクチャ — 「脳と手の分離」

3コンポーネント分離

コンテナのオンデマンドプロビジョニング

障害回復

セキュリティ — クレデンシャルがサンドボックスに渡らない

4つの核心概念

ビルトインツール

APIの使い方（Python SDK）

料金体系

Anthropicの3つのエージェント提供形態の比較

早期採用企業

Research Preview機能（アクセス申請が必要）

参考リンク

AWS SAP サービス別ノート — ユースケースと判断軸で整理する

1. リアルタイムデータ処理

なぜ複数の選択肢があるのか

Kinesis Data Streams vs SQS — 判断軸

Kinesis Data Streams の詳細

概念

データの書き込み

データの読み取り

拡張ファンアウト（Enhanced fan-out）

リシャーディング

セキュリティ

SQS のポイント

デッドレターキュー（DLQ）

Amazon MQ

2. 認証・認可パターン

なぜ複数の選択肢があるのか

STS — 一時的なセキュリティ認証情報の5つのAPI

モバイルアプリの認証 — Cognito vs STS直接呼び出し

API Gateway の認証 — Lambda オーソライザー

3. コンテンツ配信とアクセス制御

なぜ複数の選択肢があるのか

S3署名付きURL vs CloudFront署名付きURL

署名付きURL vs 署名付きCookie

S3オリジンへのアクセス制御 — OAC（Origin Access Control）

地理的なアクセス制限

キャッシュの最適化

Originのプロトコル設定

Lambda@Edge

4. データベース選択

DynamoDB

基本特性

キー設計 — DynamoDBの最重要ポイント

FGAC（Fine Grained Access Control）

キャパシティユニット計算

キャパシティモード

DynamoDB Streams

DynamoDBトランザクション

Cross-Region Replication

RDS Proxy

Redshift — Concurrency Scaling（同時実行スケーリング）

5. ネットワーク設計

Global Accelerator

Direct Connect

Transit Gateway Network Manager

EC2 プレイスメントグループ

EC2 インスタンスの選択

EC2 ネットワーク

EC2 AutoScaling メトリクス

ELB

BYOIP（自組織のグローバルIP持ち込み）

RD Gateway Server

6. セキュリティ

AWS Shield — Standard vs Advanced

CloudHSM vs KMS — 暗号化キーの管理

CloudHSMによるSSL/TLSオフロード

AWS Organizations — マルチアカウント管理

SCP（Service Control Policy）

2つの機能セット

その他のポイント

AWS Control Tower

Amazon Inspector

Posts on 図解わかりやすいAWS