Hi. I just successfully created an OAC using the CDKTF via Typescript.
I starting working with OAC from this tutorial:
To add an origin access control to an S3 origin in a distribution
Open the CloudFront console at https://console.aws.amazon.com/cloudfront/v3/home.
Choose a distribution with an S3 origin that you want to add the OAC to, then choose the Origins tab.
Select the S3 origin that you want to add the OAC to, then choose Edit.
In the Origin access section, choose Origin access control settings (recommended).
In the Origin access control dropdown menu, choose the OAC that you want to use.
Choose Save changes.
I discovered the originAccessControlId field on the distribution config is used to associate the OAC with the Cloudfront Distribution.
When simply trying to migrate from OAI to OAC, like in the following,
│ Error: CloudFrontOriginAccessIdentityInUse: The CloudFront origin access identity is still being used.
│ status code: 409, request id: <redacted>
I did discover a workaround. If I do a deploy with only creating the OAC, but not using it, then I can do a follow up deploy swapping the OAI for the OAC as shown above. Unfortunately this makes for fragile work when promoting my infra to higher environments.
Yap, I am having same issue today when I am trying to migrate to OAI to OAC. I don’t think it’s related to terraform. As my perspective, AWS tried to delete OAI first then create OAC meanwhile OAI still exist and used by other resources.
##[error]│ Error: CloudFrontOriginAccessIdentityInUse: The CloudFront origin access identity is still being used.
13:21:33 [ERR] │ Error: CloudFrontOriginAccessIdentityInUse: The CloudFront origin access identity is still being used.
##[error]│ status code: 409, request id: 6b229037-f0c7-400b-8acb-6c4893ffa181
13:21:33 [ERR] │ status code: 409, request id: 6b229037-f0c7-400b-8acb-6c4893ffa181
Has there been any movement on this? We also have a Cloudfront module that I am converting to use OAC…all works great…unfortunately if I remove the OAI resource in TF and add the OAC resource to the distro it still throws that error. Strange thing though…under the hood, it actually does delete the OAI and updates the origins to use OAC… a subsequent deployment always succeeds.
I would prefer not to have to tell my customers “First deployment will throw an error but don’t worry about it…just run it again”
So at this point…I am leaning toward just leaving the original OAI resource intact and orphaned since it does not look like we would get billed for that resource just sitting around. lol
I managed to switch from an OAI to an OAC but as you mentioned, it cannot be done with a simple Terraform update. There is some temporality involved (you must first update the bucket policy to allow both OAC and OAI, then create the OAC, then update the distro to fetch data from OAC, then remove the OAI statement from the bucket policy and the OAI). Terraform unfortunately does not handle the sequentiality needed by the switch process.
I’m wondering whether to keep going with OAI or to plan my next deployment to be manual because of this.