はじめに

前回の記事で、副業は本業を突き詰めていく過程の記事執筆にしようと言うことにしました。
今回はその第一弾となります。
本業では、世間的なクラウドシフトの波に飲まれないように、当社としてもクラウド関係の商材販売に力を入れているところです。

クラウドといってもサービス・商材は多種多様なのですが、当社ではAWSやAzureといったパブリッククラウドサービスのマネージドサービスを展開しており、そのサービス販売のためにAWSに関する知識・理解を深めようと言うことで、AWSソリューションアーキテクト（アソシエイト）と言う資格の勉強をしようと思います。

余談：なぜAWSなのか

パブリッククラウドといっても、AWS・Azure・GCP・OracleCloudなど多種ありますが、やっぱりAWSが一番学習リソースが豊富と言うのが一番魅力でした。
とはいえ、ぶっちゃけ今後はAzureが一番伸びて行きそうだとは思ってます。（Open AIとの結びつきや、Microsoft製品（OfficeやAcriveDirectory、最近だとPowerシリーズ）との親和性の高いAzureは今後社内向けの基盤構築に最も伸びるクラウドだと思ってます）
ただ、Microsoftは最近度重なる値上げで、殿様商売感がめっちゃ強くなってきたと勝手に感じているので、その反骨心でAWSにコミットしたいと思うようになった次第です。笑（とはいえ、この資格が取れたら、Microsoft365の資格取ろうかなと思ってます笑）

学習内容について

学習教材

※別にアフィリエイトではありません。笑
最初はAWSの公式ドキュメントだけで勉強しようかなと思ったのですが、資格取得のためにどれから学習していくのがいいのか素早く理解するには本がいいかなと思い購入しました。

このサイトのソリューションアーキテクト向けAWSトレーニングの「AWS Technical Essentials」は４時間程度の動画・テキストのコースになっていて、全体の概要をまず押さえたい人は受けてみるといいと思います。
私はこれを見て、「思ったより難しくなさそう」と思ったので受験しようかなと思いました。

出題範囲

詳しくは以下リンクに公式の出題範囲が書かれてますが、結構広い。笑
対象サービスだけでA4 5ページ分でした。

https://d1.awsstatic.com/ja_JP/training-and-certification/docs-sa-assoc/AWS-Certified-Solutions-Architect-Associate_Exam-Guide.pdf

大きくは以下４分野からの出題と言うことになります。
（各分野の私のざっくり理解を書いときます）

• 第１分野：セキュアなアーキテクチャの設計
  IAMなどのアカウント、ユーザーの権限周りの理解と、その辺の運用におけるベストプラクティス（rootユーザーは多要素認証にして、普段使いしないこととか）への理解
  あとは、VPCのネットワークACLやセキュリティグループへの理解

• 第２分野：弾力性に優れたアーキテクチャの設計
  ELBやAutoScalingなどを使ったデマンドに応じたリソース拡張や可用性の高いアーキテクチャへの理解

• 第３分野：高パフォーマンスなアーキテクチャの設計
  CloudFrontやキャッシュなどのサービスを組み合わせて高パフォーマンスアーキテクチャを実現する方法

• 第４分野：コストを最適化したアーキテクチャの設計
  EC2のスポットインスタンスやリザーブドインスタンスなどの購入方法の特性と、コスト管理の方法

本日の学習内容

１．グローバルインフラストラクチャ

グローバルインフラストラクチャとは
AWSが提供するクラウドサービスを稼働させるための物理的な設備のことです。
世界中のデータセンターにAWSが用意したサーバー類が存在していて、そのデータセンター間を結ぶネットワークもこのグローバルインフラストラクチャに含むと言うことです。

リージョンとアベイラビリティゾーン
AWSで実際にサーバーを動かそうとする場合、具体的にどの地域に設置されたサーバーで動かすのかと言うことから決めて行きます。
まず”リージョン”と言う「だいたいどの辺か」と言うのを決めます。
日本だと東京リージョンと大阪リージョンが存在してます。
その次に”アベイラビリティゾーン”と言う「リージョンの中のどこのデータセンター群で動かすか」と言うのを決めます。
あくまでデータセンター”群”なので、特定のデータセンターを指定する訳ではないです。このデータセンター群は非常に強固なネットワークで繋がっており、低遅延です。

つまり、リージョンは複数のアベイラビリティゾーンで構成され、アベイラビリティゾーンは複数のデータセンターで構成されていることになります。
サーバーをどのリージョン・アベイラビリティゾーンで振り分けて稼働させるかが可用性（システムを止めずに使い続ける）を高める上で必要になるわけです。
※AWS上で仮想サーバーを稼働しても、稼働しているサーバーの設置してあるデータセンターが地震などで機能停止になった場合、仮想サーバー上に保存していたデータなどをAWSは保証してくれません。自分でうまいこと設計しないといけないわけですね。（ただし、サービスによってはリージョンに依存しないもの（S3やDynamoDBなど）はこの限りではないです）

アベイラビリティゾーンの地理的・電源的独立性
上記のような可用性を高める設計のため、複数のアベイラビリティゾーン（以下AZ）を使ってサーバーを運用（マルチAZ）することが必須になってきます。
この場合、複数のAZが同じ要因（自然災害や停電など）によって被害を受けていたらAZを分けている意味がありません。
したがってAZは地理的にも離れたところかつ、電源系統的にも分かれているところで運用されています。（例えば大阪市内と兵庫県三田市など）

２．VPC

AWSのネットワークサービスはこのVPCを中心に考えていいそうです。（本に書いてました）
VPC（Amazon Virtual Private Cloud）とは
VPCは利用者ごとにAWS上にプライベートネットワークを構築するサービスです。
例えばホームページを稼働させるにしても、Webサーバーとその裏で稼働するDBサーバーなどがあり、一般にDBサーバーはインターネットに公開したくないわけです。
このような場合、Webサーバー→アプリケーションサーバー→DBサーバーとトラフィックが流れていくのですが、この流れをプライベートネットワーク上で行うこととなります。これを実現するサービスがVPCと言うことです。

VPCのCIDRブロック
プライベートネットワークなので、プライベートIPアドレスも設定できます。
特徴としては、/16~/28までしか取れないことで、10.0.0.0のネットワークアドレスでも/8は使えないと言うことです。

サブネット
サブネットにはパブリックサブネットとプライベートサブネットがあります。これらはAWSにそういうサービスがあると言うよりは、用途に違いによってこの２つに分けられると言うものです。
上述したように、インターネットに公開するようなサーバー（Webサーバーなど）はパブリックサブネットに配置し、インターネットに公開したくないサーバー（DBサーバーなど）はプライベートサブネットに配置することになります。
この２つの違いは、直接インターネットからアクセスできるかどうか（インターネットゲートウェイに接続しているか）で分類できます。
ルートテーブル
サブネット単位にルートテーブル（仮想ルータ）を設定できます。
ルートテーブルを設定しない場合、メインルートテーブル（VPC単位に割り当て）が設定されます。
このルートテーブルは、各サブネットに１つだけです。
ネットワークACL
このルートテーブル（仮想ルータ）にはネットワークACLが割り当てられていて、サブネット単位に通信制御できます。

このネットワークACLあたりから次回以降に持ち越します。
いきなりガッツリやりすぎると続かなくなりそうなのでこの辺で。

今日のまとめ

AWSはやっぱりサービスがよくできてるなと、まだ始めたばっかりですが思っている次第です。
特に、お客さんにAWSを提案していくにあたって、お客さま課題をAWSならどうやって解決することができるかを考えるきっかけになりそうなので、資格取得も大事ですが、AWSそのものの理解を深めることは非常に有益だと感じた次第です。
３日坊主にならず、アプトプットを続けて行きたいです。