AzureでSTAGINGおよびPROD環境、Webアプリ、SQLデータベースなどを使用しています。現在、PRODのSQLデータベースの規模はSTAGINGよりもはるかに高くなっています。驚くことではありません。
これらのSQLリソースをSQLElastic Poolと一緒にプールすることで、お金を節約したいという誘惑があると思います。しかし、それがSTAGINGとPRODの間にカップリングを作成するのではないかと心配していますが、私の中のすべてが悲鳴を上げるのは悪い考えです。
パフォーマンス、信頼性、セキュリティなどに合理的に影響を与える可能性のある正当な欠点は何ですか?
ステージと製品を共有するための最大のプッシュバックは、家のサイバー側から来ています。 StageとProdの間に明確な線引きを示す必要がある場合は、両方にエラスティックプールを使用しないでください。それ以外には、技術的な欠点はありません。単一のDBとプールを常に組み合わせて使用できます。ほとんどの場合、エラスティックプールの方が費用効果が高くなりますが、 ドキュメント に従って次の点に注意してください。
エラスティックプールのデータベースごとの料金はありません。使用量やプールのアクティブ時間が1時間未満であるかどうかに関係なく、プールが最高のeDTUまたはvCoreに存在する時間ごとに課金されます。
N層の物理的な分離を必要とする顧客または契約の要件がある場合、これを行うことはできません。セキュリティの観点から、2つの環境を組み合わせることは非常に悪い考えです。燃えているガソリンを注ぐのに最適な方法は、コストのために経営陣が単一のプールを要求している場合、会社が2番目のプールのコストよりも価値がないことにショックを受けるということです。私は幹部がプロジェクトで$ 5-10kを削ろうとするのを見たことがあります。私はそれを彼らに呼びました。ハッキングされるのは、発生するかどうかではなく、発生するタイミングのシナリオです。あなたはそれが適切な設計でより安全になることを設計することができるだけです。この会社が5〜10万ドルで売れなかった場合、問題が発生します。セキュリティを軽視してはいけません。また、すべてのデータを公開するだけではいけないので、それが問題である場合は、なぜセキュリティを確保しようとするのでしょうか。まだの場合は、NIST 800-53 R4を参照して、セキュリティフレームワークをよく理解してください。また、CIS-CATとそのNiceスキャナーツールは、より安全になるのにも役立ちます。