Access Denied when accessing SSR application deployed on Amplify using CDK

### Before opening, please confirm:

- [X] I have checked to see if my question is addressed in the [FAQ](https://github.com/aws-amplify/amplify-hosting/blob/master/FAQ.md).
- [X] I have [searched for duplicate or closed issues](https://github.com/aws-amplify/amplify-hosting/issues?q=is%3Aissue+).
- [X] I have read the guide for [submitting bug reports](https://github.com/aws-amplify/amplify-hosting/blob/master/CONTRIBUTING.md).
- [X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
- [X] I have removed any sensitive information from my code snippets and submission.

### App Id

N/A

### AWS Region

us-east-1

### Amplify Hosting feature

SSR

### Describe the bug

When deploying SSR applications (ver 11, 12, 13) on Amplify using CDK, after the first build is triggered and deployed we would observe Access Denied error message as below.
```

AccessDenied
Access Denied
...
...

```
One way to mitigate this issue is via navigating to "Domain Management" Page -> Click "Manage subdomains" -> Click "Save" with no changes. Similarly this could be done through AWS CLI for Amplify as well:
```
aws amplify \
update-domain-association \
--app-id \
--domain-name
```

### Expected behavior

The same behaviour does not occur while working with other Framework such as ReactJS. The expected behaviour should be that after the first build is triggered the custom domain should be able to serve the content directly.

### Reproduction steps

1. Deploy an application using below CDK python code.
```
from aws_cdk import (
# Duration,
Stack,
# aws_sqs as sqs,
aws_codecommit as codecommit,
aws_amplify_alpha as amplify,
aws_iam as iam,
aws_route53 as route53
)
import aws_cdk as cdk
import os
from constructs import Construct

class AmplifycdkStack(Stack):

def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
super().__init__(scope, construct_id, **kwargs)
self.app = self.create_app()
token_getter_domain = self.add_custom_domain()
cdk.CfnOutput(
self, "app-id", value=self.app.app_id
)
cdk.CfnOutput(
self, "domain", value=token_getter_domain
)

def create_app(self):

repo = codecommit.Repository(
self,
"AmplifyCDKNext12",
repository_name="AmplifyCDKNext12",
code=codecommit.Code.from_zip_file(
os.path.join(os.pardir, "deployment_packages/next12.zip"), "dev")
)

role = iam.Role(
self,
"amplify-role-cdk-nexttw",
assumed_by=iam.ServicePrincipal("amplify.amazonaws.com"),
description="Custom role permitting resources creation from Amplify",
)

_managed_policy = iam.ManagedPolicy.from_aws_managed_policy_name("AdministratorAccess-Amplify")
role.add_managed_policy(_managed_policy)

amplify_app = amplify.App(
self,
"cdk-amplify-next12",
source_code_provider=amplify.CodeCommitSourceCodeProvider(repository=repo),
environment_variables={'env': 'dev', 'case': 'xxxx','_LIVE_UPDATES':'[{"pkg":"next-version","type":"internal","version":"11"}]'},
role=role
)
self.branch = amplify_app.add_branch("dev", pull_request_preview=False)
self.branch.add_environment("STAGE", "dev")
return amplify_app

def add_custom_domain(self) -> str:
root_domain_name = ""
sub_domain_name = "www"
domain_name = f"{root_domain_name}"

domain = self.app.add_domain(domain_name, enable_auto_subdomain=True)
domain.map_root(self.branch)
domain.map_sub_domain(self.branch, sub_domain_name)

return domain_name
```
2. Package requirements
```
aws-cdk-lib==2.50.0
constructs>=10.0.0,<11.0.0
```
3. Navigate to Amplify Console to trigger the first build.
4. Access the application using the custom domain and the error will be reproduced.
5. To mitigate the issue we would need to perform manual operation to invoke the custom domain update API call with no changes.

### Build Settings

```yaml
default
```

### Log output

```
# Put your logs below this line

```

### Additional information

_No response_

Start with the provided CDK Python reproduction, Amplify SSR deployment, and custom-domain mapping, then compare the first-build behavior with the documented update-domain-association CLI workaround. Reproduce the AccessDenied response in us-east-1 and verify that a newly deployed SSR application serves content through its custom domain without a manual domain update.

Written by the indexing model from the issue text.