AWS自学習環境 - [新]パソコン忘備録

AWS自学習環境

aws

本項は書きかけの記事です。正確な情報は公式サイト、公式ドキュメント、記載の参照サイトでご確認ください。

OSS(OpenSourceSoftware)を利用しています。使用期限や保守、公開期間の確約がないことに留意してください。

目次

読む

はじめに

AWSのサービスは240種類以上（2023/10月時点）。これら全て網羅するのは不可能だ。
しかし主に使われるサービスに絞れば無理、不可能という言葉を除外でき易くなる。ここで取り上げる学習方法や環境作成が高効率であるとは言い難いが、考え方の１つとして読んでいただけると幸甚である。

IAMから始める

EC2、ECR/ECS/EKS、VPC、Lambdaなどがすぐに思いつくし自社/自身のサービスを展開するにはこれらは必須だ。しかしローンチするサービスをセキュリティから守れてこそ価値あるサービスになり得る。
と考えると一番大事にしなければならないのは「IAM」だということは自明であろう。

複数のAWSアカウントを用意する

IAMの延長線上に「organization」がある。これはAWSアカウントに親子関係をつくって
　複数アカウント運用の工数削減
　セキュリティ統制
　利用料の一元管理・一括請求
などを実現することが出来るメリットを享受できる。

Organizationを個人開発や勉強に？と思うかもしれないが、もはやトレンドにあり、製品ごとに分ける、SANDBOX/DEV/STAGING/PRODUCT環境ごとに分けるといったことができ、IAMロールを切り分けておけば間違ってテストをプロダクトで公開するというヘマをすることが大幅に減らせられる。

IAM Identity Center（IdC）

AWSのSingleSignOn（SSO）のことである。
　AWSアカウントの一元管理
　ログインと認証機関の連携
　一元的な監査と強化されたセキュリティ
などを実現できるメリットがある。

こちらも個人開発や学習でもセキュリティを担保できる点でメリットはある。
個人開発ならステークホルダー（出資者や案件発注元）にSTAGINGを見せてレビューしてもらうことはあるからだ。
客先常駐（SES）なら自身だけの環境でIdCに慣れておけば、要件さえまとまっていれば、すぐに取り掛かれる。

IAM User/Gourpで管理せず、ロールで管理

一昔前はIAM User/Groupで管理をしてきた。しかしクレデンシャルを使い回したり都度発行することでクレデンシャル情報が流出したり奪取されてセキュリティ事故が発せして来た歴史がある。
ユーザーにはAssumeRoleだけ権限を与え特定の環境を使う時だけ権限移譲するという使い方もこれまで多用されてきたが、Amazonの考え方はIdCに集約するのがベストプラクティスと考えている。
これからはユーザーの発行はIdCが行うが各環境の使用権限はIAMロールがハンドリングするというやり方がベターになっていくだろう。

これから

個人や少人数開発の環境を作っていく体で話をすすめる。
しかし上記のとおり極力　OrganizationやIdCを使っていく。あくまでIAM Userは外部連携や臨時的な利用に限ってのみ作成し、開発メンバーが増えてもIAM Userは作らずIdCで管理していくことにする。

参考