対象 • オンプレミス環境をクラウド環境に移行を検討中の方 • システムのリニューアルに合わせて、サーバーレス化を検討中の方 これを読んだら得れること • サーバレスを実現するにあたり、AWSのどのサービスを組み合わせれば良いか分かる。 •膨大なAWSサービスの中から、Webアプリ構築に使えるサービスの概要を知れる。

1. サーバーレスを可能にする
AWSサービスの概要

2. 2
当ドキュメントのスコープ
✓ AWSのサービスから、Webアプリケーションの構築に使えるサービスの紹介
✓ サービスをシステムアーキテクチャーの要素別に区分して機能の簡単な紹介と共にメ
リットとデメリットを提示し、比較できるようにする
※ただし、IoT、AIに関するAWSサービスは対象外（今後別文書として提示）
✓ 実際のWebサービスを作るために、AWSのサービスを組み合わせたアーキテクチャー例
を提示
✓ AWSのサービスから、Webアプリケーションの構築に
使えるサービスの紹介
✓ サービスをシステムアーキテクチャーの要素別に区分して
機能の簡単な紹介と共にメリットとデメリットを提示し、
比較できるようにする
※ただし、IoT、AIに関するAWSサービスは対象外（今後別文書として提示）
✓ 実際のWebサービスを作るために、AWSのサービスを組み
合わせたアーキテクチャー例を提示

3. 目次
1. AWSサービス紹介
● ネットワーキング
● コンピューティング
● データベース
● ストレージ
● アプリケーション統合
● セキュリティ
● 開発者ツール・DevOps
● その他
2. サービス構成例
3. AWSにおける開発・デプロイ

4. 4
1. AWSサービス紹介

5. 5
ネットワーキング
サービス 区分・概要 メリット デメリット
VPC 仮想プライベート
クラウド
● 仮想ネットワークを簡単に構築可能
● 細かいセキュリティ設定が可能
● サブネット、ルートテーブルなど最低限のネットワーク
の知識が必要
VPN 仮想プライベート
ネットワーク
● オンプレミスネットワークとVPC間でセキュアな
接続が可能
● 専用線接続サービス(DirectConnect)も用意され
ている
● オンプレを外部ネットワークと接続する事になるのでセ
キュリティ設定を密に行う必要がある
Route 53 DNS ● DNSサーバ構築、管理が不要
● 可用性、拡張性に優れている
● AWSの他サービスとの連携が容易
● 利用料金が掛かる（ただし非常に安価）
CloudFront CDN(コンテンツ
デリバリーネット
ワーク)
● 世界中へ高速にコンテンツを配信可能
● エッジロケーションにより負荷が分散される
● キャッシュにより、オリジンサーバへの負荷を低
減する
● CloudFrontとは別にS3やEC2等、コンテンツを格納す
るサーバ・サービスが必要

6. 6
ネットワーキング
サービス 区分・概要 メリット デメリット
Elastic Load
Balancing
ロードバランサー ● アプリのトラフィックを複数のターゲット(EC2、
ECS、Lambda等)に自動的に分散可能
● ELBをSSL終端とする事でサーバ(EC2等)のSSL対
応が不要となる
● Network Load Balancerを使用すれば固定IPでの
運用が可能
● (あえて書くなら）ELBの利用料金が掛かる
API Gateway サーバレスで
APIを公開
● RESTfulAPI、WebSocketAPIをサーバレスで公開
可能
● Lambdaと組み合わせて完全サーバレスのAPIを公
開できる
● スロットリング設定によりバックエンド側の負荷
を制御可能
● データ量等の制約を意識する必要がある
● Lambdaと組み合わせる場合、Lambda側の制限と合わ
せて設計する必要がある

7. 7
コンピューティング
サービス 区分・概要 メリット デメリット
EC2 仮想サーバ ● オンプレミスからの移行が容易
● 既存資産を活かし易い
● スケーリングが容易
● サーバの管理を自前で行う必要がある
Lambda サーバレスで
コードを実行
● サーバ構築、管理が不要
● AWSの様々なサービスから呼び出せる
● APIGatewayやAppSyncと連携しサーバレスな
WebAPIを提供可能
● ステートレスなので、コネクションプールを使用できず
RDS(RDB)との相性が悪い。コネクションの枯渇が発生
しやすい。→ Aurora ServerlessであればOK。
● 既存資産を活かしにくい
ECS コンテナ ● 1サーバで複数のコンテナを起動できるのでマイク
ロサービスの提供が容易
● コンテナを動かす為のサーバ(EC2)が必要
● Docker等のコンテナを構築する知識が必要
Fargate コンテナ ● コンテナを動かすサーバの管理が不要
● マイクロサービスの提供が容易
● スケーリングが容易
● Docker等のコンテナを構築する知識が必要
● EC2の同一スペックに比べてコストが若干割高。ただし
FargateはAWSの重要サービスである為、値下げされる
事が多い。
AWS Batch バッチ処理 ● サーバの管理が不要（自動起動、停止）
● 必要な時に必要なリソースを利用可能
● JP1のようなサードパーティ製のようなリッチなジョブ
スケジューラ機能が無い

8. 8
データベース
サービス 区分・概要 メリット デメリット
RDS RDB ● サーバ構築、管理が不要
● 様々なRDBMSから選択が可能
● Auroraに比べてフェイルオーバーに時間が掛かる
Aurora MySQL、
PostgreSQL互換
● パフォーマンス、可用性、信頼性に優れる
● MySQL、PostgreSQLと互換性がある
● コストが若干高い
● MySQL、PostgreSQLしか対応していない
Aurora
Serverless
Auroraの
サーバレス版
● インスタンス管理が不要で自動的にスケーリング
する
● 常時起動でも通常のAuroraに比べて料金が安い
● DataAPIを使う事でLambdaとの相性問題も改善さ
れる
● キャパシティが0の状態でアクセスすると30秒〜1分程
度の待ちが発生する（コールドスタート）
DynamoDB NoSQL ● サーバ構築、管理が不要
● スケーリングが容易
● Lambdaとの相性が良い
● RDBからの移行は設計からの見直しが必要
● 複雑なクエリが使えないので業務要件に合わせた採用検
討が必要
DocumentDB MongoDB互換 ● サーバ構築、管理が不要
● スケーリングが容易
● Lambdaとの相性が良い
● MongoDBと互換がある
● RDBからの移行は設計からの見直しが必要
● DynamoDBに比べる柔軟なクエリが使えるが、業務要件
に合わせた採用検討が必要

9. 9
データベース
サービス 区分・概要 メリット デメリット
RedShift DWH
(データウェアハウス)
● 大量データの分析、集計を高速に行える
● S3上のデータを集計する事も可能
(RedShift Spectrum)
● RDBと比べ
● SQLの並列実行に弱い
● 頻繁に更新するデータには向かない
ElastiCache インメモリ
キャッシング
● サーバ構築、管理が不要
● 超高速アクセス
● 頻繁に更新されるセッション情報などに有用
（DynamoDBだと都度課金が発生する為）
● データの永続化ができない為、他のサービスとの併用な
ど検討が必要

10. 10
ストレージ
サービス 区分・概要 メリット デメリット
S3 オブジェクト
ストレージ
● 99.999999999%の耐久性
● データ容量の制限なく保存が可能
● 静的Webホスティングが可能
● 非常に安価
● サーバサイド処理を含むサイト構築は不可
EBS EC2用ブロック
ストレージ
● 4つのボリュームタイプから用途に合わせて選択が
可能
● ボリュームサイズの増加が容易なので、最初から
最大サイズを確保する必要がない
● インスタンス間の共有ができない
● EBS内でデータを永続化すると、単一障害点となってし
まう
EFS ファイル
ストレージ
● EC2、ECS、Fargate間で共有が可能
● 自動で伸縮する為、容量を決める必要が無い
● EBSに比べてコストが高い
S3 Glacier アーカイブ用
オブジェクト
ストレージ
● アーカイブや長期バックアップを目的としている
為、S3より更に安価
● データ取得に数分〜数時間を要するので常時アクセスす
る用途では使用できない
● 3ヶ月未満のデータを削除すると早期削除料金が発生す
る

11. 11
セキュリティ
サービス 区分・概要 メリット デメリット
IAM AWSの
アクセス管理
● AWSの各リソース(サービス)に対するアクセス管
理を行う事が可能
● ユーザー単位で細かい権限管理が可能
● アクセスエラーが発生した時に原因の究明が難しい（慣
れが必要）
Cognito アプリの
アクセス管理
● アプリのサインアップ、サインインを簡単に実現
できる
● Google、Facebook等のIDプロバイダと連携が可
能
● Oauth2.0、OpenIDConnect等のアクセス管理を
サポートしている
● バックエンドリソースのアクセス管理が可能
● (あえて書くなら）Cognitoに関する専門知識の習得が
必要
WAF Webアプリケー
ションファイア
ウォール
● SQLインジェクション、クロスサイトスクリプ
ティングなど一般的な攻撃をブロック可能
● 特定のトラックパターンを除外可能
● 事前設定済みのマネージドルールを利用可能
● マネージドルールはブラックボックス化されている為、
誤認識された時に対処が難しい。
ACM SSL証明書の
発行・管理
● ELB、CloudFrontで使用できるSSL証明書を無料
で発行できる
● SSL証明書が自動更新される
● 外部発行のSSL証明書を可能
● EC2では利用できない。(前段のELBで利用する事でセ
キュリティは担保可能)

12. 12
開発者ツール・DevOps
サービス 区分・概要 メリット デメリット
CloudFormation コードによる
AWSリソース
の構築・管理
● コード(JSON/YAML)でAWSリソースを自動構築、
管理する事ができる
● コードをインフラの設計書とみなす事ができる
● 環境の複製が簡単に短時間で行える
● CloudFormation独自の記述方法にラーニングコストが
掛かる
CloudWatch リソース、ア
プリのモニタ
リング
● サーバ、コンテナのログをCloudWatchに出力可
能。ローカル保存しない事で、サーバ、コンテナ
のスケーリングが容易になる。（ログの消失を防
ぐ）
● ルールを使って各種処理の定期実行が可能
● 各リソースのメトリクスをグラフィカルに確認可
能
● アラームを設定し、メトリクスのしきい値を超え
た時にアクションを起こす事ができる(Lambdaを
使ってSlackに通知する等)
● 短時間に大量のログを出力(APIをCall)すると、スロッ
トリングが発生し、ログの抜けが発生する
● 大量のログを出力すると意外に料金が高い。

13. 13
開発者ツール・DevOps
サービス 区分・概要 メリット デメリット
CodeCommit プライベート
Gitリポジトリ
● サーバ構築、管理が不要
● AWSならではのセキュリティ、高可用性を持つGit
リポジトリが使用できる
● ソースコード管理までAWSに依存してしまう。Lambda
のようにAWS有りきのプロジェクトであれば良いか。
CodePipeline 継続的デリバリー ● サーバ構築、管理が不要
● Gitリポジトリの更新をトリガーとして、ビルド、
テスト、デプロイまで自動化する事が可能
● 手動の承認を入れる事が可能なので、誤って本番
環境にリリースする事を防げる
● CodeBuild、CodeDeploy等、他のサービスと合わせて
知識が必要
CloudBuild ビルド、テストの
自動化
● サーバ構築、管理が不要
● ビルド、テストを自動で行う事が可能
● 並列ビルドが可能（自動スケール）
● CodeBuild、CodeDeploy等、他のサービスと合わせて
知識が必要
CodeDeploy 自動デプロイ ● サーバ構築、管理が不要
● EC2、Fargate、Lambda、オンプレミスサーバへ
アプリを自動デプロイ可能
● Blue/Greenデプロイが選択可能
● CodeBuild、CodeDeploy等、他のサービスと合わせて
知識が必要

14. 14
開発者ツール・DevOps
サービス 区分・概要 メリット デメリット
Cloud9 ブラウザで
使用できるIDE
● サーバ構築、管理が不要
● コードエディタ、デバッガー、ターミナルをブラ
ウザ上で使用できる
● コードエディタを共有しペアプログラミングやリ
アルタイムレビューが可能
● Lambda関数のローカルテスト、デバッグが可能
● ローカル端末の性能に影響を受けない開発が可能
● 利用中はEC2の利用料金が掛かる

15. 15
その他
サービス 区分・概要 メリット デメリット
SNS pub/sub
メッセージング
● サーバ構築、管理が不要
● HTTP、Email、SQS、Lambdaと簡単に連携が可能
● モバイル端末へのプッシュ通知が行える
● SQSとの連携で疎結合かつ、並列処理が簡単に行
える
● (あえて書くなら）クラウドネイティブな設計思想が必
要
SQS メッセージキュー ● サーバ構築、管理が不要
● 複雑な処理を分割しやすい（疎結合・マイクロ
サービス化）
● 大量データ処理のスケーリングが容易
● 標準キューでは順序保証が無く、複数回同じメッセージ
が配信される事がある。（要件に合わせてFIFOキュー
を検討すれば良い）
Kinesis データストリーム ● 複数のコンシューマ(読み込む側の処理)
● 大量のログ、イベントデータの収集、リアルタイ
ム解析等に向いている
● SQSと比べて読み書きの実装がやや煩雑
● スケーリングを自前で行う必要がある（ライブラリは公
開されている）
SES メールサービス ● サーバ構築、管理が不要
● SMTPインタフェースを使う事で既存のメール送信
ロジックを流用可能
● バウンス(配信障害)を放置するとSESの利用停止措置を
取られる事がある（適切な処理は必要）
● 送信済みメールを一覧表示するような機能が無い為、必
要であれば自前でアプリを構築する必要がある

16. 16
その他
サービス 区分・概要 メリット デメリット
AppSync GraphQL ● サーバ構築、管理が不要
● アプリのオフライン対策を自前で行う必要がない
（オフライン時に発生した更新のみ自動同期す
る）
● DynamoDB、ElasticSearch、Lambda、外部
WebAPIといった複数データソースからのデータ取
得が可能
● GraphQL及びAppSyncの知識が必要

17. 17
2. サービス構成例

18. 18
オンプレからの移行が容易な構成 ※サーバレスではない
Public Subnet - A
VPC
Private Subnet - A
EC2
ALB
RDS(Master)
Client
✓ オンプレミスで稼働中のレガシーシステムの移行が容易
✓ 冗長化する事で可用性を高める（単一障害点を無くす）
✓ EC2は負荷に応じてオートスケーリングする
Public Subnet - C
EC2
Private Subnet - C
RDS(Slave)
Auto Scaling group
EC2をオートスケーリングに対応させるには
● EC2にアプリ情報を永続化させない
● EC2上にログを保持しない
● EC2上にセッション情報等を持たない
EC2を使い捨てできる状態にする事が重要！
障害発生時は自動的に
Masterに昇格

19. 19
コンテナによるマイクロサービス化 ※サーバレスではない
Public Subnet - A
VPC
Private Subnet - A
Fargate
ALB
RDS(Master)
Client
✓ Fargate(コンテナ)でマイクロサービス化
✓ Fargateは負荷に応じてオートスケーリング可能(設定が容易)
Fargate
Public Subnet - C Private Subnet - C
Fargate
RDS(Slave)
Fargate
ALB
障害発生時は自動的に
Masterに昇格

20. 20
レガシー構成から段階的にサーバレス化
VPC
Client
✓ APIのエンドポイントをAPI Gatewayに集約する事で、バックエンドに
異なるアーキテクチャを採用可能。フロントはバックエンドの構成を意
識する必要が無い
API Gateway
EC2
Fargate
Lambda
RDS
DynamoDB
Fargate
レガシー
SQS Lambda
※サブネットの
表記は割愛
機能単位で
段階的に移行が可能
コンテナ化
サーバレス

21. 21
画像アップロード時にサーバレスでサムネイル自動作成
Client S3 Lambda
✓ S3に画像がアップロードされると、S3のトリガーで
Lambdaが起動される。
✓ Lambdaで、アップロードされた画像のサムネイル画像
を作成し、S3に保存する。

22. 22
オンプレミス資産との連携
VPCOn-premise
Private Subnet
EC2
Public Subnet - C
EC2 Internet
Gateway
VPN
GatewayRouter
VPN
Connection
Internet
Server
RDS
✓ オンプレミス資産とAWSをVPNで繋げる
✓ 外部（インターネット）との接続を別サブネットにする事で
セキュリティを担保

23. 23
AppSyncによる完全サーバレス化
Client
DynamoDB
AppSync
Aurora
Serverless
S3Cloud
Front
Cognito
✓ AppSync(GraphQL)を使用する事で単純なCRUDはLambda無しで可能
✓ 複雑な処理はLambdaで対応
Lambda Document
DB
フロントエンド
ユーザー管理認証

24. 24
3. AWSにおける開発・デプロイ

25. 25
DevOps
✓ コードがGithubにプッシュされると、自動的にビルド、デプロイが
実行される。 ※上図にはテストを含んでいない。
CodePipeline
CodeBuild
CodeDeploy
S3
ECR
Source Code Github
Fargate
Source Artifact
Build
Register
Deploy
(Pull)
Blue/Green
Deploy

26. 26
Cloud9を使ったリモート開発
Cloud9 EC2
Lambda
Build
Client
Client Cloud9 EC2
Client
Build
ペアプログラミング
ペアプログラミング
✓ クライアントからブラウザ経由でコードエディタ等のIDEが使用可能
✓ 共同編集、ペアプログラミングが可能
✓ Cloud9からLambdaのローカルテストやデプロイが可能