Feature Request: Allow access to hosted zone id as environment variable in manifest.yaml files

[theswerd]

General

Allow access to the copilot hosted zone's information(id) as environment variable in manifest.yaml files

Why

I recently attached a CloudFront CDN to a Copilot S3 addon, but when I went to add the domain I ran into a problem. I could not reliably edit the hosted zone for the current environment. In the end, the only solution I had was to use an external hosted zone. This not only breaks the easy deployment of being able to run copilot deploy in a new account, but also complicates the tech stack.

I would like to be able to use the hosted zone of the environment.

How

I propose allowing users to add it as optional parameters to manifest files

HostedZoneID:
        Type: String
        Description: The id of the hosted zone this environments records are being hosted in.

[iamhopaul123]

Hello @theswerd. Actually using CloudFront would be an awesome idea and we are interested in making Copilot better integrated with CloudFront. Instead of directly modifying the hosted zone ID, would you mind to tell us what the architecture looks like and how you are using CloudFront with you services?

Also, I guess you use an Application Load Balanced Web service and could you possibly restrict CloudFront access to ALB instead of directly to the S3 addon? Thank you!

edit: seems like integrating ALB with CloudFront would only make sense if users cannot directly access to the ALB.

[theswerd]

We are using the CloudFront Directly connecting to our S3

We are using it as our http load balancer.

ourCloudfront:
        Type: AWS::CloudFront::Distribution
        Properties:
            DistributionConfig:
                Enabled: 'true'
                Aliases:
                    - !Sub '${App}-${Env}-${Name}-our.domain'
                DefaultCacheBehavior:
                    AllowedMethods:
                        - GET
                        - HEAD
                        - OPTIONS
                    ViewerProtocolPolicy: redirect-to-https
                    TargetOriginId: S3Origin
                    # Our custom cache policy
                    CachePolicyId: !Ref cloudfrontCachePolicy
                PriceClass: PriceClass_100
                Origins:
                      # Our bucket
                    - DomainName: !Sub '${App}-${Env}-${Name}-photosbucket.s3.amazonaws.com'
                      Id: S3Origin
                      S3OriginConfig:
                          OriginAccessIdentity:
                              !Join [
                                  '',
                                  [
                                      'origin-access-identity/cloudfront/',
                                      !Ref cloudfrontoriginaccessidentity
                                  ]
                              ]
                ViewerCertificate:
                    # RELIES ON EXTERNAL CERTIFICATE *.our.domain
                    AcmCertificateArn: arn:aws:acm:us-east-1:xxxxxxxx:certificate/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxx
                    SslSupportMethod: sni-only

In order to make this work we had to externally:

• [x] create an SSL certificate, as cloudformation only supports deploying resources in one region
• [x] create an external Route53 hosted zone because we cannot safely access the hosted zone created by copilot (I believe it is theoretically possible to recreate the hosted zone name with the given parameters but that strikes me as a bad idea)

While I like the idea of interfacing with ALBs they do not fit my use case, as I would prefer to route traffic directly from my S3 bucket to CloudFront.

[iamhopaul123]

related to #1313

[theswerd]

While these are somewhat related, we actually do not want to run our main ECS service through CloudFront at this point.

[iamhopaul123]

OK gotcha. Thanks for the input!

[efekarakus]

Thanks for the feature request @theswerd ! It makes a lot of sense

Out of curiosity is the S3 bucket a Copilot addon because you update the content periodically from a service? Or would you have preferred the bucket to be in a completely independent stack?

[theswerd]

The bucket is an addon. I use it for user photo storage, which are uploaded through the main service. I love the add-on structure because it allows me to store dev user information separately from production user information.

However, I would prefer it if there was a global addons folder though, because I see my database and storage addons both as general application addons rather than service ones. This is not a pressing issue for my team because we are currently running a monolith.

[efekarakus]

Awesome thanks for the clarification!