[New Resource]: Individually manage service enablement for an AWS Organization, aws_organizations_aws_service_access

[lorengordon]

Description

Currently, the only way to enable a service for an AWS Organization is to use the resource aws_organizations_organization, via the input aws_service_access_principals. The problem is that this model only supports exclusive management of the enabled services. That means that a single config can manage this resource and must list all of the enabled services. If different configs try to manage different services, they will separately create drift and constantly enable and disable services.

The API for this is organizations:EnableAWSServiceAccess, which actually only accepts a single service at a time. So it feels odd that aws_organizations_organization was implemented to manage all services, rather than having a separate resource that focuses on the single API call.

I do appreciate that there is a mechanism for exclusive management of the enabled services, but would also like to have a mechanism where non-exclusive management is an option. Perhaps the new "exclusive" pattern could apply here also. The logic for enabling a service would be contained in a single resource, and a separate "exclusive" resource could be used to enforce the exclusive relationship if a user desired.

This is also loosely related to #40874, making the organizations api more flexible.

Requested Resource(s) and/or Data Source(s)

• aws_organizations_aws_service_access

Potential Terraform Configuration

resource "aws_organizations_aws_service_access" "example" {
  service_principal = "iam.amazonaws.com"
}

References

• https://docs.aws.amazon.com/organizations/latest/APIReference/API_EnableAWSServiceAccess.html
• https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/organizations_organization

Would you like to implement a fix?

None

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[lorengordon]

Fwiw, I encountered this limitation of the aws_organizations_organization resource when writing a module to encapsulate the management of centralized root access. See the readme notes, plus3it/terraform-aws-tardigrade-org-centralized-root-access#1.

[philomory]

This is really important, and not just to allow splitting the management of service access across different modules or workspaces; there are also other resources within the provider that aim (actually more-or-less require) to manage service access for a single service, for example, the aws_ram_sharing_with_organization resource calls the ram:EnableSharingWithOrganization API endpoint rather than the organizations:EnableAWSServiceAccess endpoint, but, the RAM endpoint does also handle enabling service access, as well as taking other necessary steps. But this means if you want to enable RAM sharing within an organization properly, you can't have an aws_organizations_organization resource at all if you want to avoid cyclic state conflicts, which then in turn would mean you can't enable service access for any of the other services that don't have dedicated APIs of their own to do it. This is discussed in more detail in #35295.

Similar problems exist for several other services, such as Service Catalogue, and possibly also GuardDuty and SecurityHub (I haven't tried these yet but they look like they'll probably run a similar issue).