前提
AWS（クラウドプラットフォーム）について学んだことを書いていきます。
本題
巨大クラウドプラットフォーム
では、クラウドサービスの次にAWSついて書いていきます。
世界１５箇所で提供されるクラウドサービス
展開されている地域のことをリージョンと言います。
AWSの利用者は、これらの好きなリージョンに、仮想サーバーや仮想ネットワークなどを構築して運用できます。
居住国とリージョンとは関係ありません。
日本国内に住んでいても、バージニア北部などの米国のリージョンを使うこともできます。
とはいえ、地理的に近いリージョンほどネットワークのレスポンスが速いため、日本国内から利用する場合には、東京リージョン（ap-northeast-1）を使うことがほとんどです。
東京リージョン以外を使う理由
・東京リージョンでは、まだ提供されていないサービスを使いたい
・東京リージョンよりも、安く運用したい
・東京リージョンが万が一異常を起こした時のバックアップとして、別のリージョンに設置したい
AWSでは１００以上のサービスが提供されている
AWSでは特にマネージドサービスが充実しています。
AWSでよく使われるサービス
基本的にこれだけ理解すれば、オンプレミスで実現していたのと同じ、ほとんどの業務システムを構築できるはずです。
データはリージョン間を勝手に移動しない
AWSで仮想サーバーなどを構築するときには、どのリージョンに作成するのかを初めに決めます。
リージョンを１度決めると、そのサーバーが他のリージョンに勝手に移動することはありません。
そのため、国外に持ち出してはいけないデータを運用する場合も、東京リージョン上のサーバーで運用すれば問題ありません。
AWSのデメリット
主なデメリットは次の２つですが運用の工夫で解決できます。
１、定額での運用ができない
AWSは従量課金であるため、定額での運用ができない点が運用上のデメリットとしてよく挙げられます。
情報システムでは予算を確保して運用することも多いため、AWSを使いたいと思っても「いくらかかるかわからない」のでは、社内決裁が降りない、取引先の理解が得られないことも多いでしょう。
しかし、AWSにはAWS簡易見積もりツールが提供されており、高い精度で、どのぐらいの金額がかかるかを予測できます。
予測しにくいのが、「ネットワークトラフィック」ですが、「１ユーザー当たり、平均でどのくらいのデータを送受信するか」を実測し、それに想定されるユーザー数を掛け算すれば、想定から大きくかけ離れた値になることはありません。
２、自分で全てをコントロールできなくなる
そして次によくある問題が、AWSに運用管理を任せるので、完全に自分でコントロールできなくなってしまうという点です。
これは、主に次の３つ問題（不安）に分けることができます。
・データ流出の問題
まず、AWSにデータを預けることになるので、データの消失や流失が起きないかが心配になります。
しかし、AWSでは各種プライバシー認証・コンプライアンス認証をとった環境で運営されており、設定のミスや各種攻撃などに注意すればAWSを使っただけでデータが筒抜けということはまず起こりません。
もちろん、オンプレミス同様にアクセス情報を秘匿するといった対策は必須です。
・AWSの大規模障害
次に危惧されるのがAWS自体の大規模障害です。
社内の基幹システムをAWSで運用する場合、万一、AWSが停止した時は、社内業務が停止する恐れがあります。
オンプレミスでの運用ならエンジニアを派遣して、ひとまず暫定復旧を始めることまでできますが、AWSの場合は、AWSに任せて復旧を待つよりほか方法がありません。
もし本当に停止すると業務を打撃するようなシステムの場合は、AWSを利用しない、もしくは、AWSとオンプレミスを併用して、AWSが止まったときにはオンプレミスに切り替えられるようにするなど対策が必要です。
可用性や今までの障害情報などを適切に収集し、AWSを通信しない体制を構築しておくことは必要です。
・サービスがいつまで提供されるか
最後に、いつまで（個別の、あるいは全体の）サービスが提供されるのかという問題もあります。
もし、サービスが終わってしまうと、別のシステムに作り替えなければいけません。
こうした懸念を避けるには、多数のユーザーが使っているサービスだけで構成するあまりAWS独自のアンマネージドサービスに依存した作りにしないといった設計上の考慮が大事です。
AWSを過信しない
AWSは管理運用コストを減らせる、サービスを迅速に増強できるなど、数多くのメリットがあります。
これらの面ではオンプレミスのサービスの利便性を完全に上回ります。
可用性やセキュリティについての懸念もありますが、AWSではこれはかなり高水準で保たれています。
利用企業、団体のリストを見れば信頼性の高さがうかがえます。
コスト面でも、いくつかのケースではオンプレミスよりも優れているでしょう。
初期費用をかけられないようなケースでは、設備投資不要で必要な時だけ費用が発生するAWSは強い見方となります。
しかし、過信は禁物です。
クラウドサービスだからサービスが安定する、安全になる、安価になる訳ではありません。
IAMユーザー
サインインしているAWSアカウント（ルートユーザー）は、AWSに対する全ての操作のほか、支払い方法の変更や解約など、契約に関する操作もできる強力なアカウントです。
万が一、漏洩すると被害が大きくなります。
そこで、AWSアカウントは、そうした特殊な操作が必要な時にだけにしか使わないようにし、普段のAWS操作には、別アカウントを作成して、そのユーザーを使って操作するようにします。
AWSを操作できるユーザーのことをIAMユーザーと言います。
アクションとポリシー
AWSにおける各種操作は、アクションと呼ばれる単位で構成されています。
例えば、仮想サーバーを作成できるアクション、仮想サーバーを実行できるアクション、ストレージを読み込みできるアクション、ストレージを読み書きできるアクションなどです。
アクションは、とても数が多く、一つ一つ設定すると煩雑なばかりか、設定漏れも生じやすくなります。
そこでAWSでは、一つ一つ権限を設定するのではなく、あらかじめ目的ごとにアクションをグループ化したポリシーと呼ばれるものをIAMユーザーに適用することで、ユーザーが操作可能な権限を付与します。
ポリシーは自分で作ることもできますが、既存のポリシーがたくさん用意されています。
例えば、仮想サーバーに関する全ての操作ができるポリシー、仮想サーバーの新規作成や削除、設定変更などはできないが、実行や停止はできるポリシー、ストレージに関する全ての操作ができるポリシー、ストレージに関する読み書きができるポリシーなどです。
IAMユーザーに対して、このしたポリシーを複数適用すると、それらのポリシーで許可されているアクションが操作できるようになります。
・IAMグループ
IAMグループは、IAMユーザーをグループ化して権限設定する概念です。
複数のユーザーに対して、同じ権限設定をしたいときに使います。
・IAMロール
IAMユーザーがユーザー（人間）に対するアカウントなのに対し、IAMロールはAWSのリソースに対するアカウントです。
例えば、仮想サーバー（EC2）から、ストレージやサービス（S3）にアクセスする場合、IAMユーザーで管理しようとすると、EC2のプログラムに、S3にアクセスするためのユーザー名やパスワード（より正確に言うとIAMの設定で作成できるアクセスキーやシークレットアクセスキー）を使って認証する必要があります。
しかし、AWSではそうする代わりにS3にアクセスできるIAMロールを作成しておき、そのIAMロールをEC2に適用すると、それだけでアクセスできるようになります。
このように、あるサービスから、別のサービスにアクセスしたい時、アクセス元のサービスに対して設定して使うのが、IAMロールです。