Managing DNS records

[jacobwinch]

We recently made it possible for teams to manage their DNS records via code. More specifically, teams can synth the Guardian::DNS::RecordSet private resource type via a couple of constructs in @guardian/cdk.

Teams typically need to create a CNAME which points to their load balancer (or API Gateway instance) when provisioning a new application. Due to this, we initially planned to create a CNAME under the hood as part of our standard GuEc2App and GuApiLambda patterns. See #840 for an example of this implementation.

However, creating the DNS record as part of the pattern has two major drawbacks:

1. It makes migrating to @guardian/cdk considerably more complex. As the DNS record for existing applications currently points at a CloudFormed load balancer (or API Gateway instance), it doesn't truly belong to the pattern until the migration is complete. However, we need to manage the DNS record as part of the migration process.
2. It makes performing future DNS migrations more complicated. For example, if an application is created today as a lambda-backed API and we subsequently need to migrate to an EC2-backed API, or a completely different stack, then having the DNS record nested within the lambda-based pattern is likely to cause us problems.

Due to these factors, we believe that it will be simplest to manage DNS records via a standalone construct in the same template (see example). The downside of this is that teams will need to add a few lines of extra code when provisioning a new application for the first time.