Notes from support-frontend migration

[nicl]

Support Frontend is a relatively simple EC2 web app that powers support.theguardian.com. The team are in the middle of migrating the app to CDK:

guardian/support-frontend#3597

Some points of friction encountered so far:

• account-readiness failed because they use a non-standard VPC identifier ('membership' rather than 'primary'). Perhaps we should output something to help here - listing /account/vpc/* params with a note?
• there are several optional params which still cause account-readiness to fail but perhaps shouldn't (should we list these as optional in the output?)
• monorepos and where to store cdk - top-level worked here
• initial CDK diff can be noisy because keys are ordered alphabetically. Can we introduce a tool to order things alphabetically in the original cfn to make subsequent comparisons easier?
• ALB was marked as a replacement because of (we think) changes to how tags are inlined in names (string vs ref)
• GuRecordSet not supported for theguardian.com/guardianapis.com, which seems right, but generally could we improve our docs on DNS approaches here?
• DNS generally feels like an area where many devs lack knowledge, which is another CDK/migration stumbling block
• Migration Guide doesn't cover CI/CD
• Dynamo read policy is missing the describetable permission, which meant we didn't use it here
• installing extra aws-cdk libraries is required for some things (e.g. @aws-cdk/aws-ec2 for instance types) but easy to install the wrong version! (i.e. must be same as cdk version, but this is non-obvious)
• parameter name clash hit a few times (VpcId, Wazuh SG?)
• could we reduce dual-stacking work by dropping the tagging requirement and just keeping the RR flag?
• remember to add (non-secret) Cfn params in RR to avoid needing a manual first deploy in PROD