Add support for VPC Lattice ResourceGateway and ResourceConfiguration CRDs

[AlmogEinstein]

Today, the AWS Gateway API Controller supports managing VPC Lattice service networks, services, listeners, and routes through standard Gateway API CRDs (GatewayClass, Gateway, HTTPRoute, etc.).
However, there is currently no Kubernetes-native way to manage VPC Lattice ResourceGateways and ResourceConfigurations.
These resources are required when integrating AWS services (e.g., EventBridge private API destinations, Lambda, API Gateway, Step Functions) with private workloads inside a VPC, such as services running in EKS.
Without CRD support, these resources must be created using CloudFormation, Terraform, CDK, or the console, which breaks GitOps workflows and introduces non-Kubernetes IaC dependencies.

I would like the controller to introduce Kubernetes CRDs (and corresponding reconciliation logic) for:

AWS::VpcLattice::ResourceGateway
AWS::VpcLattice::ResourceConfiguration

This would allow users to define these resources using YAML in the same way the controller already supports service networks, services, and routes.
Ideal support would include:

• CRDs that map 1:1 with the VPC Lattice ResourceGateway and ResourceConfiguration APIs

Status reporting & reconciliation

• Integration with IAM Roles for Service Accounts (IRSA)
• Ability to reference VPC IDs, subnet IDs, security groups, and target endpoints
• Ability to manage associations required for EventBridge private API destinations or other AWS service integrations

This would enable fully declarative GitOps workflows for private AWS service connectivity into EKS.

I tried using Terraform as an alternative, but it quickly resulted in circular dependencies. My IaC layer provisions the foundational infrastructure (VPCs, subnets, EKS clusters, S3 buckets, etc.), while GitOps deploys the application layer (services, Ingress objects, ALBs).

To create the VPC Lattice ResourceGateway and ResourceConfiguration in Terraform, I need to reference the ALB that is created during the GitOps application deployment. This means Terraform would have to run after the GitOps cycle, which forces a three-stage deployment pipeline instead of the two-stage workflow I have today.

This breaks the clean separation between infrastructure and application layers and complicates the deployment lifecycle, making Terraform an impractical solution for managing these Lattice resources.