研究開発でAWSを使うあなたに、知っておくといい4つのこと

研究開発でAWSを使うあなたに、知っておくといい4つのこと:

わたしたちサービスイノベーション部は、このアドベントカレンダーのリストのとおり、研究開発の成果を実サービスへとつなげよう！と、とがった領域に取り組む人が多い部署です。

一方でなまじリテラシーがあるがゆえに、いざ本格的にAWSを使う段になり

・ベストプラクティスを知らず突き進み、セキュリティチェックで手戻ってしまう

・用語や概念の理解があいまいなまま動かせてしまうがゆえ、想定外の動作への対処が遅れてしまう

・スクラッチでコード書いてしまうオレオレ利用となり、拡張性に乏しくなってしまう

・一度構築したら誰も再現できない、塩漬けインフラとなってしまう

といった事態も散見されるようになってきました。

とがったことをやっているだけにちょっともったいないな、と思いながら勉強の仕方のアドバイスをすることも結構あります。

そんなアドバイスの中から、いくつか感触の良かったものをピックアップしてみようと思います。

1.「AWS 不正利用」でググってみよう

初心者が特に気を付けたいのがセキュリティインシデント。

aws 不正利用 - Google 検索

ほぼ全てが 「アクセスキーが外部に漏れ、高額な仮想マシンを利用された」パターンかと思います。

高額課金が発生すれば幸か不幸か、その時点で気付けるのですが、こっそりS3からログを盗まれてしまう、なんて空恐ろしいことも起き得ます。

アクセスキー（とシークレットアクセスキー）

ユーザーを払い出すときにチェックボックスを入れると、ダウンロードできる文字列です。

AWSではほぼ全ての機能はWeb APIから利用できる、と耳にした方も多いかと思います。これらキーを用いることで、APIを通じAWSの各サービスを利用できるのですが、外部に漏れてしまうと誰もが好きにサービスを利用可能な状態になってしまいます。

• コードを書かない人には払い出さない
• ローカルには、~/.aws以外には基本書かない
• 止むを得ず出す場合（SaaS利用など）は、必要最小限に

と、思っておきましょう。大体のことはIAMロールで出来るので、そちらを利用するのが吉です。

だってローカルのdockerで開発したいし...

.awsに書いておいて、runのときに環境変数で入れる、などで対応可能です。

run.sh

docker run -it --rm \ 
  -e AWS_DEFAULT_REGION=us-west-2 \ 
  -e AWS_ACCESS_KEY_ID=$(aws --profile default configure get aws_access_key_id) \ 
  -e AWS_SECRET_ACCESS_KEY=$(aws --profile default configure get aws_secret_access_key) \ 
  -v $(pwd)/src:/work/src \ 
  eks-ope \ 
  /bin/bash 

※無論inspectされると見えちゃうので、自分のローカルでの利用をば。

AWS SDKを使っていれば勝手にホストのIAMロールを利用してくれるので、AWSで動かす時はそちらを使えば良いでしょう。もしくはECSを使うか。

くれぐれもキーを埋め込んだまま共有レジストリにPushなんてことはなさらぬよう!!

2. AWS BlackBeltを見てみよう

多分最初の頃は、AWSのドキュメント読んでみてもちょっと何いってるかわかんない、のではないかなと思います。

わたしの周りの認知度意外と（？）低かったのですが、AWSのソリューションアーキテクトの方々が開いている、オンラインセミナー（AWS Black Belt Online Seminar）のスライドが公開されています。

AWS クラウドサービス活用資料集 | AWS

セミナーを聞くのももちろん良いのですが、スライドだけでも、初めて耳にするサービスの概要やかゆいところをざっくり把握するのに役立ちます。

認定資格を撮る際の勉強の手段としてもうってつけなので、かなりおすすめです。（入社したての頃に先輩に教わって以来、お世話になりっぱなしです）

※今年からBlackBeltの文字をスライド中に閉じ込めたせいか、SEOが弱めのようです（引っかかっても2017年のものがほとんど）。この辺があまり認知されていない所以かもしれません。

3. 手を動かそう、良質なサンプルに触れよう

あるサービスを良く理解するには、とりあえず触ってみるのがイチバン。

各サービスのドキュメントにもチュートリアルが付いているが多いのですが、それらよりおすすめなのがこちらのリポジトリ。

AWS Samples · GitHub

年一のAWSのイベント、re:Inventではワークショップが数多く開かれるのですが、会場ではこのリポジトリを参照しながら進めることが多いです。

2-3時間でできる、エッセンスが凝縮された教材が揃っているので、気になるサービス名でこのリポジトリを検索すれば良いものが引っかかるかもしれません。ぜひ試してみてください。

英語なのがちょっと辛いですが・・・コピペだけでも効果あるかと思いますのでぜひ。（AWS代はかかります）

余談ではありますが今年は特にworkshopが充実していたので学習にちょうどいい素材があつまっています。このEKSのサンプルのように相当こなれた教材も提供されています。

4. Infrastructure as a Code に（いつかは）チャレンジしてみよう

最後のこれだけいつかは・・・というちょっと遠いアドバイスです。

せっかくAWS（に限らずどのクラウドでも？）を触り始めたのならCloudFormationなどの環境構築ツールにいつかはチャレンジしたいものです。

複数人が同じ環境を、素早く並列で立ち上げられる。これが出来るだけで開発の効率は大きく異なります。少人数で開発をするのであればこのメリットを活かさずに進むのは大変勿体無い事です。また、作ったきり（担当者もいなくなった）塩漬けインフラが出来上がることに抗する良い仕組みでもある、というように思います。

とはいえ実際問題として

• 最初の学習コストが大変
• 手での変更によるテンプレートとの不一致の発生
• 巨大なインフラほどテンプレートが長大化

するといった課題もあり、これさえあれば構成管理の全てがうまくいく、というものでもありませんが……ただ、前述のメリットはこれら課題を補って余りある、と思います。

「CloudFormation qiita」 で検索をかけると色々な記事ができますが、（もともととっつきづらいこともあってか）そこそこ入門者向けの記事が掛かるのでおすすめです。

JSONで記述されている記事もあるのですが、YAMLの方がコメントを書けるのでオススメです。

GitHub - awslabs/aws-cfn-template-flip: Tool for converting AWS CloudFormation templates between JSON and YAML formats.

こいつを使うと一発でJSONをYAMLに変換、かつ関数をシンプルにできるので活用すれば良いかと思います。

---

とがった話ではありませんが、これからAWSで本格的にサービスを作ろうと思っている方の参考になれば幸いです。