今回は自分のDjango製日記アプリをAWSにデプロイしていくが、学習のため自社アプリに近い構成を目指す

・AMI=Ubuntu
・データベース＝RDS（エンジンはPostgreSQL）
・ストレージ＝S3
・独自ドメイン＆HTTPS対応

【前提】
・Githubにソースコードが上がっている
・既にAWSアカウントを持っている



以下補足メモ

■AWSの無料範囲について
既に教科書のチュートリアルでEC2インスタンスをつくってWordpressをデプロイしているが、
これは一旦削壊した方がよいのか？
あくまで個人学習用なので、できるだけコストは下げたい。
そのため、AWSの無料枠がどんなもんだったか復習する。

　無料枠には大きく2種類ある。
　　①アカウント開設時に1年間付与される枠
　　②定常的に特定サービスにおいて毎月無料で利用できる枠
　EC2は最初の1年間は月750時間まで無料。（24時間×31日＝744時間なので、要は1か月）
　ただし、これは「アカウントごと」の無料枠なので、
　もしインスタンスが２つ起動していた場合、１つのインスタンスの無料起動時間は350時間になる
　なおRDSも月750時間まで無料で同様。
　S3については5GBのストレージと20,000件のGetリクエスト、2,000件のPutリクエストが無料枠の対象。

　➡よって、やはり既存WordPressは解体してEC2を解放するのが良さそう。
　あと、NATゲートウェイも放っておくと結構お金がかかるらしいので削除する。

それぞれの停止、削除手順について
・今回、停止・削除すべき項目
　　・Webサーバー用のEC2インスタンス（中にApache、WordPressが入っている）
　　・インターネットゲートウェイ
　　・DBサーバー用のEC2インスタンス（中にMariaDBが入っている）
　　・NATゲートウェイ
・費用状況
　マネジメントコンソール右上の「請求ダッシュボード」を確認すると、
　12月の利用量は$12.51となっている
　最初の12か月は無料なはずなのに何故か調べる
　「NATゲートウェイ$0.062 per hour　　182hour　　となっている」
　つまり1時間に7円かかっているということ
　それ以外はかかっていなかった
　ただ、現状EC2インスタンスを２つ立てているのでこのままではこちらも費用がかかってしまう
・削除する順番と注意点
　まずは1時間ごとに費用がかかっているNATゲートウェイを削除する
　　VPCメニューからNATゲートウェイメニューを開き、削除するものを選択し、アクションから削除
　　なお、もう一度通信が必要になり、NATゲートウェイを作り直すと、
　　NATゲートウェイIDも変更されるためルートテーブルも編集し直す必要があるとのこと。
　次にEC2インスタンス（DBサーバー）を削除する
　　EC2メニュー→DBサーバーを選択→アクション→インスタンスの終了
　　※もし使っていた場合、EIPの解放、紐づいているS3削除なども必要
　同様にEC2インスタンス（Webサーバー）を削除する
　次にVPCを削除する。
　　削除すると「同時削除対象」が表示された
　　　セキュリティグループ（Webサーバー用）
　　　セキュリティグループ（DBサーバー用）
　　　インターネットゲートウェイ（パブリックサブネットにアタッチしていたもの）
　　　パブリックサブネット
　　　プライベートサブネット
　最後にルートテーブルからインターネットゲートウェイ向けのルートを削除する。
　以上で完全に元の状態に戻ったと思われる


■Linuxの違いについて
Linuxにはたくさんの種類（ディストリビューション）がある。
有名なのはCentOSとUbuntu
CentOSはRed Hatからの派生
UbuntuはDebianからの派生
※教科書で選んだ「AmazonLinux2」も１つのディストリビューションであるが、操作はCentOSに近い。
コマンドも違い、たとえばパッケージ管理は、CentOSはyumコマンド、Ubuntuはaptコマンドを使う。
ちなみに世界シェアはUbuntuが一番、ついで、Debian、CentOS、となっている。
しかし日本ではCentOS、Ubuntu、Debianの順。
CentOSWindows上で仮想的にLinuxを動かすWSL2はデフォルトではubuntuがインストールされる。


◆RDSについて
教科書ではRDSは使わなかった。
RDSを使わないとどう都合が悪いのか？
ケースを考える。
　1つ目はWebサーバーとして使っているEC2インスタンス内に追加でMySQLなどを追加する方法。
　　これは可能ではあるが、Webサーバー兼DBサーバーになってしまうため、
　　アクセス数が増えた場合などにWebサーバーを複数台構成にしたいなどの際に構成が複雑になってしまう。
　2つ目はEC2を2台立てる、1台目はWebサーバー、2台目はDBサーバーとする方法。（これが教科書の方法）
　　しかしこれをすると環境構築・バックアップ・レプリケーション等の運用面で手間が増えてしまう。
　よってRDSを使うのが１つの最適解となるようだ。
・RDSの作成手順
　マネジメントコンソールのRDSメニューから「データベースの作成」
　データベースエンジンの選択
　　MySQL（無料枠あり）
　　MariaDB（無料枠あり）
　　Amazon Aurora
　　PostgreSQL（無料枠あり）
　　SQL Server
　　Oracle
　AWSは自分で開発したAmazon Auroraを推している
　次の「ユースケースの選択」はAmazon Auroraを推す画面なので、気にせず開発用（無料枠あり）で進んでOK。
　ライセンスモデルとDBエンジンのバージョンの選択
　DBインスタンスクラスの選択（無料枠はdb.t2.micro）
　「マルチAZ配置」はRDS 内部で勝手にレプリケーションしてくれて、
　障害発生時にはセカンダリに勝手に切り替わってくれるという機能だが、有料
　「DBインスタンス識別子」「マスターユーザの名前」「マスターパスワード」の入力
　「パブリックアクセシビリティ」はデフォルトでは「はい」になっている。
　 「いいえ」するとVPC外から接続ができなくなり、 セキュリティ向上になる。
　「データベースの名前」などの設定。
　最後に「データベースの作成」ボタンを押して完成。数分でステータスが「利用可能」になる。

◆S3
こちらも教科書では使われていなかった。
同様にRDSを使わないとどう都合が悪いのかを考える。
　EC2ではAmazon Elastic Block Store (Amazon EBS)という、
　EC2のローカルディスクのようにアタッチするストレージサービスもあるが、
　これは容量制限があり、価格も高い。（スピードはEBSのほうが早い）
　よって拡張性とコスパを考えると静的ファイルを保管するにはS3が１つの最適解のようだ。
・S3の作成手順
　マネジメントコンソールのS3メニューから「バケットの作成」
　バケット名、リージョンを設定
　　バケット名は重複不可
　バージョニング、サーバーアクセスのログ記録などを設定
　アクセス許可を設定
　　パブリック許可
　「バケットを作成」で完了。