But if I was AWS, I would also say you should check your IAM against the real world, because if you don't, it's pretty easy to wreck you environment. ;)
But if I was AWS, I would also say you should check your IAM against the real world, because if you don't, it's pretty easy to wreck you environment. ;)
``` async function main(component: Input): Promise < Output > { const authCheck = await siExec.waitUntilEnd("aws", [ "sts", "get-caller-identity", "--region", "us-east-1" ]);
if (authCheck.exitCode === 0) {
return {
result: "success",
message: 'Credentials are Valid'
};
}
return {
result: "failure",
message: 'Credentials are invalid. Please check the credentials set on the secret/credentials prop!'
};
}
```There is no digital twin I’m aware of that is capable of simulating the real behavior of an EC2 instance. There are just too many variables to consider. To test instance launch and runtime behavior to a meaningful degree of certainty, you have to launch one first. And that means accepting the costs of doing that.
(I notice, too, that you appear to be executing the AWS CLI to do this. I’m not sure if that’s bad or not, but it smells a little fishy.)
Not sure if this is just pseudocode though.
With Infrasturcture, it turns out that what you need to know is "did I make a valid configuration", or "does this set of things work together". It's less about making a mock of the results, and more about simulating that the results would have the effect you think they will. So we can't tell you "will your application work on this size of instance" (although if you know that, you could encode that!) - but we can tell you if the options your setting are correct, if the AMI exists in the region, etc etc.