{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "lambda:CreateFunction",
        "lambda:GetFunction",
        "lambda:GetFunctionConfiguration",
        "lambda:InvokeFunction",
        "lambda:ListTags",
        "lambda:TagResource",
        "lambda:UntagResource",
        "lambda:UpdateFunctionCode",
        "lambda:UpdateFunctionConfiguration"
      ],
      "Resource": [
        "arn:aws:lambda:ap-northeast-1:123456789012:function:your-function-name"
      ]
    }
  ]
}

Error: failed to deploy function configuration: failed to list tags of
arn:aws:lambda:...: operation error Lambda: ListTags,
api error AccessDeniedException: User is not authorized to perform:
lambda:ListTags on resource

{
  "source": [
    "aws.medialive"
  ]
}

handlerに渡ってくるeventとcontextというオブジェクトについての補足
event: 実際に渡ってくるイベントのデータ(S3のアップデートとかKinesisのレコードとか）。
context: Lambda functionの呼び出しコンテキスト。done()というAPIを呼び出すと関数が終了するのだが、コードをちょっと追いきれてないのでとりあえず単純にreturnするだけな感じにstub化。ちなみにcontextオブジェクトのダンプは以下のとおり。done()の中で呼び出されているpostDone()は後で追ってみる。

ショートポーリングの場合、キュー内のメッセージ数が少ない(1000以下など)場合、
キュー内のメッセージ数で重み付けされたサンプル数のサーバにしか問い合わせにいかないため、
MaxNumberOfMessagesに指定した数より少ないメッセージしか返ってこず、
キュー内のメッセージ数が極めて少ない場合、メッセージが返却されないことがあるため、
繰り返しreceiveMessageを発行する必要がある。

という理解であってるんですかね？

ロングポーリングの場合はどうなんでしょうか？ 次の記述が見つかりました。
どうやらロングポーリングの場合、上記の問題は発生しないようです。

(receiveMessageのWaitTimeSecondsを1以上にすると、ロングポーリングになる)

Lambdaはコンピューティング時間で課金されるため、なるべく「待ち」の時間は減らしたいところですが、ショートポーリングで1,2件づつメッセージを処理するよりは効率が良さそうです。

ロングポーリングを利用する(これは必須。劇的にリクエスト数が改善されます)
ロングポーリングは管理画面から設定できるので簡単。
送信側はバッチリクエストを利用すると良い(SendMessageBatch)
受信側も複数メッセージを一度に受信すると良い(MaxNumberOfMessages)

具体的にエラーとなるのは、下記のような場合です：

iOSの証明書の有効期限が切れている

iOSの証明書が無効化されている。

AndroidのAPIキーのIP制限が設定されている

Androidの証明書が無効化されている

NumberOfMessagesPublished 発行されたメッセージの数。

NumberOfNotificationsDelivered 正常に配信されたメッセージの数。

NumberOfNotificationsFailed Amazon SNS が配信に失敗したメッセージの数。
このメトリクスは、Amazon SNS が Amazon SQS、電子メール、SMS、またはモバイルプッシュのエンドポイントへのメッセージ配信の試行を停止した後に適用されます。
HTTPまたはHTTPSエンドポイントに対して配信が試行されるたびに、メトリクスが1つ追加されます。
他のすべてのエンドポイントの場合、メッセージが配信されないとカウントが1増加します (試行回数に関係なく)。
HTTP エンドポイントの再試行の数は制御できます。詳細については、「HTTP/HTTPS エンドポイントに対する Amazon SNS 配信再試行ポリシーの設定」を参照してください。

aws sns create-topic --name test_20150715 --region ap-northeast-1