AWS認定クラウドプラクティショナー直前対策テキスト

クラウドの概念

クラウドコンピューティング
インターネットを通して提供される仮想化技術によるサービス形態

インスタンス
稼働中の仮想化されたサーバー
＝EC2

リージョン
独立したクラウド領域
リージョン間の通信、データ移動する事はできない

アベイラビリティゾーン(AZ)
リージョン内の物理的に独立した領域
AZ間の通信が可能

データセンター
AZ内のクラウド本体のコンピュータ設置場所。

エッジロケーション
エッジ＝端
ユーザに近い場所のデータセンター
CloudFront等に利用される

エラスティック(弾力性)
AWSで多用される言葉
EC2では自動でのスケールアウト、スケールアップが可能

プロビジョニング
≒セットアップ、設定等の意味

サーバープロビジョニング
＝OS、ソフトウェアのインストール、設定

ユーザー(アカウント)プロビジョニング
＝ユーザー作成、アクセス権限設定

ワークロード
＝OS、ミドルウェア、ソフトウェア、データを含めたシステム全体
AWSリソースに加えてプログラム等のソフトウェア、データ

グローバルリーチ
エッジロケーションを利用してグローバルにクラウドを利用してビジネスを行う事

ディザスターリカバリー(DR)
大規模障害復旧方法

名称	内容
バックアップ＆リストア	退避(バックアップ)しておいたシステムのある時点のデータを、戻す(リストア)する
パイロットライト	普段は停止させている障害時用システムを起動して使う方法 ＝コールドスタンバイ
ウォームスタンバイ	「障害対策/ウォームスタンバイ」参照
マルチサイト	常時別の場所で同じシステムを稼働させておく方法 ＝ホットスタンバイ

AWSクラウドの特徴

特徴

固定費から変動費
初期投資(固定費)が不要で使用した分だけ費用(変動費)が掛けられる

スケールメリット
超巨大企業が巨大なインフラを整備している為スケールメリットによる低コスト化が進んでいる

キャパシティ予測不要
リソースの使用に応じてスケールアウト、スケールアップされるインフラを利用できる為、機器、サービスのキャパシティ設計が不要

スピード
サービス構築・稼働・リリースまでの速度が速い

データセンター不要
データセンターの設備投資、運用、保守はAWSが担う為不要

数秒で世界中にデプロイ可能
各国のリージョンに数秒でデプロイ可能
低レイテンシー、低コストを実現
※レイテンシー＝遅延

アーキテクチャ原則

AWSの特徴を活かす為に推奨されるアーキテクチャ原則
具体的なプラクティス集については「Well Architected フレームワーク」参照

障害設計
１カ所の障害でシステム全体が止まる様な作りにしない

疎結合
各機能をコンポーネントとして分割する

スケーラビリティ
拡張・収縮を可能とする

サーバでなくサービス
保守の手間を軽減する為にサービスを利用する

グローバルリーチ
静的コンテンツはエッジロケーションに

AWSの主要サービス

管理

サービス名	機能	備考
AWSマネジメントコンソール	WEBベースでAWSを操作できる

コンピューティング

サービス名	機能	備考
EC2	仮想サーバ	用途/規模に応じて多様なファミリ/サイズがある
ECS	Dockerコンテナ	サーバ管理不要
Lambda	関数	インスタンス不要

　

コンテナサービス

サービス名	機能	備考
Amazon ECS	EC2/Fagate上でDockerコンテナを稼働させるサービス
Amazon EKS	Kuberntesサービス
AWS Fagate	Dockerコンテナ用サーバレスエンジン	ECS/EKSで稼働

ストレージ

サービス名	機能	備考
EBS	ブロックストレージ	EC2用。1つのEBSに接続できるEC2は1つのみ。拡張可能
インスタンスストア	ブロックストレージ	EC2用。一時的なデータの保管用
EFS	ファイルストレージ	EC2用。複数のEC2からアクセス可。EC2外からのインターネットアクセス不可
S3	オブジェクトストレージ	1つのオブジェクトがURLで指定できる S3のアクセス権限設定については「S3アクセスコントロール」参照
S3 Glacier	オブジェクトストレージ	データの取り出しに数分〜必要だが低コスト

サービス名	機能	備考
Storage Gateway	ゲートウェイ	オンプレミスからAWSの各ストレージを利用できる
Snowball	物理デバイス（小）	データ移行、エッジコンピューティング用
Snowmobile	物理デバイス（大）	〃

データベース

リレーショナルデータベース

サービス名	機能	備考
RDS	各種一般的なデータベースエンジン(Oracle等)＋Aurora
Aurora	クラスタ構成のAWS独自のRDBエンジン(MySQL/Postgre)
Redshift	データウェアハウス

　

NoSQL

サービス名	機能	備考
DynamoDB	NoSQL
ElastiCache	インメモリデータストア

ネットワーク

サービス名	機能	備考
VPC	利用者独自の論理ネットワーク
Amazon VPC拡張ネットワーク	高スループット、低レイテンシーの拡張機能
Amazon VPCエンドポイント	VPC内のインスタンスとVPC外のサービスの接続機能	セキュリティの問題でインターネットに接続せずにサービスを利用する場合に使用
ELB	ロードバランサー
CloudFront	CDN	エッジロケーションで稼働
Route53	DNS
Direct Connect	専用線
Virtual Private Network	VPN
EBS最適化インスタンス	EC2〜EBS間接続の専用化

セキュリティ

サービス名	機能	備考
IAM	ユーザ、サービス等に対する認証と認可
KMS	暗号化キーの管理
WAF	ファイアウォール

マネジメント

サービス名	機能	備考
AutoScaling	インスタンスの自動拡張
CloudFormation	コードからAWS環境を構築
CloudWatch	サービスのモニタリング

その他

メッセージングサービス

サービス名	機能	備考
Amazon SNS	pub/sub型メッセージングサービス
Amazon SQS	キュー型メッセージングサービス
Amazon SES	Eメールサービス
Amazon MQ	キュー型メッセージングサービス

　

AWSサポート

サービス名	機能	備考
ベーシックサポート	ガイドの閲覧が可能	全利用者対象
開発者サポート	・Trusted Advisorの7コアのチェック ・メールサポート(営業時間内)
ビジネスサポート	・Trusted Advisor ・電話/メール/チャットサポート(年中無休)
エンタープライズサポート	・Trusted Advisorのフルチェック ・電話/メール/チャットサポート(年中無休) ・コンサルティング ・アドバイス

　

Marketplace
AWSで利用可能なソフトウェアのカタログ
ソフトウェアベンダーの製品に対する検索・購入・デプロイが可能

APNパートナー
サポート企業のネットワーク

パートナー名	機能	備考
APNコンサルティングパートナー	設計、開発、構築、移行、管理サポート
APNテクノロジーパートナー	AWSに関するハード、接続サービス、ソフトウェア提供

Well Architected フレームワーク

AWS Well-Architected Tool
ベストプラクティスについて質問形式でチェックできるサービス

運用の優秀性

設計原則

1.プログラムコードで運用する
　従来：手作業での運用
　AWS：アプリ、インフラもコードによる自動化を推奨
2.ドキュメントへの注釈
　従来：手作業で作成
　AWS：自動作成
3.定期的に小規模リリースする
　従来：長期サイクルでの一括リリース。リリース後は凍結
　AWS：小規模リリース（その為の設計）を推奨。※失敗時にその部分だけ戻せる為
4.手順を定期的に改善する
　従来：成功した手順を凍結。間違えない様に運用
　AWS：頻繁な手順改善を推奨
5.障害を予想してテストする
　従来：障害、変更は避ける
　AWS：あえて障害を発生させるテスト実施を推奨
6.障害から学習する
　従来：リリース前に極力バグを無くす
　AWS：障害からの学習を推奨

ベストプラクティス

AMI
Amazon Machine Image

EC2インスタンスのイメージ
EBSスナップショット等のストレージを含む

VPCフローログ
VPC上の通信ログを出力

AWS Elastic Beanstalk
WEBアプリケーションの自動デプロイ(プロビジョニング)、自動スケーリング

AWS Codeシリーズ

サービス名	機能	備考
CodeCommit	Gitリポジトリ
CodeBuild	ビルド、テスト
CodeDeploy	デプロイ
CodePipeline	継続的デリバリー/継続的インテグレーション
X-Ray	マイクロサービス管理

「AWS CI/CD」参照

AWS X-Ray
マイクロサービスアプリケーション間の依存関係の分析・管理ツール

セキュリティ

責任共有モデル
AWSと利用者でセキュリティとコンプライアンスについての責任が分割される

AWSの責任
ホストのコンピュータ、OS、データセンター等におけるセキュリティ設定

利用者の責任
仮想環境のOS、ネットワーク構成、ファイアウォール構成におけるセキュリティ設定

AWS Artifact
・AWSのコンプライアンスレポート取得
・NDA締結
・SOCレポート取得

SOCレポート
重要なコンプライアンス管理および目標をAWSがどのように達成したか？の報告書
System Organization Control(SOC)

IAM
ユーザー、グループ、ロール、ポリシー
「AWSセキュリティ/IAM」参照

セキュリティグループ/ネットワークACL

機能	セキュリティグループ	ネットワークACL
制御単位	インスタンス単位	サブネット単位
許可設定	○	○
拒否設定		○
ステート	ステートフル	ステートレス
ルール	１つ	複数

　

AWS CloudTrail
AWSマネジメントコンソール等によるAWSアカウントへの操作履歴を取得

AWS Config
AWSリソースへの操作履歴を取得

AWS Shield
「AWS セキュリティ/AWS Shield」参照

Amazon GuardDuty
AWSアカウント、ワークロードに対する包括的な脅威検出
CloudTail、VPCフローログ、DNSログ等を調査する

Amazon Inspector
アプリケーションのセキュリティ評価を取得

AWS Directory Service
AWS上でMicrosoftActiveDirectoryが使用できる

S3アクセスコントロール

方法	制御
ACL	バケット内のオブジェクト単位
バケットポリシー	バケット単位
IAMポリシー	IAMユーザー、IAMロール単位

　

AWS Service Catalog
CloudFormationのテンプレートの集まり
ユーザーはCatalog外のリソースを使用できなくなる

AWS Trusted Advisor
ベストプラクティスに従ったチェックサービス
S3バケットアクセス制御、セキュリティグループポート設定、IAM使用有無、ルートアカウントでのMFA使用有無、EBSアクセス制御、RDSアクセス制御

設計原則

1.協力なアイデンティティ基盤を実装する
　従来：管理者/利用者別の認証と権限付与
　AWS：役割分担の徹底、最小限の権限付与を推奨
2.トレーサビリティ
　従来：監査時、障害時のみログでの調査を実施
　AWS：リアルタイム監視、メトリックスによる動的なアクションが可能
3.全レイヤへのセキュリティ
　従来：データセンター外部からのアクセスに対するセキュリティ対策
　AWS：外部＋アプリ、OS、ネットワークへのセキュリティ対策
4.自動化
　従来：担当者が手動で実施
　AWS：自動
5.伝送中、保管中のデータ保護
　従来：平文
　AWS:暗号化、トークン分割、アクセスコントロール
6.データ操作
　従来：手作業でのデータ操作あり
　AWS：手作業に代わるツールの提供
7.セキュリティ事故への備え
　従来：事故後の対応
　AWS：インシデント対応シュミレーションの実行、自動化ツールによる検出、調査、復旧が可能

ベストプラクティス

アイデンティティ管理とアクセス管理
意図した方法で承認されたユーザだけがアクセスできる様にする。
ユーザ＝個人、グループ、プログラム
以下のサービスを利用
・IAM
・Organizations
・STS

発見的統制
潜在的な脅威、インシデントの特定の為にログ、イベントを監視
以下のサービスを利用
・Cloud Trail
・Cloud Watch
・AWS Config
・Amazon GuardDuty

インフラ保護
深層防御を推奨
境界防御、ログ監視等を実行する
以下のサービスを利用
・Amazon VPC
・Amazon CloudFront
・AWS WAF

データ保護
データの暗号化、暗号化キーのローテーション、アクセスログ取得、データのバックアップ
以下のサービスを利用
・KMS
・S3

インシデント対応
インシデント対応テストを推奨
・CloudFormation
・Cloud Watch Events

信頼性

AWSにおける信頼性に関する設計原則
・検証済みの復旧手順が確立されている
・障害からの自動復旧
・水平方向のスケールアップ（高可用性）
・キャパシティ推測不要
・自動化

Amazon CloudWatch
各種メトリクスの監視サービス

EC2、RDS等は無料でメトリクスをCloudWatchに出力できる
ログに対する監視・自動処理も可能

メトリクス
定量化された活動についての指標

Amazon CloudWatch Events
各種メトリクスの監視し設定したしきい値を超えた場合にアクションを発生させられるサービス

Amazon CloudWatch Logs
各サービスの取得、クエリ処理、ソート、グループ化

Auto Scaling

EC2 Auto Scaling
EC2インスタンスの自動拡張

Application Auto Scaling
ECS、DynamoDBテーブル、Auroraレプリカ等の自動拡張

AWS Virtual Private Network(VPN)
オンプレミスとAWSのVPN接続サービス

AWS Direct Connect
オンプレミスとAWSの専用線接続サービス

設計原則

1.復旧手順をテストしておく
　従来：特定の障害発生シナリオのテストのみ。復旧手順の検証なし
　AWS：障害発生のメカニズム、復旧手順の検証を推奨。障害の再現可能
2.障害から自動復旧される
　従来：ログ監視に基づいた手動復旧
　AWS：システムのKPIの設定から復旧プロセスの自動実行を推奨
3.水平方向へスケールできる
　従来：リソースが1カ所にまとめられている。１か所の障害で全システムが影響を受ける
　AWS：リソースを分散。１か所の障害は他リソースに影響しない
4.キャパシティ推測不要
　従来：キャパシティを予測。超過すると処理できない
　AWS：キャパシティ予測不要。リソースの自動追加/削除を推奨
5.設定変更を自動化する
　従来：手動で変更
　AWS：自動化推奨

ベストプラクティス

基盤
ネットワーク形態、サービス制限を把握しておく
以下のサービスを利用
・CloudWatch
・AWS Trusted Advisor

変更管理
需要の変動に応じて自動的にリソースが追加/削除される設計を推奨
環境の変更はログから把握可能
以下のサービスを利用
・AWS CloudTrail
・AWS Config
・Amazon AutoScaling
・CloudWatch

障害管理
システムの常時監視から自動で対応される設計を推奨
障害後は本番環境への調査/復旧でなく、新環境での復旧/旧環境の調査が望ましい。
また以下の様な障害対応を検証しておく
・定期的なバックアップデータからのリストア
・自動化された障害テストからの復旧
以下のサービスを利用
・AWS CloudFormation
・Amazon S3
・Amazon S3 Glacier

パフォーマンス効率

EC2

効率化対象	内容
コンピューティング	インスタンス世代：新＞古 OS：新＞古
ストレージ	EBS最適化インスタンス＞非EBS最適化インスタンス
ネットワーク	拡張ネットワーキング：有効＞無効

　

RDS
設定項目
・メモリ
・パフォーマンス
・I/O最適化

自動
ストレージのスケーリング

補足
マルチAZ配置
複数AZにデータ同期されたDBを配置する構成
障害設計として高可用性、フェイルオーバーを実現できる

Amazon Redshift
データウェアハウス
大容量、高速度

Amazon ElastiCache
RDS等の前に設置して利用するインメモリデータストア
「AWS ストレージサービス/ElastiCache」参照

Amazon DynamoDB Accelerator(DAX)
DynamoDB用インメモリデータストア

Amazon S3 Transfer Acceleration
他大陸リージョンのS3アップロードサービス

設計原則

1.最新テクノロジーを利用する
　従来：安全を重視して枯れた技術、以前と同じアーキテクチャで構築
　AWS：新しい技術を利用する
2.数分でグローバル展開する
　従来：データセンターがあるローカルエリアでのみサービスを展開
　AWS：積極的にグローバル展開する
3.サーバレスアーキテクチャを利用する
　従来：サーバ/サーバ管理者を利用
　AWS：サーバレスサービスを管理者無しで利用
4.頻繁に検証する
　従来：リソースを準備できない為事前検証はしない
　AWS：多様なインスタンス/ストレージの比較検証を何度でも行う
5.システムを深く理解しておく
　従来：インフラ/アプリで分業されており全体を理解できず効率向上ができない
　AWS：全体を理解しやすく効率向上が可能

ベストプラクティス

最適なリソースの選択
CloudWatchから取得したデータを検証し、以下4つのリソースを最適化する

1.コンピューティング
3つのタイプから適切なアーキテクチャを選択する
以下のサービスを利用
・Auto Scaling

2.ストレージ
以下を考慮しストレージを選択する
・アクセス方法（ブロック/ファイル/オブジェクト）
・アクセスパターン（ランダム/シーケンシャル）
・スループット/頻度（オンライン/オフライン/アーカイブ）
・更新頻度
・可用性/耐久性

3.データベース
以下の要件からデータベースを選択する
・可用性
・整合性
・パーティション対応
・レイテンシー
・スケーラビリティ
・クエリ機能

4.ネットワーク
以下の要件からネットワークを選択する
・レイテンシー
・スループット
・サービスを提供する場所

レビュー
以下から情報を得て新しいサービスや機能を利用する
・AWSブログ
・AWSウェブサイト「最新情報」

モニタリング
性能の劣化を観測する為にメトリクスを設定/監視する
以下のサービスを利用
・Amazon Cloud Watch
・AWS Lambda

トレードオフ
以下のどちらを重視するか？によってリソースをトレードオフする
・整合性/耐久性/容量
・レイテンシー
以下のサービスを利用
・Amazon ElastiCache
・Amazon CloudFront
・Amazon DynamoDB Accelerator(DAX)

コスト最適化

EC2購入オプション

オプション	内容	課金方法
オンデマンドインスタンス	秒単位の課金(デフォルト)	秒単位
Savings Plans	1/3年のコンピューティング使用料契約
リザーブドインスタンス	1/3年のインスタンス利用契約	秒単位
スポットインスタンス	未使用インスタンスを入札して契約	秒単位
Dedicated Hosts	専用物理ホストの利用契約

　

リザーブドインスタンス

オプション	平均割引率	別リザーブドインスタンスへの変更
スタンダード	1年(40%) 3年(60%)	×
コンバーティブル	1年(30%) 3年(50%)	〇

　

AWS Organizations
複数アカウントを一元管理
請求書管理、使用状況管理

TCOCalculator
TCO計算ツール
コスト見積もりツール

・AWS使用コスト見積もり
・オンプレミスからの移行ガイダンス
廃止

総所有コスト：AWS Total Cost of Ownership

AWS Pricing Calculator
AWS料金計算ツール
個々のユースケース毎のAWS製品、サービスのコスト見積もり

AWS Cost and Usage Report(CUR)
現在の使用状況から追跡された推定請求額レポート

AWS Cost Explorer
過去のコストをグラフ化によるコスト分析ツール
リザーブドインスタンス、Savings Plans利用時の削減コストも取得できる

AWS Budgets
設定したコストを超えた際の通知を取得できるサービス

設計原則

1.消費モデルを導入する
　従来：前払い。消費前に支払う
　AWS：都度払い。未使用時はリソースを停止する

2.スケールメリットを得る
　従来：導入前のデータセンターへの一括投資のみでスケールメリットは得られない
　AWS：スケールメリット、生産性/コスト削減メリットが得られる

3.データセンター運用費を排除する
　従来：データセンター運営費、保守要員が必要
　AWS：データセンター運営費、保守要員が不要

4.費用を分析し、リソースを最適化する
　従来：運用段階では収益の分析結果を元にした最適化はできない
　AWS：システム使用状況、コストの特定が可能で収益率からリソースの最適化が可能

5.運用負担を削減する
　従来：サーバへのOS/DB導入により運用負担が発生する
　AWS：マネージドサービスの仕様により運用負担が発生しない

ベストプラクティス

費用を把握する
最終的な収益改善の為にリソースの利用コストを把握する

以下のサービスを利用
・Cost Explorer
・AWS Budgets
・リソースへのタグ付け
・請求アラート
・AWS簡易見積もりツール

費用対効果の高いリソースを使用する
・適切なインスタンス、リソースを選択する
・マネージドサービスを使用する
・適切な料金オプションを選択する

以下のサービスを利用
・Cost Explorer
・AWS Trusted Advisor

需要と供給を一致させる
無駄を省きコストを削減できる

以下のサービスを利用
・AutoScaling

長期的に最適化する
年々新サービスがリリースされる為、現状をレビューし改善する

以下のサービスを利用
・各種マネージドサービス
・AWSブログ、AWSウェブサイト「最新情報」
・AWS Trusted Advisor