AWSで何らかのシステムの運用を行う場合、同等の構成による開発・ステージング環境も持ちたくなります。
単純には本番運用環境構築時の作業内容の一部（または全部）を実施することになりますが、本番運用環境との関係において考えておくべき点がいくつかあります。
今回はその辺を整理したいと思います。
なお、「開発・ステージング環境」と書くと長いので、以下では「試用環境」と表現します。
本番運用環境と試用環境の住み分け
最初に考えるべきは、どこに、どのように環境構築するかと言うことになると思います。
最も手間をかけない方法は既に存在するサーバ（EC2,RDS）に試用環境を追加していく形かと思います。
AWS以外の環境ではサーバ台数はそのまま積算的にコストに反映されますし、試用環境の利用率は本番環境と比較すればかなり低いことも考慮するとそのために別サーバを立てることはなかなか選択しづらいです。また、同じサーバ上であればLAMP（LEMP）環境として本番運用と同一の環境で試用することになりますので、試用での実績が本番運用の信頼性とより密接に関係すると言うメリットもあります。
実のところ、今まで運用してきたシステムではこの形で試用環境を持っているケースが結構多いです。
ただ、試用において何か問題がありサーバの動作に影響を与えることがあった場合、当然ながらその影響は本番運用にも及ぶことになるというデメリットがありますし、結果として試用の仕方にも制約が生じると言う問題もあります。
次に思いつくのは既存のVPC、サブネット上に別のサーバ（EC2,RDS）を立てて、それらを使用して環境構築する方法です。
先に示した同一サーバ上に環境構築する場合の裏返しで、LAMP（LEMP）環境としての同一性の保証が若干弱かったり、コストが増えると言うデメリットはありますが、試用が本番運用に与える影響はかなり軽減されます。
また、コスト面に関してはAWSの柔軟な料金体系（従量課金であるため使用方法でコスト抑制が可能）によって他のホスティング環境と比較して選択しやすくなっています。
さらに試用の影響から本番運用を切り離すことを考慮すれば、サブネットやVPCを分ける方法もあります。
一般的には物理ネットワーク内にある特定のサーバの通信量が増えれば、同ネットワーク上に属する他のサーバはその分通信し難くなります。つまりは相互に影響し合う訳です。
ただ、AWSに関してはVPCやサブネットにおける帯域（通信性能）関連の情報をあまり見たことがありません。どちらかと言えば、ネットワーク構成を考える上で重要なポイントはセキュリティや耐障害性の観点のような印象です。セキュリティ面に関してもネットワーク構成で対応すると言うよりはセキュリティグループの構成の方が重要そうなのですが。
と言うことで、実のところ効果は今一つはっきりしませんが、管理面においてVPCごと分けておくとスッキリするような印象はあります。
最後に究極（というと大袈裟ですが）の方法としては、アカウントごと分けてしまうという方法があります。
アカウント作成自体は費用が発生しませんし、請求情報はアカウント単位での管理になっていますので、コスト管理の単位でアカウントを分けるという考え方はむしろ積極的に取り入れるべきでしょう。
当然ながらVPCの構築含めて本番環境と同等のものを全て再構築する手間が発生しますが、個人的にはまだまだAWSでの環境構築に精通しているとは言えず、復習と考えれば十分実施する価値もあります。
以上のように考えた結果、特に最後のコスト管理面を考えてアカウントごと分けてしまう方法が現状は最適であると判断しました。
AWSの料金体系は細かく決まっている上に随所に従量課金があるので、ちょっとしたミスや誤解により不要なコストを掛けてしまう可能性は十分考慮しておく必要があります。その辺の確認がし易い環境構築をまずは目指したいと思います。
S3バケット
AWSにおけるネットワーク（VPCやサブネット）およびサーバ（EC2やRDS）の名称やCIDRブロック情報などはアカウントが異なれば重複しても問題ありません。しかし、S3バケット名に関してはアカウントに関わらず全バケットの中で一意である必要があります。よって、試用環境におけるバケット名は「dev-（本番環境のバケット名）」のように命名します。
なお、上記のように命名しようと思ったらその名称が既に使用されていたということも考えられます。その場合はよしなに別の名前を付けるということで。
名前解決
当該システムのドメインが「sample.com」だった場合、当然ながら本番環境に関して同ドメイン名でアクセスできるような設定を行います。
例えば当該ドメインをお名前ドットコムで取得した場合、Route53で同ドメインに対するホストゾーンを作成し、その際に指定されたネームサーバをお名前ドットコム側で当該ドメインのネームサーバとして指定し直し、改めてRoute53の当該ホストゾーンのAレコードとして「然るべきアクセス先」を指定します。この「然るべきアクセス先」はS3だったりEC2だったり、あるいはELBやCloudFrontだったりしますが。
上記状況で、試用環境を「dev.sample.com」としてアクセス可能にしたかった場合にどのような設定を行うべきかということを考えたいと思います。
DNSの仕組み上「dev.sample.com」に関しても、まずは「sample.com」のホストゾーンが参照されます。よって、こちらで試用環境側の「然るべきアクセス先」をAレコードとして登録できてしまえば話は早いのですが、本番環境（sample.com）と試用環境（dev.sample.com）はアカウントが異なるため、sample.com（本番環境）のRoute53の設定においてAレコードの「トラフィックのルーティング先」としてdev.sample.com（試用環境）のアクセス先が選択できません。
よって、「dev.sample.com」に独自のホストゾーンを持たせ、こちらで名前解決させます。
具体的には以下のような操作を行います。
- 試用環境で「dev.sample.com」のホストゾーンを作成（ここで設定されるネームサーバを記録しておく）
- 本番環境で「sample.comホストゾーン」の「dev.sample.com」に対するNSレコードとして上記で決定されたネームサーバを設定
- 試用環境で「dev.sample.comホストゾーン」のAレコードとして「然るべきアクセス先」を設定
上記のように設定することで、dev.sample.comの名前解決は「お名前ドットコム」→「sample.comホストゾーン」→「dev.sample.comホストゾーン」と引き継がれ、最終的には「dev.sample.comホストゾーン」のAレコードによって解決されることになります。
SSL証明書
本番環境構築時にCertificate ManagerでSSL証明書を取得する際にワイルドカード証明書（先の例で言えば「*.sample.com」）となるよう指定していた場合、理屈としては「dev.sample.com」にも適用できます。ただ、CloudFrontの設定画面などにおいてSSL証明書として選択できるようになるのはあくまで自アカウントで取得した証明書のみのようで、試用環境では本番環境で取得済みの証明書は選択できるようにはなりませんでした。
ありがたいことにCertificate Managerでの証明書取得は無償なので、あまり深く考えず、試用環境アカウントで「dev.sample.com」（「*.dev.sample.com」を含む）の証明証を新たに取得し、使用することにします。
総括
最初にコスト管理のためにアカウントごと環境を分けるとの方針を示しましたが、後から上げた名前解決やSSL証明書の件は同一アカウント内で環境構築した場合は考えなくても良い（もっと簡単に対処できる）内容だったかもしれません。
それが分かった上でも、やはりコスト管理のためにアカウントは分けた方がベターだと思っていますが。
なお、毎度のことながら、上記で示した方法はあくまでこのようにすれば期待していた環境を構築できるということを示したまでであって、これが最適解である保証はありません。その辺は個人的にもさらに研鑽していきたいと思います。
