📝

SQS ソースキューとデッドレターキューのアクセス権限について

に公開
AWS
SQS
tech

デッドレターキューにアクセスポリシーを定義しなくてもソースキューからデッドレターキューにメッセージが送信されました。

検証

まずは標準キューのデフォルト設定でソースキューとデッドレターキューを作成します。

ソースキュー側でデッドレターキューを設定します。

この時点ではデッドレターキューの設定はデフォルトなので以下のアクセス権限になっています。

  • キューポリシー: 以下の通り
{
  "Version": "2012-10-17",
  "Id": "__default_policy_ID",
  "Statement": [
    {
      "Sid": "__owner_statement",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::012345678901:root"
      },
      "Action": "SQS:*",
      "Resource": "arn:aws:sqs:ap-northeast-1:012345678901:dlq"
    }
  ]
}
  • 許可ポリシーの再実行: 無効

この状態でデッドレターキューにメッセージが送信されることを確認したいので、ソースキューからメッセージを送信、ポーリングします。

ただし、疑似的な処理の失敗を再現するためにポーリングは途中で停止します。
デッドレターキューの最大受信数を 2 に設定したので、再度メッセージをポーリング、停止することでデッドレターキューにメッセージが送信されます。

デッドレターキューのキューポリシーがデフォルトの状態でメッセージの送受信が可能なことを確認できました。

デッドレターキューのキューポリシーを削除した場合

続いて以下の状態で同じ検証を実施します。

  • デッドレターキューのキューポリシーを削除
  • 許可ポリシーの再実行:有効
    • キュー別でソースキューを指定

なお、上述の検証でデッドレターキューに送信されたメッセージは削除しておきました。

この状態で再度ソースキューからメッセージを送信し、ポーリングを停止して疑似的に処理を失敗させてみます。

最大受信数を超過したタイミングでデッドレターキューにメッセージが送信されました。

以上より、デッドレターキューのキューポリシーがなくても許可ポリシーの再実行でソースキューが指定されていればメッセージの送受信が可能なことがわかりました。

補足

デッドレターキューの許可ポリシーの再実行で特定のソースキューを指定した状態では、他のキューから同じデッドレターキューを指定することはできません。

InvalidParameterValueException: Value RedrivePolicy(maxReceiveCount=10, deadLetterTargetArn=arn:aws:sqs:ap-northeast-1:012345678901:dlq) for parameter RedrivePolicy is invalid. Reason: The value for the dead-letter queue's RedriveAllowPolicy attribute prevents you from completing this request.

まとめ

今回は SQS ソースキューとデッドレターキューのアクセス権限について紹介しました。
どなたかの参考になれば幸いです。

参考資料

Discussion