Правило CloudWatch, которое запускается после обслуживания OpsWorks - PullRequest
Новая
       17

Правило CloudWatch, которое запускается после обслуживания OpsWorks

1 голос
/ 28 июня 2019

У меня есть экземпляр OpsWorks Puppet Enterprise, который находится в частной подсети (не намерен изменять это). Доступ к нему можно получить через Записи Route53, указывающие на частный IP-адрес экземпляров.

Во время окна обслуживания OpsWorks экземпляр обычно воссоздается, что приводит к еженедельному изменению частного IP-адреса. Чтобы компенсировать это, у меня есть лямбда, которая периодически обновляет набор записей с текущим IP.

Эта настройка работает, но мне не нравится ее подход. Я бы предпочел запускать Lambda по окончании технического обслуживания, а не периодически.

Моя идея заключалась в том, чтобы использовать событие изменения состояния экземпляра AWS OpsWorks Stacks в качестве триггера, предполагая, что воссоздание экземпляра во время обслуживания приводит к изменению его состояния на «онлайн» в какой-то момент: 

{
  "source": [
    "aws.opsworks"
  ],
  "detail-type": [
    "OpsWorks Instance State Change"
  ],
  "detail": {
    "status": [
      "online"
    ]
  }
}

Как оказалось, это событие никогда не вызывается во время обслуживания OpsWorks.

Следовательно, у кого-нибудь есть идея, какое событие можно использовать для запуска моей Lambda сразу после окна обслуживания OpsWorks?

Заранее спасибо.

...