Solo vs. The Cloud: How I Engineered an AI Flood Monitor and Bypassed AWS Guardrails
Building DrainWatch, a PyTorch municipal flood monitor, took late nights and endless debugging. Here is the story of how a solo developer fought Docker, Apple Silicon architecture clashes, and AWS Service Control Policies to ship an enterprise ML pipeline to ECS Fargate.
Series: DrainWatch (2 articles)
- 1Solo vs. The Cloud: How I Engineered an AI Flood Monitor and Bypassed AWS Guardrails This article
It was 3:00 AM, and my terminal was staring back at me with a dial unix /var/run/docker.sock: connect: no such file or directory error.
For weeks, I had been working day and night as a solo developer to build DrainWatch, an AI-powered infrastructure monitoring system. Urban flooding destroys cities because municipalities only clear storm drains after they overflow. I wanted to build a proactive command center that analyzed live drone feeds, using a PyTorch Vision Transformer to perform semantic segmentation. It calculated a precise "Choke Index" - the exact ratio of solid waste to flowing water, and automatically queued dispatch alerts when occlusion hit 70%.
The machine learning engine worked. The React dashboard worked. The FastAPI backend worked. But getting it into the cloud almost broke me.
The Local Architecture Nightmare
Developing heavy machine learning pipelines on a MacBook Air M3 is incredible until you need to deploy an x86_64 Docker container to AWS. My initial builds choked. Attempting to force QEMU to emulate the architecture crashed my local daemon, and mistakenly sending 2.5 GB of raw dataset files to the Docker context caused closed-pipe tar errors. I was exhausted, isolated in the project, and fighting my own local environment.
I finally broke through the wall by completely resetting my virtualization stack. I abandoned standard Docker Desktop, installed Colima, and forced it to utilize Apple's native Rosetta 2 virtualization framework (colima start --arch x86_64 --vm-type=vz --vz-rosetta). Suddenly, my 15-minute cross-compilations for the PyTorch runtime were succeeding.
When the Cloud Says No
With the massive image finally pushed to Amazon ECR in the Sydney region, I thought the hardest part was over. I configured an AWS App Runner service for a clean, serverless deployment. I hit deploy.
AWS threw this back at me:
User is not authorized to perform: apprunner:ListServices... with an explicit deny in a service control policy.
Because I was operating in a restricted student-tier organization account, the overarching Service Control Policy (SCP) had hard-locked managed compute services. I had spent days perfectly packaging an AI application, only to be locked out of the hosting environment by a bureaucratic cloud guardrail. It was incredibly demoralizing.
The Fargate Pivot
You can't bypass an SCP, but as an engineer, you can route around it. I refused to let the project die locally.
I immediately abandoned App Runner and pivoted my entire infrastructure strategy to Amazon ECS on AWS Fargate. I manually engineered the least-privilege IAM task roles required to let a Fargate instance read from my S3 media buckets and write telemetry to my DynamoDB tables. I bypassed the managed abstractions and deployed the container directly to the raw serverless compute engine.
Waiting for that ECS task status to switch from PENDING to RUNNING was the longest three minutes of the project.
When it finally stabilized, I opened my browser and navigated to the public IP address: http://3.106.243.250:8080/health .
The JSON returned {"status": "healthy"}.
Building DrainWatch solo pushed me to my absolute limits. I learned that shipping an enterprise-grade AI system isn't just about fine-tuning a model or writing clean React components. It’s about grit. It’s about staring at architecture mismatches and IAM access denials at 3 AM, choosing not to quit, and finding another way through the cloud.
Series: DrainWatch (2 articles)
- 1Solo vs. The Cloud: How I Engineered an AI Flood Monitor and Bypassed AWS Guardrails This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article