If I understand this correctly, it means I can point my entire CDK project to the emulator and test a `cdk deploy`?
I'm curious just how realistic the "internal" behaviour is emulated. It's been a while (since I got my stack working and I just don't like touching it now...), but I recall it being a real pain that sometimes odd, sometimes inconsistent things happened with setup and teardown (even through Terraform), which led to long timeouts if you did things in the wrong (but seemingly valid) order.
You could try but it likely wouldn't be reliable. AWS services have a lot of undocumented business logic that fails only when you trigger the code path. Like trying to create a resource with an attribute with too many characters, or the wrong character, etc. Doesn't fail until you run that call with that specific value. This emulator doesn't contain each service's full business logic, so you won't see the error until you try the real thing.
> I'm curious just how realistic the "internal" behaviour is emulated.
It seems like some reasonable shortcuts are taken, like services reading from each other's states directly instead of using APIs [0]. But then it will go so far as to run an in-process NodeJS emulator for lambda functions, and give it a shim so the code it runs can call other emulated AWS services using the main router [1].
[0] https://app.ilograph.com/demo.ilograph.AWS%2520Emulator/Serv... [1] https://app.ilograph.com/demo.ilograph.AWS%2520Emulator/Invo...