TCP/IP over Amazon Cloudwatch Logs
You can’t ping an AWS Lambda function. You can’t SSH into a running function without reverse tunneling. You would never run nginx or Rails inside of a function because there’s little point — accepting an inbound TCP connection on a port like a Docker container isn’t supported by function-as-a-service (FaaS) platforms. It is possible, however, to write your own userspace networking stack and do what you want with it —including using Amazon Cloudwatch Logs (or even AWS Lambda tags) as the data link layer.
This post is about implementing TCP/IP over Amazon Cloudwatch Logs using Go, which enables you to access network services running inside of AWS Lambda functions.
It’s slow and not very useful, but it was a fun way to learn more about Linux networking and using AWS services in a way that might horrify some AWS engineering teams. I’m calling this proof-of-concept “Richard Linklayer” and published the full Github code today.
I attempted to check off all three of those things using Go. With netstack, it’s possible to do some exotic things with networking in unexpected places, no kernel hacking (i.e. writing C code) required. Any Go program with read and write access to reliable-ish bi-directional communication channel — like logs, tags or carrier pigeon — can implement full in-process TCP/IP networking. There are many AWS services that meet this criteria.
