Share
Embed
Slide 1
Slide 1 text
AWS ハンズオン研修
2026
株式会社サイバーエージェント
茨木 啓瑚（いばらき けいご）
Slide 2
Slide 2 text
1. 講師紹介
2. 本日の流れ・目的
3. セットアップ
4. AWS リソースに触れる
5. Terraform ハンズオン
6. AWS ハンズオン
7. その他
2
Slide 3
Slide 3 text
講師紹介
3
Slide 4
Slide 4 text
茨木 啓瑚（いばらき けいご）
● 所属
○ 株式会社 WinTicket
● 業務内容
○ メディアアセット管理× ML 促進基盤の構築
● 横軸
○ AWS Community Builder 2026 AI Engineer
@oyasumi_pants
4
Slide 5
Slide 5 text
本日の流れ・目的
5
Slide 6
Slide 6 text
本日の目標
● チーム開発のインフラ構築を “スムーズに” 行えるようにする
● AWS リソースに対する知識的な “インデックス” を張る
※ 実際の開発で様々な AWS リソースに触れられるように
● “IaC(Terraform)” を通じて AWS リソースを構築できるようになる
6
Slide 7
Slide 7 text
本研修のゴール
バックエンド
開発に必要なインフラ構築と IaC 操作を自走できるようになる
フロントエンド・ゲームクライアント・ネイティブ・ML/DS・etc...
インフラ構築のイメージを掴み、PR から概要を読み取れるようになる
インフラ
AWS や IaC の理解を深め、他職種に教えられるレベルを目指す
7
Slide 8
Slide 8 text
セットアップ
8
Slide 9
Slide 9 text
Homebrew のインストール（for Mac）
ホームページからインストール
インストール
$ /bin/bash -c "$(curl -fsSL
https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
確認
$ brew -v
> Homebrew 4.4.28
https://brew.sh/ja/
9
Slide 10
Slide 10 text
AWS CLI
● AWS Command Line Interface (AWS CLI)
● AWS のサービスを CLI で管理するための統合ツール
● AWS のリソースの確認・作成・削除ができます
aws コマンド
を打てるように！
10
Slide 11
Slide 11 text
AWS CLI のインストール （Mac）
● AWS CLI の最新バージョンのインストールまたは更新
インストール
$ curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
$ sudo installer -pkg AWSCLIV2.pkg -target /
（Homebrew が入っていれば...）
$ brew install awscli
確認
$ which aws
$ aws --version
11
Slide 12
Slide 12 text
AWS CLI のインストール（Win）
● AWS CLI の最新バージョンのインストールまたは更新
インストール
C:\> msiexec.exe /i https://awscli.amazonaws.com/AWSCLIV2.msi
C:\> msiexec.exe /i https://awscli.amazonaws.com/AWSCLIV2.msi /qn
確認
C:\> aws --version
12
Slide 13
Slide 13 text
AWS アカウントの準備
● 自分の AWS アカウントで進める前提です
● ルートユーザーではなく、AdministratorAccess を付けた
IAM ユーザーのアクセスキーを使ってください
● IAM ユーザーの作り方は 公式ドキュメント を参照してください
13
Slide 14
Slide 14 text
AWS CLI の認証設定（アクセスキー）
IAM ユーザーのアクセスキーで設定する
設定
$ aws configure --profile default
> AWS Access Key ID: AKIAXXXXXXXXXXXXXXXX
> AWS Secret Access Key: ****
> Default region name: ap-northeast-1
確認
$ aws sts get-caller-identity --profile default
> "Account": "123456789012"
※ ルートユーザーのアクセスキーは使わない。発行したキーはリポジトリに commit しない
https://docs.aws.amazon.com/ja_ jp/cli/latest/userguide/cli-authentication-user.html
14
Slide 15
Slide 15 text
tfstate 用 S3 バケットの作成
Terraform の state を置くバケットを先に作る
作成
$ aws s3 mb s3://myproject-terraform-state \
--region ap-northeast-1 --profile default
> make_bucket: myproject-terraform-state
※ バケット名は全世界で一意。myproject は自分の識別子に置き換え、後の make setup の BUCKET_PREFIX と揃える
※ 作成できたかは次の aws s3 ls で確認する
https://docs.aws.amazon.com/ja_ jp/cli/latest/reference/s3/mb.html
15
Slide 16
Slide 16 text
AWS CLI を実行する
4. AWS CLI の実行
option: profile, region, etc...
※ default 以外の profile を使うときは、環境変数
か --profile で指定する
AWS_PROFILE
command: s3, ec2, iam, etc...
$ aws s3 ls --profile=default
> 2026-04-10 00:02:39 myproject-terraform-state
今回はバケットの
情報が出れば OK
16
Slide 17
Slide 17 text
Terraform のインストール（Mac）
brew 経由で install する
インストール
$ brew tap hashicorp/tap
$ brew install hashicorp/tap/terraform
確認
$ terraform -version
> Terraform v1.14.0
https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli
17
Slide 18
Slide 18 text
Terraform のインストール（Win）
binary package 経由で install する
確認
C:\> terraform -version
> Terraform v1.14.0
https://developer.hashicorp.com/terraform/install
18
Slide 19
Slide 19 text
Docker CLI のインストール（Mac）
Rancher Desktop 経由でインストール
インストール
$ brew install --cask rancher
確認
$ docker -v
> Docker version 28.x.x ...
※ 初回起動時: Container Engine → dockerd (moby) を選択、Kubernetes は無効で OK
※ Docker Desktop を使う場合はライセンス条件を確認してください
https://rancherdesktop.io/
19
Slide 20
Slide 20 text
Docker CLI のインストール（Win）
Rancher Desktop 経由でインストール
問題が発生した場合
公式ドキュメントを確認してください
https://rancherdesktop.io/
20
Slide 21
Slide 21 text
Docker コマンドの検証
アプリケーションを起動後
確認
$ docker -v
> Docker version 28.0.4, build b8034c0
https://docs.rancherdesktop.io/getting-started/installation/
21
Slide 22
Slide 22 text
Docker Desktop について
● Docker Desktop は条件によっては
“ライセンス料金” が発生します
● 会社で使う場合は下記ページの契約条件（従業員数・売上規模）を確認してください
https://www.docker.com/ja-jp/pricing/
22
Slide 23
Slide 23 text
AWS リソースに触れる
23
Slide 24
Slide 24 text
前提の共有
● 資料がかなり多いので、全部は触れられない想定で作っています
● 限られた時間の中でなるべく多くのリソースをキャッチアップでき
るように進めます
● 辞書的に使ってもらえると嬉しいです
24
Slide 25
Slide 25 text
様々な AWS リソースを知ろう
目次
1. 構成図で全体を把握する
6. Storage
2. Network, CDN
7. Application Integration
3. Compute, Containers
8. Management & Governance
4. Database
9. Developer Tools
5. Security, Identity & Compliance
10. Artificial Intelligence
25
Slide 26
Slide 26 text
様々な AWS リソースを知ろう
目次
1. 構成図で全体を把握する
6. Storage
2. Network, CDN
7. Application Integration
3. Compute, Containers
8. Management & Governance
4. Database
9. Developer Tools
5. Security, Identity & Compliance
10. Artificial Intelligence
26
Slide 27
Slide 27 text
様々な AWS リソースを知ろう
27
Slide 28
Slide 28 text
様々な AWS リソースを知ろう
目次
1. 構成図で全体を把握する
6. Storage
2. Network, CDN
7. Application Integration
3. Compute, Containers
8. Management & Governance
4. Database
9. Developer Tools
5. Security, Identity & Compliance
10. Artificial Intelligence
28
Slide 29
Slide 29 text
構成図から確認すると
CDN 周りも扱う
Network 全般
29
Slide 30
Slide 30 text
取り扱うサービスの紹介
Network, CDN サービス
VPC
Subnet
Route Table
Internet
Gateway
NAT Gateway
Network
ACL
Elastic
Load
Balancing
Route53
CloudFront
API Gateway
Security
Group
30
Slide 31
Slide 31 text
取り扱うサービスの紹介
Network, CDN サービス
VPC
Subnet
Route Table
Internet
Gateway
NAT Gateway
Network
ACL
Elastic
Load
Balancing
Route53
CloudFront
API Gateway
Security
Group
31
Slide 32
Slide 32 text
VPC - Virtual Private Cloud VPC とは？
● AWS クラウド上のプライベートネットワーク空間
● 論理的なネットワーク分離が可能
● ネットワーク環境のコントロールが可能
https://aws.amazon.com/jp/blogs/news/webinar-bb-amazonvpc-2020/
32
Slide 33
Slide 33 text
VPC - Virtual Private Cloud 10.0.0.0/16
図解
大きな枠として
プライベートなネットワーク
空間を敷く
https://aws.amazon.com/jp/blogs/news/webinar-bb-amazonvpc-2020/
33
Slide 34
Slide 34 text
取り扱うサービスの紹介
Network, CDN サービス
VPC
Subnet
Route Table
Internet
Gateway
NAT Gateway
Network
ACL
Elastic
Load
Balancing
Route53
CloudFront
API Gateway
Security
Group
34
Slide 35
Slide 35 text
Subnet
Subnet とは？
● Subnet は VPC 内の区切られた IP アドレスの範囲
● Public Subnet はインターネットへの直接アクセスが 可能
● Private Subnet はインターネットから直接アクセスが 不可能
● 多層アプリケーションのセキュリティ設計で重要
35
Slide 36
Slide 36 text
Subnet
10.0.0.0/16
図解
10.0.1.0/24
VPC の中にサブネットを切り
その中で EC2 が動く
パブリック
サブネット
https://aws.amazon.com/jp/blogs/news/webinar-bb-amazonvpc-2020/
36
Slide 37
Slide 37 text
Route Table
Route Table とは？
● VPC 内のネットワークトラフィックを制御するためのルールセット
● どのサブネットからどこへのトラフィックをルーティングするかを定義する
● サブネットからインターネットへの通信制御など、ネットワークフローの管理に不可欠
37
Slide 38
Slide 38 text
Internet Gateway
Internet Gateway とは？
● VPC とインターネットを接続するためのコンポーネント
● 双方向の通信を可能にし、パブリックサブネット内のリソース
がインターネットにアクセスできるようにする
38
Slide 39
Slide 39 text
インターネットへの接続
10.0.0.0/16
図解
サブネットからインターネッ
トへのルーティングを定義
インターネットや
VPC 外の AWS リソースへの
アクセスが可能になる
10.0.1.0/24
パブリック
サブネット
https://aws.amazon.com/jp/blogs/news/webinar-bb-amazonvpc-2020/
39
Slide 40
Slide 40 text
NAT Gateway
NAT Gateway とは
● プライベートサブネット内のリソースがインターネットにアクセ
スするための経路
● 送信トラフィックのみを許可し、外部からの接続はブロックする
● プライベートサブネット内のサーバーがパッチダウンロードや
API アクセスなどでインターネット接続が必要な場合に使用
40
Slide 41
Slide 41 text
インターネットへの接続
10.0.0.0/16
図解
OS のアップデートや
アプリケーションのダウンロードなど
プライベートサブネットから
インターネットへの接続を可能にする
DB など直接インターネットから
アクセスできないようにする
10.0.2.0/24
10.0.1.0/24
NAT
Gateway
プライベート
パブリック
サブネット
サブネット
https://aws.amazon.com/jp/blogs/news/webinar-bb-amazonvpc-2020/
41
Slide 42
Slide 42 text
VPC Endpoint（appendix）
VPC Endpoint とは
● AWS サービスにプライベートに接続するためのゲートウェイ
● インターネットを経由せずに S3 や DynamoDB などのサービ
スにアクセスできる
● セキュリティ強化とデータ転送コスト削減の可能性がある
42
Slide 43
Slide 43 text
VPC Endpoint（appendix）
VPC Endpoint とは
● VPC Endpoint は、グローバ
ル IP を持つ AWS サービスに
VPC
Endpoint
対して、VPC 内部から直接アク
セスするための出口
NAT Gateway
との使い分けを調査しよう
https://aws.amazon.com/jp/blogs/news/webinar-bb-amazonvpc-2020/
43
Slide 44
Slide 44 text
取り扱うサービスの紹介
Network, CDN サービス
VPC
Subnet
Route Table
Internet
Gateway
NAT Gateway
Network
ACL
Elastic
Load
Balancing
Route53
CloudFront
API Gateway
Security
Group
44
Slide 45
Slide 45 text
Security Group
Security Group とは
● インスタンスレベルのファイアウォール
● ステートフルで、許可ルールのみ設定可能
● セキュリティグループを初めて作成した場合、インバウンドルール
がない（=インバウンドトラフィックが許可されない）ので注意
https://aws.amazon.com/jp/blogs/news/webinar-bb-amazonvpc-2020/
45
Slide 46
Slide 46 text
Network ACL
Network ACL とは
● Network Access Control List の略称
● サブネットレベルのファイアウォール
● ステートレスで、許可と拒否の両方のルールを設定可能
https://aws.amazon.com/jp/blogs/news/webinar-bb-amazonvpc-2020/
46
Slide 47
Slide 47 text
インターネットへの接続
10.0.0.0/16
図解
10.0.2.0/24
10.0.1.0/24
セキュリティグループは
インスタンスレベルでの
ファイアウォール
例えば 3306 ポートへの
TCP インバウンド通信を許可など
プライベート
パブリック
サブネット
サブネット
NACL はサブネットレベルでの
ファイアウォール
47
Slide 48
Slide 48 text
SG vs Network ACL
Security Group
Network ACL
サーバーレベルで効果
サブネットレベルで効果
Allow のみを IN・OUT で指定可能
Allow/Deny を IN・OUT で指定可能
ステートフルなので
戻りのトラフィックを考慮しなくて良い
ステートレスなので
戻りのトラフィックも明示的に設定
全てのルールを適用
番号の順序通りに適用
インスタンス管理者が Security Group
を適用すればその管理下になる
Subnet 内の全てのインスタンスが
ACL の管理下に入る
https://aws.amazon.com/jp/blogs/news/webinar-bb-amazonvpc-2020/
48
Slide 49
Slide 49 text
取り扱うサービスの紹介
Network, CDN サービス
VPC
Subnet
Route Table
Internet
Gateway
NAT Gateway
Network
ACL
Elastic
Load
Balancing
Route53
CloudFront
API Gateway
Security
Group
49
Slide 50
Slide 50 text
ELB - Elastic Load Balancing ELB とは
● スケーラビリティ・アベイラビリティを兼ね備えたロードバランサー
● ELB 自体がオートスケール可能
● マネージド運用が可能で、従量課金で利用可能
● Auto Scaling や Route53 などの他サービスと連携可能
https://www.youtube.com/watch?v=gKCK0RDAhnw
50
Slide 51
Slide 51 text
ELB - Elastic Load Balancing 負荷分散
EC2
Elastic
Load
Balancing
https://www.youtube.com/watch?v=gKCK0RDAhnw
EC2
EC2
51
Slide 52
Slide 52 text
ELB - Elastic Load Balancing 負荷分散
バックエンドのサービスの
リクエスト数やコネクション数が
均等になるように負荷分散
EC2
負荷が高まったら
インスタンスを 追加
リクエスト数が 増加
Elastic
Load
Balancing
EC2
EC2
https://www.youtube.com/watch?v=gKCK0RDAhnw
52
Slide 53
Slide 53 text
取り扱うサービスの紹介
Network, CDN サービス
VPC
Subnet
Route Table
Internet
Gateway
NAT Gateway
Network
ACL
Elastic
Load
Balancing
Route53
CloudFront
API Gateway
Security
Group
53
Slide 54
Slide 54 text
Route53
Route53 とは
● スケーラブルな DNS サービス
● ドメイン名の登録・権威 DNS サービス・DNS リゾルバー・Disaster
recovery 等を提供する
● 複数のルーティングポリシーを提供（シンプル・加重・地理的）
https://www.youtube.com/watch?v=Yi-e5O_ jd6o
54
Slide 55
Slide 55 text
DNS - Domain Name System ● FQDN に対する IP アドレスなどの情報を取得する仕組み
● DNS から情報取得することを「 名前解決 (Name Resolution) 」と呼ぶ
● 各ネームサーバーが管理する名前空間を「 ゾーン (Zone) 」と呼ぶ
www.example.com.
Fully Qualified Domain Name
完全修飾ドメイン名
.com を管理する
.（ルート）
を管理する
ネームサーバー
generic Top-Level Domain
（.com, .net, .org ...etc）
ネームサーバーへ
www.example.com.
www.example.com.
192.0.2.3
.example.com を管理する
.com.（gTLD）
を管理する
ネームサーバー
ネームサーバーへ
www.example.com.
192.0.2.3
.example.com.
を管理する
ネームサーバー
フルサービスリゾルバー
https://www.youtube.com/watch?v=Yi-e5O_ jd6o
55
Slide 56
Slide 56 text
権限委譲（Delegation）
● 親ゾーンから子ゾーンのネームサーバーを FQDN で指し示すことで権限を委譲
権限委譲先のネームサーバーを
FQDN で指し示す
親ゾーン
example.com.
01.example.com.
Delegation
（権限委譲）
3600 IN NS
ns-01.awsdns-01.co.uk
ns-02.awsdns-02.net
ns-03.awsdns-03.org
ns-04.awsdns-04.com
3600 IN NS
ns-01.awsdns-01.co.uk
ns-02.awsdns-02.net
ns-03.awsdns-03.org
ns-04.awsdns-04.com
ns1.example.com.
ns2.example.com.
子ゾーン
01.example.com.
01.example.com.
ns1.example.com.
ns2.example.com.
56
Slide 57
Slide 57 text
A レコードと エイリアスレコード
子ゾーン
01.example.com.
レコード名
TTL/タイプ
値/ルーティング先
01.example.com.
3600 NS
ns-01.awsdns-01.co.uk
ns-02.awsdns-02.net
ns-03.awsdns-03.org
ns-04.awsdns-04.com
app.01.example.com.
300 A
192.0.2.100
alb.01.example.com.
-
dualstack.my-app-alb-12
34.elb.amazonaws.com.
A レコード
標準的な DNS の機能で
固定の IP に向けるためのレコード
A
エイリアス レコード
Route53 の機能で
ELB などの AWS リソースに向けることが可能
57
Slide 58
Slide 58 text
取り扱うサービスの紹介
Network, CDN サービス
VPC
Subnet
Route Table
Internet
Gateway
NAT Gateway
Network
ACL
Elastic
Load
Balancing
Route53
CloudFront
API Gateway
Security
Group
58
Slide 59
Slide 59 text
CloudFront
CloudFront とは
● グローバルな CDN（コンテンツ配信ネットワーク）サービス
● 静的・動的コンテンツをエッジロケーションからユーザーに低
レイテンシーで配信する
● ユーザー体験の向上とオリジンサーバーの負荷軽減に効果的
59
Slide 60
Slide 60 text
エッジサービス
インターネットの利用区間を
なるべく短く
より長い区間を
AWS global network で
AWS global
network
エンドユーザーの近くで DNS 名前解決、コンテンツ配信
https://aws.amazon.com/jp/blogs/news/webinar-bb-amazon-cloudfront-deep-dive-2020/
60
Slide 61
Slide 61 text
CloudFront
● ユーザーを一番近いエッジロケーションに誘導することで 配信を高速化
● エッジサーバーでコンテンツのキャッシングを行い オリジンの負荷をオフロード
クライアント
1. HTTP のリクエスト
高速化
5. コンテンツの取得
2. HTTP のリクエスト
6. HTTP のリクエスト
3. コンテンツの取得
7. コンテンツの取得
レスポンス
CloudFront
4. コンテンツをキャッシュ
オリジンサーバー
負荷軽減
https://aws.amazon.com/jp/blogs/news/webinar-bb-amazon-cloudfront-deep-dive-2020/
61
Slide 62
Slide 62 text
取り扱うサービスの紹介
Network, CDN サービス
VPC
Subnet
Route Table
Internet
Gateway
NAT Gateway
Network
ACL
Elastic
Load
Balancing
Route53
CloudFront
API Gateway
Security
Group
62
Slide 63
Slide 63 text
API Gateway
API Gateway とは
● API の作成、公開、管理、モニタリングを行うサービス
● 認証、スロットリング、リクエスト/レスポンスの変換などの機能
● Lambda と組み合わせてサーバーレス API を構築可能
63
Slide 64
Slide 64 text
API Gateway が扱う API
API Gateway は REST 系（REST・HTTP）と WebSocket の API を扱える
REST
● REST = Representational State Transfer
● 単一 HTTP メッセージで 1 つの操作に対する情報を含む
● 扱う情報を URI で表現する「リソース」として定義し、それらを
HTTP メソッド（PUT, GET, POST, DELETE, …）の表現で操作
WebSocket
API Gateway
● HTTP の上で、クライアントとサーバー間の双方向通信を実現す
るための通信仕様
● 1 つのコネクションで継続的なデータ送受信が可能
● URI スキームはセキュア WebSocket 用の「wss://~」を利用
https://d1.awsstatic.com/webinars/jp/pdf/services/20190514_AWS-Blackbelt_APIGateway_rev.pdf
64
Slide 65
Slide 65 text
様々な AWS リソースを知ろう
目次
1. 構成図で全体を把握する
6. Storage
2. Network, CDN
7. Application Integration
3. Compute, Containers
8. Management & Governance
4. Database
9. Developer Tools
5. Security, Identity & Compliance
10. Artificial Intelligence
65
Slide 66
Slide 66 text
取り扱うサービスの紹介
Compute, Containers サービ ス
EC2
Fargate
Lambda
ECS
EKS
ECR
66
Slide 67
Slide 67 text
構成図から確認すると
サーバーレスサービスも扱う
アプリケーションが動く
サーバー
67
Slide 68
Slide 68 text
取り扱うサービスの紹介
Compute, Containers サービ ス
EC2
Fargate
Lambda
ECS
EKS
ECR
68
Slide 69
Slide 69 text
オーケストレーターと実行環境
図解
コンテナ
オーケストレーター
（コントロールプレーン）
ECS
EKS
EC2
Fargate
コンテナの実行環境
（データプレーン）
69
Slide 70
Slide 70 text
オーケストレーター
図解
コンテナ
オーケストレーター
（コントロールプレーン）
ECS
EKS
EC2
Fargate
コンテナの実行環境
（データプレーン）
70
Slide 71
Slide 71 text
ECS - Elastic Container Service ECS とは
● AWS のコンテナオーケストレーションサービス
● EC2 または Fargate で実行可能
● AWS 独自のコンテナ管理を行う
71
Slide 72
Slide 72 text
EKS - Elastic Kubernetes Service EKS とは
● Kubernetes を実行するためのマネージドサービス
● セキュリティ、ネットワーク、ストレージなど、様々な AWS
サービスと連携可能
● アップストリーム版の Kubernetes との準拠性が認証済み
72
Slide 73
Slide 73 text
実行環境
図解
コンテナ
オーケストレーター
（コントロールプレーン）
ECS
EKS
EC2
Fargate
コンテナの実行環境
（データプレーン）
73
Slide 74
Slide 74 text
EC2 - Elastic Compute Cloud EC2 とは
● 仮想サーバーを構築・管理するサービス
● OS からアプリまで全て管理可能
● EC2 は柔軟性が高いが管理コストも高い
74
Slide 75
Slide 75 text
Fargate
Fargate とは
● コンテナを実行するサーバーレスコンピューティングエンジン
● EC2 に比べてインフラの管理が容易
● サーバー管理が不要で簡単だが、カスタマイズ性に制限がある
75
Slide 76
Slide 76 text
サーバーレスとは？
サーバーの管理が不要
（準備、OS 保守、etc）
柔軟なスケーリング
（拡張/縮退）
ユーザーの責任領域を
小さくしそこだけに注力
十二分に考慮された
高可用性
アイドル時の
リソース確保が不要
実際の処理負荷に応じて
自動で拡張/縮退
高生産性
マネージド
業務注力
スケーラビリティ
（機会損失防止）
マネージド
自動リソース管理
変更容易性
エンジニア
意識改革
リアルタイム
（付加価値/機能差別化）
コスト最適化
https://www.slideshare.net/slideshow/20201118-aws-black-belt-online-seminar/239325435
76
Slide 77
Slide 77 text
ECS, EKS × EC2, Fargate
ECS on Fargate
コンテナ
オーケストレーター
（コントロールプレーン）
ECS
EKS
EC2
Fargate
コンテナの実行環境
（データプレーン）
77
Slide 78
Slide 78 text
ECS, EKS × EC2, Fargate
EKS on EC2
コンテナ
オーケストレーター
（コントロールプレーン）
ECS
EKS
EC2
Fargate
コンテナの実行環境
（データプレーン）
78
Slide 79
Slide 79 text
ECS/EKS におけるコンテナ実行環境
ECS on Fargate
ECS on EC2
EKS on EC2
（セルフマネージド型ノード）
EKS on EC2
（マネージド型ノードグループ）
EKS on Fargate
抽象度のレベル
アプリケーションコンテナ
アプリケーションコンテナ
アプリケーションコンテナ
ホストのスケジューリング
ホストのスケジューリング
ホストのスケジューリング
コンテナエージェントの設定
コンテナエージェントの設定
コンテナエージェントの設定
ホストの OS / ライブラリ選定
ホストの OS / ライブラリ選定
ホストの OS / ライブラリ選定
自分たちで管理するレイヤー
https://aws.amazon.com/jp/blogs/news/aws-black-belt-online-seminar-con202-ecs-fargate-overview/
AWS が提供するレイヤー
79
Slide 80
Slide 80 text
ECS on Fargate 構成要素
Docker
イメージ
コンテナ
Docker
イメージ
コンテナ
タスク定義
● タスク定義に基づき
起動されるコンテナ群
● タスク内コンテナは
同一ホスト上で実行
タスク
参照
サービス
タスク定義を構成するコンテナ群定義
● コンテナ定義
● 要求 CPU, メモリ
● タスクに割り当てる IAM ロール
● etc...
クラスター
● 実行環境の境界
● IAM 権限の境界（クラスターに対する操作）
● スケジュールされたタスクの実行を設定可能
https://www.youtube.com/watch?v=stpz_SNiWmA&t=0s
●
●
●
●
タスク実行コピー数（n 個）を定義
起動後、タスク実行コピーを維持
ELB と連携
起動タイプ（EC2/Fargate）を設定
80
Slide 81
Slide 81 text
取り扱うサービスの紹介
Compute, Containers サービ ス
EC2
Fargate
Lambda
ECS
EKS
ECR
81
Slide 82
Slide 82 text
Lambda
Lambda とは
● サーバーレスコンピューティングサービスでコードを実行するためのインフラ
を管理せずに、関数単位でコードを実行できる
● イベント駆動型のアーキテクチャに適しており、使用した分だけ課金される
● バックエンド API の実装、イベント処理、スケジュールタスク、ファイル処理
など様々なユースケースに対応
https://aws.amazon.com/jp/blogs/news/webinar-bb-severless_usecase_pattern-2020/
82
Slide 83
Slide 83 text
Lambda と他の実行環境
EC2
Fargate
Lambda
アプリケーションコード
AMI（+ User data）
- サーバー/OS の設定
- ミドルウェア
- ランタイム
アプリケーションコンテナ
コンテナイメージ
アプリケーションコード
仮想マシン基盤
コンテナ
実行環境
自分たちで管理するレイヤー
アプリケーション
実行環境
AWS が提供するレイヤー
https://pages.awscloud.com/rs/112-TZM-766/images/BOS35_AWS-Builders-Online-Series_2022-Q1_Presentation-Deck.pdf
83
Slide 84
Slide 84 text
コンテナ or Lambda の判断
はい
アプリ
管理単位
は？
短期実行
max 15 分
または
非同期処理
いいえ
プラット
フォーム
コンテナ
はい
はい
10GB 以下
のメモリ
いいえ
CPU 処理
のみ
いいえ
はい
ステート
レス処理
Lambda
バースト
制限内
いいえ
Lambda
https://pages.awscloud.com/rs/112-TZM-766/images/BOS35_AWS-Builders-Online-Series_2022-Q1_Presentation-Deck.pdf
84
Slide 85
Slide 85 text
サーバーレス設計パターンの紹介
公式ドキュメントにて
サーバーレスサービスを使った
様々な設計パターンが
紹介されている
https://aws.amazon.com/jp/serverless/patterns/serverless-pattern/
85
Slide 86
Slide 86 text
取り扱うサービスの紹介
Compute, Containers サービ ス
EC2
Fargate
Lambda
ECS
EKS
ECR
86
Slide 87
Slide 87 text
Lambda Durable Functions
Durable Functions とは？
● Lambda 関数内でチェックポイントとリプレイにより耐久実行を実現
● steps（自動再試行）と waits（課金なしで最大 1 年停止）の 2 つの仕組み
● コールバックや条件待機で外部イベント（人的承認等）にも対応
● Durable execution SDK を追加するだけで既存の Lambda 関数を拡張可能
https://aws.amazon.com/jp/blogs/news/build-multi-step-applications-and-ai-workflows-with-aws-lambda-durable-functions/
87
Slide 88
Slide 88 text
ECR - Elastic Container Registry ECR とは
● Docker コンテナイメージを保存・管理するマネージドサービス
● プライベートリポジトリとしてイメージの共有やバージョン管理に使用できる
● Docker CLI を利用することが可能
https://aws.amazon.com/jp/blogs/news/aws-blackaws-black-belt-online-seminar-con241/
88
Slide 89
Slide 89 text
様々な AWS リソースを知ろう
目次
1. 構成図で全体を把握する
6. Storage
2. Network, CDN
7. Application Integration
3. Compute, Containers
8. Management & Governance
4. Database
9. Developer Tools
5. Security, Identity & Compliance
10. Artificial Intelligence
89
Slide 90
Slide 90 text
取り扱うサービスの紹介
Database サービス
RDS
Aurora
RDS Proxy
ElastiCache
DynamoDB
90
Slide 91
Slide 91 text
構成図から確認すると
サーバーレスサービスも扱う
RDBMS, NoSQL サービス
91
Slide 92
Slide 92 text
取り扱うサービスの紹介
Database サービス
RDS
Aurora
RDS Proxy
ElastiCache
DynamoDB
92
Slide 93
Slide 93 text
RDS - Relational Database Service RDS とは
● マネージドなリレーショナルデータベースサービス
● PostgreSQL、MySQL、MariaDB、Oracle、SQL Server、
Db2 などをクラウド上で簡単に使い始めることができる
● バックアップ、自動パッチ適用、スケーリング、監視などの管理作
業が自動化されている
https://aws.amazon.com/jp/rds/
93
Slide 94
Slide 94 text
Aurora
Aurora とは
● MySQL, PostgreSQL と互換性があり、低コストでハイパフォーマンスを発揮
することが可能
● 一瞬で数十万件のトランザクションまでスケールアップできる
Aurora
Serverless, Aurora I/O-Optimized によるコスト予測, Amazon Redshift
とのゼロ ETL 統合によるリアルタイム分析など、拡張機能も充実
https://aws.amazon.com/jp/blogs/news/data-modernization-day-japan3-20220901/
94
Slide 95
Slide 95 text
Aurora
構成要素
Availability
Zone1
Availability
Zone2
Availability
Zone3
SQL
SQL
SQL
Transactions
Transactions
Transactions
Caching
Caching
Caching
● Amazon Aurora DB クラスター
○ Amazon Aurora の管理単位
Shared storage volume
○ プライマリインスタンス、レプリカ、クラスターボ
リュームの総称
Availability
Zone1
Availability
Zone2
Availability
Zone3
SQL
SQL
SQL
● プライマリ DB インスタンス（Writer）
SQL
Transactions
○ 読み込み、書き込みを行うマスターインスタンス
Caching
Transactions
Caching
Transactions
Caching
Transactions
Caching
SQL
● Aurora レプリカ（Reader）
Transactions
○ 読み込みをスケールアウトさせるレプリカ（15 台まで）
Caching
Shared storage volume
Shared storage volume
● クラスターボリューム
（Aurora ストレージ）
○ 3 つの AZ 間でレプリケートされる仮想ボリューム
○ プライマリインスタンスもレプリカも同じものを使用
https://aws.amazon.com/jp/blogs/news/data-modernization-day-japan3-20220901/
95
Slide 96
Slide 96 text
RDS Proxy
RDS Proxy とは
● マネージドなデータベースプロキシサービス
● 接続プーリングや高速フェイルオーバーにより、アプリケーションの可用
性とパフォーマンスを向上
● Secrets Manager や IAM との連携で、認証情報の安全な管理も可能
https://www.youtube.com/watch?v=rwkRMmHC0zo
96
Slide 97
Slide 97 text
RDS Proxy 全体像
アプリケーション
RDS Proxy
RDS
接続プーリング
Fargate
シームレス
フェイルオーバー
RDS
アプリケーション
セキュリティの向上
Aurora
Lambda
IAM
Secrets Manager
https://www.youtube.com/watch?v=rwkRMmHC0zo
97
Slide 98
Slide 98 text
取り扱うサービスの紹介
Database サービス
RDS
Aurora
RDS Proxy
ElastiCache
DynamoDB
98
Slide 99
Slide 99 text
ElastiCache
ElastiCache とは
● Redis, Memcached, Valkey を提供するマネージドキャッシングサービス
● DB の前にキャッシュを置くことで、読み取り負荷を軽減し、レスポンス時間
を短縮できる
● セッション管理、リアルタイムランキング、キューなどにも使用可能
https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Amazon-ElastiCache_0228_v1.pdf
99
Slide 100
Slide 100 text
DynamoDB
DynamoDB とは
● フルマネージド NoSQL データベースサービス
● スケーラビリティに優れ、数 ms の応答時間を維持しながら無制限に拡張可能
● キーバリュー形式で柔軟なデータモデルを実現
● サーバーレスアプリケーションとの親和性も高い
https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Amazon-DynamoDB-How-it-works_1231_v1.pdf
100
Slide 101
Slide 101 text
DynamoDB のアーキテクチャ
書き込みリクエスト
読み込みリクエスト
ランダム負荷分散
書き込みリクエスト
パーティショニング
プライマリ
サーバー
リード
レプリカ
お互いに独立している
整合性が担保できない
プライマリサーバーで処理し、更新を反映
多数のサーバーで分散処理
101
Slide 102
Slide 102 text
様々な AWS リソースを知ろう
目次
1. 構成図で全体を把握する
6. Storage
2. Network, CDN
7. Application Integration
3. Compute, Containers
8. Management & Governance
4. Database
9. Developer Tools
5. Security, Identity & Compliance
10. Artificial Intelligence
102
Slide 103
Slide 103 text
取り扱うサービスの紹介
Security サービス
IAM
Secrets Manager
WAF
ACM
Cognito
103
Slide 104
Slide 104 text
構成図から確認すると
セキュリティを高めるサービス
認証認可周りも担保
104
Slide 105
Slide 105 text
IAM - Identity and Access Management IAM とは
● AWS リソースへのアクセス管理サービス
● プリンシパル, ポリシーを通じて誰が何にアクセスできるかを制御
● 必要最小限の権限のみを付与する最小権限の原則を適用することが
セキュリティのベストプラクティス
https://aws.amazon.com/jp/blogs/news/webinar-bb-aws-iam-part1-2019/
105
Slide 106
Slide 106 text
IAM - Identity and Access Management IAM とは
プリンシパル
認証
リクエスト
ユーザー（グループ）
認可
アクション
オペレーション
ID ベースポリシー
AWS リソース
CreateUser
DeleteUser
GetUser
Permissions
CreatePolicy
Permissions
Authentication
AttachRolePolicy
IAM
…
アクション
ロール
リソース
リソースベースポリシー
RunInstances
StartInstances
Instances
StopInstances
プリンシパル
CreateVpcEndpoint
…
AWS STS
環境データ
S3
Lambda
EC2
リソースデータ
CreateBucket
アプリケーション
Endpoints
ListBucket
その他ポリシー
GetObject
DeleteObject
(permissions boundary,
service control policy,
MFA Token
S3
…
access control list)
https://aws.amazon.com/jp/blogs/news/webinar-bb-aws-iam-part1-2019/
Bucket
with Objects
106
Slide 107
Slide 107 text
Secrets Manager
Secrets Manager とは
● API キーやパスワード、DB 接続情報などの機密情報を安全に保存
・管理できるサービス
● ローテーションやアクセス制御もサポートしている
● 安全に情報を保管し、IAM によるアクセス制御や自動ローテーショ
ンによってセキュリティと運用効率を両立
107
Slide 108
Slide 108 text
WAF
WAF とは
● WAF（Web Application Firewall）はウェブアプリケー
ションを保護するファイアウォール
● SQL インジェクションや XSS などの一般的なウェブ攻撃から
アプリケーションを守る（IP ベースのブロックも可能）
108
Slide 109
Slide 109 text
ACM - AWS Certificate Manager ACM とは
● SSL/TLS 証明書の管理サービス
● 証明書の発行、管理、更新を無料で簡単に行える
● CloudFront、ALB などのサービスと統合されている
109
Slide 110
Slide 110 text
Cognito
Cognito とは
● ウェブやモバイルアプリケーション向けの認証・認可サービス
● ユーザーのサインアップ、サインイン、アクセス制御を実装可能
● ソーシャル ID プロバイダーやエンタープライズディレクトリとの
連携もサポート
110
Slide 111
Slide 111 text
Cognito
ユーザープール
ID プール
Sign in
Sign in with
Username
Password
Submit
Cognito トークン
(JWT)
アプリ API
独自のユーザーディレクトリに加え、
外部 ID プロバイダーでのログインに基づき、
アプリへのアクセスに利用できるトークンを提供
https://www.youtube.com/watch?v=vWfTe5MHOIk
Corporate ID
AWS 一時
クレデンシャル
AWS API
Cognito ユーザープールに加え、
外部 ID プロバイダーでのログインに基づき、
AWS にアクセスできるクレデンシャルを提供
111
Slide 112
Slide 112 text
様々な AWS リソースを知ろう
目次
1. 構成図で全体を把握する
6. Storage
2. Network, CDN
7. Application Integration
3. Compute, Containers
8. Management & Governance
4. Database
9. Developer Tools
5. Security, Identity & Compliance
10. Artificial Intelligence
112
Slide 113
Slide 113 text
取り扱うサービスの紹介
Storage サービス
S3
113
Slide 114
Slide 114 text
構成図から確認すると
様々な場面で使える
Storage サービス
114
Slide 115
Slide 115 text
S3 - Simple Storage Service S3 とは
● 高耐久性・高可用性のオブジェクトストレージサービス
● ファイルのバックアップ、静的ウェブサイトホスティング、データ
レイク構築、アプリケーションのデータストア等に使用可能
● 99.999999999% の耐久性を持ち、アクセス頻度に合わせたスト
レージクラスを選択できる
115
Slide 116
Slide 116 text
S3 - Simple Storage Service データ保護・移行
業務サーバー
Web サービスの
コンテンツオフロード
データレイク
取り込み
分析
可視化
加工
CDN
S3 バケット
Web サーバー
バックアップ先
● アーカイブ、バックアップ
● データ移行
元データ
活用データ
● データ分析基盤
● 機械学習・IoT
非構造化
データ
● 動画サイト
● EC サイト
https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Amazon-S3-Usecases_0131_v1.pdf
116
Slide 117
Slide 117 text
S3 Vectors
S3 Vectors とは？
● ベクトルバケットにベクトルを保存し、類似検索（k-NN）が可能
● 専用ベクトル DB 不要で運用・コスト負担を大幅削減
● メタデータフィルタリング付きのセマンティック検索が可能
● 既存の S3 機能（IAM, CloudTrail, 暗号化等）をそのまま活用
https://aws.amazon.com/jp/s3/features/vectors/
117
Slide 118
Slide 118 text
S3 と CloudFront
● 一度取得したコンテンツを CloudFront へキャッシュ
● 同じデータの取得を抑え、バックエンドの負荷を軽減
https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Amazon-S3-Usecases_0131_v1.pdf
118
Slide 119
Slide 119 text
様々な AWS リソースを知ろう
目次
1. 構成図で全体を把握する
6. Storage
2. Network, CDN
7. Application Integration
3. Compute, Containers
8. Management & Governance
4. Database
9. Developer Tools
5. Security, Identity & Compliance
10. Artificial Intelligence
119
Slide 120
Slide 120 text
取り扱うサービスの紹介
Application Integration サービス
SQS
Step Functions
EventBridge
120
Slide 121
Slide 121 text
構成図から確認すると
リソースとリソースを繋ぐ
柔軟なリソース群
121
Slide 122
Slide 122 text
SQS - Simple Queue Service SQS とは
● フルマネージドのメッセージキューイングサービス
● マイクロサービス間の疎結合を実現し、システムの耐障害性と拡張性を向上させる
● 非同期処理が必要な場合や、システム間の通信をオフロードしたい場合に有効
● トラフィックのスパイク時にもデータを失うことなく処理を継続できる
122
Slide 123
Slide 123 text
SQS - Simple Queue Service プロデューサー
コンシューマー
キューにメッセージを
送信するアプリケーション
キューのメッセージを
取得するアプリケーション
プロデューサー
メッセージ
キュー
コンシューマー
メッセージ
キュー
プロデューサーが生成するデータ
メッセージをキューイングする
分散キュー
https://d1.awsstatic.com/webinars/jp/pdf/services/20190717_AWS-BlackBelt_AmazonSQS.pdf
123
Slide 124
Slide 124 text
SQS の利用ケース
ユースケース
1. バッファリングとバッチ化
2. ワークキュー
一時的なリクエスト増の均一化
プロデューサーとコンシューマーの
処理の依存関係を低減
3. リクエストのオフロード
4. ターゲットのファンアウト
重い処理の切り出しによる応答性能の改善
Amazon SNS との組み合わせによる
処理の並列化
https://d1.awsstatic.com/webinars/jp/pdf/services/20190717_AWS-BlackBelt_AmazonSQS.pdf
124
Slide 125
Slide 125 text
Step Functions
Step Functions とは
● ワークフローを視覚的に構築・実行するサービス
● 複数の AWS サービスを組み合わせて複雑なビジネスロジックを実装可能
● エラー処理, 再試行ロジック, 並列処理などもサポート
125
Slide 126
Slide 126 text
Step Functions
● 分散アプリケーション・マイクロサービス
Star t
FetchAnOrder
全体を「 ステートマシン 」と呼ばれる仕組
RegionChoice
みでオーケストレートできる
CreateOrderA
● 定義したステートマシンは マネジメント
コンソールから「 ワークフロー 」という形
式で可視化できる
OrderOK
CreateOrderB
DatabaseError
ProcessOrder
UnservedRegion
NoOrderPossible
End
https://d1.awsstatic.com/webinars/jp/pdf/services/20190522_AWS-Blackbelt_StepFunctions.pdf
126
Slide 127
Slide 127 text
EventBridge
EventBridge とは
● サーバーレスのイベントバスサービス
● AWS サービス間、自社アプリケーション、SaaS アプリケー
ション間のイベントを仲介する
● イベントに基づいてターゲットのアクションをトリガーできる
127
Slide 128
Slide 128 text
様々な AWS リソースを知ろう
目次
1. 構成図で全体を把握する
6. Storage
2. Network, CDN
7. Application Integration
3. Compute, Containers
8. Management & Governance
4. Database
9. Developer Tools
5. Security, Identity & Compliance
10. Artificial Intelligence
128
Slide 129
Slide 129 text
取り扱うサービスの紹介
Management & Governance サービス
CloudWatch
CloudTrail
129
Slide 130
Slide 130 text
構成図から確認すると
構築したアプリケーションの
可観測性を向上させる
130
Slide 131
Slide 131 text
CloudWatch
CloudWatch とは
● AWS リソースのモニタリングサービス
● メトリクス収集、ログ管理、アラーム設定、ダッシュボード作
成などの機能を提供
● リソースの状態をリアルタイムで把握できる
131
Slide 132
Slide 132 text
システムの状態把握に必要な要素
ログ
What：タイムスタンプが記録
された、時間の経過とともに起
こったイベントの記録
Why： 予測不可能な振る舞いを
発見するのに役立つ
CloudWatch Logs
メトリクス
CloudWatch
Metrics
トレース
AWS X-Ray
What：時間間隔で
計測されたデータの
数値表現
Why： 傾向の把
握、予測 に役立つ
What：関連する一連の分
散イベントの表現
Why： リクエストの流れ
とリクエストの構造の両方
を可視化 することで因果関
係の追跡に役立つ
132
Slide 133
Slide 133 text
CloudWatch の全体像
Application Monitoring
[外形監視]
CW Synthetics
[リアルユーザーモニタリング]
CW RUM
[SLI/SLO・サービスマップ]
Application Signals
Insights
[インターネット監視]
CW Internet
Monitor
[トレース]
CW ServiceLens
[構造化ログによるメトリクス]
CW Container Insights / Contributor
Insights
[Lambda 拡張機能によるメトリクス]
Lambda Insights
[アプリケーションコンポーネントのメトリクス]
Application Insights
[アラーム]
CW Alarms
[メトリクス]
CW Metrics
Infrastructure
[ログ]
CW Logs
EC2
AWS サービス
CW
Agent
[リアルタイムメトリクス分析]
CW Metrics Insights
[タグベース視覚化]
CW Metrics Explorer
[メトリクスストリーム]
CW Metric Streams
[ダッシュボードに統合]
CW Dashboard
Amazon Kinesis
Data Firehose
パートナー
サービス、
S3/Redshift
[ログ分析]
CW Logs Insights
[イベント]
Amazon EventBridge /
Amazon EventBridge
Scheduler
https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_AmazonCloudWatch_0330_v1.pdf
133
Slide 134
Slide 134 text
CloudTrail
CloudTrail とは
● AWS アカウントのガバナンス、コンプライアンス、リスク監査を支援するサービス
● AWS アカウント内の API コールをログとして記録し、誰が何をいつ行ったかを追跡できる
● 不正アクセスや意図しない変更の検出、コンプライアンス要件の遵守確認などに活用できる
134
Slide 135
Slide 135 text
API リクエストの証跡取得
API インターフェース
認証・認可
IAM
AWS サービスの
API エンドポイント
API リクエスト
証跡取得
CloudTrail
https://d1.awsstatic.com/webinars/jp/pdf/services/20210119_AWSBlackbelt_CloudTrail.pdf
135
Slide 136
Slide 136 text
Cost Explorer
Cost Explorer とは
● コストと使用量を視覚的に分析できる AWS のツール
● サービス別・API 別など多様なフィルタでコストを確認可能
● 将来のコスト予測や予算の管理にも活用できる
136
Slide 137
Slide 137 text
Cost Explorer を使ってみよう
1. マネジメントコンソールのトップから Billing and Cost Management へ
Billing and Cost
Management に移動
137
Slide 138
Slide 138 text
Cost Explorer を使ってみよう
2. Billing and Cost Management から Cost Explorer へ
コストサマリー の確認
コストモニター の設定が可能
Cost Explorer へ移動
138
Slide 139
Slide 139 text
Cost Explorer を使ってみよう
3. 期間・粒度・ディメンション・グラフ形式を指定して、コストを可視化
どのサービスにどれくらいのコスト
が掛かるかを可視化
日付範囲・粒度
ディメンション・グラフ形式
を指定
139
Slide 140
Slide 140 text
Cost Explorer を使ってみよう
4. (appendix) 特定のサービスのコストを API 粒度でも閲覧可能
同じ VPC の括りでも
コストの掛かり方が異なる
ディメンションを API オペレーションにして
特定のサービスを指定
140
Slide 141
Slide 141 text
様々な AWS リソースを知ろう
目次
1. 構成図で全体を把握する
6. Storage
2. Network, CDN
7. Application Integration
3. Compute, Containers
8. Management & Governance
4. Database
9. Developer Tools
5. Security, Identity & Compliance
10. Artificial Intelligence
141
Slide 142
Slide 142 text
取り扱うサービスの紹介
Developer Tools サービス
CodePipeline
142
Slide 143
Slide 143 text
構成図から確認すると
アプリケーションの
CI/CD を担う存在
143
Slide 144
Slide 144 text
CodePipeline
CodePipeline とは
● 素早く信頼性の高いアプリケーション更新のための継続的デリバ
リーサービスを提供
● ソフトウェアリリースプロセスをモデル化することで可視化
● コードが変更されるとコードのビルド, テスト, デプロイを実施
● AWS サービスやサードパーティーのツールと統合
https://d1.awsstatic.com/webinars/jp/pdf/services/20201111_BlackBelt_AWS%20CodeStar_AWS_CodePipeline.pdf
144
Slide 145
Slide 145 text
サポートしているプロバイダー
Source
● Amazon S3
● Amazon ECR
● AWS CodeCommit
● GitHub
● GitHub Enterprise Server
● Bitbucket
● GitLab
Build
● AWS CodeBuild
● Commands
● Jenkins
● CloudBees / TeamCity
●
●
●
●
●
●
●
●
Test
Deploy
AWS CodeBuild
AWS Device Farm
BlazeMeter
Jenkins
Ghost Inspector
Micro Focus StormRunner Load
Nouvola
Runscope
● Amazon S3
● AWS CloudFormation
● AWS CodeDeploy
● Amazon ECS（Blue/Green）
● Amazon EKS / EC2
● AWS Elastic Beanstalk
● AWS AppConfig
● AWS Service Catalog
Approval
Invoke
● Manual
●
●
●
●
AWS Lambda
AWS Step Functions
AWS CodePipeline
Amazon Inspector
https://docs.aws.amazon.com/ja_ jp/codepipeline/latest/userguide/actions-valid-providers.html
145
Slide 146
Slide 146 text
パイプラインの例
ECS に Deploy
Source に ECR を設定
146
Slide 147
Slide 147 text
様々な AWS リソースを知ろう
目次
1. 構成図で全体を把握する
6. Storage
2. Network, CDN
7. Application Integration
3. Compute, Containers
8. Management & Governance
4. Database
9. Developer Tools
5. Security, Identity & Compliance
10. Artificial Intelligence
147
Slide 148
Slide 148 text
取り扱うサービスの紹介
Artificial Intelligence サービス
Bedrock
SageMaker
AgentCore
148
Slide 149
Slide 149 text
Bedrock
Bedrock とは
● 基盤モデルを活用した生成 AI アプリケーションを簡単に構築、拡張できる
● API を経由して様々な基盤モデルにアクセス、インフラ管理は不要
● データセキュリティやコンプライアンスを実現
● エージェント機能、RAG 機能、非公開でのモデルのカスタマイズなど基盤モデル
の効果を高める様々な機能を提供
https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2024_Amazon-Bedrock-Overview_v1.pdf
149
Slide 150
Slide 150 text
SageMaker
SageMaker とは
● 全ての開発者とデータサイエンティストに 機械学習モデルの構築、トレー
ニング、デプロイ手段を提供
● 機械学習のワークフロー全体をカバーする完全マネージド型サービス
● データのラベル付け、アルゴリズムの選択とトレーニング、デプロイの調整
と最適化を行い実行
https://d1.awsstatic.com/webinars/jp/pdf/services/20190206_AWS_BlackBelt_SageMaker_part1.pdf
150
Slide 151
Slide 151 text
Amazon Bedrock AgentCore
AgentCore とは？
● AI エージェントの構築・デプロイ・スケーリングを提供
● Runtime、Gateway、Memory などの複数コンポーネント
● 任意のフレームワーク（LangChain 等）のエージェントをデプロイ可能
https://aws.amazon.com/jp/bedrock/agentcore/
151
Slide 152
Slide 152 text
AgentCore のコンポーネント
Runtime
Gateway
Identity
エージェント実行環境
ツール接続・MCP 変換
認証認可の管理
Memory
Policy
Evaluations
会話記憶（短期・長期）
行動制御（Preview）
品質モニタリング（Preview）
Observability
Code Interpreter
Browser
運用監視・トレース
サンドボックスコード実行
サーバーレス Web 操作
https://aws.amazon.com/jp/bedrock/agentcore/
152
Slide 153
Slide 153 text
Terraform ハンズオン
153
Slide 154
Slide 154 text
クラウド開発における課題
● 人的ミスが発生しやすい
● 環境の再現が難しい
● 構築手順の属人化
● 大規模な環境構築に時間がかかる
● 構成管理が困難
154
Slide 155
Slide 155 text
IaC（Infrastructure as Code） とは？
● 安全で一貫性のある展開
○ コード化による信頼性、再利用性と共有性、予測可能な管理
● 標準化されたワークフロー
○ 直感的な記述、チーム間の統一、依存関係の自動管理
● インフラの追跡管理
○ 状態ファイルによる正確な把握、安全な変更管理、迅速な復旧と再現
155
Slide 156
Slide 156 text
Terraform とは？
● マルチプロバイダー対応
○ AWS, Google Cloud, Azure etc...
● 統一された管理方法
○ モジュール化による再利用、プロバイダー間のリソースを組み合わせ可能
● 効率的なデプロイメントフロー
○ Initialize → Plan → Apply のサイクル
156
Slide 157
Slide 157 text
Terraform のライフサイクル
1
Scope
2
プロジェクトに必要なインフラの特定
3
Initialize
必要なプラグイン等のインストール
5
Author
インフラの構成を記述
4
Plan
記述した構成の変更をプレビュー
Apply
計画された変更を実行
https://developer.hashicorp.com/terraform/tutorials/aws-get-started/infrastructure-as-code
157
Slide 158
Slide 158 text
早速 Terraform を触ってみる
1. Terraform で nginx コンテナを立ち上げる
2. Terraform の基本を学ぶ
https://developer.hashicorp.com/terraform/tutorials/aws-get-started/infrastructure-as-code
158
Slide 159
Slide 159 text
リポジトリの Clone
https://github.com/CyberAgentHack/getting-started-with-terraform
159
Slide 160
Slide 160 text
必要なインフラを特定しよう
Image
Container
160
Slide 161
Slide 161 text
インフラの構成を記述しよう
modules/nginx/nginx.tf
resource
“docker_image”
を参照
resource
“docker_container ”
“resource” ブロックで
作成する構成を記述
161
Slide 162
Slide 162 text
terraform init
environments/xxx/nginx で実行
$ cd environments/xxx/nginx
$ terraform init
1. プロバイダーのダウンロードとインストール
2. バックエンドの初期化
3. モジュールのダウンロード
162
Slide 163
Slide 163 text
terraform init（初期化）
Initializing the backend...
modules/nginx/nginx.tf が使用される
Initializing modules...
- nginx in ../../../modules/nginx
Initializing provider plugins...
- Finding kreuzwerker/docker versions matching "~> 4.0.0"...
- Installing kreuzwerker/docker v4.0.0...
…
Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above.
…
Terraform has been successfully initialized!
自動生成され、
選定したプロバイダーの情報を記録
You may now begin working with Terraform. Try running
"terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.
…
163
Slide 164
Slide 164 text
terraform plan
environments/xxx/nginx で実行
$ terraform plan
記述した構成の変更をプレビュー
※ Rancher Desktop の場合は -var="docker_host=unix://$HOME/.rd/docker.sock" を付ける
164
Slide 165
Slide 165 text
terraform plan（計画）
Terraform used the selected providers to generate the following execution plan.
Resource actions are indicated with the following symbols:
“nginx” module の
+ create
“nginx” という名前の
“docker_container” resource を構築
Terraform will perform the following actions:
# module.nginx.docker_container.nginx will be created
+ resource "docker_container" "nginx" {
+ attach
= false
…
}
# module.nginx.docker_image.nginx will be created
+ resource "docker_image" "nginx" {
+ id
= (known after apply)
“nginx” module の “nginx” という名前の
…
“docker_image” resource を構築
}
Plan: 2 to add, 0 to change, 0 to destroy.
165
Slide 166
Slide 166 text
terraform apply
environments/xxx/nginx で実行
承認フローをスキップ
--auto-approve は無くても OK
$ terraform apply --auto-approve
計画された変更を実行
※ Rancher Desktop の場合は -var="docker_host=unix://$HOME/.rd/docker.sock" を付ける
166
Slide 167
Slide 167 text
terraform apply（実行）
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following
symbols:
+ create
Terraform will perform the following actions:
# module.nginx.docker_container.nginx will be created
plan と同じように作成するステップが走る
+ resource "docker_container" "nginx" {
+ attach
= false
…
}
# module.nginx.docker_image.nginx will be created
+ resource "docker_image" "nginx" {
本来は承認ステップが入る
+ id
= (known after apply)
...
}
Plan: 2 to add, 0 to change, 0 to destroy.
module.nginx.docker_image.nginx: Creating...
module.nginx.docker_image.nginx: Creation complete after 6s
対象のリソースが作成される
[id=sha256:2c9168b3c9a84851f91e03534dc4136951e9f581ab3ac8ee38b28b49ad57ba38nginx]
module.nginx.docker_container.nginx: Creating...
module.nginx.docker_container.nginx: Creation complete after 1s
[id=9eee7200841c6b8b54153f20ce4f9eb1afffad6ba2d3f2c4c33d9aff6ebf8ed1]
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.
167
Slide 168
Slide 168 text
terraform destroy
environments/xxx/nginx で実行
承認フローをスキップ
--auto-approve は無くても OK
$ terraform destroy --auto-approve
構築されたリソースを削除
※ Rancher Desktop の場合は -var="docker_host=unix://$HOME/.rd/docker.sock" を付ける
168
Slide 169
Slide 169 text
terraform destroy（破壊）
...
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following
symbols:
- destroy
Terraform will perform the following actions:
リソースを破壊する際にどうなるかの記載
# module.nginx.docker_container.nginx will be destroyed
- resource "docker_container" "nginx" {
- attach
= false -> null
…
}
# module.nginx.docker_image.nginx will be destroyed
本来は承認ステップが入る
- resource "docker_image" "nginx" {
- id
= "sha256:2c9168b3c9a84851f91e03534dc4136951e9f581ab3ac8ee38b28b49ad57ba38nginx" -> null
…
}
Plan: 0 to add, 0 to change, 2 to destroy.
module.nginx.docker_container.nginx: Destroying... [id=9eee7200841c6b8b54153f20ce4f9eb1afffad6ba2d3f2c4c33d9aff6ebf8ed1]
対象のリソースが破棄される
module.nginx.docker_container.nginx: Destruction complete after 0s
…
[id=sha256:2c9168b3c9a84851f91e03534dc4136951e9f581ab3ac8ee38b28b49ad57ba38nginx]
module.nginx.docker_image.nginx: Destruction complete after 0s
Destroy complete! Resources: 2 destroyed.
169
Slide 170
Slide 170 text
tfstate について
構築されたリソースが実際にどういう 状態なのかを追跡する
resource
state
“docker_container”
“docker_container”
“docker_image”
resource
“docker_image”
現在のリソースの
“状態” が記載される
170
Slide 171
Slide 171 text
tfstate について（apply 後）
environments/xxx/nginx/terraform.tfstate
{
"version": 4,
"terraform_version": "1.14.0",
…
“docker_container” が
"resources": [
{
ある “状態” が記載される
"module": "module.nginx",
"type": "docker_container",
"name": "nginx",
"provider": "provider[\"registry.terraform.io/kreuzwerker/docker\"]",
...
“docker_image” が
},
{
ある “状態” が記載される
"module": "module.nginx",
"type": "docker_image",
"name": "nginx",
"provider": "provider[\"registry.terraform.io/kreuzwerker/docker\"]",
...
}
],
"check_results": null
}
を参照
171
Slide 172
Slide 172 text
Terraform module について
modules/nginx を参照
module は
再利用可能 な Terraform の
コードパッケージ
module
resource
resource
variable
provider
“docker_container”
“docker_image”
“environment”
“container_ports”
“kreuzwerker/docker”
172
Slide 173
Slide 173 text
Terraform module について
environments/xxx/nginx/main.tf
を参照
module "nginx" {
source = "../../../modules/nginx"
tfstate にあった
module.name は “nginx”
environment = var.environment
container_ports = var.container_ports
providers = {
docker = docker
}
}
今回の “xxx”, “yyy” のように
複数の環境から module を
再利用できる
main.tf
173
Slide 174
Slide 174 text
Variables（変数）について
modules/nginx/variable.tf
を参照
variable "environment" {
description = "Environment name."
}
環境を示すための
“environment” 変数
variable "container_ports" {
type = object({
internal = number
external = number
コンテナポートを示すための
“container_ports” 変数
})
description = "Ports mapping for the Docker container."
}
variable.tf
174
Slide 175
Slide 175 text
Variables（変数）について
environments/xxx/nginx/variable.tf
を参照
variable "environment" {
default = "xxx"
}
module 使用側で変数の値を
“xxx” という名前で定義
variable "container_ports" {
default = {
internal = 80
external = 8000
module 使用側で変数の値を
“80”, “8000” でポートを定義
}
}
variable.tf
175
Slide 176
Slide 176 text
Variables（変数）について
environments/xxx/nginx/main.tf
を参照
module "nginx" {
source = "../../../modules/nginx"
module が受け付ける変数に
variables で定義した
“environment” を代入
environment = var.environment
container_ports = var.container_ports
providers = {
module が受け付ける変数に
variables で定義した
“container_ports” を代入
docker = docker
}
}
main.tf
176
Slide 177
Slide 177 text
terraform ブロック
environments/xxx/nginx/provider.tf
を参照
terraform {
required_providers {
必要なプロバイダー（“docker”）
とバージョンの指定
docker = {
source = "kreuzwerker/docker"
version = "~> 4.0.0"
必要な Terraform のバージョンの指定が可能
}
}
required_version = ">= 1.14.0"
tfstate ファイルの
保存場所を記載
backend "local" {}
}
provider.tf
177
Slide 178
Slide 178 text
provider ブロック
environments/xxx/nginx/provider.tf
...
を参照
特定のプラットフォームとの
連携方法を定義
provider "docker" {
host = "unix:///var/run/docker.sock"
}
プロバイダー固有の設定を定義
provider.tf
178
Slide 179
Slide 179 text
resource ブロック
modules/nginx/nginx.tf
を参照
resource "docker_container" "nginx" {
image = docker_image.nginx.image_id
name = local.container_name
“どのリソース”、“何という名前”
かを定義
ports {
internal = var.container_ports.internal
external = var.container_ports.external
リソース固有のフィールド
に値を代入する
}
}
nginx.tf
179
Slide 180
Slide 180 text
resource ブロック
ドキュメントの定義 を参照
基本的にドキュメントに
何を実装すれば良いかが書いてある
フィールドとして
“Required” / “Optional”
の項目がある
https://registry.terraform.io/providers/kreuzwerker/docker/latest/docs/resources/container
180
Slide 181
Slide 181 text
resource 間の参照
modules/nginx/nginx.tf
を参照
resource "docker_image" "nginx" {
...
}
resource "docker_container" "nginx" {
image = docker_image.nginx.image_id
name = local.container_name
“nginx” という名の
“docker_image” resource の
“image_id” を 参照する
ports {
internal = var.container_ports.internal
external = var.container_ports.external
}
}
nginx.tf
181
Slide 182
Slide 182 text
AWS ハンズオン
182
Slide 183
Slide 183 text
前提の共有
● 以降のコマンドは profile 名 default が前提です。別名なら
make setup の PROFILE と --profile を読み替えてください
183
Slide 184
Slide 184 text
リポジトリの Clone
https://github.com/CyberAgentHack/aws-terraform-handson
184
Slide 185
Slide 185 text
make setup の実行
リポジトリのルートで実行
実行
$ make setup BUCKET_PREFIX=oyasumi-handson USER_NAME=ibaraki
確認
$ git diff
# myproject -> oyasumi-handson, your-name -> ibaraki に置換されていれば OK
※ BUCKET_PREFIX, USER_NAME は自分の識別子・名前に置き換えてください
185
Slide 186
Slide 186 text
Bookshelf の概要
1. Go で書かれたアプリケーション
2. 書籍の登録や一覧が可能
※ AI で出力した画像です
186
Slide 187
Slide 187 text
今回対象のアーキテクチャに触れる
187
Slide 188
Slide 188 text
土台となるリソースを構築する
CloudFront が未設定の状況
アプリケーション層が未実装
オーケストレーターも未実装
188
Slide 189
Slide 189 text
プロジェクトに必要なインフラの特定
189
Slide 190
Slide 190 text
プロジェクトに必要なインフラの特定
CloudFront で HTTPS
アクセスを追加する
アプリケーション層を追加
アプリケーション実装を build して
image を構築
190
Slide 191
Slide 191 text
ハンズオン
1. Network module を構築
2. Database module を構築
3. Operation module を構築
4. Docker イメージを ECR に push
5. ECS module を構築
6. CloudFront module を構築
7. 疎通確認
8. リソースの削除
191
Slide 192
Slide 192 text
ハンズオン
1. Network module を構築
2. Database module を構築
3. Operation module を構築
4. Docker イメージを ECR に push
5. ECS module を構築
6. CloudFront module を構築
7. 疎通確認
8. リソースの削除
192
Slide 193
Slide 193 text
プロジェクトに必要なインフラの特定（再掲）
ネットワーク層を構築
193
Slide 194
Slide 194 text
もう少し解像度を上げる
実装するリソースのグルーピング
VPC / Subnet
Internet Gateway
Route Table
NAT Gateway
Security Group / ACL
194
Slide 195
Slide 195 text
Terraform に起こすと
terraform/aws/modules/network
resource
“aws_vpc”
resource
resource
“aws_subnet”
“aws_internet_
gateway”
resource
“aws_route_table”
を参照
resource
“aws_nat_gateway”
resource
resource
“aws_route”
“aws_security_
group”
resource
“aws_eip”
resource
“aws_network_acl”
195
Slide 196
Slide 196 text
Terraform に起こすと
module 間の依存関係
ecs module
database module
network module
operation module
output: vpc_id / public_subnet_ids / private_subnet_ids
isolated_subnet_ids / private_route_table_ids
196
Slide 197
Slide 197 text
Network module の構築
terraform/aws/environments/default/network
で実行
$ cd terraform/aws/environments/default/network
$ terraform init
$ terraform plan
$ terraform apply
VPC, Subnet, NAT Gateway 等が作成されます
（数分かかります）
197
Slide 198
Slide 198 text
マネジメントコンソールから確認
VPC と検索する
VPC を押下
198
Slide 199
Slide 199 text
マネジメントコンソールから確認
handson-vpc が Available なら OK
左メニューの「お使いの VPC」を押下
199
Slide 200
Slide 200 text
マネジメントコンソールから確認
左メニューの「サブネット」を押下
public / private / isolated が 2 つずつなら OK
200
Slide 201
Slide 201 text
マネジメントコンソールから確認
0.0.0.0/0 の行き先が NAT Gateway なら OK
201
Slide 202
Slide 202 text
マネジメントコンソールから確認
AZ ごとに 1 つ Available なら OK
202
Slide 203
Slide 203 text
ハンズオン
1. Network module を構築
2. Database module を構築
3. Operation module を構築
4. Docker イメージを ECR に push
5. ECS module を構築
6. CloudFront module を構築
7. 疎通確認
8. リソースの削除
203
Slide 204
Slide 204 text
プロジェクトに必要なインフラの特定（再掲）
データベースを構築
204
Slide 205
Slide 205 text
もう少し解像度を上げる
実装するリソースのグルーピング
Aurora MySQL
Security Group
Secrets Manager
EventBridge
Scheduler
IAM
205
Slide 206
Slide 206 text
Terraform に起こすと
terraform/aws/modules/database
resource
“aws_rds_cluster”
resource
“aws_rds_
cluster_instance”
resource
“aws_db_
subnet_group”
を参照
resource
“aws_secretsmanager_
secret”
resource
resource
resource
“aws_security_
group”
“aws_scheduler_
schedule”
“aws_iam_role”
resource
“aws_iam_policy”
206
Slide 207
Slide 207 text
Database module の構築
terraform/aws/environments/default/database
で実行
$ cd terraform/aws/environments/default/database
$ terraform init
$ terraform plan
$ terraform apply
Aurora クラスターの作成には 10〜15 分かかります
207
Slide 208
Slide 208 text
マネジメントコンソールから確認
RDS と検索する
Aurora and RDS を押下
208
Slide 209
Slide 209 text
マネジメントコンソールから確認
左メニューの「データベース」を押下
handson-bookshelf-db-cluster が
利用可能 なら OK（作成に 10〜15 分）
209
Slide 210
Slide 210 text
マネジメントコンソールから確認
「データベース」から開く
クラスターとライター 1 台が利用可能なら OK
210
Slide 211
Slide 211 text
マネジメントコンソールから確認
DB のパスワードの保存先（値は表示しない）
211
Slide 212
Slide 212 text
マネジメントコンソールから確認
stop / start の 2 つが有効なら OK
212
Slide 213
Slide 213 text
ハンズオン
1. Network module を構築
2. Database module を構築
3. Operation module を構築
4. Docker イメージを ECR に push
5. ECS module を構築
6. CloudFront module を構築
7. 疎通確認
8. リソースの削除
213
Slide 214
Slide 214 text
プロジェクトに必要なインフラの特定（再掲）
DB セットアップ用の
EC2 を構築
214
Slide 215
Slide 215 text
もう少し解像度を上げる
実装するリソースのグルーピング
EC2 Instance
IAM
Security Group
S3 Bucket
215
Slide 216
Slide 216 text
Terraform に起こすと
terraform/aws/modules/operation
を参照
resource
resource
resource
“aws_iam_role”
“aws_iam_
instance_profile”
“aws_instance”
resource
“aws_security_
group”
resource
“aws_s3_bucket”
216
Slide 217
Slide 217 text
Operation module の構築
terraform/aws/environments/default/operation
で実行
$ cd terraform/aws/environments/default/operation
$ terraform init
$ terraform plan
$ terraform apply
DB セットアップ用の EC2 と S3 バケット
が作成されます
217
Slide 218
Slide 218 text
マネジメントコンソールから確認
EC2 と検索する
EC2 を押下
218
Slide 219
Slide 219 text
マネジメントコンソールから確認
左メニューの「インスタンス」を押下
handson-operation-instance が
実行中 なら OK
219
Slide 220
Slide 220 text
マネジメントコンソールから確認
プライベート・パブリック IP なし・IAM ロール付きなら OK
220
Slide 221
Slide 221 text
マネジメントコンソールから確認
operation 用のバケット（バージョニング有効）
ができていれば OK
221
Slide 222
Slide 222 text
DB セットアップ
./ で実行
$ make db-setup
手元の AWS CLI（profile default）から
SSM 経由で Operation EC2 に実行を依頼
EC2 が自分の IAM ロールで Secrets Manager から
パスワードを取得し、DB ユーザーとテーブルを作成
※ apply 直後に失敗したら、数分待って再実行
222
Slide 223
Slide 223 text
マネジメントコンソールから確認
Systems Manager と検索する
Systems Manager を押下
223
Slide 224
Slide 224 text
マネジメントコンソールから確認
make db-setup の実行が 成功 なら OK
左メニューの「Run Command」→「コマン
ド履歴」タブ
224
Slide 225
Slide 225 text
ハンズオン
1. Network module を構築
2. Database module を構築
3. Operation module を構築
4. Docker イメージを ECR に push
5. ECS module を構築
6. CloudFront module を構築
7. 疎通確認
8. リソースの削除
225
Slide 226
Slide 226 text
Docker イメージの構築
./ で実行
ibaraki は自分の名前に置き換え
（make setup で設定した名前）
$ export USER_NAME=ibaraki
$ docker build -t bookshelf:$USER_NAME -f api/Dockerfile .
226
Slide 227
Slide 227 text
Docker イメージの構築
./ で実行
想定通りの image, tag なら OK
$ docker image ls
REPOSITORY TAG
bookshelf ibaraki
IMAGE ID
13b3c54a2fd9
CREATED
SIZE
44 seconds ago 10.6MB
227
Slide 228
Slide 228 text
構築（bucket key の確認）
terraform/aws/environments/default/ecr/provider.tf ※ make setup 実行後は修正不要
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 6.0"
}
}
make setup で
自動設定済み
backend "s3" {
bucket = "myproject-terraform-state"
# make setup で置換済み
key
= "ecr/terraform.tfstate" # make setup で置換済み
region = "ap-northeast-1"
encrypt = true
profile = "default"
make
} setup で
自動設定済み
}
provider.tf
228
Slide 229
Slide 229 text
AWS CLI を実行する（再掲）
4. AWS CLI の実行
option: profile, region, etc...
※ default 以外の profile を使うときは、環境変数
か --profile で指定する
AWS_PROFILE
command: s3, ec2, iam, etc...
$ aws s3 ls --profile=default
> 2026-04-10 00:02:39 myproject-terraform-state
今回はバケットの
情報が出れば OK
229
Slide 230
Slide 230 text
ECR module の構築
terraform/aws/environments/default/ecr
で実行
$ cd terraform/aws/environments/default/ecr
$ terraform init
$ terraform plan
$ terraform apply
コンテナイメージを置く ECR リポジトリが
作成されます
230
Slide 231
Slide 231 text
ECR リポジトリの URL 取得
terraform/aws/environments/default/ecr/
で実行
今回の対象 module を特定
$ terraform init
$ terraform output -raw repository_url
module の output を参照
231
Slide 232
Slide 232 text
ECR リポジトリの URL 取得
terraform/aws/environments/default/ecr/
で実行
シェル変数に格納
$ REPO_URL=$(terraform output -raw repository_url)
$ echo $REPO_URL
ECR の URL が表示されれば OK
232
Slide 233
Slide 233 text
マネジメントコンソールから確認
S3 と検索する
S3 を押下
233
Slide 234
Slide 234 text
マネジメントコンソールから確認
make setup で指定した S3 バケット を参照
234
Slide 235
Slide 235 text
マネジメントコンソールから確認
ecr フォルダ
と進んでいく
235
Slide 236
Slide 236 text
マネジメントコンソールから確認
“開く” を押下する
内部で tfstate が見つかる
236
Slide 237
Slide 237 text
マネジメントコンソールから確認
“outputs” があることが分かる
“repository_url” があることが分かる
237
Slide 238
Slide 238 text
ECR にログイン
terraform/aws/environments/default/ecr/
で実行
ECR にログインする
$ aws ecr get-login-password --region ap-northeast-1 --profile default |
docker login --username AWS --password-stdin $REPO_URL
シェル変数があることを確認
profile を適用
238
Slide 239
Slide 239 text
Docker イメージの再確認
terraform/aws/environments/default/ecr/
で実行
想定通りの image, tag なら OK
$ docker image ls
REPOSITORY TAG
bookshelf ibaraki
IMAGE ID
13b3c54a2fd9
CREATED
SIZE
44 seconds ago 10.6MB
239
Slide 240
Slide 240 text
イメージのタグ付け
terraform/aws/environments/default/ecr/
で実行
make docker-tag
でも実行可能
$ docker tag bookshelf:$USER_NAME $REPO_URL:$USER_NAME
240
Slide 241
Slide 241 text
イメージの push
terraform/aws/environments/default/ecr/ で実行
$ docker push $REPO_URL:$USER_NAME
241
Slide 242
Slide 242 text
マネジメントコンソールでイメージの確認
Registry と検索して開く
「プライベートリポジトリ」を押下
242
Slide 243
Slide 243 text
マネジメントコンソールでイメージの確認
リポジトリ名を押下
243
Slide 244
Slide 244 text
マネジメントコンソールでイメージの確認
想定通りの image があれば OK
244
Slide 245
Slide 245 text
ハンズオン
1. Network module を構築
2. Database module を構築
3. Operation module を構築
4. Docker イメージを ECR に push
5. ECS module を構築
6. CloudFront module を構築
7. 疎通確認
8. リソースの削除
245
Slide 246
Slide 246 text
プロジェクトに必要なインフラの特定（再掲）
アプリケーション層を追加
246
Slide 247
Slide 247 text
もう少し解像度を上げる
実装するリソースのグルーピング
ELB
Security Group
ECS on Fargate
IAM
CloudWatch
247
Slide 248
Slide 248 text
Terraform に起こすと
terraform/aws/modules/ecs
を参照
resource
resource
resource
“aws_cloudwatch_log_group”
“aws_lb_listener”
“aws_ecs_task_definition”
resource
resource
resource
“aws_lb_target_group”
resource
resource
“aws_lb”
“aws_ecs_service”
“aws_iam_role”
“aws_ecs_cluster”
resource
resource
resource
resource
“aws_iam_policy”
“aws_iam_role_policy_attachment”
“aws_security_group”
“aws_security_group”
248
Slide 249
Slide 249 text
Terraform に起こすと
module 間の依存関係
network module
database module
ecs module
ecr module
cloudfront
module
249
Slide 250
Slide 250 text
AWS CLI を実行する（再掲）
4. AWS CLI の実行
option: profile, region, etc...
※ default 以外の profile を使うときは、環境変数
か --profile で指定する
AWS_PROFILE
command: s3, ec2, iam, etc...
$ aws s3 ls --profile=default
> 2026-04-10 00:02:39 myproject-terraform-state
今回はバケットの
情報が出れば OK
250
Slide 251
Slide 251 text
構築（bucket key の確認）
terraform/aws/environments/default/ecs/provider.tf を参
照
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
make setup で設定済み
version = "~> 6.0"
}
}
backend "s3" {
bucket = "myproject-terraform-state"
key
= "ecs/terraform.tfstate" # make setup で置換済み
region = "ap-northeast-1"
encrypt = true
profile = "default"
}
provider.tf
make setup
で設定済み
make setup で設定済み
}
251
Slide 252
Slide 252 text
構築（bucket key の確認）
terraform/aws/environments/default/ecs/data.tf を参照 ※ make setup 実行後は修正不要
data "terraform_remote_state" "network" {
backend = "s3"
config = {
bucket = "myproject-terraform-state" # make setup で置換済み
key
= "network/terraform.tfstate" # make setup で置換済み
region = "ap-northeast-1"
profile = "default"
}
}
data "terraform_remote_state" "ecr" {
backend = "s3"
config = {
bucket = "myproject-terraform-state" # make setup で置換済み
key
= "ecr/terraform.tfstate" # make setup で置換済み
region = "ap-northeast-1"
profile = "default"
}
}
data "terraform_remote_state" "database" {
backend = "s3"
config = {
bucket = "myproject-terraform-state" # make setup で置換済み
key
= "database/terraform.tfstate" # make setup で置換済み
region = "ap-northeast-1"
profile = "default"
}
}
make setup で
自動設定済み
data.tf
252
Slide 253
Slide 253 text
ECS module の構築
terraform/aws/environments/default/ecs
で実行
$ cd terraform/aws/environments/default/ecs
$ terraform init
$ terraform plan
$ terraform apply
ALB, ECS Cluster / Service, IAM Role 等が作成されます
（数分かかります）
253
Slide 254
Slide 254 text
マネジメントコンソールから確認
ECS と検索する
Elastic Container Service を押下
254
Slide 255
Slide 255 text
マネジメントコンソールから確認
左メニューの「クラスター」を押下
クラスター名を押下（タスクが 2 件実行中）
255
Slide 256
Slide 256 text
マネジメントコンソールから確認
タスクが 2 件実行中 なら OK
サービスが アクティブ なら OK
256
Slide 257
Slide 257 text
マネジメントコンソールから確認
イメージが ECR の URI を指していれば OK
257
Slide 258
Slide 258 text
マネジメントコンソールから確認
登録済みターゲット 2 つが「正常」なら OK
258
Slide 259
Slide 259 text
マネジメントコンソールから確認
起動ログとリクエストのログが出ていれば OK
259
Slide 260
Slide 260 text
ハンズオン
1. Network module を構築
2. Database module を構築
3. Operation module を構築
4. Docker イメージを ECR に push
5. ECS module を構築
6. CloudFront module を構築
7. 疎通確認
8. リソースの削除
260
Slide 261
Slide 261 text
もう少し解像度を上げる
実装するリソースのグルーピング
CloudFront
Distribution
Origin (ALB)
261
Slide 262
Slide 262 text
Terraform に起こすと
terraform/aws/modules/cloudfront
resource
“aws_cloudfront_
distribution”
を参照
output
“alb_dns_name”
262
Slide 263
Slide 263 text
CloudFront module の構築
terraform/aws/environments/default/cloudfront
で実行
$ cd terraform/aws/environments/default/cloudfront
$ terraform init
$ terraform plan
$ terraform apply
CloudFront の作成には数分かかります
263
Slide 264
Slide 264 text
CloudFront URL の確認
terraform/aws/environments/default/cloudfront
で実行
$ terraform output app_url
> "https://xxxxxx.cloudfront.net"
この URL でアプリケーションにアクセスできます
（HTTPS）
264
Slide 265
Slide 265 text
マネジメントコンソールから確認
CloudFront と検索する
CloudFront を押下
265
Slide 266
Slide 266 text
マネジメントコンソールから確認
左メニューの「ディストリビューション」
を押下
ステータスが 有効 なら OK
Domain は terraform output の app_url と同じ
266
Slide 267
Slide 267 text
マネジメントコンソールから確認
オリジンが ALB なら OK
267
Slide 268
Slide 268 text
ブラウザから確認
/api/v1/books を開いて書籍が返れば OK
268
Slide 269
Slide 269 text
アプリケーションの確認（API）
書籍データを登録してみる
xxxxxx は自分の CloudFront ドメインに置換
curl -X POST \
https://xxxxxx.cloudfront.net/api/v1/books \
-H "Content-Type: application/json" \
-d '{
"title": "テスト書籍",
"author": "テスト著者",
"isbn": "1234567890123",
"publisher": "テスト出版社",
"description": "これはテスト用の書籍データです。"
}'
269
Slide 270
Slide 270 text
アプリケーションの確認（API）
書籍データを取得してみる
xxxxxx は自分の CloudFront ドメインに置換
curl -X GET https://xxxxxx.cloudfront.net/api/v1/books
270
Slide 271
Slide 271 text
ハンズオン
1. Network module を構築
2. Database module を構築
3. Operation module を構築
4. Docker イメージを ECR に push
5. ECS module を構築
6. CloudFront module を構築
7. 疎通確認
8. リソースの削除
271
Slide 272
Slide 272 text
リソースの削除（CloudFront）
terraform/aws/environments/default/cloudfront
で実行
$ cd terraform/aws/environments/default/cloudfront
$ terraform destroy
作成と逆順に消していきます
make destroy-all でまとめても OK
272
Slide 273
Slide 273 text
リソースの削除（ECS）
terraform/aws/environments/default/ecs
で実行
$ cd terraform/aws/environments/default/ecs
$ terraform destroy
ALB / ECS Service / Task / IAM Role が消えます
273
Slide 274
Slide 274 text
リソースの削除（ECR）
terraform/aws/environments/default/ecr
で実行
$ cd terraform/aws/environments/default/ecr
$ terraform destroy
push したイメージごと消えます
（force_delete）
274
Slide 275
Slide 275 text
リソースの削除（Operation）
terraform/aws/environments/default/operation
で実行
$ cd terraform/aws/environments/default/operation
$ terraform destroy
DB セットアップ用の EC2 と S3 バケットが消えます
275
Slide 276
Slide 276 text
リソースの削除（Database）
terraform/aws/environments/default/database
で実行
$ cd terraform/aws/environments/default/database
$ terraform destroy
Aurora の削除には数分かかります
276
Slide 277
Slide 277 text
リソースの削除（Network）
terraform/aws/environments/default/network
で実行
$ cd terraform/aws/environments/default/network
$ terraform destroy
最後に VPC / Subnet / NAT Gateway が消えます
277
Slide 278
Slide 278 text
マネジメントコンソールから確認
「お使いの VPC」を開く
handson-vpc が出なければ削除完了
278
Slide 279
Slide 279 text
リソースの削除（tfstate）
./ で実行
$ aws s3 rb s3://myproject-terraform-state --force --profile default
tfstate 用の S3 バケットは手で作ったので手で消します
myproject は make setup で指定した
BUCKET_PREFIX に読み替え
279
Slide 280
Slide 280 text
その他
280
Slide 281
Slide 281 text
コスト管理
● 予算に収まるよう開発してください
○ 意識するための仕組みを入れる
ex. 日次で Slack に通知する
○ 不要なインスタンスは停止する
○ IaC で作成する場合にはデフォルト値に気をつける
281
Slide 282
Slide 282 text
ご清聴ありがとうございました
282