いずれも、現在のリソースの状態とコードの差分を常に管理でき、正確な実行プランを持ち、ステートを安全に維持できます。作りっぱなしでメンテナンスされなくなるコードは、限定的なシーンでしか活用できない上に負債返却の機会を失うため、採用には慎重です。考えたいと思う日々でした。使うにあたっての注意をいくつかおまけにどうぞ。クラウドによる挙動の違いIaC実行時の挙動は、IaCの実装やクラウド側のAPIにより異なります。クラウドによって挙動が変わることがあるのは、マルチクラウドをしたことがある人なら経験があるのではないでしょうか。コード未設定時の値戻らず、設定されたときの状態が残るケースが散見されます。リソースを作ると、クラウド側で設定していないことまで設定してくれます。手間がかかるという面もありますが、コードとリソースの状態が一致する要素になっていると感じます。連携方法によって変わります。ステートだけ保持してローカル実行をすることもできます。クラウド環境における設定対象とします。前回IaCを適用した状態とします。↩クラウドによる面があるのは同意するところです。何かとポータルを使う機会があります。↩6つもある理由は不明ですが、ステートがないことに由来すると考えています。読者になるこのブログについて引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。