feat: [PIDM-1151] create checkout front door cdn

[dylantangredi-jakala]

depends on #3475
reference PR on ecommerce -> #3427

List of changes

• created Azure Front Door CDN config for Checkout as new file

NOTE: this does not create the record A or switch DNS as we can see from the attached plan, thanks to the enable_dns_records = false variable setting in the custom_domains array.
Effective switch will happen in a dedicated PR

Motivation and context

This change in needed to migrate the checkout CDN to Azure Front Door as Microsoft CDN Classic is being deprecated by Azure.
Technical analysis -> https://pagopa.atlassian.net/wiki/x/8wCHlg
Historical notes/tests -> https://pagopa.atlassian.net/wiki/x/ngDVmg

Type of changes

• Add new resources
• Update configuration to existing resources
• Remove existing resources

Does this introduce a change to production resources with possible user impact?

• Yes, users may be impacted applying this change
• No

Impact Assessment:

• The CDN migration will replace the existing Classic CDN with Azure Front Door (effective switch will happen with a new PR)
• During the transition, there may be brief DNS propagation delays (effective switch will happen with a new PR)

Rollout plan:

• https://pagopa.atlassian.net/wiki/x/BQC2lg

Does this introduce an unwanted change on infrastructure? Check terraform plan execution result

• Yes
• No

Plan Summary: (attached below)

• Plan: 14 to add, 0 to change, 0 to destroy.

Other information

Note: the PR has not been applied yet in dev. Terraform plan has been executed and validated, but terraform apply has not been run.

• pre-commit run successful
  
  
  

NOTE: this PR is not currently applicable in DEV since the CDN Classic has been removed from the DEV environment, see Test Migrazione Atomica DEV 2026 01 29

UAT plan:

./terraform.sh plan weu-uat \
    -target="azurerm_resource_group.checkout_fe_rg" \
    -target="module.checkout_cdn" \
    -target="module.checkout_cdn_frontdoor" \
    -target="module.checkout_fe_frontdoor_web_test" \
    -out=uat_checkout_cdn.tfplan

Plan: 14 to add, 0 to change, 0 to destroy.
Saved the plan to: uat_checkout_cdn.tfplan

terraform show -no-color uat_checkout_cdn.tfplan > uat_checkout_cdn_plan_20260203.txt uat_checkout_cdn_plan_20260203.txt

---

If PR is partially applied, why? (reserved to mantainers)

[dylantangredi-jakala]

TODO: check if this azapi provider is still needed after the migration (not present in ecommerce-app).
Same for azuread and null_resource

[dylantangredi-jakala]

Edit: untouched for now

[infantesimone]

From an initial review, everything generally makes sense. However, looking at this PR, I have concerns about how we plan to handle the Prod rollout. What are the concrete steps to be executed in production?
Applying everything as-is could potentially cause downtime, so I think we should first focus on rollout plan to ensure zero downtime.

• A few points for consideration:
• Is it possible to perform the upgrade to v4 first?
• Can we create the new CDN without removing the existing one, and then switch the DNS afterward?
  Finally, we should also define a clear rollout plan.

[dylantangredi-jakala]

@infantesimone I'll try to answer here:

• Is it possible to perform the upgrade to v4 first?
• Can we create the new CDN without removing the existing one, and then switch the DNS afterward?
• Finally, we should also define a clear rollout plan.

• Yes, the dependency is one-way, in the sense that we cannot migrate to Front Door without upgrading to v4 since the cdn_frontdoor module only exists in the v4 module collection at .terraform/modules/__v4__/cdn_frontdoor, but we can upgrade the modules to v4 without necessarily migrating the CDN.
  • for convenience, I will keep this PR/branch for the CDN migration only. I will move the modules upgrade to a new PR that will branch out from main, while this one will branch out from the new one.
    EDIT: a branch with the modules upgrade was already created (thanks @pietro-tota) so I rebased this one onto it ✅
• Possibly, with more complicated steps. I will write my findings in the jira comment section for this existing task. In general it seems like we could make use of the enable_dns_records param while creating the new CDN/storage account with a different module name from the existing one. This will require a content sync in some way, from the old storage account to the new one, or deploy to both SAs during the migration period. The other option would be to modify the cdn_frontdoor module to support an existing storage account, since by default it can only work if it creates it as new during setup. rif -> (src/domains/ecommerce-app/.terraform/modules/v4/cdn_frontdoor/main.tf) there is count in the module definition so I suppose it always creates a new SA
• I will check what was the rollout plan for ecommerce, generally speaking this is high impact as I've stated in the Impact Assessment section

[pietro-tota]

@infantesimone I'll try to answer here:

• Is it possible to perform the upgrade to v4 first?
• Can we create the new CDN without removing the existing one, and then switch the DNS afterward?
• Finally, we should also define a clear rollout plan.

• Yes, the dependency is one-way, in the sense that we cannot migrate to Front Door without upgrading to v4 since the cdn_frontdoor module only exists in the v4 module collection at .terraform/modules/__v4__/cdn_frontdoor, but we can upgrade the modules to v4 without necessarily migrating the CDN.

  • for convenience, I will keep this PR/branch for the CDN migration only. I will move the modules upgrade to a new PR that will branch out from main, while this one will branch out from the new one.
    EDIT: a branch with the modules upgrade was already created (thanks @pietro-tota) so I rebased this one onto it ✅

• Possibly, with more complicated steps. I will write my findings in the jira comment section for this existing task. In general it seems like we could make use of the enable_dns_records param while creating the new CDN/storage account with a different module name from the existing one. This will require a content sync in some way, from the old storage account to the new one, or deploy to both SAs during the migration period. The other option would be to modify the cdn_frontdoor module to support an existing storage account, since by default it can only work if it creates it as new during setup. rif -> (src/domains/ecommerce-app/.terraform/modules/v4/cdn_frontdoor/main.tf) there is count in the module definition so I suppose it always creates a new SA

• I will check what was the rollout plan for ecommerce, generally speaking this is high impact as I've stated in the Impact Assessment section

An hint for the second point: keep it simple.
As suggested by @infantesimone we can create the new cnd profile (with it's own storage account etc) without custom domains association in the first place, allowing us to deploy to prod without affecting the already existing CDN profile.
Once both SA are aligned we can proceed to DNS switch to make it point to the new CDN (adding custom domains in frontdoor that point to existing dns record) in place of the old one and after checking that no more traffic is handled by the old cdn delete it altogether.

I would leave the double SA during the migration phase (each cdn with it's own sa) as it will be temporary, just for the switch phase. Checkout-fe side we can modify the deploy pipeline to allow to deploy to both the new and the old cnd profiles (see here) allowing us to update the cdn and check that it's working before the switch (using endpoint hostname)

[dylantangredi-jakala]

Following the suggestions, we now have one branch with the v4 modules upgrade -> #3475 and one branch (the one from the current PR) where a new terraform file is defined, containing the code for the Front Door CDN creation and no custom domains. This will we applied in DEV and tested soon.

A future PR will contain the code to make the actual switch and the file renaming/deletion.

[infantesimone]

Maybe https://wisp2.pagopa.gov.it and onetrust are no longer used, but to check with the team @pagopa/pagopa-team-touchpoint

[dylantangredi-jakala]

Removed wisp domain with 543020b after confirming with the team.
TODO check onetrust domains
EDIT: onetrust domains are needed for the correct scritpt loading on checkout terms page here https://github.com/pagopa/pagopa-checkout-fe/blob/1e0219051c645162e8a89eaf0690ce6320c81170/static/terms/it.html#L23

[infantesimone]

to check *.sia.eu

[dylantangredi-jakala]

Removed with 543020b after confirming with the team

[infantesimone]

not used https://acardste.vaservices.eu

[dylantangredi-jakala]

Thanks, removed with 543020b

The base branch was changed.

[dpulls]

🎉 All dependencies have been resolved !