Audit AWS SDK usage in workflow core (RBAC/secrets/artifact stay; IaC drivers reviewed for plugin move)

[intel352]

Continuation of #617. The DO half of the SDK audit shipped in v0.52.0 (godo
gone from core). This issue tracks the AWS half.

In scope (move to workflow-plugin-aws via the same Option A force-cutover
pattern used for #617):

• module/aws_api_gateway.go
• module/cloud_account_aws.go
• module/cloud_account_aws_creds.go
• module/codebuild.go
• module/nosql_dynamodb.go
• module/pipeline_step_s3_upload.go
• module/platform_apigateway.go
• module/platform_autoscaling.go
• module/platform_dns_backends.go
• module/platform_ecs.go
• module/platform_kubernetes_kind.go
• module/platform_networking.go

Out of scope (justified non-IaC core surfaces; STAY in core):

• module/s3_storage.go — generic S3-compat artifact/blob storage (also used by non-AWS providers)
• module/iac_state_spaces.go — S3-compat state backend (also used by DO Spaces, MinIO, etc.)
• iam/aws.go (if present) — RBAC integration
• plugin/rbac/aws.go (if present) — RBAC plugin glue
• artifact/s3.go (if present) — generic S3-compat artifact storage

Goal: same as #617 — Dependabot bumps for AWS SDKs target the provider
plugin repo, not core, except for the generic S3-compat surfaces above.

[intel352]

Scope-refinement audit (post-#654 merge)

After classifying the 12 in-scope files by IaC-vs-operational, recommend splitting #653 into two phases. Phase 1 mirrors #617's force-cutover pattern cleanly; Phase 2 is a separate operational-tooling audit with no clean precedent.

Phase 1 — IaC modules + credential resolvers (RECOMMENDED for next force-cutover PR)

File	LOC	Module type	Plugin successor
module/platform_ecs.go	571	platform.ecs	infra.container_service (provider: aws)
module/platform_apigateway.go	519	platform.apigateway	infra.api_gateway (provider: aws)
module/aws_api_gateway.go	277	(duplicate of platform.apigateway)	same as above
module/platform_autoscaling.go	485	platform.autoscaling	infra.* equivalent TBD — plugin may need new resource type
module/platform_dns_backends.go	358	platform.dns (AWS backend)	infra.dns (provider: aws)
module/platform_networking.go	638	platform.networking	infra.vpc + infra.firewall (provider: aws)
module/cloud_account_aws.go	125	DO-style credential resolver	plugin owns credential broker
module/cloud_account_aws_creds.go	177	credential plumbing	plugin owns credential broker
Total (8 files)	~3150

This is the AWS analog of #617's platform.do_* deletion. workflow-plugin-aws v0.1.0 currently exposes 13 infra.* capabilities (container_service, k8s_cluster, database, cache, vpc, load_balancer, dns, registry, api_gateway, firewall, iam_role, storage, certificate); the legacy platform.* types map onto those.

Note: AWS plugin is at v0.1.0 (DO plugin was at v0.12.0 when #617 shipped). Parity is partial — Phase 1 may need to file plugin-side issues for any missing successor (notably infra.autoscaling_group for platform.autoscaling).

Phase 2 — Operational tooling using aws-sdk-go-v2 (DEFER, separate audit)

These import aws-sdk-go-v2 but are NOT IaC providers — they're runtime pipeline tools or local-dev plumbing:

File	LOC	Purpose	Disposition
module/codebuild.go	589	AWS CodeBuild orchestration (CI builds)	Move to a workflow-plugin-codebuild, OR keep as built-in runtime step ?
module/pipeline_step_s3_upload.go	228	S3 artifact upload	Probably stays in core (paired with artifact/s3.go non-IaC out-of-scope item)
module/nosql_dynamodb.go	95	DynamoDB client (registered in plugins/datastores/plugin.go)	Datastore plugin — likely stays
module/platform_kubernetes_kind.go	845	KIND (local Kubernetes-in-Docker) — NOT actual AWS infra	Wrongful inclusion in original scope; verify aws-sdk-go-v2 usage and consider whether the import is essential

The platform/providers/aws/drivers/ tree (RDS, EKS, ALB, IAM, SQS, VPC, eks_nodegroup) wasn't covered in this issue's original scope and serves IaC infra.* types directly from core. That's a separate architectural question: is platform/providers/aws/drivers/ the canonical core path (in which case plugin is redundant) or the legacy path being phased out (in which case it should also move)? Recommend filing as a separate question.

Recommendation

• Open #NEXT-PHASE-1 "Move Phase-1 AWS IaC modules to workflow-plugin-aws" — mirrors Move provider SDK dependencies out of Workflow core #617 single-PR force-cutover, but blocks on plugin parity verification (incl. potential plugin issues for missing successors).
• Open #NEXT-PHASE-2 "Audit AWS operational-tooling SDK usage in workflow core" — handles codebuild, s3_upload, dynamodb, kubernetes_kind separately.
• Open #NEXT-PHASE-3 "Disposition of platform/providers/aws/drivers/ tree" — orthogonal architectural question.

Phase 1 has the same risk/reward profile as #617 and can be executed autonomously once plugin parity is verified or filed-as-gap. Phases 2/3 need design decisions that don't map onto the #617 pattern.

Generated as part of the post-#617 autonomous AWS audit. 🤖