I do like the idea of saving prompts for projects like these (Which is also where the above question is answered: "Creating an MIT-licensed wrapper around Moto that has 100% feature parity with Localstack." [0] Which (i assume) is motivated by the recent changes to Localstack's distribution model [1])
[0] https://github.com/robotocore/robotocore/blob/main/prompts/2...
[1] https://blog.localstack.cloud/the-road-ahead-for-localstack/
Digital twin to me means an additional synchronized representation of a system that I can use to interact with the underlying plant.
I think this sort of thing is still useful. I'd never attempt to build something like this without modern AI tools. This is arguably a good use case assuming you are checking your work against AWS actual.
Actual twins don't occupy the same space time on the same 4D trajectory.
For the sake of the metaphor, both should respond the same way to the same inputs. You can, for instance, run two medical lab tests using two twins in parallel and get interchangeable results.
That said, I imagine when this twin is sufficiently faithful, one could first issue state convergence commands until the digital twin mirrored the real, and then overlay an orchestrator to do things perhaps you're thinking of such as: if digital deploys of config changes work, then the same change is applied to the real.
So this is awesomely timed.