What security problem would you be addressing with osquery that Fargate doesn't already address? If you're worried that AWS is owned up, it doesn't matter which AWS service you use.

Attacker owns my service, spawns a shell. OSQuery will tell me that a new process is running. Fargate will not tell me anything, to my knowledge.

OSQuery as a sidecar might work, if you stuff it in the container, but I doubt it can access the audit subsystem and I'm unsure if it's really been tested in that sort of environment.

I'm not concerned about container escapes or the underlying host being owned.

My take: you can run osquery in a container, but people don't, because osquery does a lot of stuff that doesn't make sense in a container environment, where you start from minimized, fine-grained control over the environment (honestly, I see a lot more productionized osquery in endpoint security than I do in serverside security). Anything you're trying to accomplish with osquery in a Fargate container, you can presumably accomplish with it or something else.

OSQuery was merely a strawman, I also mentioned the audit subsystem, but these are just implementation details.

I can not easily, in a supported fashion, track things like process executions or file interactions in a Fargate container. Maybe OSQuery could run as a sidecar, maybe auditd is actually exposed to the container, I honestly don't know.

The end result is that companies leveraging things like aws lambda or fargate are also likely giving up instrumentation that they would consider standard on EC2.

I don't think this is really controversial to say. You can absolutely justify to me that instrumentation is not worth 3rd party patch management and a nice ACL system etc.

I was thinking of this very limitation when posting the original Q. If e.g., there a RCE issue with my PHP server on Fargate, as the attacker I have a foothold and there's no monitoring inside the container as I try to move laterally. I guess the same is true with EC2 backed containers though

You can instrument the container itself (the environment in which RCE against PHP would provide an attacker).

You can't instrument the container engine or the host server, because AWS owns the security of those. But AWS will do a better job with those than you will, or at least, your whole usage of AWS is premised on that.

How often do people actually instrument their containers? I guess my original premise is wrong if you can simply set up the same monitoring inside your container

You can't do the same things; for instance, some container instrumentation schemes want an LKM to be resident, and that obviously won't work on Fargate. But you can generally accomplish the same goals.