雑記
AWS / Azure / Googleと使ってきたけど、やっぱりAWSが一番使いやすい。
個人的には、Windowsを使っていたけれど、Azureを好きになりたかったけれど、癖が強すぎてどうにも慣れなかった。
（最新技術に対し、AWSより遅い割に、慣れたサービスを無情に切り捨てていくという悪印象がどうしても払拭できず、業務命令以外では使わなくなってしまった。まぁマイクロソフトサービスというブランドは流石に強いので会社ではメッチャ使うけど。）
Googleは、まぁとにかく利用頻度が低いので、AWS / Azureと比べたら会社での利用がほぼないから、好きだの嫌いだの言える状態にまだ至っていない・・・
会社で使うようになれば、また見解も変わるポテンシャルを秘めていると思うんだけどな。
ということで、今のところ個人的にAWSがダントツ一位で好きなクラウドサービスの座に君臨し、はや5年以上。
ただ、AWS / Azure / Googleとクラウド横断できるterraformは手放すことができず、今回もterraform利用の解説です。
（AWS CloudFomationも最近、機能を拡充していて魅力的なのだけど、AWS以外のサービスも使いたいから仕事以外では封印）
本記事でのAWSの基本構成
前書きが長くなってしまったけど、AWSは基本的にterraformでポチッと作って、サービスの動作確認にいつも時間を割いています。
terraform init
terraform apply -auto-approve
ということで今回もポチッと下記の構成を作成。
apply後のイメージ
VPC
サブネット
ルートテーブル
キーペア
EC2
#疎通確認
疎通対象
パブリックVPCにあるEC2からプライベートVPCにあるEC2へ
疎通成功パターン(SG許可)をVPC Reachabilityで確認
疎通失敗パターン(SG拒否)をVPC Reachabilityで確認
受け側のSGで止めてくれているのが可視化されてますね。
その他
この構成からの派生01
ENIのキャプチャ設定すればWireSharkの分析も出来るので、そのうち確認
この構成からの派生02
同一VPC内での疎通確認でしたが、VPCピアリングさせれば、異なるVPC間での経路も確認できますね。
VPC Reachabilityがない時期は、毎回EC2に入って疎通確認していたのので、マジありがたい。
この構成からの派生03
自宅環境から、EC2にVPN接続
EC2は作り過ぎな気もするけど、教科書通りのこの基本構成は色々なパターンにでも拡張出来る構成ですね。（最近サーバレスばかりだから久しぶりに感じました）
環境のリセット
terraform destroy -auto-approve
これで、AWS利用料も極力落としお勉強は完了と。
この円安時代、少しでもAWS利用料金を減らそうと、LocalStackに目を付けていたけれど、AWS以上に費用が掛かりそうでしたからね。
ちょっと一言
NAT GWは、作成するだけで最低1時間分の料金がかかってしまうとのこと。
（仮に5分の利用であっても、1時間分の料金がかかる）
普通に使うのであれば、なんの問題もない制約だけれど、検証として「作成→破壊」を繰り返す実験をやるときは要注意。たまーにこういう利用時間請求ではなく、1時間固定とか作った時点で課金のサービスがあるので要チェック
蛇足
個人的にAWSで好きなのは、API Gateway / Lambda / SES / Route53 / Stepfunctions / S3。
とにかくAPI GatewayとLambdaの組み合わせは最強すぎる。
SESは今までPostfix/Dovecotの組み合わせ、Route53はBindでの障害対応から開放してくれた最強サービス。
StepFunctionsは、サーバレスサービスの重鎮だし、S3はもはやあって当然の空気のような存在。
逆に
- OpenSearchは好きだったのに、ElasticSearchと何故袂を分かってしまった⋯
- Bedrockは使いたいモデルの日本リージョンでの適用遅すぎ⋯
- Connectは最強に面白いけど、個人での使い道があまり無い⋯(Asteriskで案外十分だし)
- Transcribeは、Clipto.AIで十分と
残念な点も。
SageMakerは、使おう使おうと思っているものの、使えず仕舞い。画像処理や動画処理系の仕事があったら手を出してみたいかな。