From the SNS Developer Guide:
If Amazon SNS doesn't receive a successful response from your endpoint, it attempts to deliver the message again. This applies to all messages, including the subscription confirmation message.
Conceptually, what's happening seems like it must be something like this: one part of SNS (the part that needs your subscription to be confirmed) has essentially asked a different part of SNS (the part that delivers HTTP messages to HTTP endpoints) to deliver a message to your endpoint. In this case, it's the confirmation message.
Like any other message, the original sender doesn't get asked if a failed message should be retried -- SNS just retries it. It seems sensible that this would still hold true even if the original sender happens to be a different internal part of SNS, as in the case of subscription confirmation.
Not responding with an HTTP response code that tells SNS you got the message causes SNS to try again after a few seconds... so even if, meanwhile, you already confirmed your subscription, the part of SNS that has been tasked with delivering a message to you is unaware of that -- it only knows, from its perspective, that there's a message you apparently didn't receive, which means a retry.
A message being retried will have the same x-amz-sns-message-id: request header, each time it is retried. This gives you the ability to tell the difference between a retried message and a message that seems identical to a previous message, but is in fact a different message with the same payload.
From the same page linked above, that any response code between 200 and 499 inclusive within the allotted time is considered a successful delivery.
Make sure that your endpoint responds to the HTTP POST message from Amazon SNS with the appropriate status code. The connection will time out in 15 seconds. If your endpoint does not respond before the connection times out or if your endpoint returns a status code outside the range of 200–4xx, Amazon SNS will consider the delivery of the message as a failed attempt.
Including the 4xx status codes within the concept of "success" seems counterintuitive until you take into account the concept of what "delivery" means -- it means your endpoint did receive the message. A 4xx response suggests that your endpoint did not like the message in some way, but the message was indeed delivered. This is in contrast to a 5xx error which, in a general sense, implies that your endpoint is not -- at least as of this moment -- capable of processing the message.
This behavior also suggests another design consideration: as a failsafe against "lost" comfirmation attempts, if your application's attempt to contact the SNS endpoint to complete the confirmation fails, your application should return a 5xx error to back to SNS so that SNS will try again and the process may subsequently succeed.
200 OK) when you receive the incoming message? That would make sense -- one part of SNS has been asked to "deliver something" ... which just happens to be the confirmation the message to you. It is retrying because it thinks it failed to deliver "something." It sounds like the service isn't intentionally asking you to reconfirm, but rather it's just doing what it's supposed to do with anything it's supposed to deliver -- just like it would with normal SNS notifications -- retry -- when you don't respond with something affirmative. – Michael - sqlbot