Я нашел причину для этого, но из трассировки стека не было совершенно очевидно, что происходит.
Решение. Оказалось, что политика в роли, назначенной лямбдене разрешил действие PutObject для целевого сегмента.Я просто добавил целевую корзину в список.
То, как я это выяснил, состояло в том, чтобы поднять детализацию ведения журнала boto3.Непосредственно перед копированием я добавил следующее:
boto3.set_stream_logger('', logging.DEBUG)
Первый параметр - это обычно имя службы, но ''
интерпретируется как все службы.Моя регистрация для лямбды была настроена на сброс в журналы cloudwatch, поэтому я мог проверить их там.
Я обнаружил следующие ошибки во время CopyObject:
[DEBUG] 2018-11-20T10:20:37.981Z 4a230839-ecac-11e8-8412-7bf802a1306b ConnectionError received when sending HTTP request.
Traceback (most recent call last):
File "/var/runtime/botocore/vendored/requests/packages/urllib3/connectionpool.py", line 372, in _make_request
httplib_response = conn.getresponse(buffering=True)
TypeError: getresponse() got an unexpected keyword argument 'buffering'
During handling of the above exception, another exception occurred:
...repeated...
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/var/runtime/botocore/endpoint.py", line 222, in _get_response
proxies=self.proxies, timeout=self.timeout)
File "/var/runtime/botocore/vendored/requests/sessions.py", line 573, in send
r = adapter.send(request, **kwargs)
File "/var/runtime/botocore/vendored/requests/adapters.py", line 415, in send
raise ConnectionError(err, request=request)
botocore.vendored.requests.exceptions.ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response',))
Выглядело так, как будтосначала возникла ошибка TypeError, которая заставила меня поверить, что я мог столкнуться с несовместимостью версий пакетов между запросами и urllib3.Но оказывается, что этот путь к коду является устаревшим путем к коду, выбранному urllib3, и ожидается, что он будет использован при возникновении других сетевых ошибок (см. проблема буферизации на github ).Это была красная сельдь - это нормально.Реальная причина - это то, что спровоцировало это в первую очередь.
Я обнаружил еще несколько записей до того момента в трассировке, где соединение с конечной точкой https сегмента установилось успешно, но ответ не мог быть прочитан.Таким образом, соединение было закрыто до того, как requests
смог даже прочитать код состояния в PUT.
Я ожидал, что смогу хотя бы прочитать AccessDenied
, что облегчило бы диагностику.Другие вызовы S3 завершатся неудачно с AccessDenied
, я не уверен, почему этот вызов особенный.Возможно, это политика, которая помогает защитить общедоступные корзины.не уверен.
В любом случае, настройка разрешений исправила его.