Happy it helped. If you have a very high throughput app (or something that logs gigantic payloads), the "logging pauses" may slow down your app in non-obvious ways. Diagnosing it the very first time took forever (I think I straced the process in the docker container and saw it was hanging on `write(1)`)
My guess is this is all due to CloudWatch logs putlogevents failures.
By default a docker container configured with awslogs runs in "blocking" mode. As logs get logged, docker will buffer them and push to CloudWatch logs frequently. In case the log stream is faster than what the buffer can absorb, stdout/stderr get blocked and then the container will freeze on the logging write call. If putlogevents is failing, buffers are probably filling up and freezing containers. I assume most of AWS uses it's own logging system, which could cause these large, intermittent failures.
If you're okay dropping logs, add something like this to the container logging definition:
USB has a built in protocol level reset that should achieve the same thing. The only change is 5V power is not cut. It's basically the same as doing an OS reboot from the peripheral's perspective.
If the USB device still doesn't respond then it means that they have some buggy firmware that requires a hard reboot to work.
For certified piston aircraft, generally yes. The engines are pretty much made by a few manufacturers based on ancient designs, and while you may get some "newer" benefits in some models, such as fuel injection (instead of carborators), or digital engine control (FADEC), they're pretty much ancient technology compared to modern engines. Most still have manual mixture control for example and very limited monitoring.
The only example in that class (sub $750k) I can think off the top of my head with a better engine is DA40 NG, which uses a modified Mercedes diesel engine.
https://aws.amazon.com/blogs/containers/preventing-log-loss-...