Coloque o proxy do SSM Agent no serviço systemd real
Use o drop-in do agente e o desvio de metadata e depois distinga a conectividade dele da própria requisição curl de um componente do Image Builder.
Primeiro identifique o emissor que falha: a comunicação do SSM Agent ou um download dentro do componente do Image Builder. Uma exportação por shell SSH não atualiza o agente em execução.
Para a unidade systemd normal amazon-ssm-agent, combine o drop-in documentado em /etc/systemd/system/amazon-ssm-agent.service.d/override.conf:
[Service]
Environment="http_proxy=http://proxy.example:8080"
Environment="https_proxy=http://proxy.example:8080"
Environment="no_proxy=169.254.169.254"O endpoint HTTP pode transportar destinos HTTPS. Quando o agente pode usar um intermediário público para os seus endpoints públicos de serviço da AWS, a lista de proxies HTTP fornece candidatos para esses URLs; preserve o desvio de metadata. Mantenha 169.254.169.254 direto para os metadados da instância; a AWS também documenta [fd00:ec2::254] para o endpoint de metadados IPv6.
Recarregue o systemd e reinicie a unidade real do agente após a alteração. O empacotamento snap do Ubuntu usa outro local de unidade/drop-in, então ajuste-se à instalação.
Se o agente funciona mas o curl do componente falha, forneça o ambiente desse comando. As minúsculas http_proxy importam para o curl; uma transação bem-sucedida do agente não estabelece essas entradas da requisição filha.