AWSの主要なサービス概要

# はじめに
追記:850点ほどでAWS認定クラウドプラクティショナー合格することができました。

AWSクラウドプラクティショナーの認定試験を受験するにあたり学んだサービスの概要をまとめました。
内容の構成に関しましては[AWS認定資格試験テキスト　AWS認定 クラウドプラクティショナー](https://www.sbcr.jp/product/4797397406/)を参考にさせていただきました。
AWSの基礎を学べる良書と感じました。

# AWS主要なサービス概要
## AWSクラウドの概念
### クラウドとは
インターネット経由でコンピューティング、データベース、ストレージ、アプリケーションをはじめとした様々なITリソースをオンデマンドで利用することのできるサービスの総称。

`オンデマンド:従量課金のことで、実際に使った分の支払いをすること`
[クラウド (クラウドサービス) とは？](https://aws.amazon.com/jp/cloud/)
### クラウドの6つメリット

#### 固定の償却コストが変動コストに
自前でデータセンターやサーバーを持つ場合(オンプレミス)には実物の購入や建物や冷却装置などの多額の投資を固定の償却コストとして扱う必要があったが、クラウドサービスを利用することで必要な時に必要な分だけ利用して支払う変動コストにすることができる。当然実物の購入費や施設の維持費も必要なくなる。

`オンプレミス:サーバーなどを使用者が自前の施設などで管理する運用方式。略称は「オンプレ」`
#### スケールによる大きなコストメリット
数十万規模のユーザーがクラウドサービスを使用するため、規模の経済が働きオンプレよりも低い変動コストを実現することができる。

`規模の経済:多くの企業が同じサービスを利用することで1企業あたりの支払うコストが低くなること`
`IntelがAWSに特化したIntel Xeon プロセッサを提供するくらい大規模なクラウドサービスである`
#### キャパシティ予測が不要に
オンプレでは必要なキャパシティを事前に計算し用意しておく必要があったが、クラウドではリソースの増減を行うことができるので予測する必要がなくなった。
自前でサーバーを確保しておくことは多額のコストがかかり、使用していない時にもコストが発生するがクラウドでは必要な時にのみ使用することができるのでコストも抑えることができる。

#### 速度と迅速性の向上
クラウドではITリソースを必要な時に簡単に利用することができる。従来のオンプレミスではサーバーの用意に数週間の時間を要していたためクラウドを利用することで迅速に必要なものを揃えることができ、組織としての俊敏性が向上する。
アジリティと表現することもある。

#### データセンターの運用保守投資が不要
オンプレではデータセンターを管理することに人員や、サーバーの設置・保守運用といった業務が発生していたがクラウドを利用することでそれらの業務をする必要がなくなるため企業はサービスの開発に専念することができる。

#### わずか数分で世界中にデプロイ
わずか数回クリックするだけで世界中にデプロイすることができる。
`デプロイ:サービスをインターネットを通じてアクセスできるように世界に展開すること`

[クラウドサービスの導入で得られる 6 つのメリット](https://aws.amazon.com/jp/cloud/)
### クラウドのデメリット
オンプレと比較すると自社でサーバーを扱うことができないためカスタマイズ性が落ちることがあげられる。
また、クラウドにアクセスするにはオンライン環境が必須である。
[クラウドサーバ導入における2つのデメリット](https://www.gate02.ne.jp/column/11/#:~:text=%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89%E3%82%B5%E3%83%BC%E3%83%90%E3%81%AE%E3%83%87%E3%83%A1%E3%83%AA%E3%83%83%E3%83%881,%E5%BF%85%E9%A0%88%E3%81%A7%E3%81%82%E3%82%8B%E3%81%93%E3%81%A8%E3%81%A7%E3%81%99%E3%80%82)
### Well-Architectedフレームワーク
[AWS Well-Architectedホワイトペーパー](https://aws.amazon.com/jp/architecture/well-architected/?wa-lens-whitepapers.sort-by=item.additionalFields.sortDate&wa-lens-whitepapers.sort-order=desc)
クラウドアーキテクトがアプリやワークロード向けに高い安全性、性能、障害耐性、効率化を備えたインフラを構築する際に役立つ。
いくつかの基本的な質問に答えると、自分のアーキテクチャがクラウドのベストプラクティスがどの程度実践できているかを知り、改善するためのガイダンスを得ることができる。
#### Well-Architectedの5つの柱
##### 運用上の優秀性
変更の自動化、イベントの対応、日常業務を管理するための標準化が含まれる。
##### セキュリティの柱
データの機密性と整合性、権限管理における権限の特定と管理、システムの保護、セキュリティイベントを検出する制御の確立などが含まれる。
##### 信頼性の柱
障害から迅速に回復してユーザーの要求に応える。
分散システムの設計、復旧計画、変更の処理方法が含まれる。
##### パフォーマンス効率の柱
ワークロードの要件に応じた適切なリソースタイプやサイズの選択、パフォーマンスのモニタリング、ビジネス要件の増大に応じて効率を維持するための情報に基づいた意思決定が含まれる。
##### コスト最適化の柱
費用が発生する箇所の把握と管理、最適で正しい数のリソースタイプの選択、時間経過に伴う支出の分析、過剰な出費を抑えながらのビジネスニーズに対応したスケーリングなどが含まれる。
#### Well-Architected Tool
#### 概要
ワークロードの状態をレビューして、ベストプラクティスと比較することができる。
WAフレームワークをベースとしており、クラウドアーキテクトがアプリ向けに実装可能な安全で高いパフォーマンス、障害耐性を備えた、効率的なインフラ構築をサポートする目的で開発された。
利用するには、マネジメントコンソールでワークロードを定義し、5つの柱に沿った質問に解答するだけ。その後AW Toolから実績のあるベストプラクティスを使ったクラウド向けアーキテクチャの設計方法に関する計画が提示される。
#### 料金
無料
### クラウドの種類
[SaaS、Paas、IaaSとは](cloud-ace.jp/column/detail01/)
[VDI（デスクトップ仮想化）とDaaSの違いとは
](https://cloud.nissho-ele.co.jp/vdiblog/vdi_daas/#:~:text=DaaS%EF%BC%88%E3%83%80%E3%83%BC%E3%82%B9%EF%BC%89%E3%81%A8%E3%81%AF%E2%80%9D,%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E4%B8%80%E7%A8%AE%E3%81%A7%E3%81%99%E3%80%82)
#### IaaS
`Infrastructure as a Service`の略
インフラをインターネット上のサービスとして提供する形態のこと。
Google Compute CloudやAmazon EC2が代表的なサービス。
#### PaaS
`Platform as a Service`の略
ハードウェアやOSなどのプラットフォーム一式をインターネット上のサービスとして提供する形態のこと。
Google App EngineやMicrosoft Azureなどが代表的なサービス。
#### SaaS
`Software as a Service`の略
これまではパッケージ商品として販売していたソフトウェアをインターネット経由で提供・利用する形態のこと。
Salesforceなどが代表的なサービス。
#### DaaS
`Desktop as a Service`の略
クラウド上にあるデスクトップをインターネットを経由して提供・利用する形態のこと。
クライアント側の端末では画面の共有とマウスとキーの入力操作を行うだけなので、マシンの性能が低くても様々なサービスを利用できることからリモートワークに導入するために注目されている。
### クラウドのデプロイモデル
#### クラウド
完全にアプリケーションがクラウド上にデプロイされていて、アプリの全体がクラウド上で実行される。
#### ハイブリッド
クラウドベースのリソースと、クラウド上にはない既存のリソースとの間でインフラを接続する方法。
(クラウド＋オンプレミスでの運用など)
#### オンプレミス
リソースをオンプレミスでデプロイする方法。
## AWSのセキュリティ
### 責任共有モデル
AWSはセキュリティを最優先事項と言い切っている。しかし、ユーザーの使い方次第ではセキュリティを維持することはできない。そのためAWSとユーザーでセキュリティを担う責任を共有する責任共有モデルを実施している。
これはAWSとユーザーで明確にセキュリティ維持の責任範囲を分けることで成り立っている。
初期段階ではAWSはクラウドの本体に責任を持ち、ユーザーはクラウドの中身に責任を持つ。しかし、AWSの提供するマネージドなサービスを利用することで、利用した部分はユーザーからAWSの責任範囲に移管される。
#### AWSの責任範囲
ハードウェアやリージョン、アベイラビリティゾーン、エッジロケーションなどの物理的なものや、各種ソフトウェアの管理(アップデートやパッチなど)がAWSの担当。
仮想化を実現するハイパーバイザーもAWSの責任範囲。
#### ユーザーの責任範囲
ゲストオペレーティングシステムの管理(アップデートやパッチのインストール)、関連するアプリケーションソフトウェアの管理やAWSより提供されるセキュリティグループファイアーウォールの設定などがあげられる。
AWSからセキュリティ対策のサービスが複数提供されているので活用していくことが望ましい。
各管理プレーンはユーザーの担当
### クラウドのセキュリティ
#### データの保護
ユーザーのプライバシー保護のため強力な安全策が用意されている。
全てのデータは安全性が非常に高いデータセンターに保存される。
#### コンプライアンスの要件に準拠
インフラストラクチャの中で数多くのコンプライアンスプログラムを管理できる。
コンプライアンスの準拠に必要な要件は初めから達成されている。
例えば、自国のリージョンを使用することでデータの国内保持のコンプライアンスを達成することができる。
#### コスト削減
ユーザーは独自のデータセンターなどを管理する費用を支払う必要もなく、AWSでは非常に高いレベルのセキュリティ対策を行ってくてるため、セキュリティにかける費用も抑えられる。
#### 迅速なスケーリング
AWSクラウドの使用量に合わせてセキュリティをスケーリングできる。ビジネスの規模にかかわらずAWSインフラによってユーザーのデータが保護される。
### MFA
多要素認証のことであり、通常のIDとパスワードの入力に加えて認証に必要な要素を追加することでセキュリティを強化することが目的。
例として、ワンタイムパスワードの追加入力や秘密の質問なあどと行った様々なものがある。
AWSはマネジメントコンソールへのログインに対してMFAの追加を強く推奨している。
### セキュリティのベストプラクティス
ユーザーが責任を担う部分のベストプラクティスとして4つの項目がある。
#### 転送中のデータの保護
パスワードなどが暗号化されることなく送信されてしまわないように適切な通信プロトコルを使用すること。
脆弱性のある暗号化プロトコルの使用も避ける。
#### 蓄積データの保護
蓄積データの物理的な保護はAWSが行ってくれるが、運用の中でデータを出力する際にデータへのアクセス権限のない者がアクセスできてしまうことがある。その際に個人情報などを見られてしまわないようにデータの暗号化を行うことが望ましい。AWSではストレージやデータベースの暗号化オプションが存在するのでこれらを使用することも検討する。
#### AWS資格情報の保護
ルートアカウントを使用すると全ての権限が使用できてしまうので、ユーザーごとにIAMユーザーを作成して必要最低限の権限を与えて運用する。
#### アプリケーションの安全性の確保
クロスサイトスクリプティングやSQLインジェクションなどの攻撃に対する対策をしておく。
日頃から脆弱性に対する情報収集を行うことや、Amazon Inspectorを使用した脆弱性診断を行うことが望ましい。
### IAM
AWS Identity and Access Managementの略。
ユーザーのAWSクラウドリソースへのアクセス管理サービス。
ユーザーのグループ作成、管理やアクセス権を使用してリソースへのアクセス許可、拒否の設定を行える。
AWSサインアップ時に作成したアカウントはルートアカウントと呼ばれ、全ての権限を持っているため日常的に使用しないようにする。
そこで、IAMユーザーやIAMグループを作成することができる。
追加設定として日時の制限やアクセス元のIPアドレス、SSLを使用しているかどうか、MFA認証が行われているかなどの条件を追加することができる。
料金
#### IAMグループ
IAMユーザーをグループでまとめることができる。
開発グループや運用グループなどでくくることで管理がしやすくなる。
作成された段階では何も権限がない状態になっている。
グループにユーザーを追加することで自動でそのユーザーにもグループと同じ権限が適用される。
複数のユーザーの権限管理を行えるので権限管理を行いやすい。
1000人以上いるような会社の各部門などで権限管理を行う際に重宝する。
グループをユニットと表現することもある。
#### IAMユーザー
IAMユーザー毎にAWSの各種リソースに対するアクセス権を設定でき、IAMユーザーに対してAPIキーも作成できる。
作成された時には権限が何も与えられていない状態になっている。権限を追加する際には必要最低限の権限のみを付与する。
権限の許可と拒否が相反する際には拒否が優先される。
APIキーは1人のユーザーに2つまで発行できる。これはキーの入れ替えを行う際に2つないと一時的にAPIキーがない状態が生まれてしまうのを避けるため。
#### IAMポリシー
AWSリソースヘのアクセス管理に利用するもの。
IAMアイデンティティまたはAWSリソースにアタッチする。
オペレーションの実行方法を問わずにアクションのアクセス許可を定義するもの。ポリシーが適用されたユーザーはそのリソーへのアクセスが可能となる。
料金は無料。
[AWS IAM](https://aws.amazon.com/jp/iam/)
IAMユーザーを作成したらポリシーを設定することでアクセス管理を行える。
##### AWS管理ポリシー
AWSが用意している再利用可能なポリシー。複数のIAMユーザー、IAMグループ、IAMロール間で共有可能。
##### カスタマー管理ポリシー
ユーザーが作成した再利用可能なポリシー。複数のIAMユーザー、IAMグループ、IAMロール間で共有可能。
##### インラインポリシー
各IAMユーザー(IAMグループやIAMロール)専用にユーザーが個別作成するポリシー。
[IAM ポリシー](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies.html)
#### IAMロール
IAMロールを使用すると通常はリソースにアクセスしないユーザーやサービスへのアクセスを委任することができる。
一時的にセキュリティの認証を得ることができるロールを担うことができる。
[IAMロール](https://aws.amazon.com/jp/iam/features/manage-roles/)
### AWS Organizations
アカウントの作成を自動化できたり、アカウント単体毎ではなくまとめて請求を行うことができる。
まとめて請求することでS3の容量計算が変わったりと料金が節約できる場合がある。
### セキュリティグループ
1つ以上のインスタンスのトラフィックを制御する仮想ファイアウォール。
今までは中央集権的なファイアウォールを1つだけ外部ネットワークの前に置いていた、それぞれのノードの前に設置することがベストであったがコストの面と、サーバーを置くラックのスペース制限もありできなかった。しかし、クラウドでは各インスタンス毎に個別のファイアウォール設定を行えるセキュリティグループを用いることで実現できる。
セキュリティグループはその名前の通り、グループとして同目的のサーバー群に同じ設定を適用することもできる。
行える設定としては以下がある。
・許可ルールの指定が可能
・拒否ルールの指定は不可能
・インバウンドトラフィックとアウトバンドトラフィックのルールを個別に指定可能

デフォルトの仕様
・セキュリティグループを新規作成する際にはインバウンドルールはない。
・ルールを追加するまで別のホストからインスタンスに送信されるインバウンドトラフィックは許可されない。
・デフォルトでは全てのアウトバンドトラフィックを許可するアウトバンドルールがある。
・セキュリティグループはステートフル。
・インスタンスからリクエストを送信する場合にはそのリクエストのレスポンストラフィックはインバウンドセキュリティグループルールに関わらず許可される。
### パワーユーザー
IAMユーザーの管理以外の全ての権限が有効になっているユーザーのこと。
### ルートアカウント
AWSのアカウント作成時のアカウントをルートアカウントという。
ルートアカウントは全ての操作をすることができる権限の最も強いアカウントである。
業務での操作ではルートアカウントは使用せずに適切な権限のみを与えた別のユーザーを作成して利用する。
ユーザーは1アカウントの中で複数作成することができる。
### 組織単位
組織単位のことをOUと呼ぶ
Organization User
### サービスコントロールポリシー(SCP)
組織を管理するために使用できるポリシータイプのこと。
組織内の全てのアカウントの最大限使用できる権限を提供し、アカウントの組織のアクセスコントロールガイドラインに沿って活動することを確実にすることができる。
組織が一括請求のみを有効にしている時にはSCPは使用できない。
### インラインポリシー
ユーザーが自身で作成と管理をすることができるポリシー。
プリンシパルエンティティにアタッチすることができる。
`プリンシパルエンティティ: (ユーザーまたはロール) を使用してリクエストを送信するユーザーまたはアプリケーション。 プリンシパルに関する情報には、プリンシパルがサインインに使用したエンティティに関連付けられたポリシーが含まれます。`
[プリンシパルエンティティ](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/intro-structure.html)
### カスタマー管理ポリシー
AWSアカウントで作成、管理できる。管理者権限を有しているユーザーまたはAWS側によって作成されて複数のIAMエンティティにアタッチすることができるポリシータイプ。
### 鍵の種類
#### IDとパスワード
マネジメントコンソールへのログインに使用される。
これらの管理はユーザーの責任。
MFAを使用することでセキュリティを強化できる。
#### キーペア
EC2などのログインに使用するもの。キーペアは公開認証方式という認証方式である。
公開鍵と秘密鍵のペアで構成されており、サーバーやEC2インスタンスに公開鍵を設定しておき、アクセスするユーザーの秘密鍵と一致するかで認証する。
秘密鍵の管理はユーザーの責任で、紛失した際には鍵のリセットを行うことはできない。
利用者毎に秘密鍵を生成することが望ましく、誰がアクセスしたかの特定も容易になる。
利用者毎にキーペアを生成して公開鍵をサーバーに設定する。
公開鍵はパブリックキー、秘密鍵はプライベートキー(PEMキー)と呼ぶこともある。
パブリック暗号はパブリックキーを使用してデータを暗号化し、受信者はプライベートキーを使用してデータを複合すること。
`複合化:暗号化されたデータを元に戻すこと`
#### APIキー
CLIやSDK、プログラム上で使用する際にはAPIキーを利用する。
APIキーはアクセスキーとシークレットアクセスキーのペアで構成される。
### AWS Shield
マネージド型の分散サービス妨害のDDoS攻撃の保護サービス。
DoS攻撃はトラフィックを増大させて、サーバーに負荷をかけることでサービスの利用を困難にさせたりダウンさせたりすることを目的とした攻撃のことである。それを複数のコンピューターをのっとりターゲットに対して一斉に行う攻撃をDDoS攻撃という。
AWS Shieldはアプリのダウンタイムとレイテンシーを最小限に抑える常時稼働の検出と自動インライン緩和策を提供している。
StandardとAdvancedの二つの種類がある。
[AWS Shield](https://aws.amazon.com/jp/shield/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc)
#### Standard
無料
一般的なDDoS攻撃から保護してくれる。
Amazon Cloud FrontやAmazon Route53と一緒に使用するとインフラを標的とした既知の攻撃から総合的に保護してくれる。
#### Advanced
有料
攻撃の通知や分析、レポートの作成をDDoS Response Teamにアウトソーシングすることができる。
Advancedを利用するとAWS WAFサービスが無料かつ無制限に利用することができる。
### AWS WAF
WAFはWeb Application Firewallの略。
アプリの可用性の低下、セキュリティの侵害、リソースの過剰消費などの一般的なWebの脆弱性からアプリを保護するマネージド型のWebアプリケーションファイアーウォール。
SQLインジェクションやクロスサイトスクリプティング、定義した特定のトラフィックパターンを除外するWebセキュリティルールの作成などを行える。
料金は利用した分にだけ課金される。基本料金は無料。初期費用はなし。
しかし定義は最初から設定されているわけではないので、自分で設定する必要がある。サードパーティの提供するWebセキュリティルールを設定することも可能。
この料金は以下の3つできまる。
・Webアクセスコントロールリスト(Web ACL)数に基づく課金方式
・Web ACLごとに追加するルール数に基づく課金方式
・受け取るWebリクエスト数に基づく課金方式
AWS WAFはAmazon CloudFrontにデプロイでき、EC2上で動作するウェブサーバーやオリジンサーバーの手前に配置したApplication Load BalancerやAPIを使用するためのAmazon API GateWayに適用できる。
[AWS WAF](https://aws.amazon.com/jp/waf/)
### Inspector
自動化されたセキュリティ評価サービスで、AWSにデプロイしたアプリのセキュリティとコンプライアンスを向上させることができる。
自動的にアプリを評価して、露出、脆弱性、ベストプラクティスからの逸脱がないかを確認できる。
評価のあとは重大性の順に結果を表示した詳細なリストが作成され、確認することができる。
評価はルールパッケージに沿って行われる。
料金使用した分にだけ支払う。料金は2つの基準があり、EC2インスタンスの数と、選択したルールパッケージのタイプによって料金が変わる。
Inspectorで診断が行えるものは以下。
・一般的な脆弱性や漏洩
・ネットワークセキュリティにおけるベストプラクティス
・認証におけるベストプラクティス
・OSのセキュリティにおけるベストプラクティス
・アプリケーションセキュリティにおけるベストプラクティス
・OCI DSS3.0アセスメント(クレジットカード会社の情報セキュリティ基準)
[Amazon Inspector](https://aws.amazon.com/jp/inspector/)
### AWS Artifact
AWSのコンプライアンスレポートにアクセスできるセルフサービスポータル。
AWSの監査人が作成したレポート、認証、認定、その他のサードパーティによる認定にオンデマンドでアクセスできる。
AWSとの契約を確認、承認、管理できる。組織内の全てのアカウントにAWSの契約を適用できる。
AWSのセキュリティ管理環境の高い透明性を保つ。セキュリティとコンプライアンスを継続的にモニタリングして新しいレポートをすぐに確認できる。
料金は無料。
Service Organization Control(SOC)、Payment Card Industry(PCI)のレポートなどが取得可能。
[AWS Artifact](https://aws.amazon.com/jp/artifact/)
### ネットワークACL
ネットワークアクセスコントロールリスト(ネットワークACL)は1つ以上のサブネットのインバウンドトラフィック(受信)とアウトバンドトラフィック(送信)を制御するファイアウォールとして動作するVPC用のセキュリティオプションレイヤー。
セキュリティの追加レイヤーをVPCに追加するにはsキュリティグループと同様のルールを指定したネットワークACLをセットアップできる。
セキュリティグループと似ているので注意。
[ネットワークACL](https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-network-acls.html)
### AWS Key Management Service (AWS KMS)
このサービスを使用すると暗号化キーを簡単に作成して管理し、幅広いAWSノサービスやアプリでの使用を制御できるようになる
セキュアで弾力性の高いサービスで、キーを保護するために検証済み、または検証段階のハードウェアセキュリティモジュールを使用する。
AWS CloudTrailと統合されており、全てのキーの使用ログを表示できるので規制及び、コンプライアンスの要求に応えることができる。
フルマネージド型である。(キーの使用権限などはユーザーだが、権限の実行、耐久性、物理的な部分はAWS)
マネジメントコンソール、またはSDK、CLIからキーの権限を簡単に作成、インポート、ローテーション、削除、管理できる。
料金は無料枠がありつつ、キーストレージやキーの使用量によって課金される。
[AWS KMS](https://aws.amazon.com/jp/kms/)
### AWS CloudHSM
クラウドベースのハードウェアセキュリティモジュール(HSM)。これによりクラウドで暗号化キーを簡単に生成して使用できるようになる。
FIPS 140-02レベル3認証ずみのHSMを使用して暗号化キーを管理できる。業界標準のAPIを使用してアプリケーションを柔軟に統合できる。
CloudHSMはハードウェアのプロビジョニング、ソフトウェアへのパッチ適用、効果養成、バックアップといった時間のかかる管理タスクを自動化する完全マネージメント型のサービスである。オンデマンドでキャパシティを追加及び削除することで簡単にスケールできる。前払いの必要はない。
料金はHSMを起動してから終了するまで各HSMごとに1時間単位で課金される。
[AWS CloudHSM](https://aws.amazon.com/jp/cloudhsm/)
### Amazon Guard Duty
悪意のある操作や、不正な操作を継続的にモニタリングすることで脅威を検知するサービスである。AWSのアカウントとワークロードを保護する。
VPCフローログmCloud Trailイベントログ、DNSログ、悪意のあるIPやドメインのリストを用いることで悪意を検知する。
AWS Organizationを使用して複数のアカウントにサポートを提供するので全てのアカウントにGuardDutyを適用させることができる。
料金は分析されたAWS CloudTrailのイベントの数、分析されたAmazonVPCフローログとDNSログデータの量に基づいている。
GuarDuty分析のためにこれらのログソースを有効化することへの追加料金はない。
[Amazon GuardDuty](https://aws.amazon.com/jp/guardduty/)
### Access Advisor
IAMエンティティが最後にAWSサービスにアクセスした日付と時間を表示する機能のこと。
AWS CLIまたはSDKでIAMアクセスアドバイザーAPIを使用することで全アカウントのIAMアクセス権限の分析を自動化することができる。
IAMのアクセス管理などを支援することができる。
## AWSのテクノロジー
### リージョン
現在は24のリージョンと1つのローカルリージョンがある。
リージョン内には2つ以上のアベイラビリティゾーンがある。
日本にいても東京リージョンしか選択できないわけではなく他のリージョンも選択できる。
複数のリージョンに完全に稼働する同じシステムを構築して災害時のダウンタイムを最小にするマルチサイトアクティブ-アクティブという構成も検討できる。
リージョンによってコストや使用されるサービスが異なることがある。
どのリージョンを選択するかには以下がある。
・保存するデータやシステムがそのリージョン地域の法律やシステムを所有している企業のガバナンス要件を満たしているか
・ユーザーや連携するデータに近いか
・必要なサービスが揃っているか
・コスト効率が良いか
マルチリージョンで展開することで99.99%以上の可用性を実現できる。
マルチAZでは1リージョンを丸ごと巻き込む災害があった際には99.99%以上の可用性は維持できない。ほぼ止まらないシステムを構築できるがその分コストがかかってしまう。
### アベイラビリティゾーン(AZ)
1リージョンには必ず2つ以上のAZがある。
複数のデータセンターから構成されている。
各AZは停電や災害が発生した際に同時に被害に合わない場所に構成されている。
事前に障害が発生することを見越した設計となっており、これは`Design for Failure(障害に備えた設計)`と呼ばれている。
これらの設計がされていることから、AWSでは可用性、対障害性を持った運用を行うことができる。
同一リージョン内のAZは高速なプライベート光ファイバーネットワークにより数ミリ秒の低レイテンシー接続を実現している。
99%以上可用性を維持することはできない。
マルチAZでは1リージョンを丸ごと巻き込む災害があった際には99.99%以上の可用性は維持できない。
### エッジロケーション
全世界に200箇所以上存在する。
リージョンのない国にも設置されている。
エッジロケーションの用途としては以下2つ
・低レイテンシーなDNSクエリの実現
・コンテンツの低レイテンシー配信
Amazon Route53というDNSサービスがエッジロケーションで使用されており、低レイテンシーでDNSクエリを返すことができる。
CDNサービスであるAWS CloudFrontもエッジロケーションで使用されており低レイテンシーでコンテンツキャッシュを配信することができる。
Route53とCloudFrontはDDoS攻撃から保護するAWS Shield Standardの対象なのでエッジロケーションでサービスへの攻撃から保護することができる。
#### その他
ユーザーからさらに近い位置にあるAWS LocalZone。
アプリに10ミリ秒未満のレイテンシーを実現するAWS Wavelength。
オンプレミスの施設でAWSを利用するAWS Outpostsのような色んなサービスがある。
エッジロケーションを使用することでユーザーに最も近い場所から低レイテンシーでサービスを提供することが可能となる。
## コンピューティングサービス
●
## ネットワークサービス
●
API Gateway
## ストレージサービス
### Amazon Elastic Block Store(EBS)
EC2インスタンスにアタッチして使用するブロックストレージボリューム。
以下の特徴がある。
・EC2のインスタンスのボリュームとして使用
・AZ内でレプリケートされる
・ボリュームタイプの変更が可能
・容量の変更が可能
・高い耐久性のスナップショット
・ボリュームの暗号化
・永続的ストレージ
別のリージョンにあるEBSからスナップショットを作成した場合にはそのリージョン内にスナップショットが作成される。
自動スナップショットをバックアップとして取得することが出来るが、初期状態では設定されていないので設定する必要がある。
#### EC2インスタンスの追加ボリュームとして使用
EC2インスタンスのルートボリューム(ブートボリューム)または追加ボリュームとして使用する。
不要になればいつでも削除できる。
#### AZ内でレプリケート
EBSは同じAZ内の複数サーバー間で自動的にレプリケートされる。
ハードウェアの障害が発生してもデータが失われることはない。
#### ボリュームタイプの変更が可能
標準のSSD、プロビジョンドIOPS SSD、スループット最適化HDD、Cold HDDというボリュームタイプがある。
標準SSD（汎用SSD）の性能は最大でも16,000IOPSで、かつ一定の性能を約束するものではない、これを超える際にはプロビジョンドIOPSを検討する。
プロビジョンドIOPSは最小のIOPSを指定することができる。指定できる最大値は64,000。
SSDをほとんど使用せずにコストを節約したい場合にはスループット最適化HDDを、さらにアクセス頻度が低い場合にはCold HDDを検討する
後者2つはルートボリューム(ブートボリューム)として使用することはできない。追加ボリュームとしてのみ。
ボリュームタイプは使用を開始した後でも変更できる。
`IOPS:1秒あたりにディスクが処理できるI/Oアクセスの数のこと`
#### 容量の変更が可能
確保しているストレージ量に対して課金が発生する。
容量は使用を開始した後からでも変更できる。
そのため足りなくなってきたら容量を変更することが出来る。
#### 高い耐久性のスナップショット
EBSは同じAZ内で自動的にレプリケートされているがそのAZ自体が使えなくなった際にはEBSも使用できなくなってしまう。
EBSのスナップショットを作成するとS3の機能によりスナップショットが保存される。
S3はイレブンナインの耐久性なので、このスナップショットもイレブンナインの耐久性になっている。
スナップショットは複数のAZに自動的に冗長化される。
#### ボリュームの暗号化
ボリュームを暗号化すると、作成したスナップショットも暗号化される
暗号化に関して追加の操作は必要ない。
#### 永続的ストレージ
EBSはインスタンスのホストとは異なるハードウェアで管理されている。インスタンスを一時停止して再度稼働させた際にもEBSで保存したデータは残っている。つまりインスタンスの状態に関係なく永続的にデータが残っている。
#### インスタンスストア
EBSに対してインスタンスのホストローカルのストレージを使用するのがインスタンスストア。
これはインスタンスが起動している時のみデータを保持している。
EC2を停止するとインスタンスストアのデータも消える。
インスタンスストアをルートボリュームとして起動出来るAMIもあるが、その際にはEC2は停止することができない。
インスタンス用のブロックレベルの一時ストレージを提供する。
ホストコンピュータに物理的にアタッチされたディスク上に存在する。
一時的で物理的にアタッチという点がポイント。
頻繁に変更される情報であるバッファ、キャッシュ、スクラッチデータ、その他の一時コンテンツなどのストレージに最適である。
[Amazon EC2 インスタンスストア](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/InstanceStorage.html)
### Amazon Simple Storage Service(S3)
●
#### Amazon Glacier
アクセス頻度が低いが長期保存したいデータの保存に向いている。
### Amazon Elastic File System(EFS)
複数のEC2インスタンスからマウントして供用利用できるファイルストレージサービス。
LAN上にあるNASとして利用できる共有ファイルストレージ。
パブリックなインターネットからのアクセスができないようにして完全な内部向けのストレージとしてセキュリティを強化できる。
リージョンに設置されるサービス。
リージョン、AZ、VPC間でアクセスできる。
Direct ConectあるいはAWS VPNを介して複数のEC2インスタンスやオンプレミスサーバー間でファイルを共有できる。
フルマネージド型。
従量課金で、2種類のストレージタイプがある。
[Amazon EFS](https://aws.amazon.com/jp/efs/)
### Amazon Storage Gateway
オンプレミスアプリケーションとAWSのストtレージサービスをシームレスに接続して利用できるゲートウェイサービス。
オンプレミスから実質無制限のクラウドストレージへアクセスを提供することのできるハイブリッドクラウドストレージ。
ユースケースとしてオンプレミスのデータのバックアップをAmazon S3に作成することが可能となる。
従量課金で使用するストレージタイプと容量、リクエストの回数、AWS外に転送されるデータ量に基づいて課金される。
[Amazon Storage Gateway](https://aws.amazon.com/jp/storagegateway/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc)
### Snowball
物理デバイスを使用してペタバイト級の大容量データ転送を行うことができるサービス。
オンプレミスからAWSヘデータを転送する目的で利用される。
#### Snowmobile
エクサバイト級のデータを転送する際に使用する。
## データベースサービス
### RDS
RDSはAmazon Relational Database Serviceの略。
利用できるデータベースエンジンはAmazon Aurora、MySQL、PostgreSQL、MarinaDB、Oracle、Microsoft SQL Server。
RDSを使用することでインフラ管理から解放される。
デフォルトで7日間の自動バックアップが適用される。(0~35日間で設定できる)指定した時間にバックアップデータが作成される。
35日間を超えてバックアップデータを保存しておく場合には手動のスナップショットを作成できる。
自動バックアップも手動スナップショットもRDSのスナップショットインターフェイスからアクセスできるが実態はS3の機能を利用して保存している。
RDSのバックアップスナップショットの耐久性は非常に高い。
スナップショットの復元からインスタンスを起動できる。
データベースの単一障害点とならないように設計する必要がある。
RDSのマルチAZ配置をオンにするとAZを跨いだレプリケーションが自動的に行われる。マスターに障害が発生した際のフェイルオーバーも自動で行われる。
レプリケーション用のユーザー作成、レプリケーションそのものの設定、レプリケーションのための管理を行う必要はない。
マスターとスタンバイの間でレプリケーションが実行され、マスターに障害が発生した際にはスタンバイがマスターになる。
Amazon Aurora、MySQL、PostgreSQL、MarinaDBではリードレプリカを作成することができ、リードレプリカにより読み込みの負荷をマスターデータベースから軽減できる。
他のリージョンにリードレプリカを作成することもできる。これをクロスリージョンレプリカという。
垂直スケーリングを行える。
キャパシティは自動で向上させることができない。容量はスケーリングできる。
RDSはAZに設置されるサービスである。
オートスケーリングの設定はユーザー側でする必要がある。
ライトレプリカという読み込み機能をレプリケーションする機能はRDSにはない。
`ホットスタンバイ：ホットスペアともいう。複数の同じ構成のものを用意しておいて障害発生時に本番系から待機系に切り替える方式のこと`
`コールドスタンバイ：同じ構成のものを用意しておくが、普段は停止しておき障害発生時に起動して切り替える方式のこと`
[Amazon RDS](https://aws.amazon.com/jp/rds/)
#### ポイントタイムリカバリー
自動バックアップを設定している期間内であれば数秒までを指定して特定のインスタンスを復元できる。過去直近では5分前に戻せる。
このポイントタイムリカバリーはトランザクションログが保存されていることによって可能になっている。
RDSが起動したタイミングでトランザクションログは保存され始めている。
#### Amazon Aurora
クラウドに最適化して設計されたリレーショナルデータベースエンジン。
MySQL、Postgreをそのまま移行させることが基本的には可能。
MySQLの5倍、PostgreSQLの3倍のスループットを実現する。
高速分散型リレーショナルデータベース。
マルチクラスター機能によって別AZにWriterのマスターをマルチ構成で生成できる。
リードレプリカは最大１５個まで生成できる。
リードレプリカはマルチAZ構成させることができる。
リードレプリカは手動で増加させることが出来る。
バックアップが非常に強固。
スタンバイにアクセスできる。(リードレプリカがマスター昇格する)
ディスクの容量を見込みで確保しなくても自動で増加する。
[Amazon Aurora](https://aws.amazon.com/jp/rds/aurora/)
### DynamoDB
NoSQL型の高いパフォーマンスを持ったフルマネージド型のデータベースサービスである。
データベースサーバとしてのインスタンスを作成する必要はなくテーブル作成からスタートする。
最低限の設定ではテーブル名とプライマリーキーを決めれば使い始めることが出来る。
リージョンを選択して利用する。
アイテムと呼ばれるデータを保存すると自動で複数のAZで同期されて保存される。つまり最初からマルチAZ構成になっている。
データ容量は無制限である。
課金は使用しているデータ容量のみに課金される。
性能は自分で決めることができ、書き込みと読み込みのキャパシティユニットを設定する必要がある。
ユースケースはモバイル、IoT、大規模なWebシステムのバックエンド、サーバーレスアーキテクチャ、ジョブステータスの管理、セッション管理、クリックストリームデータなど様々。
DynamoDBは水平スケーリングが可能で大量のアクセスがあってもパフォーマンスを保ったまま処理が出来る。
しかし、厳密なトランザクションが必要な処理や複雑なクエリには向かない(銀行の振り込みなど)
SQLとは異なりキーさえあっていれば自由度の高いデータを保存することが可能。
セッションデータやメタデータの蓄積、ゲームの行動記録、IoTデータの蓄積及び解析に向いている。
JOSN形式のデータの保存、処理するドキュメント型のデータベースとして利用するのも向いている。JOSN形式ドキュメントからデータを取得、操作を高速に実行することができる。
マネジメントコンソールから1クリックするか、APIコール、CLIを利用して継続的バックアップを有効化しないと自動バックアップはされない。
全てのデータはSSDに保存される。
DynamoDB Streamsを有効化することでレプリケーションプロセスを管理することなく高速で大規模にスケールされたグローバルユーザーベースのアプリケーションを構築出来る。
Tagsなどの半構造化データの処理にも向いている。
キャパシティモードは以下を選択できる。
・オンデマンドは利用負荷が予測できない場合に選択するモード
・プロビジョニング済み(デフォルト)は利用負荷が予め予測できる場合にはプロビジョンンドスループットを選択する
`SSD:Solid State Disc`
`半構造化：非構造化データにフレキシブルな構造を与えたもの(フレキシブル構造はNoSQLとも呼ばれる)`
#### Amazon DynamoDB Accelerator(DAX)
フルマネージド型の高可用性インメモリキャッシュでDynamoDBに特化している。
リクエストのレイテンシをミリ秒からマイクロ秒に短縮する機能である。
[Amazon DynamoDB](https://aws.amazon.com/jp/dynamodb/)
### Amazon Redshift
高速でシンプルなデータウェアハウスサービス。
データの分析に使用する。
大規模のなデータ分析にも対応している。
ペタバイト級の構造化データと半構造化データを標準的なSQLを使用してクエリをすることが出来る。
クエリの結果をS3データレイクに保存することもできる。そうすることでAmazon EMR、Amazon Athena、Amazon SageMakerといった他の分析サービスを使用してさらに分析をすることが出来る。
[Amazon Redshift](https://aws.amazon.com/jp/redshift/)
### Amazon ElasticCache
インメモリデータストアサービス。
RDSやDynamoDBのクエリの結果をキャッシュに使用したりアプリのセッション情報を管理する用途で使われる。
高スループットかつ低レイテンシーなインメモリデータストアからデータを取得して大量のデータを扱うアプリケーションを構築したり、既存のアプリケーションのパフォーマンスを改善したりすることが可能。
ミリ秒未満の応答時間が必要な最も要求の厳しいアプリケーション向けに、完全マネージド型のRedisとMemcachedを提供する。
[Amazon ElasticCache](https://aws.amazon.com/jp/elasticache/)
### Amazon Neptune
フルマネージドなグラフデータベースサービス。
関係性や相関情報を扱う。
SNS、レコメンデーションエンジン、経路案内、物流最適化などのアプリの機能に使用される。
[Amazon Neptune](https://aws.amazon.com/jp/neptune/)
### Amazon Kinesis
ストリーミングデータをリアルタイムで収集、処理、分析することが簡単になるサービス。
インサイトを適時に取得して新しい情報に迅速に対応することができる。
このサービスを利用すると機械学習、分析、その他のアプリに用いる動画、音声、アプリログ、ウェブサイトのクリックストリーム、IoTテレメトリデータをリアルタイムで取り込める。
データを受信するとすぐに処理及び分析を行うため、全てのデータを収集するのを待たずに処理を開始して直ちに応答することができる。
完全マネージド型。
[Amazon Kinesis](https://aws.amazon.com/jp/kinesis/)
### Amazon Athena
インタラクティブなクエリサービス。
S3内のデータを標準のSQLを使用して簡単に分析できる。
サーバーレスである。
実行したクエリに対してのみ料金が発生する。
誰でもSQLのスキルを使って大型データセットを素早く簡単に分析することが出来る。
[Amazon Athena](https://aws.amazon.com/jp/athena/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc)
### Amazon Managed Apache Cassandra Service(Amazon MCS)
スケーラブルで可用性の高い管理されたApache Cassandra互換データベースサービス。
キーと値や表示形式を含む大量の構造化データを保存、取得、管理することが出来る。
事実上の無制限のスループットとストレージで毎秒数千リクエストを処理できるアプリを構築可能になる。
サーバーレス。
従量課金。
[Amazon MCS](https://aws.amazon.com/jp/blogs/news/new-amazon-managed-apache-cassandra-service-mcs/)
### AWS Database Migration Service(AWS DMS)
データベースを短期間で安全にAWSに移行することが出来る。
移行中もデータベースは完全に使用できる状態に保たれているのでダウンタイムを最小限に保つことが出来る。
一般的に広く普及しているほとんどの商用データベース、オープンソース出たベースとの移行で使用できる。
異なるデータベース間でも移行することができる。(OracleからMySQLなど)
このサービスを使用するとデータの高可用性を維持しつつ継続的にレプリケートし、Amazon Redshift、Amazon S3にデータをストリーミングすることでペタバイト級のデータウェアハウスに統合できる。
移行先のスキーマ作成もSCT(Schema Conversion Tool)で自動作成できる。
Amazon Aurora、Amazon Redshift、Amazon DynamoDM、Amazon DocumentDBに移行する場合はDMSを6ヶ月間無料で利用できる。
[AWS DMS](https://aws.amazon.com/jp/dms/)
## 管理サービス
### Cloud Watch
各インスタンスの状況をモニタリングするサービス。
標準メトリクスというAWSが管理している範囲の情報をお客様側での追加設定なしで収集している。
メトリクスデータはダッシュボードで可視化出来る。
主な機能は以下。
・標準メトリクスの収集、可視化
・カスタムメトリクスの収集、可視化
・ログの収集
・アラーム
標準メトリクスはCPUの使用率やネットワークのステータス情報など。
標準メトリクスで取得できない情報はカスタムメトリクスとして取得することが出来る。このカスタムメトリクスはPutMetricDataAPIを使用して書き込むことが出来る。
CloudWatchへの書き込みを行うプログラムはCloudWatchエージェントとして提供されているのでEC2にインストールするだけで使用できる。
CloudWatch Logsを使用すると各ログを取得することができる。
ログの情報をEC2の外部に書き出すことでEC2をよりステートレスにできる。
ログとして書き出すことでオートスケーリングで終了させたインスタンスのログの解析を行うことができる。
このメトリクス値に対してアラームを設定することが出来る。
アラームに対して実行できる3つのアクション
・EC2の回復：EC2ホストに障害が発生した場合には自動で回復する。
・AutoScalingの実行：AutoScalingポリシーではCloudWatchアラームに基づいてスケールイン、スケールアウトのアクションを実行する。
・SNSへの通知：SNSで通知することでそのメッセージをEメールで送信したりLambdaへ渡すなどできる。これを利用して監視の仕組みを作成することができる。Lambdaへ渡すことでアラームの後の処理を自動化できる。
メトリクスの保存期間を過ぎたものは消去される。これ以上の期間使用したい場合にはS3などに保存する。CloudWatch Logsでは任意の保存期間を設定でき、消去しないこともできる。
CloudWatch Eventsは発生した運用上の変更を認識できる。これに対してアクションを実行することもできる。
CloudWatchはEC2へのアクセスログを取得できない。
[Amazon CloudWatch](https://aws.amazon.com/jp/cloudwatch/)
### Cloud Trail
AWSアカウント内の全てのAPIの呼び出しを記録できる。つまりAWSアカウント内における全ての操作を記録できるということ。
監査や調査に使用することができる。
誰がいつどのアクションを実行したのかを確認できるので、コンプライアンス違反などを監視できる。
Cloud Watch Logsと統合することでログデータを検索したり、コンプライアンス違反のイベントを特定したり、インシデントの調査と監査の要求に対する応答を迅速化したりできる。
似たサービスにAWS Configがあり、こちらはリソースの変更を記録する。誰がいつ何を変更したのかを自動で記録できる。コンプライアンスや監査の要件には適さない部分もある。
### AWS Config
AWSリソースの設定を評価、監査、審査出来るサービス。リソースの設定が継続的にモニタリング及び記録されて望まれる設定の評価を自動的に実行出来る。
このサービスを利用するとAWSリソース間の設定や関連性の変更を確認し、詳細なリソース設定履歴を調べ、社内ガイドラインで指定された設定い対する全体的なコンプライアンスを確認できる。これによりコンプライアンス監査、セキュリティ分析、変更管理、運用上のトラブルシューティングを簡素化できる。
ルールから逸脱するものがあればSNSで通知することが出来る。
EC2のアクセスログは取得することができない。
誰がどのアクションを実行したのかは監視できない。
従量課金。
[AWS Config](https://aws.amazon.com/jp/config/)
### AWS Systems Manager
AWSのインフラを可視化し制御するためのサービス。
このサービスを使用することで様々な運用データを確認でき、AWSリソース全体に関わる運用タスクを自動化出来る。
リソースをアプリごとにグループ化して運用データの表示を行える。これによりモニタリングやトラブルシューティングを行うことが出来る。
インフラを安全に運用、管理することが出来るようになります。
このサービスの一つであるOpsCenterを利用すると運用上の問題の確認、調査、解決を一元的に行うことが出来る。
[AWS Systems Manager](https://aws.amazon.com/jp/systems-manager/)
### CloudFormation
AWSの各リソースを含めた環境を自動生成、更新、管理できる。
Terraformと同様のサービス。
CloudFormationを利用することで同一のAWS環境を何度でも自動で構築できる。
自動プロビジョニングをコードを用いて行うことが出来る。
コードはAWS CodeCommitなどのリポジトリでバージョン管理出来る。
### Elastic Beanstalk
Webアプリの環境を簡単にAWSに構築するサービス。CloudFormationと似ているがテンプレートを作成する時間が必要なく、設定パラメータを提供することでApacheやNginx、IIS、各言語の実行環境も合わせて簡単に構築出来る。しかし、AWSの全てのサービスを網羅しているわけではなくWebアプリケーションやタスク実行環境を構築することに向いている。
アプリケーションの継続デプロイのための高性能な機能を有している。 
### AWS Trusted Advisor
このサービスは環境の状態を自動的にチェックして回りベストプラクティスに対してどうだったかを示すアドバイスをレポートする。
チェック項目は以下の5点
・コスト最適化
・パフォーマンス
・セキュリティ
・フォールトレランス(耐障害性)
・サービス制限
#### コスト最適化
見直すことでコストを最適化出来るという視点でアドバイスをレポートしてくれる
具体的にどれくらいコストが削減されるかも提示される。
主な項目として
・使用率の低いEC2インスタンス
使ってないのに起動していたり、過剰に高いスペックのインスタンスがある。これらは適切に運用することでコストを下げれる可能性がある。
他にもEBSやRedshiftも使用率をチェックされる。
アイドル状態についてはELB、RDS、elasticIPアドレスに対してもチェックされる。
・リザーブドインスタンスの最適化
リザーブドインスタンスの購入でコストが下がらないかチェックする。
購入済みのリザーブドインスタンスについては有効期限が切れる30日前からアラートの対象になるので購入し忘れの防止になる。
リザーブドインスタンスは継続更新はできず、新規購入することが求められる。
#### パフォーマンス
・使用率の高いインスタンス
実装している処理に対してリソースが不足している可能性があるので、処理が最も早く終了するインスタンスへの切り替えを推奨することもある。
・セキュリティグループルールの増大
ルールが多いとそれだけトラフィックが制限されることになる50以上のルールがあるとパフォーマンスの低下に繋がる恐れがある。
このアラートが発生した場合にはルールをまとめられないか検討する必要がある。
対象のインスタンスにそれだけのポートを必要とする機能を多くインストールしていないか、インスタンスを分けることはできないかを検討する。
・コンテンツ配信の最適化
CloudFrontにキャッシュを持つことでS3から直接配信するよりもパフォーマンスが向上する。
キャッシュがどれだけ使用されているかを示すヒット率もチェックされる。
#### セキュリティ
セキュリティリスクのある環境になっていないかをチェックする。
・S3バケットのアクセス許可
誰でもアクセス出来るバケットがないかをチェックする。
意図してそのように設定している場合ももちろんある。
こういう設定にしたい場合にはバケット全体を公開するのではなくその中に作ったオブジェクトのみを公開にすることで、誤って機密情報をバケットに公開するというリスクが避けれる。
・セキュリティグループの開かれたポート
リスクの高い特定のポートが許可されていないか、セキュリティグループをチェックする。
・パブリックなスナップショット
EBSやRDSのスナップショットは他の特定のアカウントに共有することも出来る、アカウントを特定せずに公開共有することも出来る。
誤って公開すると他の全てのAWSカウントと共有してしまうことになるので、必要なアカウントとの共有のみになるようにチェックする。
・ルートアカウントのMFAとIAMの使用
ルートアカウントを使用するのは危険なのでIAMを使用する。
また、MFAを設定することでセキュリティを強化出来る。
IAMパスワードポリシーが有効かされているかのチェックもある。
#### フォールトレランス
障害耐性の低い状態でないかのチェックを行う。
・EBSのスナップショット
EBSのスナップショットが作成されていない、または最後に作成されてから時間が経っていないかをチェックする。
EBSボリュームはAZ内で複製されているがAZに障害が起こる可能性はある。EBSスナップショットを作成するとスナップショットはS3に保存されるので高い耐久性でデータが保持される。
・EC2、ELBの最適化
複数のAZでバランスよく配置されているかをチェックする。
ELBではクロスゾーン負荷分散やConnecting Draining(セッション完了を待ってから切り離す機能)が無効になっていないかチェックする。
・RDSのマルチAZ
マルチAZになっていないデータベースインスタンスがないかをチェックする。
#### サービス制限
AWSアカウントを作成した最初の時点ではサービス制限がいくつかある。これはソフトリミットと呼ばれている。
これは誤った操作による意図しない請求を回避する。不正アクセスによる意図しない請求を回避するため。
インスタンスの最大数の制限などがある。制限を超えて使用する予定がある場合にはAWSに事前に申告しておく。
### Amazon Cognito
アプリケーションに素早く簡単にユーザーのサインアップ、サインイン、及びアクセスコントロール機能を追加することが出来る。
SNSアカウントなどを利用したサインインもサポートしている。
無料枠ありの従量課金制。
[Amazon Cognito](https://aws.amazon.com/jp/cognito/)
### Amazon Simple Workflow Service(Amazon SWF)
クラウドのワークフロー管理アプリケーション。
デベロッパーが並行したステップ、または連続したステップがあるバックグラウンドジョブを構築、実行、スケールするのに役立つ。
クラウド内の完全マネージド型の状態トラッカー、及びタスクコーディネーターとしてみなすことができる。
[Amazon SWF](https://aws.amazon.com/jp/swf/)
### AWS リソースグループ
リソースグループツールを使用するとプロジェクトと使用するリソースに基づいて情報を整理、及び統合するカスタムツールを作成できる。
これを使用すると多数のリソース上のタスクを一度に管理及び自動化しやすくなる
[AWS リソースグループ](https://docs.aws.amazon.com/ja_jp/ARG/latest/userguide/welcome.html)
### AWS マネジメントコンソール
アカウントを登録することで使用できるGUIツール。
シンプルで直感的にAWSリソースにアクセスすることが出来る。
コマンドでアクセスできるのはAmazon CLI。
## 請求と料金
### サポートプラン
AWSには4つのサポートプランがあり、エスカレーションパス(問合せ先)を確保することができる。
#### ベーシックプラン
・AWSアアウントを作成した時に提供されている無料のサポートプラン
・技術サポートはAWSサービスの稼働状況をモニタリングしているヘルスチェックのみ
・Trusted Advisorは最低限必要な項目のみ
#### 開発サポートプラン
・29USDか使用料の3%のお大きい方
・技術サポートを作成できるユーザーは1ユーザーで時間帯は9:00~18:00
・構成要素についてのアーキテクトサポート
・Trusted Advisorは最低限必要な項目のみ
#### ビジネスプラン
・100USDか使用料に応じた計算式の高い方
・技術サポートを作成できるユーザーは無制限で、時間帯は24時間
・アーキテクチャはユースケースのガイダンス
・Trusted Advisorは全項目
・サポートAPIが使用可能
・サードパーティソフトウェアのサポート
#### エンタープライズプラン
・15,000USDか使用料金に応じた計算式の大きい方
・技術サポートを作成出来るユーザーは無制限で、時間帯は24時間
・アプリケーションのアーキテクトサポート
・Trusted Advisorは全項目
・サポートAPIが使用可能
・サードパーティソフトウェアのサポート
・テクニカルアカウントマネージャー(TAM)
・サポートコンシェルジュ
・ホワイトグローブケースルーティング
・管理ビジネス評価
### リザーブド購入の種類
・Elastic Chacheリザーブドノード
・DynamoDBリザーブドキャパシティ
・Redshiftリザーブドノード
・EC2リザーブドインスタンス
・RDSリザーブドインスタンス
のように様々な種類が存在する。
### 請求ダッシュボード
どのサービスにいくらくらい使用しているのかを確認することができる。
### コストエクスプローラー
何をどれだけ使っているのかを確認、分析に利用できるもの。
### コスト配分タグ
AWSサービスにはタグをつけることが出来るサービスがあり、タグはキーと値で構成されている。
このタグをコスト分析のために有効化しておくことでコスト分析に利用できる。
### 請求アラーム
CloudWatchでは請求金額もメトリクスの1つである。そのため、SNSと連携することで設定していた請求額を超えたりした際には通知をすることが出来る。請求アラームを設定することで意図しない請求や、使いすぎを防止できる。
### AWS Badgets
設定予算を超えると予測される時にアラートを発信するサービスで、請求アラームと組み合わせて使用する。
### 一括請求
Qrganizationの一括請求を使用することで複数アカウントの請求を1つにまとめることが出来る。
一括請求により複数アカウントでリザーブドインスタンスが使用できるようになったり、複数アカウントの合計使用量でボリュームディスカウントを受けられる可能性もありメリットがある。
### AWS簡易見積もりツール
AWSでどれくらいのコストがかかるのかを事前に確認することができる。
マネジメントコンソールにログインしなくても使用することができる。
このサービスが今後終了が通知されている。
今後はAWS料金計算ツールを使用する。
### TCO計算ツール
AWSへの移行、導入を検討している際にオンプレミスで構築した場合とのコスト比較をレポートしてくれるサービス。
経営層などへのプレゼンテーションに利用できる。
マネジメントコンソールへログインしなくても使用することができる。
### AWSのコスト使用状況のレポート
サービス、料金、予約などに関するメタデータを含むAWSのコストと使用状況に関する最も包括的なデータを提供する。
使用状況のデータを日単位または時間単位で集計することも可能である。
### Pay as you go
使った分だけのライセンス料を払う課金方式。
## その他サービス
### AWS Server Migration Service(AWS SMS)
サーバーの移行を支援するサービス。
多数のオンプレミスのワークロードをAWSに移行するためのサービス。
クラウドへの移行プロセスの簡素化ができ、数回のクリックで移行を開始できる。
ダウンタイムを最小にすることができる。
追加料金なしで使用できるが移行プロセス中に使用されるS3バケット、EBSボリューム、データ転送、及び実行するEC2インスタンスに対しては標準料金がかかる。
[AWS SMS](https://docs.aws.amazon.com/ja_jp/server-migration-service/latest/userguide/server-migration.html)
### AWS Application Discovery Service(AWS ADS)
オンプレミスデータセンターに関する情報を収集することにより、エンタープライズのお客様の移行プロジェクト計画を支援するサービス。
サーバーの設定データ、使用状況データ、動作データが収集され、提供される。これによりワークロードを把握することができる。
収集されたデータはAWS ADSのデータストアに暗号化形式で保存される。このデータを総所有コスト(TCO)の見積もりやAWSへの移行計画に使用できる。
このデータをAWS Migration HubというサーバーをAWSに移行し、移行する際の進捗を追跡できるサービスでも使用できる。
[AWS ADS](https://aws.amazon.com/jp/application-discovery/)
### Infrastructure Event Management
エンタープライズプランのユーザー(追加料金を払うとビジネスプランのユーザーも可能)が利用できるプログラムで、アプリの起動、インフラの移行、マーケティングイベントなどの大規模なイベントなどの計画に利用できるサービス。
イベントの前に戦略的な計画の支援を受けたり、リアルタイムサポート得ることができる。
料金プランには様々なものがある。
### Amazon Simple Queue Service(Amazon SQS)
完全マネージド型のメッセージキューイングサービス。
マイクロサービス、分散システム、及びサーバーレスアプリケーションの切り離しとスケーリングが可能である。
コンポーネント間でメッセージを送信、保存、受信できる。メッセージが失われることなく他のサービスを利用可能にしておく必要もない。
プッシュ形式ではなくポーリング処理による通知である。
以下の２種類のメッセージキューを利用できる。
・標準キュー　最大限のスループットが得られ、配信順序はベストエフォート型で配信は少なくとも1回行われる。
・SQS FIFOキュー　メッセージが送信される順序の通りに1回のみ処理されるように設計されている。
`ポーリング処理：複数の機器やプログラムに対して順番に定期的に問合せを行い、一定の条件を満たした場合に送受信や処理を行う通信及び処理方式のこと`
`ベストエフォート型：最大限の結果が得られるように努力する。結果に関しての保証は行わないとする方式`
### Amazon Simple Email Service(Amazon SES)
デベロッパーが任意のアプリでメールを送信できるようにする費用対効果の高い、柔軟でスケーラブルなメールサービスである。
このサービスを利用すると安全、グローバル、大規模にEメールを送信することができる。
配信可能性を最適化する。
使用例として取引Eメール、マーケティングEメール、Eメールの一斉送信があげられる。
料金はEC2からの利用した場合には月に62,000通までは無料。無料期間の有効期間はなし。
送信メールデータ、受信メールチャンク、EC2データ転送に関しては課金されるので注意。
[Amazon SES](https://aws.amazon.com/jp/ses/)
### 不正使用対策チーム
AWSリソースが不正に利用されていた場合に報告するところ。
不正利用の種類としてはスパム、ポートスキャニング、DoS攻撃、侵入の試み、不快なコンテンツや著作権違反のコンテンツのポスティング、マルウェア攻撃などがあげられる。
`ポートスキャニング:対象のコンピュータのTCPあるいはUDPのポートに接続を試みて、機能の停止や侵入などの攻撃に使えそうな脆弱性がないかを調べること`
### Amazon Connect
音声とチャットのためのクラウドのコンタクトセンター。顧客サービスを低コストで提供できる。
事例としてコールセンターシステムの構築を行える。
[Amazon Connect](https://aws.amazon.com/jp/connect/)
### Amazon Litesail
このサービスは単純なワークロードで、迅速なデプロイ及びAWSの使用するのに最適なサービスで小規模で始めることができる。
クラウドに慣れていない人でも簡単に扱えるように必要な物が最初から揃っているプランである。
ヴァーチャルプライベートサーバー(VPS)を提供する。
[Amazon Litesail](https://aws.amazon.com/jp/lightsail/)
### Amazon Workmail
既存のデスクトップ及びモバイルメールクライアントアプリをサポートする安全なビジネスメール及びカレンダーサービス。
マネージドである。
Outlookとの互換性がある。
[Amazon Workmail](https://aws.amazon.com/jp/workmail/)
### Amazon Simple Notification Service(Amazon SNS)
システム間通信とアプリの個人通信の両方に向けてのメッセージサービスを提供している。
疎結合化されたマイクロサービスアプリケーション間のメッセージングを可能にしている。
SMSやモバイルプッシュ、電子メールを介してユーザーと直接通信したりできる。
アプリの疎結合化ができる。
従量課金である。
フルマネージド型。
[Amazon SNS](https://aws.amazon.com/jp/sns/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc)
`プッシュ方式とは:サーバーから能動的に情報を送信する通信方式`
`プル方式:クライアント側からの要求に基づいてサーバーが応答する場合にはプル型という`
### Amazon EMR
オープンソースのツールを利用して膨大な量のデータを処理するための業界をリードするビッグデータのクラウドプラットフォーム。
使いやすく、伸縮性があり、低コスト、信頼性、セキュア、柔軟性といった特徴を持っている。
ビッグデータフレームワーク、クラスタープラットフォームと表現することもある。
[Amazon EMR](https://aws.amazon.com/jp/emr/?nc=sn&loc=1&whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc)
# 参考
主な学習は以下を参考にいたしました。
その他の参考資料は文中に記載させていただいております。
[AWSホワイトペーパー](https://aws.amazon.com/jp/whitepapers/?whitepapers-main.sort-by=item.additionalFields.sortDate&whitepapers-main.sort-order=desc)
[AWS各サービスの概要](https://aws.amazon.com/jp/?nc2=h_lg)
[AWS認定資格試験テキスト　AWS認定 クラウドプラクティショナー](https://www.sbcr.jp/product/4797397406/)
[この問題だけで合格可能！AWS 認定クラウドプラクティショナー 模擬試験問題集（7回分455問）](https://www.udemy.com/course/aws-4260/)

# 注意
サービスの内容は執筆当時のものです。また、個人が取りまとめたものになりますので公式のドキュメントとズレが生じている場合には公式ドキュメントが正しい内容になります。