おことわり
本記事はクラウドプラクティショナー、つまりAWSの概要を把握しているレベルの知識をキャッチアップできるものになっています。
なので、めちゃくちゃ長いです。
ご注意ください。
また、内容や画像はAWSの公式サイトの物を多く使用しておりますが、中にはキャッチアップのために別のサイトから学んだ内容も入っていると思います。
そちらについては、勉強を実際に行っていたのが1年前のため、判明次第引用として追加させてください。
はじめに
皆さん、業務でAWS使ってますか。
AWSを日常的に触る方も、そうでない方もいらっしゃると思いますが、最近以下の記事がトレンドに入っているのを見かけました。
https://qiita.com/aki_number16/items/8ab86ff69200e45cd1bf
これを見て、意外とクラウドプラクティショナーに興味のある方がいらっしゃるんだなと思いまして、クラウドプラクティショナーをとるために学ぶべきことをまとめたものを公開しようと思います。
私も文系エンジニアでインフラ1年目に取得したので、割と0から学ぶにしても網羅できているはずです。
対象者
主に、AWS入門者向け、かつインフラ初心者向けの内容となっています。
AWSの概要知識について知りたい方は読むと良いです。
本記事の内容を把握しておけば、クラウドプラクティショナーには合格できます。
受験結果
ちなみに、ここまでの知識状態でクラウドプラクティショナー模擬試験を受講したところ、23/25で92%の正答率となりました。
以下内訳です。
総合スコア92%
Cloud Concepts 80%
Security 100%
Technology 100%
Billing and Pricing 66%
この結果不足していると思われた部分については資料内に補足しておきました。
実際の試験ではスコアは891点で、全領域十分な理解をしているとのことだったので、大体本記事くらいの知識を身に付ければ合格できる資格だと思います。
良く出た内容としては以下になります。
・サポートプランの差
・EC2 DB ストレージのケース問題（1か月間24時間稼働したい場合EC2のどの運用プランを選ぶかなど）
・ある状況でトラステッドアドバイザーを使うか、クラウドトレイルをつかうか、クラウドウォッチを使うか
・各種設計原則
・TCOについて
試験情報
もしクラウドプラクティショナーを受けるようでしたら、以下の動画を参考にするとよいと思います。
https://aws.amazon.com/jp/blogs/news/webinar-bb-practitioner-2018/
試験申し込みと模擬試験は下記から行えます。
https://aws.amazon.com/jp/certification/certified-cloud-practitioner/
ホワイトペーパーは以下にあり、日本語の物もあります。
著者は本記事の内容を覚えた後、サービス概要だけ読みました。
https://aws.amazon.com/jp/whitepapers/
概要
下記のAWSが用意している動画を要約しています。(無料)
資料内で使われる画像も、この動画からキャプチャしたものになります。
https://www.aws.training/transcript/curriculumplayer?transcriptId=yYaEAfD2gEq1JuCJNn7yEw2
動画を見て理解できる方なら、この記事より動画を見たほうが、章末問題などがあってよいと思います。
ただ、機械音声とちょっと怪しい日本語が絶妙にストレスになることは覚悟しましょう。
また、動画内に出てきた単語の説明なども行っているので、初学者も理解しやすい内容になっています。
ただし、AWS全般を触っているのでめちゃくちゃ長いです。（私の記事ではいつものことです）
読むべき内容は背景を灰色、見出しを赤にしています。
見出しが青の内容は単語の補足です。
クラウドの概念
クラウドコンピューティングの定義
量課金制による、インターネット経由の、ITリソースとアプリケーションの、オンデマンド配信サービス
「従量課金制」
従量制とは、サービスを利用した時間に応じて料金を課す方式
「ITリソース」
システムを構成するハード・ソフトウェアの総称
「オンデマンド」
On-Demandとは、英語で「要求（Demand）に応じて」という意味である。
つまり、注文に応じた対応を表す。
クラウドコンピューティングができる前
クラウドができる前は、ピーク時にかかる負荷を予想して、キャパシティをプロビジョニングする必要があった。
この場合、予測に満たない負荷の間は使用しないリソースにコストをかけることになり、予測を超えた場合はシステムが耐え切れないという事態になっていた。
また、物理的にマシンを用意する必要があったので、電力や場所など、間接的な費用も掛かっていた。
「キャパシティ」
保持、受け入れ、または取り込む能力を言う。
システムの負荷耐性と思えばよい。
「プロビジョニング」
準備、用意
AWSによって解決された現状
たいして、現在はAWSというITリソースを仮想（物理的に存在しない）の状態で用意できるサービスができた。
AWSのクラウドコンピューティングを使用すると、物理的なITリソースのキャパシティ限界や間接費の問題を解決し、必要な時に必要なだけの高度な機能を使い捨てで使用できるようになった。
これによって今までになかった柔軟性と俊敏性を得ることができた。
例えば、開発者が新しいテスト環境が必要となれば、従来であれば物理的にサーバーを購入するところから始まって、数週間もの時間をかけてプロビジョニングをおこなっていたはずが、AWSを使うことで、数分で環境を立ち上げることも可能となった。
そのため、１つの環境をみんなで初期化したりしながら使いまわして事故が起きたりすることもなく、必要な時に必要な数の環境を用意したりすることができ、より迅速かつ柔軟な開発が行える。
クラウドコンピューティングの特徴
システムに伸縮性があることが特徴といえる。
伸縮性はITリソースをスケールアップ（より高い性能にする）やスケールアウト（台数を増やす）を実現できる能力のことである。
必要なマシンの数が１台でも1000台でも、1時間でも24時間でも対応できる。
・新しいアプリケーションをすばやくデプロイ（実行可能な状態に）する
・ワークロード（負荷）に応じて瞬時のスケールアップ・アウトが行える
・不要なリソースを即座にシャットダウンできる。
・スケールダウンした分のインフラ料金はかからない
さらに、システムの伸縮性やら柔軟性というだけでなく、高い安全性を実現するのにも非常に有効である。
AWSクラウドインフラストラクチャはリージョンとアベイラビリティゾーンを中心として構成される。
アベイラビリティゾーンを分けてアプリケーションやデータベースを管理することで、今までありがちだった単一のデータセンターでは実現できない、高い可用性・耐障害性・拡張性を実現できる。
「リージョン」
世界中にある、AWSのリソースが保管された物理的な場所、２つ以上のアベイラビリティゾーンで構築される
「アベイラビリティゾーン」
リージョン内にある1つ以上のデータセンターで構築される拠点
同一リージョンでも、アベイラビリティゾーンが違えばそれらのITリソースは物理的かつ地理的に独立して存在していることを表す。
「可用性」
トラブルがあっても、どれだけシステムを動かし続けられるか
加えて、AWSでは多要素認証・アクセスコントロールが導入されており、アカウントの管理を単純なID/PWだけではなく、外部のハードやアプリケーションと連携して安全性を高めている。
つまるところ、便利で安全で簡単ということ。
AWSの基本的なインフラについての説明
グローバルインフラストラクチャ
AWSのグローバルインフラは以下の３つの要素で説明できる
- リージョン
- アベイラビリティゾーン
- エッジロケーション
- AWS Local Zones
- AWS Wavelength Zone
- AWS Outposts
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-regions-availability-zones.html
「リージョン」
リージョンは世界中にある物理的な場所、２つ以上のアベイラビリティゾーンで構築されるある区域を指す。
リージョンはAWSのあらゆるサービスを配信するデータセンターの所在を区分けしているもので、ユーザーはリージョンとそこに所属するアベイラビリティゾーンを選択し、そこでAWSのサービスを使用する。
AWSサービスやストレージ（データの保存場所）等は、リージョン別に存在しているものもあるため、どのリージョンを選ぶかという話がまず存在する。
このときに重要なのは、対象リージョンに自分の使用したいサービスが存在するかと、レイテンシー（遅延）がどの程度発生するかである。
レイテンシーについては単純に自分の端末から地理的に近いリージョンを選択すれば問題ない。
サービスについては公式サイトを確認するのが良い。
https://aws.amazon.com/jp/about-aws/global-infrastructure/regional-product-services/
リージョンは地理的に離れて存在するため、システムの可用性を高めるためにマルチリージョン（複数のリージョン）に同じ構成のシステムを構築するということも検討できる。
例えば日本に地震が起きてデータセンターがすべて機能しなくなっても、アメリカに構築したシステムには影響がないからだ。
「アベイラビリティゾーン」
アベイラビリティゾーンはリージョン内にある１つ以上のデータセンターである。
（複数のデータセンターをまたいで構築されることもあるので、単一のデータセンターというわけではない。）
例えば、日本リージョンに存在する東京AZと京都AZといったように想像すればわかりやすい。
此方も地理的に離れており、AZ同士は電力元も含めてあらゆるリソースを独立して持っているため、システムの可用性を高めるために同じ構成のシステムを構築することも検討できる。
マルチリージョンまでしなくとも、マルチアベイラビリティゾーンにはしておくということが多い。
AWSはマルチAZでデータをプロビジョニングすることをベストプラクティスとしている。
AZ間は高速かつ低レイテンシー（遅延）で接続されている。
「エッジロケーション」
アベイラビリティゾーンとは別で立っている小さなデータセンター。
エッジロケーションではAmazon CloudFrontというコンテンツ配信ネットワーク（CDN)が提供される。
CloudFronとはコンテンツへのリクエストがあった際、最もユーザーに近いエッジロケーションからコンテンツを配信するサービスで、エンドユーザーに対して素早くコンテンツを配信できる。
また、ElastiCacheというキャッシングを行うサービスにも使われる。
「AWS Local Zones」
一言でいえばデータセンターを用意できないが、AWSの物理的に近いサーバーと通信するようにするもの。
コンピューティング、ストレージ、データベース、およびその他の選択された AWS のサービスを、エンドユーザーから近い場所に配置できる、アベイラビリティゾーンのさらに細かいものです。
地理的にエンドユーザーと近い場所で、レイテンシーの影響を受けやすいアプリケーションを実行できます。
「AWS Wavelength Zone」
一言でいえば、5Gを使って低レイテンシーなアプリケーションをつくるためのもの。
モバイルデバイスおよびエンドユーザーに対して 10 ミリ秒未満のレイテンシーを実現するアプリケーションを、開発者が構築できるようになります。
AWS 開発者は、Wavelength Zone にアプリケーションを配置することができます。
AWS Wavelength により、AWS のサービスを 5G ネットワークのエッジで提供できるため、モバイルデバイスからアプリケーションに接続する際のレイテンシーを最小限に抑えることができます。アプリケーショントラフィックは、モバイルプロバイダーネットワークから出ることなく、Wavelength Zone で実行されるアプリケーションサーバーに到達できます。これにより、インターネットまでの間にある、100 ミリ秒以上のレイテンシーを引き起こし得る余分なネットワークホップ数が削減されるため、お客様は、5G の広い帯域幅と低いレイテンシーを使い切らずにすみます。
対モバイルで高速な動作が要求されるときに使用します。
「AWS Outposts」
一言でいえばオンプレのデータセンターにAWSのサーバを置くこと。
AWS Outposts は、オンプレミス（物理的にPCを用意してそこで動作する）のシステム、ローカルのデータ処理、またはローカルのデータストレージへの低レイテンシーのアクセスを必要とするワークロードに最適です。
要約すると、AWS上ではなくオンプレミス上で動作するシステムがAWSと高速に連携できるようになるものです。
Local Zones、Wavelength、Outpostsはどれも低遅延でAWSに接続するためのソリューションです。
ネットワーク（Amazon Virtual Private Cloud VPC)
AWSはクラウドコンピューティングサービスであり、それらが提供するITリソースは仮想のものである。
そのため、ネットワークも自社のものではなく、外部に作ることになるわけだが、その時によりセキュアなネットワークでITリソースを管理したいなどの欲求がある。
そこで使用するのがこのVPCというサービスである。
VPCは、AWSクラウド内にプライベートなネットワークを構築することができる。
このネットワークは、構築するうえで様々な項目を設定可能としており、
使用するIPアドレスの範囲やサブネット、ルートテーブルといった標準的なネットワークの構成項目を定義できる。
こうすることで、インターネット上に公開するものや、アクセス制限をかけるものを分けて管理することができるようになる。
「サブネット」
文字通り、VPCの大きなネットワークの中をさらに区切るサブのネットワーク
「ルートテーブル」
ルートテーブルとは通信をどこに流すかを定義するための情報で、サブネット毎に存在する
例えばVPCネットワークAに所属するサブネットAに紐づいているルートテーブルに送信先は10.0.0.0/16のIPアドレスの範囲にのみ通信を許可すると書かれていたとすると、サブネットAに所属するサーバーからは10.0.0.0/16の範囲にしか通信を行えなくなったりする。
VPCを使う上での注意点
VPC内にサーバーを立てたりすると、同時にそのサーバーに住所が割り振られる。
この住所がIPアドレスである。
ネットワーク内での通信はこの住所を指定して行う。
このIPアドレスのどこからどこまでを使用するかという定義は、複数のVPCを使用する場合には意味を持つ。
VPCピアリングというサービスをつかって複数のネットワーク（VPC)をまたいで通信を行う場合、IPアドレスの範囲がかぶっていると、ネットワークAのIPアドレスかネットワークBのIPアドレスかを特定することができない。
そのため、複数のVPCネットワークを使用する場合、そのIPアドレスの使用範囲がかぶらないようにネットワークを構築する必要がある。
また、VPCはAWSの基幹部分ともいえるサービスで、VPC内で使用できるAWSは非常に多い。
例えば、サーバーを立てるEC2などが代表される。
VPCはリージョン単位で使用するもので、アベイラビリティゾーンごとにVPCを用意することができない。
そのため、リージョンにVPCを建て、その中にアベイラビリティゾーンを分割してサブネットをいくつか作り、そこにサーバーを立てたりするような使い方になる。
サブネットは、複雑化を避けるためなるべく少数にとどめることが推奨される。
デフォルトではVPC内のすべての場所に通信を許可するため、プライベートかパブリックか等も含めてサブネットを差別化したい場合は、ルートテーブルの編集を忘れないこと。
「パブリックネットワーク」
インターネットにアクセスできるネットワーク
VPCにインターネットゲートウェイをアタッチし、VPC内以外の通信トラフィック（ネットワークを流れる情報）をインターネットゲートウェイに送信するようにルートテーブルを設定した場合、実現することができる。
また、VPC内のインスタンスがパブリックな通信を行おうとした場合、パブリックIP（インターネットに公開されるIP）が必要になる。
「インターネットゲートウェイ IGW」
インターネットにアクセスするための通信の出入り口
「プライベートネットワーク」
インターネットにアクセスできず、特定の範囲でのみ通信を許可されたネットワーク
コンピューティングサービス（EC2・Lightsail・ECS...)
どのようなサービスを立ち上げるにしろ、サーバーレスで実装することを除けば、まずはコンピューターを用意してサーバーを立てるところから始まる。
サーバーを物理的に用意するオンプレミス環境では、物理的にPCを購入し、保守人員を確保し、物理的な環境を整え、定期的にメンテナンスを行うと多額のコストがかかる。
また、PCは利用状況ではなくプロジェクトの計画によってスペックが決定されるため、運用や計画が後に変わった場合に対応することも難しい。
「オンプレミス」
自社内の設備によって運用することを指します。
会社でコンピュータを買ってきて、設置して、そこで動くシステムをオンプレミスで稼働するシステムと呼びます。
しかし、AWSにおいては使うときだけ仮想上に指定したスペックでサーバーを起動できるため、スケールアップもスケールアウトも思いのままだ。
物理的なサーバーを管理する必要がないので、物理的な環境も必要がなく、早い話がクライアントPC1台を用意してAWSが提供するサービスを使うだけでよいのだ。
「スケールアップ・スケールアウト」
スケールアップはサーバーを増強すること、スペックを上げることを言います。
スケールアウトはサーバーの台数を増やすことを言います。
どちらもサーバーにかかる負荷が大きくなったときに行う対応です。
代表的なのはAmazon Elastic Compute Cloud（EC2)で、安全でサイズ変更可能なコンピューティング性能をクラウド内で提供してくれる。
EC2を使うことによって、プロジェクトの計画による事前のプロビジョニングではなく、現状・必要にあわせたサーバーを使用することができる。
他にも、AWSはAmazon Lightsailというサービスを提供している。
これは、数分で仮想プライベートサーバーを起動して、ウェブサーバーとアプリケーションサーバーを管理できるようにしてくれる。
他にも、AWSはAmazon Lightsailというサービスを提供している。
これは、数分で仮想プライベートサーバーを起動して、ウェブサーバーとアプリケーションサーバーを管理できるようにしてくれる。
また、Dockerコンテナ（仮想環境の一種）を使用している場合にも、Amazon Elastic Container Service(ECS)が対応している。
このサービスは、インフラストラクチャの部分もまるごと管理してくれるため、ユーザー独自で運用システムを用意する必要がなくなる。
さらに、AWS Lambdaというコード実行サービスを使えば、そもそもサーバーを建てる必要もなく、ただコード実行のみ行うこともできる。
もはやサーバーを起動したりすることを考える必要すらない、サーバーレスを実現できる。
これもまた、物理的なリソースを必要としないクラウドだからこそ実現できるメリットであるといえる。
セキュリティグループ
セキュリティグループは仮想サーバーにおけるファイアーウォール（通信制限をかける機構）といえる。
セキュリティグループを詳細に設定することで、自分が構築したサーバーへのアクセスをコントロールすることができる。
例えば、以下ではDBServerにアクセスできるのはAdminNetworkを除けばAPPServerだけである。
WWWServerからアクセスすることはできない。
そういったコントロールを行うのがセキュリティグループ（SG)である
（多層ウェブアーキテクチャを前提とした多層セキュリティグループの例）
「多層ウェブアーキテクチャ」
アプリケーションを複数のソフトウェアエージェントで実行するクライアントサーバーモデル。
代表的なモデルとして三層アーキテクチャがある。
三層アーキテクチャはユーザインタフェース・ビジネスロジック・データベースでアプリケーションを分割して稼働させるもであるである。
「クライアント・サーバーモデル」
昔はメインフレームと呼ばれる一台の巨大なPCを操作していたが、現在はPCの価格低下により複数台のPCをそれぞれ役割に特化させて組み合わせて使うようになった。
こうして、操作するPC（クライアント）と提供するPC（サーバ）に分けた運用が一般的となり、これをクライアントサーバーモデルと呼ぶ
基本的にサービス提供を行う側がサーバーを用意し、ユーザーは自分の持つ端末をクライアントにすることが多い。（例：google検索)
上の図を読み解いていくと、まずウェブアプリケーション層（ユーザーインターフェース）がインターネットからの接続を受け付けているため、SGによって送信元0.0.0.0/0(デフォルト設定）ですべての接続を受け付ける状態であることがわかる。
ちなみに、ルートテーブルとの違いは、ネットワーク全体の設定であるか、SGに所属するサーバーの設定であるかである。
その後、アプリケーション層（ビジネスロジック）ではウェブアプリケーション層からのアクセスだけを受け付け、データベース層はアプリケーション層からのアクセスのみを受け付けることがわかる。
このような細かいアクセスの設定を行えるのが、SGである。
主要なサービスの紹介
全てを紹介することはさすがに難しいのですが、よく使われる主要なサービスを紹介します。
クラウドプラクティショナー試験の選択肢に出てきたものは全て載せるようにしています。
Amazon Elastic Compute Cloud EC2
[Amazon_EC2][1] ※よい内容だったのでリンクさせていただきます
よくEC2と呼ばれるが、Amazon Elastic Compute Cloudの略で、サーバーを立てるときに使う。
AWSではサーバーのことをインスタンスと呼ぶので、今後インスタンスを記載されたらEC2によって建てられたサーバーのことだと覚えておく
仮想のサーバーなので、AMIという形でバックアップを取っておけるし、AMIを共有することで誰でも決まった構成のインスタンスを立てることもできる。
ec2インスタンスは、用途に合わせて様々な種類を要している。
例えば、データベースサーバーにするなら物理メモリ容量を最適化したいが、そういった場合はr4シリーズのインスタンスを使うなどである。
これによって、ユーザーは様々な役割に合わせて最適なサーバーをプロビジョニングできるようになる。
さらに、インスタンスの運用方式にもいくつかの種類がある。
これには3種類の実行方式がある。
「オンデマンド」
リクエストに応じてインスタンスを起動する。
通常はこの形態で、必要な時にインスタンスを起動し、不要な時に止める。
「リザーブド」
事前に1年もしくは3年の単位で料金を払っておくことで、通常より安い金額でインスタンスを起動できる。
長期的かつあるていど安定した運用を行えるものはこの方式にすることでコストを抑えられる
「スポット」
インスタンスの料金が常に変動し、一定金額以下の場合に起動、高くなったら停止という運用方式。
作業を中断したり、1日のうちどこかで作業を行えればよいものなどはこれを使うことでコストを安く抑えられる。
AWS Lambda
以前説明したように、AWS Lambdaはサーバーレスでコードを実行することができるイベントドリブン型のサーバーレスコンピューティングサービスである。
AWSでは、様々なサービスが動作をしており、これらがどのように実行されたかをイベントとしてキャッチしてコードを実行することができる。
「イベントドリブン」」
event driven 何かイベントが発生して、それに対応してプログラムが動くこと
イベント駆動ともいわれる。
AWS Lambdaでは、サービスのプロビジョニングを行わずにコードを実行できるので、サーバーを管理する必要がない。
これをサーバーレスという。
AWS Lambdaでは可用性の高いコンピューティングインフラストラクチャでコードが実行されており、ログをとったりコードをモニタリングしたりと、あらゆる管理を行える。
また。サポートされている言語もNode.js Java C# pythonなど幅広い。
また、AWSのイベントだけでなく、Amazon API Gatewayを使用したhttpリクエストへの応答などでも起動することが可能である。
また、実行されるコード自体についても、Amazon CodePipelineやAWS CodeDeployを使用して自動的にデプロイすることもできる。
スペックとしては以下のようになる。
・ディスクスペース 512MBまで
・メモリ 128~1536MBまで
・実行時間 最大５分まで
・リクエストとレスポンスのペイロード ６MBまで
・イベントリクエストの本文 128kbitまで
Elastic Load Balancing(ELB) Application Load Balancer(ALB)
ALBはELB(Elastic Load Balancing)のサービスの一部として導入された2種類目のロードバランサー
CLB(Classic Load Balancer)の後継機で、これにいくつかの機能を追加した強化版
「ロードバランシング」
複数のサーバ、コンピュータ機器に対してリクエストや処理などを振り分けること
例えば同じ内容のアプリケーションをデプロイしたサーバーインスタンスを複数用意し、これらにアクセスを分散させて負荷分散を実現したいときなどに、ALBはそれらを適切に行ってくれます。
ALBでは様々なリクエストを受け付ける中で、どのような通信ポート番号でアクセスしてくるかによって、アクセス先のpathを差別化することもできます。
「path」
ファイルまでの階層 C:\Users\works\Desktop....みたいな
ALBを知る上で、以下の3つの要素について知っておきましょう。
「Listener」
リスナーは接続要求をチェックするプロセスです。
設定したプロトコルとポートを使用します。
リスナーに対して定義したルールによって、ロードバランサーが1つ以上のターゲットグループ内のターゲットに要求をルーティングする方法が決まります。
「Target」
ターゲットは、確立されたリスナールールに基づくトラフィックの宛先です。
「Target Group」
各ターゲットグループは、指定された通信プロトコルとポート番号を使用して、要求を1つ以上の登録済みターゲットにルーティングします。
ターゲットは複数のターゲットグループに登録できます。 ヘルスチェックは、ターゲットグループごとに設定できます。
「ポート」
通信機器や個々のコンピュータの持つIPアドレスの下に設けられた補助アドレスとして、0から65535までの「ポート番号」が使われる。
これにより、1台のコンピュータで複数のサービスを提供したり、複数のコンピュータと同時に通信できるようになっている。
例えば、同じサーバーにアクセスするのでも、ポート1001番はテスト環境、ポート1000番は本番環境というように分けることができる。
例 http://172.255.255.255:10001/ ここでいう:の左側がIPアドレスで、どのサーバーにつなぐかを表しており、:より右側がポート番号
「通信プロトコル」
プログラムの通信方式
SSHやTCP等といった種類があるが、主に相互に通信を送受信するために、お互いが同じ方式でデータを解釈できるようにきめたフォーマット、ルール。
「日本語で話す」プロトコルを自分と相手で共有が取れてないと、例えばアメリカ人に日本語で話しかけてもいい返事は帰ってこない。
多分エラーメッセージ「ぱーどぅん？」が返ってくる。
ネットワーク接続は、前述したIPアドレス・ポート・通信プロトコルを組み合わせて行われるということがわかればよい。
AutoScaling
オートスケーリングは非常に便利な機能です。
ロードバランサーの話がありましたが、オートスケーリングは負荷に合わせて自動でインスタンスの数を増やし、ロードバランサーが自動でそのインスタンスにアクセスを割り振ってくれます。
もちろん、その逆も可能です。
オートスケーリングでは、起動設定・Auto Scaling グループ・Auto Scaling ポリシーを登録する必要があります。
グループでは、いくつ以上いくつ以下のインスタンス数を保つか、どのロードバランサーで管理するかなどの情報を設定します。
ポリシーはスケールを行うスケジュール登録です。
負荷分散だけでなく、サービスを自動的に停止・開始するという使い方もできます。
Amazon Elastic Block Store EBS
EBSはEC2でつかえるストレージです。
これはドライブをHDDにするかSSDするかなども選べ、容量が不足したら簡単に追加することができます。
これらは使用した分だけ料金がかかります。
「ストレージ」
ファイル置き場、倉庫、保管ボックスみたいなイメージ
「HDD」
HDDはHard Disk Drive（ハードディスクドライブ）の略で、データやプログラムなどを電磁的に書き込んだり読み出したりする記憶装置です。
SSDと較べて1ドライブで保存できるデータ量が大きい
「容量単価」としては安価になる
消費電力が比較的大きい
「SSD」
SSDはSolid State Drive（ソリッドステートドライブ）の略で、HDDと同様の記憶装置です。
半導体素子メモリを使ったドライブ（記憶媒体）のことを指します。
読み書きの速度が非常に速い
容量が少ない
まだまだ容量単価としての価格は高い
物理的に存在しているストレージ（皆さんのＰＣの中にあるHDDなど）と比較し、EＢSは物理的な故障もなくレプリケーションもできるため耐久性が高く、カスタマイズも自由です。
ログ置き場は速度がいらない安価なＨＤＤ、アクセスを繰り返す部分には高速なSSDなど運用も効率的に行えます。
データはスナップショット（ある時点のバックアップ）を作成でき、リージョンをまたいで移動することもできます。
容量が足りなくなれば、あとから簡単に拡張することもできます。
「レプリケーション」
データを別のところで同じように複製する。
EBSの種類は、大きく５つ。SSD２種類、HDD２種類、旧世代のマグネティック１種類、となっています。
SSDとHDDの比較としては、IOPS(インプット・アウトプット Per Second、1秒あたりの処理できるデータの出し入れの数)とスループット、コストがよく用いられます。あとそれらを考慮した上での具体的な使い分け、とか。
ざっくりまとめると、SSDは「高IOPS」「ランダムアクセス向き」、HDDは「高スループット（処理能力）」「シーケンシャルアクセス（記憶媒体の先頭から順に検索しアクセスしていく）」「低コスト」、という感じ。
マグネティックはコストを下げたければというところです。
あと、HDDは起動ボリュームに指定できません。
SSD、HDDともに、それぞれ汎用・高性能が選択できます。
EBSの特徴
•AZごとに独立、他のAZのEC2からは使用不可
•スナップショットをS3に保存可能、S3経由で他AZに移動可能
•EC2とEBSは1:Nの関係で構築できる
Amazon simple Store service S3
こちらもストレージサービスです。
EBSがインスタンスのストレージとなるもので、インスタンスごとに別にで用意されるストレージなら、こちらはインスタンスに関係なくどんと用意されているストレージです。
グローバルサービスといって、同一リージョン内のリソースが共通で使用することができます。
様々な場所から共通でアクセスできる保存ボックスです。
EBSは容量の制限があり、その使用料から料金が決められていました。
S3は数テラバイトあろうがすべて保存できます。
それゆえ、料金はリクエスト単位となっています。
PUT COPY POST LIST GETはすべてお金がかかります。
また、データはHTTPアクセスできるためすべてＵＲＬが自動で付与されますし、低レイテンシーです。
プライベートなネットワークからでもアクセスできます。
S3はバケットという単位で内部を区切ることができ、バケット別にアクセスをコントロールしたりもできます。
Amazon Glacier
ぐれいしあって読みます。これもストレージです。
S3より遅いけど安いやつで、法律上必要だけど普段まったくアクセスしないみたいなファイルを長期間保存することにむいています。
グレイシアは遅いので、データの取り出しには数分から数時間かかります。
ここに保存されるデータは「アーカイブ」という単位で保管されます。
また、S3でいうバケットにあたる、保管場所のことを「ボールド」と呼んでいます。
グレイシアでは、S3などのアクセス可能なあらゆる場所のデータをアーカイブできます。
例えば、S3に保存された30日以上アクセスのないデータはグレイシアに自動的に移動するといったことも可能です。
Ｓ３は最大５ＴＢのファイルを保存できますが、グレイシアは４０ＴＢものファイルを保存できます。
これはどちらも1ファイル当たりの最大容量で、ストレージ自体の容量限界はありません。
料金はアップロードと取り出し時にかかります。
Amazon Storage Gateway
オンプレ環境とAWS環境の間でシームレスに使えるストレージ
Amazon Command Line Interface CLI
AWSのアカウントを作成すると、ブラウザ上でマネジメントコンソールを開いてそのうえでリソースを操作します。
CLIはブラウザではなくコマンドプロンプトやターミナルからコマンドでawsを操作できる機能です。
スクリプト化すればawsへの操作を自動化することもできます。
例えば、pythonのboto3モジュールなどを使ってAWSのAPIを実行することで、AWSを画面から操作しなくてもインスタンスの情報を取ったりできます。
Amazon Relational Database Service RDS
これはアマゾンが提供するリレーショナルデータベースです。
リレーショナルデータベースというのは、表でデータを管理していて、ＳＱＬを使って高度なデータの検索が行えたり、トランザクションの管理ができたりするデータベースです。
例としてはOracleやDB2などがあります。
対して、KVSという、キーと値だけでデータを持っているデータベースもあります。
RDBは複雑な条件を指定した検索に向いており、KVSは速度を重視する場合に使用します。
業務用のアプリケーションでは、ほとんどがRDBを使用しています。
通常、データベースとはデータが追加でどんどん入ってきて容量が大きくなったり、頻繁にアクセスされたりするものなので、スケールやらセキュリティやらパッチ適用やら、そもそもインストールやらとたくさんの管理タスクが存在します。
内容も単純でなく、専門的な知識を必要とするものが多いです。
RDSではそれらを大幅に自動化しています。
パッチ適用やバックアップ、スケーリングやらの管理タスクも自動になるのです。
また、データの内容をコピーし、スタンバイ状態で別のアベイラビリティゾーンにデータベースインスタンスを立てておくこともできます。
これによってデータベースインスタンスのあるアベイラビリティゾーン単位で障害が起きた場合でも、迅速な復旧を行えます。
RDSでは6種類のリレーショナルデータベースに対応しており、ユーザーのニーズに応じて選ぶことができます。
Amazon Aurora
RDSは様々なリレーショナルデータベースを提供するサービスでした。
Auroraは、RDSで提供されるリレーショナルデータベースのうちの一つです。
Amazon Aurora は、標準的な MySQL データベースと比べて最大で 5 倍、標準的な PostgreSQL データベースと比べて最大で 3 倍高速です。
また、商用データベースと同等のセキュリティ、可用性、信頼性を、10 分の 1 のコストで実現します。
Amazon Aurora のストレージシステムは分散型で耐障害性と自己修復機能を備えており、データベースインスタンスごとに最大 64 TB まで自動スケールされます。
Amazon Aurora は、最大 15 個の低レイテンシーリードレプリカ、ポイントインタイムリカバリ、Amazon S3 への継続的なバックアップ、3 つのアベイラビリティーゾーン (AZ) 間でのレプリケーションにより、優れたパフォーマンスと可用性を発揮します。
つまり、一般的なリレーショナルデータベースよりも早くて安い上で安全安定性は一般的な水準を出せ、単一障害点（ここが壊れたらシステムが止まる）となりやすいデータベースの弱点を分散型にすることで補っており、自己修復もスケールもできてリカバリーもできるすごいデータベースですよということです。
Auroraは高性能なＤＢですが、今まで使っていたアプリケーションをクラウドに移行するという場合、データベースは既存のものを使用しているはずです。
この置き換えを行うか否かという判断は、Auroraの可用性にあるといえます。
当然ですが、たいていの場合はデータベースは一つで、その中にデータを入れています。
その場合、対象のデータベースは単一障害点となります。
これは、データベースがトラブルにあった場合、システムは止まってしまうということです。
Amazon Auroraでは、高可用性を実現できます。
Auroraでは継続的にS3にバックアップを作成しながら、3つのアベイラビリティゾーンにデータのコピーを6つ保存します。
また、データベースはマスター（更新対象）とリードレプリカ（参照対象）にわけて管理され、リードレプリカは15個まで用意できるため、データの損失が発生することはありません。
さらに、Auroraはプライマリーデータベース（データベースが作成され、メンテナンスされる本番データベース）がクラッシュした場合、60秒以内に復帰できるように設計されています。
これは、通常であればREDOログというデータベースに対して行われた更新ログからすべてのSQLを実行しなおして復旧するところを、データベースへの読み込み動作があるたびに細かく行って状態を保存しているためです。
これらの耐障害性能がどうしても欲しいなら、データベースのリプレイスは十分検討されるべきでしょう。
Amazon DynamoDB
DynamoDBは、NoSQLのデータベースです。
リレーショナルデータベースのようなSQLを使って複雑にデータの検索を行えるデータベースに対して、高い速度が評価できます。
また、リレーショナルデータベースではテーブル（データを入れておく場所）の構造を更新する場合はすべてのデータを更新する必要がありますが、NoSQLでは古い構造と新しい構造を同時に持つことができるというのも特徴です。
これは、アプリケーションの進化に応じて柔軟なデータベースを苦労なく保てるという利点があります。
DynamoDBはオートスケーリングにも対応しており、負荷に対して柔軟です。
ストレージの拡張なども自動で行えます。
多数のユーザーが高い頻度でアクセスを繰り返すようなDBには非常に有効で、低レイテンシーで柔軟な運用を行うことができます。
また、DynamoDBでは、インフラストラクチャは完全にアマゾンが管理しており、これについて気にする必要もありません。
データの検索方法は基本的にはKVSですが、データに紐づけられた属性から検索を行うことも可能です。
しかし、その方法はパフォーマンスに良くない影響を与えるでしょう。
そのため、複雑なデータ管理には向いていないといえます。
そういった場合はRDSを使うと良いでしょう
Amazon ElastiCache
キャッシュを行う機能です。
「キャッシュ」
よく使うデータを高速低用量のメモリ内に保存しておくことで、次回使用時に素早くデータを取り出し使用できる機能
つまり、アプリケーションの速度を高速化するための機能です。
RedisとMemcachedという既存のキャッシュシステムに対応しています。
RDBの紹介の時に、KVSが早くてSQLをつかうRDBは遅いという話をしましたが、RedisはNoSQL、つまり高速なデータ検索を可能にするシステムです。
Amazon Redshift
これは高速なデータウェアハウスです。
「データウェアハウス」
データを時系列順で保管する倉庫で、書き換えや部分的な消去などができません。
データベースは今の状態を記録し更新することに強みがありますが、データウェアハウスは連続したデータの履歴保管が主な用途です。
SQLや既存のBIツール（データ分析ツール）を使って高度なデータ分析を行えます。
しかも、高速に大量のデータを処理できます。
料金は使用した分だけかかりますが、1時間当たり２5セントからです。
年間でテラバイトあたり1000ドル程度の料金で処理でき、これは従来のデータウェアハウス製品の1/10のコストしかかかっていないことを表します。
しかもデータの扱いは保管中でも通信中でもすべて暗号化されているため、安心安全です。
ビックデータの解析などにも向いているといえるでしょう。
Redshift Spectrum を使うと、Amazon S3 に保存されたオープンデータフォーマットに直接クエリを実行することもできます。
また、これらを使用した分析サイクルを自動化することは非常に簡単で、ユーザーはそのデータを使ったビジネスの改善に集中することができるようになります。
Amazon CloudWatch
AWSのクラウドリソースと実行されるアプリケーションをモニタリングするサービス
ログの収集やモニタリング、アラーム設定などが行える。
Amazon CloudTrail
AWS内で、だれがいつどこで何をしたかを監視しているサービス。
何らかの想定外な作業が確認された場合は、ここから誰が作業したのかを確認することができる。
AWS Config
AWSのセキュリティと統治を行うための機能で、構成変更を通知したり履歴を確認したりするだけでなく、あらかじめルールを記載しておくことで、AWSリソースがルールに従って構築されているかを確認したりもできます。
Amazon Trusted Advisor
AWSを使用していると、リソースのあれやこれやと確認したいものが出てくるわけですが、AWSでは所有するリソースは膨大です。
たとえば、全く使われていないストレージや、動作していないインスタンスにアタッチされたEIPなど、お金はかかるが最適化されていないもの、有ったらどうにかしたいものなどは無数にありますね。
Trusted Advisorは、アカウントのすべてのリソースをチェックし、ベストプラクティスを提供してくれます。
これは、サービスの制限・セキュリティ・耐障害性・パフォーマンス・コストのそれぞれ項目で実行されます。
これはコンソール画面の一部ですが、一目でどの分野に問題があり、どれくらいコストが無駄になっているかを見ることができます。
さらに、この機能にはapiも用意されており、自動でこれらを適用することも可能です。
Amazon CloudFormation
AWSのリソースを使った構成まるごとをテンプレートという形に落とし込むことで、依存関係などを一切考慮せずに環境構築を行うことができます。
つまるところ、インフラを設定ファイルのようにまとめてしまえます。
テンプレートをyamlやjsonで書いて、cloudFormationでスタックにする。
スタックはリソースの集合体を表していて、要は環境丸ごとまとめたものだと思えばよい。
スタック内部のリソースをどういった順番で構築するかなどはCloudFormationが自動的におこなってくれる。
AWSで環境構築などを行う際に、Cloudformationのテンプレートをコードで管理して複数のリソースの集合体を管理したりします。
同じような環境を顧客ごとに立てたりする場合は、必須に近いサービスです。
AWS OpsWorks
AWSインスタンスに対してChefを使える機能
「Chef」
ファイルに記述した設定内容に応じて自動的にユーザーの作成やパッケージのインストール、設定ファイルの編集などを行うツール
自動化につかう
Amazon Batch
バッチ処理を行うためのサービス
バッチ処理は大量のデータを決められたルールで処理していくというようなものが多く、非常に時間もかかる。
AWS Batchは、処理データの要領などによって動的にコンピューティングリソースを決定し、高いパフォーマンスで処理を行える。
「バッチ処理」
あらかじめ定めた処理を順次実行すること。
営業時間中に行われた処理に対して、大量のデータを夜中のうちに加工したりするのにつかわれることがおおい。
Amazon simple Queue Service SQS
メッセージキューイングを行う機能です。
メッセージを保管しておくことができます。
「メッセージキューイング」
あるプログラムが送信したメッセージを格納しておく
そのメッセージは取り出されるまではそこにおり、そのメッセージを必要とするプログラムが何らかのタイミングでメッセージを受け取りに行くことができる。
そして、そのプログラムは受け取ったメッセージに応じて動くという機構。
先に入れたものを先に取り出すFIFO（ファストインファストアウト）とかその逆のFILOとか取り出しの順番がきまってたりする。
それによってスタックとキューで名前が分かれてたりする。
非同期で動くプログラムどうして連携を取りたいケースなどに使用する。
「非同期」
Ａが実行されるまでBは待機するという状態を同期しているという。
非同期は逆で、Aを実行したらその結果を待たずにBも動けること、を表す。
Amazon simple Notification Service SNS
これはメッセージをためておくSQSと違って、メッセージを送るための機能です。
Amazon SNS を利用すれば、アプリケーションは「プッシュ」メカニズムを使用して、複数のサブスクライバーにタイミングが重要なメッセージを送信することができます。
そのため、更新を定期的に確認したり、ポーリング（一定間隔で順繰りに要求がないか尋ねる）したりする必要性がなくなります
Amazon EC2 Container Service ECS
Dockerコンテナを使うための機能です。
「Docker」
EC2のような仮想環境をつくるためのツール。
windowsのなかにlinux環境を用意したりできるため、AWS以外でも広く使われている
もともと仮想環境を使用していたユーザーとしてはDockerはEC2よりもなじみ深いものですし、既にdockerが提供する優れた環境もたくさんあるので、EC2ではdockerをより利用しやすくしつつそのまま使えるようになっています
Amazon EC2 Container Registry ECR
dockerにもEC2でいうAMIのようなイメージ存在し、それを利用することで簡単に環境を立てることができる。
ECRはそういったDockerコンテナのレジストリである
「レジストリ」
情報を保存しておくデータベース
Windows OSが設定情報を保存しておくデータベースをレジストリと呼んでいる。
Amazon Lightsail
こちらも仮想サーバーを立てるためのサービスで、数分でプライベートなクラウド環境を構築できる。
サーバー料金にインターネット転送料金やディスク料金が含まれているのが特徴的で、VPCも専用の物が用意されるのでEC2と連携したりするのは苦手（無理ではない）、後停止していても金がかかる
インターネットへの転送料金に追加のお金がかからないので、サーバー1台で運用する、画像や動画など配信データ量が比較的多いWebサイト向け。
ロードバランサーとかはないので、簡単にサーバー立ち上げてちょっと使って本運用はEC2とか、おためしにもいい。
AWS Elastic Beanstalk
Elastic Beanstalk を使用すると、アプリケーションを実行しているインフラストラクチャについて考えることなく、AWS クラウドでアプリケーションのデプロイと管理を簡単に行うことができます。
我々は単にそのアプリケーションをアップロードするだけで、Elastic Beanstalk がキャパシティーのプロビジョニング、ロードバランシング、スケーリング、およびアプリケーション状態モニタリングといった詳細を自動的に処理します。
しかも、Elastic Beanstalk に関して別途料金が発生することはありません。
Elastic Beanstarkはplatform as a service （PaaS）です。
Paasとは、ネットワークを通じたサービスとして、アプリケーションを利用するためのプラットフォーム（土台）を顧客に提供する形態をいいます。
なんやかんや言いますが、Elastic Beanstalkがサポートしている言語で書かれたコードを、自分の環境に簡単に配置・管理できますよという話です。
Elastic Beanstalk は、Go、Java、PHP、.NET、Node.js、PHP、Python、および Ruby で作成されたアプリケーションと、各言語に対応するさまざまな種類のプラットフォーム設定をサポートしています。
以下のように、ホストコンピュータやＯＳ、アプリケーション実行サービスやHTTPサービスも用意してくれているので、我々は、アプリケーションをAPサービスに、画面情報をHTTPサービスに渡すだけでアプリケーションを動かせるのです。
また、この環境への負荷があがれば、自動でスケーリングしたり、それによって増設されたＡＰサーバーに適切なロードバランシングを自動で行ってくれますよというサービスですね。
我々がやるべきことはコードを書いて、アップロードするだけです。
コードがアップロードされると、AWS Elastic Beanstalkはコードの実行に必要な環境を自動で起動して管理もやってくれます。
アプリケーションを運用するためのインフラをAWS上に構築するためには、AWSの知識はもちろんのこと、OSやネットワーク等について多様な知識が必要です。
AWSは、各システム固有の細かい要件に柔軟に対応するために、詳細で複雑な設定項目が無数にあり、正直なところ一朝一夕でどうにかなる知識の量ではありません。
（この記事が鬼長いことでもわかると思います）
ただ、逆に考えれば「細かい要求はしない、とにかくオススメのインフラをくれ、アプリケーションはそれに合わせて作る」と割り切れるのであれば、複雑な部分を隠蔽した状態で、シンプルにAWSを利用できるはずです。
Elastic Beanstalkはそのような要求に応えるサービスです。
オンプレからAWSへの移行用サービス
AWS Application Discovery Service ADS
サーバーやストレージ、ネットワーク機器から設定や使用状況のデータを自動収集し、アプリケーションのリストや動作方法、依存関係を把握できるサービス。
AWS Database Migration Service DMS
データベース移行用のサービス
処理中も移行元のデータベースは動かしたままで問題ありませんし、oracleからAuroraというような別のDBへの移行もサポートしています。
AWS Server Migration Service SMS
オンプレミスの VMware vSphere または Microsoft Hyper-V/SCVMM 仮想マシンの AWS クラウド AWS SMS への移行を自動化
AWS Organizations
アカウント一元管理を行えます。
たとえば、複数アカウント使用している場合に請求を一回にまとめたりできます。
AWS inspector
セキュリティを評価できます。
Amazon Inspector では、自動的にアプリケーションを評価し、露出、脆弱性、ベストプラクティスからの逸脱がないかどうかを確認できます。
評価の実行後、重大性の順に結果を表示した詳細なリストが Amazon Inspector によって作成されます。
この調査結果は直接確認することもできますが、Amazon Inspector コンソールまたは API を介して入手可能な詳細な評価レポートで確認することもきます。
AWS Server Migration Service SMS
オンプレミスの VMware vSphere または Microsoft Hyper-V/SCVMM 仮想マシンの AWS クラウド AWS SMS への移行を自動化
AWS snowbal
AWSとオンプレ環境の間で大量のデータ転送を行えるサービス
AWSのセキュリティ
責任共有モデル
AWSは様々な機能を提供していますが、あくまでこれは何かを成し遂げるためのツールを提供しているにすぎません。
そのため、AWSとユーザー、それぞれが責任を持つべき領域が存在します。
そのため、AWSのユーザーはこの責任共有モデルについて理解する必要があります。
AWSの責任範囲
AWSはクラウドのセキュリティに責任を負います。
これは、AWSを運営するのに必要な物理的なサーバーなどのすべてのグローバルインフラストラクチャを保護する責任があるという意味です。
そのため、自信によって物理的なサーバーが故障し、AWSが動かなくなったとしてもユーザーに責任は在りません。
リージョン・アベイラビリティゾーン・エッジロケーションに含まれるもの等、すべてAWSの責任です。
また、それだけでなくデータベースやストレージ、ネットワーキングなどの基本的とみなされた製品のセキュリティ設定にも責任を持っています。
これらのサービスが使用するオペレーティングシステム（ＯＳ）やパッチ適用などもAWSの責任となります
ユーザーの責任範囲
ユーザーはクラウド上に保存するあらゆるものを保護する責任を負います。
例えば、データベース自体のパッチ適用などの管理はAWSの仕事ですが、そのデータベースをプライベートなネットワークに設置してデータに対しての外部からの攻撃に備えるのはユーザーの仕事です。
以下のようなものが対象となります。
- AWSに保存するコンテンツ
- コンテンツで使用されるサービス
- コンテンツが保存される国（リージョンの選択）
- コンテンツの形式・構造、暗号化など
- コンテンツにアクセスできるユーザーの制御
EC2やVPCなど、Iaasのカテゴリに分類される製品はユーザーがすべて管理します。
「Iaas」
Infrastructure as a Service
IaaSはサーバーやストレージ、ネットワークなどのハードウェアやインフラまでを提供するクラウドサービスの総称
「Paas」
Platform as a Service
システム開発に必要なアプリケーションとOSをつなぐミドルウェアやデータベース管理システム、プログラミング言語、WebサーバーOSなどといったソフトウェア一式を提供してくれます。
「Saas」
Software as a Service
従来はパッケージとして提供されていたアプリケーションを、インターネット上で利用する提供形態です。
エンドユーザーにとっては、このSaaSが一番なじみのあるクラウドサービスかもしれません。
端末にアプリケーションをインストールすることなく、必要なサービスをインターネット経由で手軽に利用することができます。
セキュリティサービスの紹介
AWSのセキュリティ用件は、最も厳しい顧客のニーズを満たすように設計されています。
Identity and AccessManagement 、 ログ作成とモニタリング、 暗号化とキー管理、 ネットワークのセグメンテーション、 DDos保護など様々なセキュリティサービスは、ほぼ追加料金なしで使用することができます。（使用した分だけお金がかかるものもあります）
これらのサービスを、オンプレミス環境にインフラを構築するよりもはるかに低い運用オーバーヘッドで、ニーズに合わせて使用できます。
「オーバーヘッド」
システムを利用するための付加的処理や、余分な時間など
AWSでは、ネットワークや構成管理、アクセスやデータについて、セキュリティに特化したツールを提供しています。
加えて、モニタリングやログ作成機能を使うことで、環境内の出来事を完全に可視化できます。
ネットワークについては、プライベート（社内）からのアクセスのみを許可したり、パブリックなネットワークを構築したりできます。
全サーバーにおいて、データのやり取りはTransport Layer Securityによって暗号化され、AutoScalingやコンテンツ配信戦略の一部としてDDosを緩和する技術もあります。
「DDos」
コンピュータに対して複数のマシンから大量の処理負荷を与えることでサービスを機能停止状態へ追い込む手法
AWSにはクラウドリソースを組織の基準とベストプラクティスに準拠させつつ、スピードを向上させるための幅広いツールが用意されています。
AWSリソースを組織の基準に従って行うためのデプロイツールや、AWSリソースへの変更を追跡管理するインベントリおよび構成管理ツール、EC2インスタンス向けに標準的な設定済みの強固な仮想マシンを作成するテンプレート定義および管理ツールがあります。
AWSはクラウド内に保管しているデータにセキュリティレイヤーを追加し、スケーラブルで効率的な暗号化機能を提供します。
EBS S3 Glacier RDS Redshift などのストレージやデータベースサービスで利用できるデータ暗号化機能もあります。
また、AWS内で開発されたりデプロイされたサービスにも暗号化とデータ保護を行えます。
AWSではサービス全体に対してユーザーアクセスポリシーを定義し、管理します。
例えば、個々のアカウントにAWSリソース全体での権限を定義できるIdentity and Access Managementや
ハードウェアによる認証をおこなえるMulti-Factor Authenticationなどがあります。
AWSには、環境で何が起きているかを把握することができるツールがあります。
例えば、APIをコールした実行者や内容・時間・発生地点などに関する高い可視性や調査とコンプライアンスレポートを容易にするログ収集オプション。
特定の閾値を条件としたアラート機能などがあります。
「コンプライアンスレポート」
監督当局や官公庁によって定められる規則、標準、法律、規制などに準拠することを目的として企業によって作成されるレポートを指します。
ユーザーはAWS Service Catalogを使用することができます。
これは、IT管理部門向けには、CloudFormationのテンプレートとして管理されるAWSリソース定義や、これらの利用権限をカタログとして一元管理する機能を提供します。
ユーザ部門ではIT管理部門が作成したカタログより、求める機能に応じたAWS環境を必要に応じて起動する事が可能となります。
CloudFormationはテンプレートに記載された内容でインスタンスを立てたりできる機能ですが、これは通常そこで使用されるすべてのAWSサービスに対してIAMによる許可が必要になります。
しかし、権限を広範囲に付与するのは危険といえます。
そのため、この機能はIT管理者が問題ないと提示したテンプレートを作成でき、ユーザーはそれを使用してインスタンスを立てることができるようになる機能です。
そのテンプレートの集合体をポートフォリオといいます。
AWS Marketplaceでは、皆さんのオンプレミス環境にある既存の制御と同等かそれ以上の制御を行える、業界のトップ製品が多数提供されています。
ここにはマルウェア対策やウェブアプリケーションファイアーウォール、侵入に対しての保護なども含まれます。
これらの製品がＡＷＳの様々な機能を補完し、顧客のニーズに合わせたセキュリティを実現できます。
アクセスコントロール IAM
AWSのあらゆるサービスへのアクセスは、アカウントに対して付与する権限の有無によってコントロールすることができます。
これを行うのがIAM（Identity and Access Management)です。
IAMでは以下のことが行えます。
- IAMユーザーとそのアクセス権限の管理（アカウントのID/PW等の管理）
- IAMロールとその権限の管理（サービスに対しての権限管理）
- フェデレーションユーザーとその権限の管理
「フェデレーション」
複数のインターネット サービス間のユーザ認証連携を意味します。
複数のサービスで認証情報を共有することで、1度のユーザ認証で複数のサービスを利用可能にします。
アクセスコントロールのベストプラクティス
1.AWSリソースに無制限にアクセスできるルートアカウントのアクセスキーを削除します。
代わりにIAMユーザーアクセスキーか、一時的なセキュリティ認証を使用します。
2.アカウントのセキュリティを確保するために、AWSルートアカウントでMFAを有効にして保護を強化します。
3.IAMユーザーを作成し、必要な権限のみ付与します。
ルートアカウントは権限が強く危険なため、日常的には使用しません。
4.ユーザー単位で権限を管理するのは複雑なので、IAMユーザーグループの単位で権限を管理します。
5.IAMパスワードポリシーを使用し、定期的なパスワード変更をおこないます。
6.EC2インスタンスで実行されるアプリケーションに対してIAMロールを使用してアクセスできるサービスを制限します。
7.強い権限で作業をする場合はユーザーの認証情報を共有するのではなく、ロールを使用して権限を委任します。
8.退職者など不要なユーザーは常に削除します。
9.ポリシー条件を使用してセキュリティを強化します。
10.AWSアカウントのアクティビティをCloudTrailでモニタリングし、誰がどこで何をしたかをCloudWatchで記録します。
コンプライアンスプログラム
AWSでは以下のようにコンプライアンスをサポートしている。
「コンプライアンス」
法令遵守、企業などが、法令や規則をよく守ること。
保証プログラムを含むAWSのコンプライアンスアプローチ
- 業界の認証と独立したサードパティ認証機関による証明書の取得
- AWSのセキュリティと統制の方法に関する情報をホワイトペーパー及びウェブサイトコンテンツで公表
- NDAに基づいて証明書やレポートなどのドキュメントを提供
「NDA」
秘密保持契約（NDA）とは、取引を行う上で知った相手方の営業秘密や顧客の個人情報などを、取引の目的以外に利用したり、他人に開示・漏洩することを、禁止する契約のことです。
リスク管理、統制環境、情報セキュリティといった、AWSのリスク管理とコンプライアンスプログラム
下記ページにて、コンプライアンスプログラムごとにどのような対応がされているかなどを確認できる。
https://aws.amazon.com/jp/compliance/programs/
AWSのユーザーが担うべきコンプライアンスの責任
AWSはあらゆるコンプライアンスプログラムに対応しており、AWSが提供するサービスは適切な設定を行うことでコンプライアンスを守ることができる。
なので、ユーザーは自分が守るべきコンプライアンスを理解し、適切な運用を行うことが求められる。
そのための機能はAWSが提供するし、ドキュメントも用意する。
つまり、コンプライアンスの達成にはAWSとユーザーの連携が必要であるということです。
コンプライアンスを守るためには、以下のようなステップを踏むと良い。
確認
AWSから提供される情報や他の情報を確認して、IT環境全体について可能な限り多くのことを把握してから、全てのコンプライアンス要件をドキュメント化します。
設計
エンタープライズのコンプライアンス要件を満たすために統制目標を設計及び実装
特定
サードパーティが所有する統制を特定及びドキュメント化します。
検証
統制目標がすべて達成され、主要な統制がすべて効果的に設計及び運用されていることを確認します。
様々なサポート
AWSクラウド上に保管されるユーザーのデータを保護する様々な取り組みを紹介します。
AWS Trusted Advisor
AWSリソースの問題を自動で見つけ、可視化してくれるオンラインツール。
AWSアカウントチーム
ユーザーからの最初の問い合わせ窓口
セキュリティ問題を解消するための適切なリソースを紹介してくれる。
AWSエンタープライズサポート
15分以内対応、24時間サポート年中無休で電話・チャット・メール対応してくれる。
専任のテクニカルアカウントマネージャによるコンシェルジュサービス
AWSプロフェッショナルサービス/AWSパートナーネットワーク
プロフェッショナルサービスはAWS クラウドを使用して期待するビジネス上の成果を実現するようお客様をサポートできる、専門家からなるグローバルチームです。
パートナーネットワークはAWSを使う側の企業が所属するネットワークで、AWSのサービスや技術に長けたベンダーとして公式サイトで紹介され、いち早く新たなサービス・技術の試用ができたり、技術者向けに特別な教育を受けることができる制度です。
どちらも、実証済みの設計に基づいてお客様のセキュリティポリシー及びセキュリティ手順の構築をサポートします。
AWS勧告・速報
現在判明している脆弱性や脅威を提供
AWS監査人のラーニングパス
監査人・コンプライアンス・法的なロールの担当者はAWSを使って内部オペレーションのコンプライアンスを実現する方法を学ぶことができます。
AWSコンプライアンスソリューションガイド
コンプライアンスに関して、何から手を付けてよいかわからないというときは、こちらから学習をすることができます。
AWSにおける設計原則
自社のインフラストラクチャをベストプラクティスにのっとってAWSで構築するためのサポートとして設計のフレームワークは用意されています。
AWSでは5つの柱に基づいてアーキテクチャを設計します。
「フレームワーク」
枠組み、決まりきった手順
ITにおいては、みんなが使いそうな決まりきったプログラムがあらかじめ用意されており、穴埋めするだけで目標とするものが完成するようなひな形を指すこともある。
ここでは決まりきった手順の意味。
アーキテクチャ設計における5つの柱
セキュリティ
IAM
リソースへのアクセス制限
検出制御
ログの取得と分析など
インフラストラクチャの保護
ネットワークの分割やパッチ適用、ファイヤーウォールやゲートウェイなど外部からの侵入への対処
データの保護
データの分類や暗号化、バックアップ、複製復旧
インシデントへの対応
インシデントへの対応プロセスの手順化
セキュリティ設計原則
「全てのレイヤーにセキュリティを適用する。」
どの場所にあるインフラもすべてのレイヤーが保護されてなければなりません。
「追跡可能性の実現」
あらゆるアクションを記録し監査し、だれがいつどこで何をしたのかを把握できる必要があります。
「自社システムの保護」
基本的に、AWSはインフラとサービスにおいてセキュリティを担保しているので、ユーザーは自社システムの保護に全力をつぎ込むべきです。
「セキュリティのベストプラクティスを自動化」
例えば、日常的もしくは異常なセキュリティイベントへの対応などは自動化されるべきです。
信頼性
これは、障害児の復旧能力と、アクセス量に対してのシステムの速度など需要を満たす機能を指します。
クラウド上の信頼性は以下の要素で担保されます。
基盤
アーキテクチャやシステムの基礎的な要素が綿密に計画され、確固としたものであり、需要や要件の変化に対応で木、障害を自動で復旧できる仕組みを用意しましょう。
変更管理
システムを構築する前に、信頼性に影響を与える基盤の要件を整えておく必要があります。
変更管理は、変更によってシステムが受ける影響を完全に理解し、意識することです。
障害管理
障害管理は、システムを変更する前に前もって計画を立ててシステムをモニタリングし、予測し、検知し、対応することに加え障害発生を未然に防ぐことです。
信頼性設計原則
「復旧手順のテスト」
実際に障害が発生しなくても、シミュレーションが簡単に行えるのがクラウドなので、実際の障害が発生する前に確認しましょう。
「障害からの自動復旧」
AWSでは閾値を超えた瞬間にアラートするようなっていも、それを受けとってプログラムを実施するようなこともできますので、自動かは容易です。
「集計システムの可用性向上」
単一の大規模リソースは、単一障害点になりやすいです。
なので、これらは複数の小規模なリソースに分割することで、システムへの影響を軽減できます。
これを水平スケーリングといいます。
つまり、負荷が高くなったからインスタンスを大きくするというスケーリングではなく、もう一台同じアプリを立てて負荷を分散するほうがよいということです。
「キャパシティを予測しないこと」
自動でスケーリングできるのだから、予測する必要はない。
これぐらい必要だろうで固定のリソースを管理するのではなく、どうであっても対応できるように自動化しよう
「変更管理とオートメーション」
アーキテクチャやインフラストラクチャにて変更を加える際には、自動化する仕組みをつくっておいて、それが対応する範囲のみにとどめるべきです。
そうすることで、個別に単独なのシステムやリソースを調整する必要がなくなります。
### パフォーマンス効率
選別
アーキテクチャを最適化するための最適なソリューションを選定しましょう。
レビュー
AWSは仮想化されているがゆえに、リソースのカスタマイズやソリューションの検証が容易です。
そのため、レビューを繰り返して継続的なソリューションのイノベーションを行いましょう。
モニタリング
運用が始まったら、パフォーマンスをモニタリングし、問題は影響が出る前に修正する必要があります。
CloudWatchやkinesis、SQSやLambdaなどモニタリングに適した機能も多く取り揃えています。
トレードオフ
全てにおいて最高のパフォーマンスを発揮するソリューションは在りません。
一貫性、耐久性、容量を時間やレイテンシーとトレードすることが必要になります。
```
パフォーマンス効率設計原則
「最新テクノロジーの標準化」
知識が必要で複雑な実装が難しいテクノロジーは、AWSがサービス化して提供する。
なので、ユーザーはそれをちゃんとキャッチして使っていこう。
「分単位で世界中にデプロイ」
アーキテクチャの変更をしたら、すぐにすべてのシステムにデプロイしましょう。
AWSは世界中の複数リージョンにあるシステムに簡単にデプロイでき、レイテンシーの短縮と顧客サービスの向上を最低限のコストで実現できます。
「サーバーレスアーキテクチャの使用」
インフラ管理がなければ運用コストはなくなり、トランザクションコスト（仲介料）もなくなります。
「頻繁な実験」
仮想化によって既存環境を破壊せずにテストをおこなうことができるようになります。
そのため、従来よりも気軽かつ高速にテストが行えるので、テストを繰り返してシステムの効率を向上させましょう。
「変更管理とオートメーション」
アーキテクチャやインフラストラクチャにて変更を加える際には、自動化する仕組みをつくっておいて、それが対応する範囲のみにとどめるべきです。
そうすることで、個別に単独なのシステムやリソースを調整する必要がなくなります。
「メカニカルシンパシー」
実現しようとすることに最も適した技術を使う
コストの最適化
コスト効率の高いリソース
コストが十分に最適化されたシステムは、所有するリソースをすべて利用することで最低限のコストで最高のパフォーマンスと機能要件を満たします。
需要と供給の一致
柔軟なスケーリングを実施し、必要な時に必要なだけのリソースを使うべきです。
支出の認識
自分たちの使用するリソースにどれだけのコストがかかっているかを一点の曇りなく把握しましょう。
時間の経過に伴う最適化
設計時ではなく、運用が始まってからも徐々に改善を続けましょう
コストの最適化設計原則
「消費モデルの導入」
固定のコストを払い続けるのではなく、使用したコンピューティングリソースの消費量に応じて料金を支払いましょう
「全体的な効率の評価」
システムの生産量とコストのバランスを常に把握しましょう
そしてそこから生産量を上げコストを削減したときどれだけの利益が出るかを認識しましょう
「データセンター運用の費用をなくす」
データセンターにかかる費用を自社でもつのではなくすべてAWSでまかなうことで完全になくしましょう
「支出を分析し、帰結させる」
何によっていくらかかっているかを完全に把握しましょう。
これによりどの部分を改善する必要があるかを明確にし、それによってどれだけのコストが軽減できるかを検討できます。
「マネージド型サービスの仕様」
AWSが提供するサービスにはインフラを一切気にしなくてよいS3などのマネージド型サービスもあれば、EC2のようなインフラ構成の把握が必要なサービスもあります。
なるべくサービスをマネージド型サービスに集約することで、運用コストを下げることができます
運用上の優秀性
ここではビジネスの価値を提供するためのシステムの実行とモニタリング、および継続的にプロセスと手順を改善することに焦点を当てています。
ここでは以下のことが重要になります。
- 変更の管理
- 自動化
- イベントへの対応
- 日常業務をうまく管理するための標準の定義
AWSの料金
料金の基礎
AWSの料金は以下のような特性があります。
従量課金制（使用した分だけお金がかかる）
予測ではなく、ニーズによってお金がかかることで、ビジネスの拡大縮小を自在におこなえるようにしている。
予約による値引き
EC2やRDSのような特定のサービスについてはリザーブドキャパシティー料金が適用されます。
EC2を例にしてみると、リザーブドインスタンスには全額前払い、一部前払い、前払いなしのプランがあり、最大で75%にまで価格が変動します。
基本的には予測ではなくニーズによって料金がかかりますが、完全に予想が立つような分野ではこのような方法でコスト削減を行える可能性があります。
使用量が増加するほど、1単位当たりに値引きがかかる
AmazonS3やEC2は、ボリュームディスカウントの精度があります。
つまり、たくさん使えば使うほど安くなります。
AWSの拡大にあわせて値引きがかかる
AWS自体の事業拡大や技術革新によっても値下げが行われます。
AWSでは2006年以降すでに44回もの値下げが行われています。
ちなみに、これをスケールメリットといいます。
AWSでは、これらの料金要件があわないユーザーのために、大規模プロジェクト向けカスタム料金を設定することもできます。
また、AWSは新規のユーザーが参入しやすいように1年間の無料枠も用意しています。
さらに、AWS上のサービスには常に無料のサービスもいくつかあります。
VPC, Elastic Beanstalk, CloudFormation, IAM, Autoscaling, OpsWorksなどのサービスがそれにあたります。
メジャーサービスにかかるコスト
AWSの支払い要素には以下のようなものがあります。
- データ転送
- コンピューティング
- ストレージ
ここですこし、データ転送について詳しく説明します。
データ転送にかかるコスト
データ転送に料金は発生しますが、着信データ転送及び同一リージョン内での他サービスとの間のデータ転送については料金が発生しません。
EC2,S3,RDS,SimpleDB,SQS,SNS,VPCにおける発信データは集約され、発信データ転送レートで課金されます。
明細書ではAWS Data Transfer Outという項目になります。
次に、サービスごとの特徴を見ていきます。
EC2
EC2ではサーバーの起動時間を元に料金が発生します。
インスタンスを作成したから終了するまでですね。
また、インスタンスのマシン構成を良くしようとしたら、1単位当たりの料金は高くなります。
前述しましたが、EC2にはリザーブドインスタンスの制度があるため、購入プランによって割引はあります。
また、インスタンスの数を増やして負荷分散をするというのは一般的な運用ですが、AutoScalingでインスタンスの数を増やすという行為には料金は発生しませんが、当然増やしたインスタンスの分だけ使用料はかかるようになります。
また、増やしたインスタンスに対して着信を割り振るELBの実行時間や通信料も料金が発生します。
EC2インスタンスはcloudwatchを使って使用状況を監視できますが、これも基本モニタリングだけなら料金はかかりませんが、詳細モニタリングの機能を使用すると料金が発生します。
EC2ではIPを静的に管理したいことがあるため、ElasticIPを使用する場合があります。
これも基本的に料金はかかりませんが、アタッチしたインスタンスが動いていない場合無駄に静的アドレスを確保していることになるので、料金が発生するようになっています。
S3
S3はまずストレージのクラスによって料金が変わります。
標準では99.999999999%の耐久性(イレブンナイン）と99.99%の可用性（フォーナイン）を保証しますが、助長性を少し下げるSIA(標準ー低頻度アクセス）オプションをつけることでやすくなります。
ちなみにこちらはイレブンナインとスリーナインになります。
0.01%の可用性の差にこだわらないなら安いほうでいいですね。
また、S3に対してはPUT COPY POST LIST GETなどのリクエストでお金がかかります。
IOPSは考慮されません。（ファイルの大きさではなくリクエストでお金ががかる）
EBS
こちらはボリュームタイプで料金が変わります。
汎用（ＳＳＤ）、プロビジョンドＩＯＰＳ（ＳＳＤ）、マグネティックの3種類があります。
まず、料金はストレージをプロビジョンした量（何ＧＢのストレージを用意するか）で毎月お金がかかります。
また、通信にもお金がかかります。
汎用なら入出力、マグネティックはリクエストの数、プロビジョンドIOPSはIOPSをプロビジョンした量もお金がかかります。
プロビジョンドIOPSはデータの出し入れ速度をAWSに保証してもらう機能です。
また、EBSではスナップショット（バックアップ）をS3に保存する機能があるので、それもＧＢあたりでお金がかかります。
また、こちらも着信は無料ですが発信データ転送はお金がかかります。
RDS
EC2と同じようにＤＢインスタンスを立ててから終了するまでの稼働時間でお金がかかります。
RDSは複数の種類のデータベースを管理しているので、どれを使うかによっても価格が上下します。
RDSにもオンデマンドだけでなくリザーブドを行うサービスがあり、こちらは1年もしくは3年の期間でＤＢインスタンス料金を前払いすると全体的に見て安い金額でRDSを使えるようになります。
また、RDSは負荷があがったときに備えて複数のデータベースをプロビジョンできますが、こちらはアクティブである限り、メインで使用しているデータベースストレージが100%を超えるまでは料金は発生しません。
DBインスタンスが終了していると、バックアップストレージに対して料金がかかります。
また、アベイラビリティゾーンをまたいで複数のＤＢを管理しようとすると料金がかかります。
Cloud Front
データをエッジロケーションを通じて低レイテンシーかつ高速に送信するサービスで、料金はリクエストの数によって決まりますが、リージョンによって料金は変わります。
TCO計算ツール
オンプレ環境で運用をしているが、AWSに乗り換えたらどうなるかなということをサーバーの数などを入力することで計算できます。
AWS Total Cost of Ownership 総所有コスト計算ツールは以下から起動できます。
https://awstcocalculator.com
これは以下のことに使用します。
- AWSを使用してコスト削減を見積もる。
- 役員へのプレゼンテーションで使用できるレポートの詳細に使う
- ニーズに最も適合するように前提条件を変更する。
これを使用することによって、AWSを使うことでどれだけコストダウンできるかなどの試算をすることができます。
AWS サポートプランの概要
AWSサポートは、すでにAWSを使用しているしていないにかかわらず、すべてのお客様をサポートします。
積極的なアドバイスが必要な場合
テクニカルアカウントマネージャを用意します。
TAMはアドバイス、アーキテクチャレビュー、および継続的な意思疎通によって
ユーザーに常に情報を提供します。
TAMはユーザー専任の担当者です。
既にAWSを使用しており、ベストプラクティスを実践しようと考えている場合
AWS Trusted Advisorを使用します。
アカウントの支援が必要な場合
課金・アカウント管理のエキスパートであるサポートコンシェルジュを用意します。
コンシェルジュは技術的なこと以外のすべての課金・アカウントレベルの質問に対応できます。
サポートプランのオプション
ベーシックは無料で、下に行くほどレベルの高いサービスが提供されます。
ビジネスサポートまでは、ソリューションアーキテクトによる優れた設計レビューを受けることができません。
ベーシックサポートプラン
AWS Trusted Advisor4項目
技術サポートケースを作成できるユーザー０
フォーラム
料金Ｑ＆Ａ
開発者サポートプラン
AWS Trusted Advisor4項目
技術サポートケースを作成できるユーザー１
フォーラム
料金Ｑ＆Ａ
技術Ｑ＆Ａ(回答まで最短12時間で電話は不可 メールでの対応で、平日9-18時までの対応)
ビジネスサポートプラン
AWS Trusted Advisor全項目
技術サポートケースを作成できるユーザー無制限
フォーラム
料金Ｑ＆Ａ
技術Ｑ＆Ａ(最短60分で対応し、24時間365日対応 電話もメールもＯＫ)
エンタープライズサポートプラン
AWS Trusted Advisor全項目
技術サポートケースを作成できるユーザー無制限
フォーラム
料金Ｑ＆Ａ（コンシェルジュ）
技術Ｑ＆Ａ(最短15分で対応し、24時間365日対応 電話もメールもＯＫ)
最優先対応
TAMがつく
おわりに
はい、疲れました。
大体これくらいの内容を把握していればクラウドプラクティショナーに合格できます。
多くのサービスはやはりインフラとして必要な要素を実現しているものにすぎないので、そういった知識があればすんなりとサービスを理解できると思います。
ただ、運用経験が無かったりインフラ初心者であれば、単語の意味を理解するだけでも手間取り、なかなかAWSについて理解することも難しいと思います。
そんな方に、この記事が少しでも誰かの役に立てば幸いです。
そのうちソリューションアーキテクト（アソシエイト）を取得したら、これらを前提としたうえでさらに必要な知識が何なのかをお伝えする記事を作らせてもらおうかと思っています。（たぶん6月以降...）
正直これをおさらいするだけでも吐きそうなのですが、頑張ります。
以上、お疲れ様でした。