はじめに
最初はクラウド環境をポータルなどを経由して作ることもあるとは思いますがいざ、インフラをコード化して自動化していこうとしてもなかなか始められないもしくは進まないといった場合に参考にしてください。
また、新規で作るようなときに初めに決めておくと便利そうなものをあげておきます。
普段コードを書いてる人は何気なくやっていることかもしれませんがガッツリインフラエンジニアだった人はあまりなじみがなかったりするので始める前の指標にしてください。
環境の定義
これから作るシステムの環境を決めましょう。
本番(商用)環境と開発環境はすぐ決まるが検証環境を「RC」と読んだり「ステージング」と呼んだりとチームによってあいまいになりがちなのでここで用途を決めておく。
実際にコードを使って構築する際の検証でも使用したいので特に検証環境が曖昧だと
本番環境にも影響が出ることもあるのでルールを明確にしておくようにする
命名規則
作るインフラのリソースそれぞれに付ける名前の命名規則を決めましょう。
これを決めておらず、ポータルなどいわゆる手動でリソースを作っている場合に人によって名前がバラバラで数カ月経つと用途不明のリソースが出来上がります。
（思い切って削除できればいいですが、そうといかないほうが多いように見えます）
コード化を進めていくと変数を使って環境差分を埋めていくとどうしても必要になってくるので初めに決めておきましょう。
よく使っている例としては[環境名]-[システム名]-[サービス名]などです。
クラウドのサービスによっては使える文字列に制限があるサービスもあります
ですが、その辺は臨機応変に例にある3要素が入るようにすれば大体、名前もかぶらず使えると思います。
権限
各環境に対する誰が何をしてよいかの定義をしましょう。
例えば、本番環境は運用者しか変更ができないとか開発環境は誰でもなんでも作ってよい状況にする（お金の制約はあるとは思いますが）など各チームのポリシーを決めておきます。
どこでも手動で作れてしまうとせっかくのコード化も実際の環境とコードのずれが出てきてしまいコードを使わなくなるといった事態に陥るので気を付けましょう。
コード管理
他のアプリケーションのコードと同じようにコードのバージョン管理を行う。
Gitを使うことによりシステムのアプリケーションと同様のフローで扱うことも可能になります。
具体的に例をあげると新規機能で必要になったクラウドインフラがあったとします。
検証環境でコードを作成これを検証用ブランチで管理（自分はよく「develop」ブランチとしてます）。
これを上記の環境定義で決めた検証環境で構築しアプリケーションと合わせることでテストします。このテストを合格したら本番環境用のブランチへマージします（「master」ブランチと呼んでます）。
これであれば環境差異を極力減らしテスト可能にすることで本番環境でのバグを減らす要因となります。また、同じコードを流すのでインフラ面でも本番環境構築を容易にします。
定義はドキュメント化
コードと一緒にreadmeなどを書き保存しておくことをおすすめします。
もちろん、wikiなどチームの文化に合わせてドキュメント管理していれば大丈夫です。
あまりおすすめしないのはバージョン管理されていないテキストやexcelなどのファイルです。あまり変化することはない定義ですが信頼に関わるので使わないで済むなら使わない方向が吉です。
まとめ
上記の要素が全部決まっていないと始められないというわけではありません。
ですが、インフラのコード化を進めていくうちに出てくる課題の一部です。
とくに命名規則など途中で方向修正が大変になるケースが出てくるので決められるうちに決めておくことをおすすめします。