Question for Fleet team (or others with experience...
# aws
m
Question for Fleet team (or others with experience) regarding 'moving' an existing self-managed deployment on AWS to a new VPC. Context and additional info shared in this thread 🧵
Current setup Self-managed fleet deployment created using Fleet's Terraform example for AWS on github into a new VPC (also defined in the same Terraform example) Current situation and desired changes We're implementing a number of networking changes to support various VPC-to-VPC and VPN-to-VPC connectivity across VPCs and accounts in our AWS Organization using services like AWS Transit Gateway (TGW). Part of these changes includes re-deploying certain VPCs to CIDRs that confirm with our new internal IP address management strategy that avoid problems related to overlapping CIDRs between VPCs and simplifying route table rules by ensuring all VPCs in a given AWS region are within the same parent CIDR block (e.g. us-east-1 VPCs all within 10.0/16 to 10.31.0.0/16). This calls for "moving" fleet to a new VPC that's in the same account and region as our current deploy. Ask for guidance Wondering how I should go about doing this and any caveats or gotchas to be aware of. My assumption is that maybe I just need to do something along the lines of: 1. take a manual backup/snapshot of the RDS database of the existing fleet deployment 2. modify the VPC module in the fleet terraform to use the new desired CIDR 3. modify the RDS database in the fleet terraform to be created from the snapshot created earlier 4. modify the existing terraform to prevent destruction of any KMS keys or secrets created from the initial deployment and ensure they get re-used for the new deployment
Additional question: Rather than do an "in-place" replacement like the example steps I outlined above, could I just deploy a brand-new fleet deployment using the same RDS snapshot and encryption keys/secrets re-use strategy I mentioned above, run it in parallel to the original during testing, and then delete the old deployment once the new one is tested and verified to be working correctly? I'm more comfortable with an approach like this to avoid pro-longed downtime if I make a mistake when deploying the replacement environment. If this is possible, wondering whether temporarily having two fleet deployments running in parallel would break things or otherwise create problems for our existing devices under fleet management.