AWS официально заявляет, что CloudFront может потребоваться максимум 15 минут, чтобы включить или отключить распространение. Несмотря на то, что мы обнаружили, что это в целом верно, мы сталкивались со случаями, когда отключение рассылки занимает более 15 минут, и поэтому я рекомендовал бы, чтобы любое решение учитывало возможность того, что по какой-либо причине это может занять более 15 минут. минут, чтобы отключить распространение.
Хотя это не идеальное решение, управляемое событиями, определенно возможно сделать это в основном на основе событий. Наше решение реализовано с использованием CloudWatch, Lambda, SQS и CloudTrail. Понятно, что вы уже включили CloudTrail, но для будущих читателей, которые могут столкнуться с подобной проблемой, если вы еще этого не сделали, первым делом необходимо включить CloudTrail для входа в свою учетную запись (примечание: использование CloudTrail повлечет за собой сборы, как подробно здесь ). Как только CloudTrail включен, CloudWatch Events сможет получать события CloudFront из CloudTrail.
Теперь, когда CloudTrail включен, мы можем фактически удалить отключенный дистрибутив. В CloudWatch создайте событие CloudWatch, которое при событии UpdateDistribution из CloudFront запускает функцию Lambda, которая публикует сообщение, содержащее идентификатор распространения, в очередь задержки SQS с максимальной задержкой 15 минут (настройка на основе консоли инструкции здесь ).
Потребителем сообщения в очереди SQS является вторая лямбда-функция. При вызове эта лямбда-функция должна вызывать API CloudFront GetDistribution для предоставленного идентификатора распространения и проверять, если Distribution.DistributionConfig.Enabled === true, и если это ложно, проверять, если Distribution.Status === Deployed.
Логика может быть адаптирована к вашим конкретным потребностям или варианту использования, но отсюда потенциальный рабочий процесс мог бы просто проверить, если Distribution.DistributionConfig.Enabled === true. Если это правда, то выйдите из функции, потому что вы ожидали, что она будет отключена, но это не так, значит что-то не так; возможно, дистрибутив был повторно активирован вручную, или произошла ошибка его отключения где-то, или, может быть, UpdateDistribution API был вызван по другой причине, независимо от причины, дистрибутив не находится в ожидаемом состоянии, и мы не должны продолжать. Перед выходом из функции вы должны / можете убедиться, что это не произойдет, молча отправив сообщение SNS, чтобы уведомить администратора о том, что произошла эта ошибка.
Двигаясь дальше, если Distribution.DistributionConfig.Enabled === true возвращает false, убедитесь, что Distribution.Status === Deployed. Если это возвращает false, это будет означать, что отключение все еще InProgress, и вам нужно подождать дольше. Чтобы справиться с этим, не оставляя Lambda включенным (и не платя за это), просто опубликуйте второе сообщение в моей очереди задержки, которое снова содержит идентификатор распределения, и функция затем завершается. Лямбда сработает снова через 15 минут и повторите следующий процесс при следующем вызове.
Если проверка на Distribution.DistributionConfig.Enabled === true возвращает ложь, а Distribution.Status === Deployed возвращает истину, то распределение отключено и готово к удалению. Отсюда просто вызовите DeleteDistribution API с идентификатором распределения и ETag из GetDistribution вызова, который вы сделали в начале. Работа API выглядит примерно так: DeleteDistribution --id {distributionId} --if-match {ETag}. Если он успешно удален, вы получите 204, и все, все готово. Если есть ошибка, вы получите 4xx, который вам нужно будет обработать.