https://serverless-stack.com/ logo
#help
Title
# help
e

Erik Robertson

12/08/2021, 9:39 AM
Hello all. My setup uses two AWS accounts, one for dev (which also hosts the route53 account for our domain name) and another one for staging & production. Deployment of my API stack works fine in dev but fails in staging with the error below.
It seems you are configuring custom domains for you URL. And SST is not able to find the hosted zone "<http://dataworks.us|dataworks.us>" in your AWS Route 53 account. Please double check and make sure the zone exists, or pass in a different zone.
Which makes sense since that account doesn't host the domain. I therefore created a role on the dev account providing access to Route53 to the staging/production account and assigned that role to the user I use for deployment on staging. However that doesn't make a difference and I'm still getting that error.... Any ideas ? I would like to use dev-api.domain.name for my dev deployment (works fine) and stg-api.domain.name for staging and api.domain.name for prod.
I saw this https://serverless-stack.com/chapters/share-route-53-domains-across-aws-accounts.html but it doesn't seem to be applicable since that uses a subdomain. I might have to go that route if we don't find an alternative solution....
c

Chad (cysense)

12/08/2021, 12:03 PM
So if you're open to doing api.dev.domain.name and api.stg.domain.name what you can then do instead is create a hosted zone in each account with the relevant tld. Something like this: https://theburningmonk.com/2021/05/how-to-manage-route53-hosted-zones-in-a-multi-account-environment/
e

Erik Robertson

12/08/2021, 12:08 PM
And sticking to my original plan is not possible via the user policy I setup ? No other alternatives you can think of ?
t

thdxr

12/08/2021, 3:49 PM
Have you looked into setting NS records up?
I think that's probably what's in the article you linked. You really don't want to go the cross account route and actually try to create resources in another account. You'd have to do that with sst.Script and it gets pretty messy since cloudformation is directly managing the records
What I typically do is host things at
<account>.<http://mydomain.com|mydomain.com>
and then manually maintain dns records for public facing routes pointing at them
c

Carlos Daniel

12/08/2021, 3:58 PM
I like to host the different environments using
<environment-name>.<http://api.domain.com|api.domain.com>
, and for that, I just: • create an NS on my dev account pointing to the production account that owns the Route53 domain; • when creating the ACM for that domain on the dev account, I specify the certificate should cover `*.api.domain.com`; This way, my app should be able to create the domains like
<http://local.api.domain.com|local.api.domain.com>
,
<http://live.api.domain.com|live.api.domain.com>
, and so goes on :)
t

thdxr

12/08/2021, 4:02 PM
^ same
e

Erik Robertson

12/09/2021, 1:28 PM
FYI I followed your recommendations. All good. Thanks for the help.
c

Carlos Daniel

12/09/2021, 2:00 PM
Great!