custom domain default naming convention - make {appName} optional

[neekey]

Hi Copilot team, I've been using copilot for a while on a project setup by previous cowork, and really enjoyed it. The only little thing that is bothering me a bit is the default DNS naming convention when you add your custom domain.

I am fully aware of https://github.com/aws/copilot-cli/issues/1188 and even though now we have http.alias option, I still find it not ideal. Let me describe my use case below which I feel like is not too uncommon.

Fictional Use Case

Imagine you are developing an application called "Holly", and you have holly.com registered. Now you are gonna create a microservice architecture backend, using copilot seems to be an easy choice. You can create multiple services and mange them in different code repositories.

Say we will start will three internet facing API services (not a good realistic example but not the point here):

• account management
• reporting
• billing

it will make sense to setup the DNS for the services under service.holly.com like below:

• account.service.holly.com
• reporting.service.holly.com
• billing.service.holly.com

The Issue

now let's create an new application called holly in copilot (for a small project, i think it's very common everything is under one single application) and initiate it with custom domain service.holly.com, and creating our first environment staging by default we will get an DNS name like

• account.staging.holly.service.holly.com
• reporting.staging.service.holly.service.holly.com
• billing.staging.service.holly.service.holly.com

It's all very nice except the holly.service.holly.com part is a bit.... not ideal.

If we try to use http.alias to set alias to staging.account.service.holly.com, it comes with its limitation:

`http.alias` must match one of the following patterns:
- staging.holly.service.holly.com,
- <name>.staging.holly.service.holly.com,
- holly.service.holly.com,
- <name>.holly.service.holly.com,
- service.holly.com,
- <name>.service.holly.com
✘ execute svc deploy: deploy service account to environment staging: alias "staging.account.service.holly.com" is not supported in hosted zones managed by Copilot

Current Solution

The issue above leaves me two options:

• change my alias to account-staging.service.holly.com
• manage the DNS in route53 + manually update ALB + setup SSL certification (which is not ideal as one of the point about Copilot is the infrastructure management for me, but yeah i can try adding those into addons..)

Proposed Feature

The feature I'm proposing is an extra configuration to allow the DNS naming convention. for example, if I can change the default name generated as the following pattern (just have appName removed) I would be very happy and I dont need to do any extra work:

{serviceName}.{envName}.{domainName}

which will get me:

• account.staging.service.holly.com
• reporting.staging.service.service.holly.com
• billing.staging.service.service.holly.com

[iamhopaul123]

Hello @neekey. Yeah I agree out default naming might not fit many use cases but it was designed like that mainly because we don't want our default domains to have any chance to cause collision with the other apps. Let's say if appName is removed then it is possible that if you use the same domain to create another app, there will be a collision. However, possibly one mitigate to this is allowing users to remove appName (not by default) if that is a request by many users.

For the current workaround

manage the DNS in route53 + manually update ALB + setup SSL certification (which is not ideal as one of the point about Copilot is the infrastructure management for me, but yeah i can try adding those into addons..)

This is not recommended because any manual changes to the CFN resources could result in drift resources, which are unpredictable.

I am fully aware of https://github.com/aws/copilot-cli/issues/1188 and even though now we have http.alias option, I still find it not ideal.

Could you elaborate why #1188 is not a good fit for you?

account.service.holly.com reporting.service.holly.com billing.service.holly.com

Could you name your app to be service with domain name to be holly.com and three services account, reporting, and billing, so that they can set their aliases to be account.service.holly.com, reporting.service.holly.com, and billing.service.holly.com respectively?

[neekey]

@iamhopaul123 thanks for the respond 👍

I would love to see the appName optional setting to be implemented, but I understand it will depend on how many users are requesting it.

Your suggestion about using service as the app name, tbh might be the easiest workaround for now, i will give it some thought, main mental block in this use case the app name "service" is too generic, but which will vary a lot in real life scenarios.

for #1188 I assume we are talking about the http.alias? I was mainly talking about the limitation about it:

`http.alias` must match one of the following patterns:
- staging.holly.service.holly.com,
- <name>.staging.holly.service.holly.com,
- holly.service.holly.com,
- <name>.holly.service.holly.com,
- service.holly.com,
- <name>.service.holly.com
✘ execute svc deploy: deploy service account to environment staging: alias "staging.account.service.holly.com" is not supported in hosted zones managed by Copilot

In this case <name>.service.holly.com is allowed but <subName>.<name>.service.holly.com is not, so I cant achieve staging.account.service.holly.com (I do want to distinguish the environment difference), that's why I was thinking, I might just do account-staging.service.holly.com instead.

[iamhopaul123]

Hello @neekey. Gotcha. Sorry I was thinking about certificate import which allows users to use any alias they'd like to use. Maybe that'll be a better solution for you? Let me know your thought about it!