複数の環境でSQSを共有する

Question

一部の非同期ジョブキューの信頼性を向上させるためにSQSを検討しています。私は、複数のキューや環境（ファームクラスタ、開発者サンドボックス、開発者ラップトップなど）をサポートするための最適なSQS展開戦略を特定しようとしています。私たちの以前のジョブ・キューでは、それぞれの環境ごとに独立したキュー・サーバーを使用していました。 SQSはグローバルリソースなので、セキュリティ/隔離とメンテナンスの最適な経路はまだわかりません。

さらに悪いケースでは、ジョブタイプ（レポート、ETLなど）と環境（プロダクション、デモ、開発者サンドボックスなど）のそれぞれの組み合わせを処理するために、数千の個別のSQSキューを作成する必要があると思います。 。環境ごとに単一のキューを使用できますが、それはジョブに基づいて動作を制御する能力を制限するようです。逆に、各ジョブにグローバルキューを使用することはできますが、環境を分離することは不可能です。

これはメンテナンスとセキュリティの負担に似ているようですので、他の顧客が大規模な環境やキューのペイロードタイプでSQSをうまく活用しているかと思います。

Answer 1

環境を分離するために、各環境（prod/demo/etc。）を別々のAWSアカウントに分割します。

すべてのキュー（およびその他のAWSリソース）を作成および管理するためにCloudFormationやTeraformなどを使用することをお勧めします。これにより、メンテナンスとセキュリティの負担が軽減されます。

Answer 2

マークBの回答に記載されているように、完全に別のアカウントを使用するのが適切なベストプラクティスですが、それだけではありません。同じAWSアカウントに複数の環境を設定し、異なるレベルで隔離することができます。

リソースにネーミング標準を適用する必要がある場合は、IAMを使用して、特定のアクセスキーとロールをその環境に関連付けられているリソース（例：SQSキュー）に対するアクセス権のみに制限できます。

• ETL開発
• ETL-デモ
• ETL-生産
• レポート開発
• レポートデモ
• ：

  たとえば、次のキューを持つことができます報告書作成

これらのキューにアクセスするロールに最低限の特権を適用すると、環境ごとに対応するアプリケーションのみにアクセスできるようになります。 CloudFormationを使用している場合は、リソース名の環境部分をスタックのパラメータとして指定することができます。

---

つまり、アカウントレベルで隔離すると、より強力な保証が提供されます。あなたの許容レベルのリスクとコンプライアンスポリシーに応じて、別々のアカウントを遵守する必要があるかもしれません。また、サンドボックス開発のためだけに別のアカウントを持つなど、ハイブリッドなアプローチも可能ですが、プロダクション前のリソースとプロダクションリソースを1つのアカウントにまとめておく必要があります。単一のアカウントの命名規則を使用すると、本当に鍵となり、JenkinsやCloudFormationなどのツールを使用して自動化することができます。