『AWSの基礎』について自分なりのまとめ

はじめに

AWSの基礎を大雑把にまとめてみました！

『AWS の基礎』と聞くと最初かまえてしまいますが、『同じ認識あるよね?そのためにこういうように出来るようにしてあるからね！』と言っている感じです！

例えば通信の暗号化httpsにする機能とか、『あるからね？』とか
ではなぜこんな基本的なことを『AWS の基礎』とするかと思いますが、
そもそも『https』や『暗号化』といった認識がない人からしたら知っておくべき知識だからです。

例えば1つだけの誰でも見れるhtmlを表示させたいだけの人にはawsは必要ないかと。
きっとそういう人たちがAWSはいいからAWS使う〜〜みたいにならないように『AWS の基礎』というページを用意しているのかなと、、憶測ですが、

なのでAWSはあくまで、
よりセキュアに
よりパフォーマンスを
より柔軟に出来ることを望む人達が私たちのサービスを使うべきですからねと言いたいのかと思っています。

あとAWSを使うことは本当にコストを抑えられるか？等気になると思います。
私も思います。
これに関しては使い方によるのかなの認識です。
ただサービスを大きくする予定ならとりあえずAWSを使うみたいにしてもいいのかなと、、
今後実際に使う予定なのでこんな感じだったよ等々記事に出来たらなと思っています！

AWS の基礎

・セキュリティ
・パフォーマンス効率
・信頼性
・運用上の優秀性
・コストの最適化

AWS の基礎をもう少し詳細に

『セキュリティ』について

まずセキュリティを理解するためにおおまかに『アクセス権限』、『アクセス制御』、『暗号化』的なことに対応しているよを認識しておく必要があるかと思います。

【権限(アクセス権限等)】
このユーザーは〇〇まで出来る権限。
このユーザーは〇〇までアクセス出来る権限。
といったようにユーザーに権限をつけられるようになってます。

※関連用語: IAMポリシー、VPC、セキュリティグループ(ポート制御)　※ここら辺詳細詳しく説明出来ないのでカテゴリ分類間違えていたらすみません。

【アクセス制御】
〇〇という文字が含まれているものは拒否するというようにアクセス内容に一定のルールをつけることが出来ます。
その他インターネットからアクセス出来る、AWSサービス間でしかアクセス出来ないようにするといったことも出来ます。
その他許可するポートとかを制限する等も出来ます。

※関連用語: WAF

【暗号化】
保存するテキストや画像、送信するテキスト等を送信する相手しかわからないようにして送る機能もあります。

※関連用語:https

■■■■■■■■メモ■■■■■■■■
以前の表修正しました。以前の内容のもの『改善前』として以下に残しています。
よろしくお願いいたします。
https://kaizenkibokijisaito.com/articles/view/12?tab=1

アクセス制御関連
・RDS、ECSなどのリソースごとに『ネットワークコントロールセキュリティが存在』

暗号化関連
・リソース(pdfや画像、DB)のリソース暗号化はデフォルトで設定。私的に非公開にしなくてもいいもの管理しているのならほんの少しでもコスト、パフォーマンスのために暗号化OFFの設定とか考えてもいいのかな〜と感じています。ただここの暗号化は本当に少しのコストと処理時間かからないと言っているのでOFFにしてもあまり変わらないのかもとも思ったりしています。ただメール的な暗号化はOFFに間違って設定しないようにしないとなとか思ってます。
・暗号化をするためのキー(CMS)を作成するためにあるものがKMS

『パフォーマンス効率』について

パンダさんが何か言ってます、、、

パンダさんが言っている感じだと少し雑なのでここでもう少し説明を追記させていきたいと思います。

『ペットではなく家畜』は、アクセスが多くなったら他サーバーと交換してアクセスに耐えれるようにしようと言ったものです。もし自社サーバーとかだと気軽にこのサーバーに変更とかは難しくついついこのサーバーはペットだから変えられないみたいなの無くそうねと言ったものです。

『適切なサービスと適切なサービス設定』はこれもまた基本的なことでアーカイブ用のものはアーカイブに適したサービスを、頻繁にアクセスされるものは頻繁にアクセスされるを想定したサービスを使おうねと言ったものです。これは今後使おうと思った際どんなことに適しているサービスなのか説明等を読めば問題なさそうですね。
主要なサービス書いてあったもの雑ではありますが以下リンクにまとめてあります！
もしよかったら見てください。
AWS主要サービス選択検討表(サービス公開、ストレージ(画像の保存先など)、データベース)

『垂直スケーリングと水平スケーリング』についてまず簡単に説明すると入れるものが増えた時、大きなボックスにするか、新たなボックスを買うか的なことを言っているのみです。

でどっちがいいかですがそれはその時によると言った感じかと、、

ちなみに私が個人でサービスを公開する場合ギリギリまで『垂直スケーリング』しているような気がしています。あとは金額的に『垂直スケーリング』が危うそうだったら『水平スケーリング』を検討でパフォーマンスというより金銭的なことで考えそうです。

■垂直スケーリング ※ボックスを大きくするのイメージ
利点:
・大きくするのは増やす処理より簡単。
(データが合うように処理等考えなくていいから)
欠点:
・大きくするには増やすより限界がある。
・大きくしただけの場合他にサーバーない場合ダウンした時サービス使えなくなる。

■水平スケーリング　※入るボックスを増やすのイメージ
利点:
・一箇所のサーバーがダウンしてもサービス使えなることを防ぐことができる。
欠点:
・増やすは大きくするより処理大変。
(データが合うように処理等考えないといけないから)

■■■■■■■■メモ■■■■■■■■

Amazon CloudWatch の料金を超える追加料金は発生しません。詳細については、Amazon EC2 Auto Scaling を参照してください。EC2 以外のサービスもスケールする場合は、AWS Auto Scaling を使用できます。
https://aws.amazon.com/jp/ec2/features/

Amazon CloudWatch自体は一定以上使用するとお金かかるようです。
https://aws.amazon.com/jp/cloudwatch/pricing/

『信頼性』について - サーバーの置き場所編

AWSは色々な国や地域にサーバーを置いておく場所を管理しています。
各場所それぞれは独立しているため、もしA国で火災が起きてもB国で火災が起きなければサービスが運用できますよと言ったものです。

勘の言い方なら分かるかと思いますが、自分のサービスを動かすサーバーをA国のみと、A国とB国で使うを比べた場合、A国とB国で使う方が費用も時間もそれだけかかりますよというもの。

なのでどんなことがあってもサービスを停止したくない場合等は色々な国のサーバー上でサービスを運用しようねと言ったという感じです。

国と言ってしまいましたが、AWSでは『リージョン』と『AZ(アベイラビリティーゾーン)』と言った言い方をしています。厳密にはAWSのサイトを見る感じでになりますが、大雑把に言えば『リージョン』は国、『AZ(アベイラビリティーゾーン)』は地域程度に考えればいいのかと感じています。
※国と言ってしまっていますが、実際には東京リージョン、大阪リージョンがあるので都市的な感じで考えた方がいいのかもしれません、、

詳しく確認したい方はリージョンマップとエッジネットワークのサイトを見てください。

ここで気をつけたいのが、日本人に提供したいサービスは日本または日本に近い『リージョン』や『AZ(アベイラビリティーゾーン)』を選択する必要があるということです。

ただ日本が全滅した時でもサービスを運用しておきたいなら他国のもう少し遠いところも検討したいといった感じかと思います。

ここは自分や会社の上司やお客さんと相談ですかね？

『日本が壊滅してもサービスは運用しておきたいですか？』等々。
100%の確率でNoかと思いますが、、

または
『東京が地震でやばいことになってしまった時もサービスを運用しておきたいですか』等々。

ちなみに、東京、大阪が一気に火災でやばいことになってしまうこともなきにしもあらずなのであくまで備えるの感覚でという感じですね。

何が言いたいかというと、東京、大阪に置いておけば絶対大丈夫ですということではないということです。

ここでは主にサービス運用するサーバーの置き場所についてお話ししましたが、AWSには他場所でも分離しておくようにすることでなるべく一箇所に障害が起きても多くに障害が起きないようにしていますよと言っています。すごいでしょう！ちゃんとしているでしょう！と言いたい感じです。

『信頼性』について - 制限編

次に制限の話です。図で見てもらうように、AWSには『外部からの制限』、『内部からの制限』がかかるようになっています。

『外部からの制限』はリクエスト無限に受け付けてしまういとんでもないサーバー費用になったり、過剰なアクセスでシステムが処理しきれない等起きてしまうのを防ぐため、

『内部からの制限』は間違った処理での無限ループが発生した場合止めないと不必要なコストがかかったり内部のものが壊れたりしてしまうからですね。

制限は緩和できる制限そうでない制限あります。

制限の確認や制限緩和申請にはサービスクォータというものを使うようです。

『運用上の優秀性』について

作業が自動化されればそれだけ、人的ミスは少なくなります。
それを知っている人はそういったサービスがAWSにはあるか気になるかと思います。
AWSは『CloudFormation』というサービスで可能ですよといっています。

この『CloudFormation』というサービスですがインフラの設定に関することです。
もし自分のサービスを止めたい時に処理がいくつか必要なものを自動化するためのものという使う感じの理解です。

ただその自動化自体に問題があるかもしれません。

それを改善するために、
何が起きたか分析しなければいけません。

AWSにはそれら測定、分析するためのものもあるよと言ってます。

CloudWatch
インフラの設定の自動化処理の監視かと。
ここでエラーとか発生したか等々みるの認識です。

CloudWatch Logs Insight
上記のCloudWatchで出たログをいい感じで検索できるようなサービスの理解

CloudTrail
誰がどこで何をしたか的なことを監視するもの的な理解です。
個人ではあまり使用しないのかなと考えてます。

その他にも以下のようなサービス等あるみたいです。
Athena…S3 に保存されたログの分析
RDS…構造化データの分析に持って来いらしいです。
RedShift…大量の構造化データの分析にもってこいらしいです。
Elasticsearch Service…ログのデータ分析にもってこいらしいです。

『コストの最適化』について

まずAWSは自分の会社にサーバー設置してサービス動かすより安くすみますよと言っています。
ここはそうでないとという気持ちなのでここで終了します。

コストの最適化に一番重要とされるものは、
『適切なインスタンスサイズ』と『適切なファミリー』の選択だそうです。
これに関してはここにとてもわかりやすく記述されていました。

ここで難しいと思っても大丈夫です。
最初とりあえずで使ってそのあとAWS Compute Optimizerで適切なものはこれですよ！っと教えてくれるものもAWSにあるみたいなので。

それ以外でコストのことも考えるとき以下のような選択肢もあるようです。
Lambda…コードが実行されている時のみお金かかる。これこそ究極の従量課金だそうです。ちょっと作成したコードを試してみたい時とかは使うのもアリかもです。

Savings Plans…ある程度使う分を予約することで割引してもらえる。これはある程度サービスは落ち着いてきたら検討できたりするのかと考えています。あとこの先サービスが終了しないということが明確であればいいかもです。最大72%の割引になるようです。なので2万だったら5600円に抑えることもできるのかもという感じですね。最大なのでアレですが、ちなみに予約期間は1年から3年間とのこと。なので3年分予約して、1年しか使わなかったらその分損です、、

EC2 スポットインスタンス…使用されていない箇所を使うの認識です。ここに関してはサービスとして考えているものではなく、お勉強で使う感じの箇所の認識です。

参考

必要な箇所にリンクを貼る形にしています。

最後に

あたりまえのことが多い認識ですが、
これらのことを大まかに知っているとAWSのサービスを使う際に少し躊躇しなくなるのかもなどと感じました！