I'm reading Disaster Recovery of Workloads on AWS: Recovery in the Cloud. It's a great article!
I'm struggling with two issues right now: legacy one-account AWS usage and managing developer drift on a non-AWS project.
The article gave me insight into approaching the migration from one-account AWS to multi-account: Use the Pilot light strategy.
The Pilot light strategy allows you to create a replication of your infrastructure from one region to another. It recommends you use another account. Many AWS customers, including myself, created their initial infrastructure all in the main account. This strategy would also work to migrate to a separate production account using AWS Organizations. Then, after replication, the main account can be restricted to management, and the replication pipeline could transition to keep another pilot light system ready to go.
Managing developer drift is a bit harder. I like that AWS Config and Cloudformation detect configuration drift, but as a data and application architect, my issues usually arise within 3rd party applications, not AWS.
My challenge is to understand and track how developers drift on data pipeline applications and database configurations. Often developers don't recognize when they are drifting applications and do so in attempts to "just get done." Training and tighter controls can address, but both take time, patience, and diligence. A technical change monitoring approach can keep quality before the rules become developer habits.