Put SSM Agent's Proxy on Its Actual systemd Service
Use the agent drop-in and metadata bypass, then distinguish its connectivity from an Image Builder component's own curl request.
First identify the failed sender: SSM Agent communication or a download inside the Image Builder component. An SSH-shell export does not update the running agent.
For the regular amazon-ssm-agent systemd unit, merge the documented drop-in at /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"The HTTP endpoint can carry HTTPS destinations. When the agent may use a public intermediary for its public AWS service endpoints, the HTTP proxy list supplies candidates for these URLs; preserve the metadata bypass. Keep 169.254.169.254 direct for instance metadata; AWS also documents [fd00:ec2::254] for the IPv6 metadata endpoint.
Reload systemd and restart the actual agent unit after the change. Ubuntu snap packaging uses another unit/drop-in location, so match the installation.
If the agent works but the component's curl fails, supply that command's environment. Lowercase http_proxy matters to curl; a successful agent transaction does not establish those child-request inputs.