É possível forçar a recriação do EC2 :: Instance ou RDS :: DBInstance na amazon cloudformation?

É possível forçar a recriação de uma instância EC2 ou RDS usando pilhas de formação de nuvens?

Minha pilha fica presa em um ponto em que simplesmente destruir e criar o recurso a corrigirá, em vez disso, tive que excluir a pilha inteira para continuar trabalhando.

editar:

Esse problema me atingiu duas vezes. Primeiro, criei uma instância da AWS :: RDS :: com alguns padrões e tentei fazer o downgrade para "EngineVersion": "5.5". Mudar isso deve acontecer com alguma interrupção, mas as instâncias mysql não podem ser desclassificadas de 5.6 para 5.5, portanto a pilha foi deixada no estado UPDATE_FAILED e não consigo recriar o RDS sem um truque desagradável.

A outra ocorrência foi que eu tenho vários "AWS :: EC2 :: Instance", que baixa e executa um script a partir de "UserData", obviamente, se Y alterar o script baixado, eu preciso recriar a instância e não há como fazê-lo. Mais uma vez, uso o mesmo truque desagradável para recriar a máquina.

O truque desagradável:

Em vez de usar um grupo de dimensionamento automático de uma máquina, resolvi os dois problemas alterando a zona de disponibilidade nas propriedades ... mas me deixou com um gosto ruim

Para instâncias do EC2 suportadas por loja, um truque é adicionar um comentário ao script de dados do usuário contendo um número de versão, data ou similar e alterá-lo sempre que desejar que a instância seja recriada:

{
    "Resources" : {
        "MyEC2Instance" : {
            "Type" : "AWS::EC2::Instance",
            "Properties" : {
                // ... other properties ...
                "UserData": { 
                    "Fn::Base64" : {
                        "Fn::Join" : [ ":", [
                        "#!/bin/bash\n",
                        "# Version: 1.0\n",
                        // ... rest of user data ...
                    ]]}
            }
        }
    }
}

Qualquer alteração em UserDatafará com que a instância seja substituída (ou seja, regenerada). O comportamento do script de dados do usuário deve ser o mesmo, pois a única modificação é um comentário. Observe que isso não funciona para instâncias apoiadas pelo EBS.

Para o RDS, você pode tirar um instantâneo do banco de dados da instância atual do RDS e modificar seu modelo para usar esse instantâneo com DBSnapshotIdentifier:

{
    "Resources" : {
        "MyDB" : {
        "Type" : "AWS::RDS::DBInstance",
        "Properties" : {
            // ... other properties ...
            "DBSnapshotIdentifier": "<db snapshot ID>"
        }
    }    
}

Sempre que DBSnapshotIdentifierfor alterado, a instância do banco de dados será substituída. O uso de snapshots também permitirá que você mantenha os dados quando o snapshot foi feito. (Se você quiser limpar os dados, poderá criar um instantâneo vazio e passá-lo como entrada. Ou excluir e recriar toda a pilha do CloudFormation.)

Uma abordagem mais genérica é alterar o nome lógico do recurso. De Modificando um modelo de pilha nos documentos do CloudFormation:

Para a maioria dos recursos, alterar o nome lógico de um recurso é equivalente a excluir esse recurso e substituí-lo por um novo. Quaisquer outros recursos que dependam do recurso renomeado também precisam ser atualizados e podem fazer com que sejam substituídos. Outros recursos exigem que você atualize uma propriedade (não apenas o nome lógico) para acionar uma atualização.

Se você colocá-lo em um AutoScalingGroup, poderá editar o mínimo / máximo / padrão do AutoScalingGroup para 0 e, assim que ele começar a destruir a instância antiga, poderá colocar o mínimo / máximo / padrão em 1/1/1 e presto: nova instância.

Se o seu EC2 estiver em um AutoScalingGroup, você poderá definir a AutoScalingGroupNamepropriedade com um número de versão.

Toda vez que você alterar esse número de versão, o CFN: 1. criará um novo grupo de dimensionamento automático e ativará as instâncias desejadas 2. matará instâncias no antigo grupo de dimensionamento automático e o excluirá

Aqui está um pedaço de código da minha pilha em que eu uso essa técnica para forçar um grande número de máquinas EC2 a recriar e puxar automaticamente o novo software do S3.

AutoScalingGroup:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
        AutoScalingGroupName: !Sub "${StackName}-${ServiceName}-${ServiceVersion}"