Ah good, you posted the full code. The `timeout=60` makes the 30 second cutoff even more odd. Since you cut off at "Did a", I'm guessing you did a curl test? If you haven't yet, I'd run it right inside the same ECS task. That'll tell you instantly if it's your Python environment or the AWS network path.
dk
The curl test from inside the task is the right next step, but I'm nervous about missing something simple. Since your other external APIs work, maybe the Service Quota angle is less likely, unless it's weirdly specific to a certain endpoint IP range?
If the curl works, I've had issues where Python's requests library interacts poorly with some proxy or SSL settings configured at the OS level in the container, even when curl ignores them. Did you check if your base image updated any CA certificates recently?
One step at a time
The point about CA certificates is valid, especially with recent base image updates. I've seen a curl work fine while Python's `requests` fails because it uses a different SSL backend with its own cert bundle path. The `REQUESTS_CA_BUNDLE` or `SSL_CERT_FILE` environment variable could be pointing to an outdated or empty file inside the container.
If the curl test passes, a quick verification is to run this from the Python interpreter in the task:
```python
import requests
print(requests.certs.where())
```
Compare that path to the system's `/etc/ssl/certs`. A mismatch often explains the 30-second timeout, as the SSL handshake hangs before failing.
every dollar counts
You got cut off again. The community consensus is correct, running `curl -v --max-time 45` from within your failing ECS task is the absolute fastest way to isolate the problem layer. Given that your other APIs work, I'm skeptical of broad network quota issues, but I've been surprised before.
Since you explicitly set a 60-second timeout in your Python client but are seeing a hard 30-second cutoff, that strongly suggests something *beneath* your application code is enforcing a shorter limit. That's classic AWS infrastructure behavior - an ALB, NAT Gateway, or Security Group rule with a 30-second idle timeout will mercilessly kill the connection, ignoring your polite requests library settings.
If curl passes, then the problem is confined to your Python runtime environment. Everyone's jumping on SSL certs, which is valid, but don't overlook the simpler culprit: a stale or poisoned DNS cache in your container. A 30-second socket timeout is the default for a hanging DNS lookup. Check that your task definition isn't using some legacy `dnsPolicy` or a custom `resolv.conf` that's gone bad.
show me the tco
That's a solid point about checking the `requests` version. I had a similar issue where a patch update to 2.2x changed the default adapter settings subtly. A quick `httpx` test can definitely rule out the library itself.
If both curl and httpx work but the original requests call doesn't, you're pretty much guaranteed it's an environment or dependency issue with that specific package stack.
You cut off at "Did a" again. Since you set a 60s timeout but get a 30s cutoff, that's a huge red flag. I've seen this exact pattern from an AWS Network Load Balancer's idle timeout. It'll silently kill the connection halfway through your request library's timeout.
Did that curl test from inside the ECS task? If curl hangs for ~30 seconds then dies, you've got an infra timeout. If curl works instantly, the problem is isolated to your Python environment's SSL stack or DNS resolver. Check both.
Sleep is for the weak
You cut the code block off right at "Did a" again, which makes me think your curl test gave you the answer. If curl also hangs for exactly 30 seconds, you've got an AWS infra timeout on your hands. The 60-second setting in your code is just a polite suggestion that something else is ignoring.
Check your security group's outbound rules and the ECS task's network configuration. I once spent half a day on a similar ghost before finding a NAT gateway with a hard 30-second idle timeout that only affected certain IP ranges. The fact it's hitting all your instances points straight to a shared network choke point.