AWS 無料利用枠で何かやってみる Day 6 〜VPC設定とEC2構築
- Day 6 で何やる？
- 参考にしたサイト／書籍は以下の通り（感謝）
- まずVPC周りを構築する
- EC2起動
- EC2にSSH接続するための設定（インターネットゲートウェイ／ルートテーブル）
- EC2にSSH接続
- 後述
Day 6 で何やる？
【再掲】ようやく、EC2建ててみます。サーバを作りたいというよりは、AWSのVPC関連の設定に重きを置いて。（Day 5で言いました。）
参考にしたサイト／書籍は以下の通り（感謝）
サイト
- (1) 【AWS VPC入門】1.VPC/Subnet - Qiita
- (2) 【AWS VPC入門】2.EC2/Internet Gateway/Route Table - Qiita
- (3) 弊社で使っているAWSリソースの命名規則を紹介します | DevelopersIO
- (4) IPアドレスの基礎知識 - Qiita
- (5) でのインスタンスのテナンシーの設定 Amazon EC2 Auto Scaling - Amazon EC2 Auto Scaling (日本語)
※(5)のAWSのサイトは自動翻訳が不十分で「Amazon EC2 Auto Scalingでのインスタンスのテナンシーの設定」が正しいです。
作業自体はほぼ(1)(2)のまんまです。ありがとうございます。
実業務で、既存のインスタンス名などネーミングルールがばらばらで嫌だなと思っていたら、(3)にてかなりいい感じのルールを見つけたので踏襲させて頂きました。標準化って大事ですよね。
書籍
- 今回もなし
まずVPC周りを構築する
AWSアカウントを作成すると、default VPC及び周辺の設定が用意されているが、とりあえず構成を理解することが目的であるため、一から作ります。
VPC設定
文章で書くと、「VPCを作成」ボタンが2回出てきて、ちょっと「お、おぅ」ってなりますね。
前述の通り、名前（Nameタグの値）は、サイト(3)に倣ってます。
CIDRブロックで、VPCに割り当てるネットワーク領域を設定する。CIDR表記については、サイト(4)を参考に。なお、今回設定した「10.0.0.0/16」は、IPアドレス数：65536 （ホストアドレス数：65534）のネットワークとなります。
無料利用枠とか関係なしに、そんなに使いません。※厳密にはこの後サブネット作るので、その範囲だと100ちょいになります。
テナンシーの詳細は以下参照。仮想サーバを物理的にどう配置するかという設定で、defaultだと物理ハードウェアを共有する設定となり、それ以外は専有となり別料金も掛かるようです。
サブネット設定
- ①：「サブネット」タグを選択
- ②：「サブネットを作成」ボタンを押す
- ③：先程作成したVPCを選択する（＝VPC内のサブネットを作る）
- ④：サブネットの設定を行う（サイト(1)に倣い、public用とprivate用を作成）
- ⑤：「サブネットを作成」ボタンを押す
文章で書くと、「サブネットを作成」ボタンが2回出てきて、ちょっと「お、おぅ」ってなりますね。
CIDRブロックで「/26」としているので、IPアドレス数：64 （ホストアドレス数：62）のネットワークとなります。
ポイントは、サブネット指定時にAZの指定がある点。
VPCは仮想環境かつ、その範囲は利用者によって規定された仮想的なネットワークとなるが、このネットワークを複数AZに跨って設定することが可能であり、この構成を「マルチAZ構成」と呼ぶ。
AWS 無料利用枠で何かやってみる Day 3 〜AWSキーワード整理 - Reverse[re:verse|re:birth] engineering
とDay 3 で何故か断言しているが、VPCにおけるマルチAZ構成は、サブネットを複数のAZに作成し、そのAZ内に冗長構成を作ることで実現するという事になるはず。
EC2起動
ようやくEC2に取りかかれます。
EC2のダッシュボードから、
- ①：「インスタンス」タグを選択
- ②：「インスタンスを起動」ボタンを押す
※起動ってイメージ湧きにくいですが、すでにあるマシンイメージを「起動」するからだと思います。 - ③：Amazon マシンイメージ(AMI)を選択（OS＋αのテンプレートですね）
【重要】無料利用枠ユーザーは「無料利用枠の対象」を選んでくださいね - ④：インスタンスタイプを選択（起動するEC2のスペックですね）
【重要】無料利用枠ユーザーは「無料利用枠の対象」を選んでくださいね - ⑤：「確認と作成」ではなく、「次のステップ」ボタンを押す
追記
一番大事な、「インスタンス詳細の設定」のキャプチャが漏れています。
ここでは、ネットワーク（つまりVPC）とサブネットの指定が必要になります！！
追記終わり
- ⑥：ストレージサイズはデフォルト8Gですが、無料利用枠は30Gまであるので必要に応じ増やします → 「次のステップ」ボタンを押す
- ⑦：インスタンス名をNameタグでつけて、「次のステップ」ボタンを押す
- ⑧：セキュリティグループを設定しますが、既存では未作成なので新規で作成します。ここは用途によって異なりますが、SSH/HTTP/HTTPSの設定を行います。（インバウンドルールのみ設定）
- SSH：ソースに「マイIP」を設定すると、現在AWSコンソールに接続している環境のグローバルIPアドレスが割当られます。ただ、このグローバルIPは固定じゃないはずなので、今後不便になりそうです。（後述）
- HTTP/HTTPSはどこからでも。
- 「確認と作成」を押します。
- ⑨：確認画面で設定確認後、「起動」を押します。 ※「起動」出てきましたね！！
- ⑩：ただ、まだ起動はせずキーペアの選択or作成を要求されます。EC2に接続するための、公開鍵（EC2に自動配置）と秘密鍵（SSH接続元のローカルに配置）となるので、新規で作成します
- ⑪：キーペア（秘密鍵、.pemファイル）をダウンロードします。 ※ssh接続に必要となります
- ⑫：「インスタンスの作成」ボタンを押す → EC2構築done!!
EC2にSSH接続するための設定（インターネットゲートウェイ／ルートテーブル）
SSH接続するには、通常インターネットを介する必要があります。一方で、VPCはあくまでAWS上の仮想ネットワークであるため、その橋渡し役の仮想ルーターであるインターネットゲートウェイを設定します。
- ①：「インターネットゲートウェイ」タグを選択
- ②：「インターネットゲートウェイの作成」ボタンを押す
- ③：インターネットゲートウェイの設定（名前だけ）を行い、「インターネットゲートウェイの作成」ボタンを押す
- ④：一覧から作成したインターネットゲートウェイを右クリックし、「VPCにアタッチ」を選択
- ⑤：先程作成したVPCを選択し、「インターネットゲートウェイのアタッチ」を押す
次に、作成したEC2がインターネット接続＝ローカルIP以外はインターネットゲートウェイを通してインターネットに接続するために設定を行います。そのためには、ルートテーブルを設定する必要があります。
- ⑥：「ルートテーブル」タグを選択
- ⑦：「ルートテーブルの作成」ボタンを押す
- ⑧：ルートテーブルの設定（名前と紐づくVPC）を行い、「作成」ボタンを押す
- ⑨：一覧から作成したルートテーブルを選択肢し、「ルートの編集」を選択
- ⑩：送信先：「0.0.0.0/0」、ターゲット：上記で設定したインターネットゲートウェイを指定し、「ルートの保存」を押す
ようやく終わりかと思いましたが、ルートテーブルはサブネットにも関連付ける必要があります。これはサブネット単位で、セキュリティ面からルーティングを変えるためと思われます。（あまり詳しくないです。）
- ⑪：「サブネット」タグを選択
- ⑫：EC2を構築したサブネットを指定し、「ルートテーブルの関連付けを編集」を押す
- ⑬：作成したルートテーブルを指定し、「保存」を押す
EC2にSSH接続
.pemを配置の上、SSH接続すると、
chmod 400 trial-dev-ec2.pem
$ ssh -i "trial-dev-ec2.pem" ec2-user@[*EC2のパブリック IPv4 アドレス（インスタンス概要で確認できます）*]
The authenticity of host '[*上記のIPアドレス*]' can't be established.
ECDSA key fingerprint is SHA256:**********************************
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[*上記のIPアドレス*]' (ECDSA) to the list of known hosts.
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-2/
[ec2-user@ip-10-0-193-21 ~]$
お疲れ様でした！！
後述
いやー、AWS触るよりブログ用の画像作ったり、理解を確認しながら文章書くのが大変でしたね。
そう考えると、 Qiitaさん(https://qiita.com/) とか、 クラスメソッドさん(https://dev.classmethod.jp/)、及び執筆者の皆さんにはマジで感謝だなとしみじみ思いました。
感謝
なお、今回の投稿内で述べた自宅PCのIP変わる問題について、Lambda使ってマイIPの変更を反映している方がいらしゃったので、紹介しておきます。面白いこと考えるな〜。
AWS 無料利用枠で何かやってみる Day 5 〜IAMユーザー作成
Day 5 で何やる？
ようやく、EC2建ててみます。サーバを作りたいというよりは、AWSのVPC関連の設定に重きを置いて。
そう意気込んだ矢先、やはりルートユーザーで進むのは邪道だと思って、IAMユーザー作ったり。
IAMユーザー作らずルートで良いかなと思いつつ、お作法に乗っ取り、IAMユーザー作成。認証認可の勉強になるしね。#AWS #AWS無料利用枠
— nabe_merchant (@nabe_merchant_r) 2021年5月8日
IAMユーザー作った後にMFA認証の設定権限がなく、以下を参考にポリシー作成して、IAMグループにアタッチ。事なきを得る。https://t.co/D2ZKVXPujv
ヘッダデザイン（ナビゲーションバー含む）や、本文のデザインが気になりHTML/CSSいじってました。
AWSの勉強進めながら、ついついHatenaブログのCSSいじりに注力してしまった。
— nabe_merchant (@nabe_merchant_r) 2021年5月8日
明日はVPC理解のためにEC2環境構築を行う。#AWS #はてなブログ
CSS3は正直全然触れた事なかったですが、なるほど面白なという感覚。
ナビゲーションバーは、実装したものの、現状のコンテンツ量では「ナビゲーションするものが無い」というナビゲートをしてくれたので良しとする。
ということで、Day 5 は、
- IAMユーザー作成
- IAMユーザーでのMFA認証（ポリシーの設定）
- EC2構築 → 時間足りなかったので、後半戦で対応します！！
とする。
参考にしたサイト／書籍は以下の通り（感謝）
サイト
- (1) AWSアカウントの作成と必ずやるべきセキュリティ対策 | Avinton Japan
- (2) IAM チュートリアル: ユーザーが自分の認証情報および MFA 設定を管理できるようにする - AWS Identity and Access Management
- (3) AWS: MFA で認証された IAM ユーザーが [My Security Credentials] (マイセキュリティ資格情報) ページで自分の認証情報を管理できるようにする - AWS Identity and Access Management
書籍
- 今回はなし
IAMユーザー作成
ルートユーザーでログイン後、IAMにてユーザーの作成を行う。 なお、ルートユーザーについては、Day 1 でも触れたが、以下を参考に設定済み。
仮想 Multi-Factor Authentication (MFA) デバイスの有効化 (コンソール) - AWS Identity and Access Management
IAMユーザー作成手順は以下の通り、まずIAMに「ユーザー」選択後、「ユーザーを追加」を押下する。
次に、実際のユーザー作成だが、ここはほぼ設定することはなく、
- ユーザー名
- アクセスの種類
- パスワード関連
となる。
アクセスの種類は、IAMユーザーのコンソール以外での利用（開発端末等からの直接接続と認識）の場合、「プログラムによるアクセス」が必要となるが、現時点で不要であること。 また必要になった際に、設定不足で利用できないことを確認するために、あえて設定しない。
パスワードに関しては、自動生成＋初回ログイン時に変更がセオリーと思われるため、デフォルト設定で進む。
ここまで楽勝と思っていたら、「アクセス許可の設定」が唐突に現れる。
ただ、Day 4 にて認証認可の予習をしている私には、少し焦った程度で、生産性への影響はなかった。
AWS 無料利用枠で何かやってみる Day 4 〜認証認可とは - Reverse/Re:verse/Re:birth engineering
アクセス許可の設定は、
- ①IAMグループへのユーザー追加：IAMグループのポリシーがユーザーに適用される
- ②既存ユーザーのコピー：任意のユーザーと同等の設定（IAMグループ及び直接アタッチされたポリシー）
- ③既存ポリシーのアタッチ：左記の通り
となり、既存ユーザーは存在しないので、①③の選択となるが、IAMグループに触れる機会なので、①を選択肢、以下の通り、VPC/EC2/RDS/S3にフルアクセス可のポリシーをアタッチしたグループを作成し、ユーザーを追加した。
確認画面のキャプチャが漏れたが作成が完了すると、以下の画面が表示される。
サインイン用のURLとユーザー名、初期パスワードが提示されるので、それに従いサインインすれば、IAMユーザーでサインインできる。ただ、焦ってこのままサインインするとルートユーザーが強制ログアウトされ、上記の画面表示も消えるので注意されたし。（※私の事例となります）
なお、ダウンロードできるcsvに、サインイン用のURLとユーザー名、初期パスワードの情報があったり、ログイン手順をメールするとおそらくサインイン用のURLとユーザー名はメールされるのではないかと思います。（初期パスワードも連携されるのかな？）
※参考サイト(1)を元に進めております。
IAMユーザーでのMFA認証（ポリシーの設定）
作成したIAMユーザーでサインイン後、ルートユーザー同様MFAでの認証を設定しようと、IAMの画面で「あなた権限無いよ〜」(意訳)と指摘され、何もできません。
厳密には「IAMUserChangePassword」のポリシーは直接アタッチされている（これはIAMユーザーのデフォルトなのかな）ので、IAMの仕組みとしては、パスワード変更しかできない状態。
従って、私は上記の参考(2)(3)を元に、専用ポリシーを作成し、IAMグループ（上記とは別）にアタッチして、ユーザーを参加させることで対応した。
ポリシーの中のAllowManageOwnVirtualMFADevice/AllowManageOwnUserMFAステートメントが、本件の中では重要なため切り出すと、
この AllowManageOwnVirtualMFADevice ステートメントにより、ユーザーは自分の仮想 MFA デバイスを作成、更新、削除できます。リソース ARN は、現在サインインしているユーザーと名前が一致する MFA デバイスにのみアクセスを許可することに注意してください。ユーザーは、各自の仮想 MFA デバイス以外の MFA デバイスを作成または削除することはできません。
この AllowManageOwnUserMFA ステートメントでは、ユーザーは自分のユーザーの仮想、U2F、またはハードウェア MFA デバイスを表示または管理できます。このステートメントのリソース ARN は、ユーザー自身の IAM ユーザーにのみアクセスを許可します。ユーザーは他のユーザーの MFA デバイスを表示または管理することはできません。
{
"Sid": "AllowManageOwnVirtualMFADevice",
"Effect": "Allow",
"Action": [
"iam:CreateVirtualMFADevice",
"iam:DeleteVirtualMFADevice"
],
"Resource": "arn:aws:iam::*:mfa/${aws:username}"
},
{
"Sid": "AllowManageOwnUserMFA",
"Effect": "Allow",
"Action": [
"iam:DeactivateMFADevice",
"iam:EnableMFADevice",
"iam:ListMFADevices",
"iam:ResyncMFADevice"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
何となく読み取れますが、AWSポリシー、奥が深いですね。
EC2構築は今晩着手しますが、ブログにまとめるのは、明日以降になりそうです。
AWS 無料利用枠で何かやってみる Day 4 〜認証認可とは
Day 4 で何やる？
ということで、Day 3での宣言通り、「AWSでの認証認可」の整理をやります。
あとは、無料枠で何するか妄想してDay 4 終えます。（まだ触らないの！？）
なお、AWSアカウント作ったのに、サービス全然使わないので、AWSから「早く使いなよ！！」ってメール来ました。
参考にしたサイト／書籍は以下の通り（感謝）
サイト
- IAM とは - AWS Identity and Access Management
- https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_compare-resource-policies.html
- 【図解/AWS】初心者にも分かりやすいIAM入門～ロールとグループとポリシーの違い,設計・設定手順について～ | SEの道標
- AWS IAMポリシーを理解する | DevelopersIO
書籍
- AWS認定資格試験テキスト AWS認定ソリューションアーキテクト - アソシエイト 改訂第2版 www.amazon.co.jp
AWSキーワードの整理と学習 続き
AWSでの認証認可
IAMユーザーはAWSアカウント(root)で作成できるユーザーアカウント（認証）。このユーザーにポリシーと呼ばれるAWSサービスの操作権限をアタッチすることで、IAMユーザーがサービス利用を認可される。
IAMユーザーを束ねる概念としてIAMグループがあり、グループへのユーザー追加はもちろん、グループにポリシーをアタッチすることで、グループ内のユーザーへの認可も可能となる。
上記と同様に、AWSサービスに対しても他のAWSサービスを操作させるためのポリシーをアタッチすることが可能で、その際は操作する側のAWSサービスにIAMロールを設定し、ポリシーをアタッチする。
ここまでが、「ユーザーベースのポリシー」で、種類としては - AWS管理ポリシー：AWSが提供する汎用的なポリシー - カスタマー管理ポリシー：ユーザーが定義するポリシー（再利用可能） - インラインポリシー：個別作成するポリシー がある。
ユーザーベースのポリシーとは別に「リソースベースのポリシー」があるが、この理解が若干ややこしい。ここではわかる範囲で記載するが、今後AWSを利用して誤解があった場合は訂正する。
ユーザーベースが操作する主体に付与するのに対して、リソースベースは操作される側に付与する。従って、リソースベースのポリシーは〇〇にどの操作を許可するという記述になる。（であっているかな？）
図を書いた方が良いが、参考リンクの焼き回し感で出るので控えます。
無料利用枠で何するか
ようやく無料利用枠の開始。
使いたいサービス（サイト記載の順）は
あとは、機械学習とIOT系はどんなものかは試してみたいな。
「何を作る」というよりは「AWSとは何か」を探っていき、作りたいものを考えることにする。
AWS 無料利用枠で何かやってみる Day 3 〜AWSキーワード整理
Day 3 で何やる？
ということで、Day 2での宣言通り、AWSキーワードの整理と学習をやります。
とはいえ、完璧の学習するとなると、どんどんAWS触るタイミングが遠ざかるというか、熱量無くなるので、今日だけ取り組んで、後は適宜学習していきます。 個別サービスについては実際に使う際に整理するとして、共通の概念を抑えていきたいと思う。
なお、AWSのリファレンスガイドにある用語集を真剣に読もうとすると、読んでる内に浦島太郎状態になりそうなので、そっ閉じ。（※キーワードを元に公式の解説を読むには良いと思います。）
参考にしたサイト／書籍は以下の通り（感謝）
サイト
- AWS初心者がインフラ設計/構築を理解するために、まず最初におさえるべきキーワード15選 - Qiita
- AWS用語解説 - Qiita
- AWS サービスがどこにあるのかまとめ - Qiita
- VPC のセキュリティグループ - Amazon Virtual Private Cloud
- Amazon EC2 セキュリティグループ - Qiita
- 【AWS IAMとは？】初心者にもわかりやすく解説 | WafCharm（ワフチャーム） - AIによるAWS / Azure WAFのルール自動運用サービス
- AWS IAMポリシーを理解する | DevelopersIO
書籍
- AWS認定資格試験テキスト AWS認定ソリューションアーキテクト - アソシエイト 改訂第2版 www.amazon.co.jp
AWSキーワードの整理と学習
RegionとAZ:Availability Zone
RegionとAZ(:Availability Zone)は仮想の話ではなく、物理（地理）的拠点の話。
例えば、Regionはアメリカ北カリフォルニアや、中国北京や、日本東京。構築するサービスがどこからアクセスがあるかなどを検討した上で、Region選択することで通信効率は上がるが、Regionによって提供サービスやコストは異なる。また、Regionは完全に独立しているため、複数Region上で同一（というか共同）の仮想環境は構築できないと思われる。
AZはRegion内のデータセンターで、各AZは地理的・電源的に独立しているが、AZ間は高速なネットワーク回線が引かれているのでAZ間のネットワーク遅延は気にする必要はなさそう。
世界規模の何かを企んでいない限りは、Region選択は日本で良いと思われる。可用性に関しては、マルチAZ構成で担保できるが、この観点はVPCの説明が必要になる。
VPCとマルチAZ
VPCとはVirtual Private Cloudのこと。正直言う、「Cは何か知らなかった。プライベートな何かとは理解していたが...。」
AWS上に利用者が作る仮想環境（ユーザークラウド環境のような感じかな）が、VPCとなる。
では、VPCを作らないと基本的にAWSのサービスを利用できないかと言うとそういう訳ではなく、サービスによって
- グローバルサービス
- リージョンサービス
- AZサービス
があり、AZサービスがVPC内に構成するサービスになっている認識。対象はEC2やRDS、ネットワーク等なのサービスというよりは、仮想環境（インスタンス）構築のイメージ。
VPCは仮想環境かつ、その範囲は利用者によって規定された仮想的なネットワークとなるが、このネットワークを複数AZに跨って設定することが可能であり、この構成を「マルチAZ構成」と呼ぶ。
とは言え、複数AZのそれぞれに仮想環境を構築したからといって、可用性に繋がる訳ではなく、例えばEC2で構築したサーバをマルチAZ構成にしているのであれば、インターネットゲートウェイ(IGW)の設定にて、冗長化や障害時復旧を実現する必要がある。なお、IGWはリージョンサービスとなるため、単一AZ障害には巻き込まれないという寸法となっている。
サブネットやルートテーブル、セキュリティグループなどなどネットワーク周りも整理すべきだが、ここは机上だけだと混乱するので、実際の構築と合わせて知識を整理する。
と言いつつセキュリティグループ
セキュリティグループはVPC内のインスタンスの仮想ファイアウォールの役割となる。インバウンドはデフォルトが拒否なので、セキュリティグループは必要分の許可設定が必要で、アウトバウンドがデフォルトが許可なので、不要分を削除する必要がある。
インスタンス単位ではなく、サブネット単位のファイアウォール機能もあり、ネットワークアクセスコントロールリスト (ACL) がその役割となる。
AWSでの認証認可
AWSでは、認証認可を「IAM：Identity and Access Management」が行う、、、、ん。概要がつかめたが整理が間に合わないので、Day 4で対応する！！
ん？いつになったらAWSのサービス触るのか！？
AWS 無料利用枠で何かやってみる Day 2
- Day 2 で何やる？
- AWS 無料利用枠使用状況アラートをオプトインする
- AWS Budgetsで念の為のコスト監視（コスト予算設定）を行う
- ちゃんと勉強したいAWSキーワード（Day 3以降の学習ネタ）
Day 2 で何やる？
ということで、このあたりやります。
- 無料利用枠死守のための設定
- 業務では分かった振りしてなんとなく使っているキーワードを洗い出す（Day 3以降の学習ネタ）
AWS 無料利用枠使用状況アラートをオプトインする
以下の情報に従うと、
AWS無料利用枠使用状況アラートにより、 では、その月の使用量が 85% を超えたときに からAWS通知を受け取ることができます。
とのこと。
ということで早速設定（ついでにAWSコンソールのリージョン変更）
該当サービスは「無料利用枠の使用アラートを受信する」をチェックして、設定の保存をすればOK。
ついでに「E メールで PDF 版請求書を受け取る」もチェックして、受動的にもコスト確認可能としておく。
AWS Budgetsで念の為のコスト監視（コスト予算設定）を行う
「AWS無料利用枠使用状況アラート」のドキュメントをさらっと読んだが、あくまで「無料枠」を対象としたアラートと読み取れるため、無料枠対象外に関しては誤って利用（そんな想定はない）した際に、どうなるの？という疑問がある。
従って、AWS Budgetsで予算設定することで、コスト監視を念の為行う。
方法については、以下を参照して実施した。というか、アラートの設定も以下が詳しい。ありがとう、Qiita!!
あとこちらも参考にさせて頂きました。
ちゃんと勉強したいAWSキーワード（Day 3以降の学習ネタ）
ロールとポリシーは、正直言われるがままに設定している感じなので、きちんと抑えたい。
あと、AWS内のネットワーク周りも分かってない。 VPCはともかく、エンドポイントは要するに物理NWでは何なのか。みたいな。
そう、つまり何も分かっていない、ことが分かったことがこのセクションの収穫！！
そんなこんなで、調べているとまたQiitaに出くわす。
Qiita最高だな！！ 次回以降は、基礎的な勉強結果のまとめ（参考にしたサイトと、理解のサマリー）を綴る。
ん？いつになったらAWSのサービス触るのか！？
Reverse/Re:verse/Re:birth
AWSの勉強を始めるにあたって、ブログに記録を残そうと思い、Hatena Blogさんで開始した。
ブログのタイトルは
Reverse/Re:verse/Re:birth engineering
reverse ：世にあるProductを観察し、engineeringを再学習し、
re:verse：再び、様々な技術・知識・思考を導入し、
re:birth ：再び、engineerになる。
30代半ば、ITエンジニア
久しぶりにコーディングする機会を得て、エンジニアリング再始動という感じで、ブログを綴れば良いかと。
なお、noteもやっていたりする。正確には再開した、が正しいか。
Hatena Blogは、エンジニアnabe_merchantとしての記事を残していきたいと思う。
エンジニアとしての「技術・知識・思考」に関連する内容だ。
noteは必然とその他となる。Twitterもやっているが、、、、控えておこう。あれはマルチバースの話だ。
ん？その内容なら、Qittaのほうが良くね？と思ったそこのあなた！！
確かにそうなんじゃないか...と思いつつも、Qittaはハードル高いわ〜と思いつつも、Hatena Blogの中でQittaのリンクめちゃめちゃ貼りたおして、re:birthしたいと思います。
AWS 無料利用枠で何かやってみる Day 1
「AWS 無料利用枠で何かやってみる」って、ナニソレ？
業務でようやく、AWSを使うチーム/PJTに配属されたので、すでに社用アカウントでは触り出しているのだが、「ゼロから自分」でということで、AWS無料枠を使って、具体的にAWSのサービスを触ってみることとする。
漂う今更感...ええーーーい！！そんなものは漂っていない！！！
AWS無料利用枠については、以下を参照してください。
Day 1 で何やる？
Day 1 としては、とりあえずアカウント作成と今後のプランとタスクを整理する。
アカウント作成
アカウント作成は、上記のリンクの以下の「まずは無料で始める」ボタンを押下して進むだけ。
途中で、決済方法を求められて、「えっ無料枠じゃないの」って感じになる...けど
当然、無料枠のことは調査済みです。上記サイトを引用すると下記の通り。（※2021/05/01時点の情報となります。）
- 12 か月間無料:
これらの無料利用枠は、AWS の新規のお客様のみが対象であり、AWS にサインアップした日から 12 か月間ご利用いただけます。12 か月間の無料利用の有効期限が切れた場合、またはアプリケーション使用量が無料利用枠を超えた場合は、標準の料金、つまり従量制料金をお支払いください (価格の詳細については、各サービスのページをご覧ください)。ご利用にあたっての条件が適用されます。詳細については、提供規約をご覧ください。
- 常に無料:
これらの無料利用枠は、12 か月間の AWS 無料利用枠の期間が終了しても自動的に期限切れにはなりません。既存および新規の AWS のお客様のいずれも、無期限にご利用いただけます。
- トライアル:
これらの無料利用枠は、最初に利用した時点から開始する短期間の無料トライアルです。トライアル期間が終了すると、標準の料金、つまり従量制料金をお支払いください (価格の詳細については、各サービスのページをご覧ください)。
つまり、
- 12ヶ月無料のサービスについては、本日2021年5月1日を起点として、12ヶ月間使えるが、各サービスの無料上限があり、超えると課金！！
- 例：Amazon EC2 750 時間/月、Amazon S3 5 GB など
- 常に無料のサービスについては、期間制限なし、各サービスの無料上限があり、超えると課金！！
- 例：Amazon DynamoDB 25 GB、AWS Lambda 100 万/月の無料リクエスト など
- トライアルは各サービス利用から、それぞれのサービスで規定されている期間＆上限の範囲内は無料、超えると課金！！
- 例：Amazon Redshift 2 か月（1 か月あたり 750 時間の dc2.large 使用量が 2 か月間無料） など
と話がそれたので戻す。
アカウント作成は、登録ページが促す通り、そのまま入力してください。雑な説明ですが、下手に補足する必要はないです。最後の方にSMS認証があるので、日本を指定して携帯電話番号入れて認証を完了させる。
アカウント作成の直後にやるべきこと
作成したアカウントは、ルートユーザーとなる。
AWSアカウントは、ルートユーザーとIAMユーザーがあるが、そのあたりの詳細は以下。
AWS アカウントのルートユーザー 認証情報と IAM ユーザー認証情報 - AWS 全般的なリファレンスdocs.aws.amazon.com
適切なアクセス許可を持つ IAM ユーザーを使用して、タスクを実行し、AWS リソースにアクセスすることをお勧めします。ただし、アカウントの ルートユーザー としてサインインした場合にのみ、以下に示すタスクを実行できます。
とあるので、本当はIAMユーザー作って、AWS触ったほうがいいのだが、個人＆まだ何のサービス触るかも決めてないので、IAMユーザー作っても都度リソースの割当...めん...ということでとりあえずルートのまま進める。
ただし、かなり強力なユーザーで、アカウント乗っ取りとか怖過ぎので、MFA（多要素認証）を設定する。
設定方法は以下の「AWS アカウントの root ユーザーの仮想 MFA デバイスを有効にする」を参照。
仮想 Multi-Factor Authentication (MFA) デバイスの有効化 (コンソール) - AWS Identity and Access Managementdocs.aws.amazon.com
なお、認証アプリは「Google Authenticator」を利用。
Day 2 以降 で何やる？
業務で利用しているのは、 - API Gateway - Lambda - RDS - DynamoDB など。このあたりは、お膳立てなしで環境準備などできるようになりたいなと。
次に、上記をServerless Frameworkでdeploy可能になり、最終的にはCode系からリリースする方法を理解する感じかな。
いや、業務で出来ているならいいのでは？という点はあるが、ポイントは「ゼロから自分」。
あとは、SQSとかGlueは触って置きたい。EC2はどうしようか。
なお、可能な限り無料枠は超えたくないので、利用状況やコスト発生状況を見極めるために、「AWS Budgets」の勉強が最優先！！
AWS Budgets（設定した予算のしきい値を超えるとアラートを発信）| AWSaws.amazon.com
編集後記
- ブログの名前ダサい。今晩なんとかする
- テンプレートもうちょい横広いか、文字小さくしたい。今晩なんとかする
- noteとの棲み分けは....。今晩なんとかする
- 技術系のみこのブログ使うイメージ
- もろもろ、今晩なんとかする！！
