Skip to content

Conversation

@rlymbur
Copy link
Contributor

@rlymbur rlymbur commented Sep 18, 2025

What type of PR is this?
Feature

Which issue does this PR fix:
#691

What does this PR do / Why do we need it:
This PR implements standalone VPC Lattice services that are not automatically associated with service networks. Currently, the AWS Application Networking Controller only processes routes that are always associated with a service network. This enhancement allows for decoupling of service creation and ownership from service network membership, providing more flexibility in service management scenarios.

Key changes:

  • Adds annotation-based configuration (application-networking.k8s.aws/standalone: "true") to control service network association behavior
  • Supports both Gateway-level and Route-level annotations with Route-level taking precedence
  • Maintains full backward compatibility - existing deployments continue to work unchanged
  • Surfaces VPC Lattice service ARN in route annotations for external integrations (e.g., AWS RAM sharing)

If an issue # is not available please add repro steps and logs from aws-gateway-controller showing the issue:
See issue #691 for detailed requirements and use case description. The issue requests the ability to create VPC Lattice services without automatic service network association to support scenarios where service creation and service network membership need to be managed independently.

Testing done on this change:

  • Unit tests added for annotation processing and validation logic
  • Unit tests for service model building with standalone mode detection
  • Unit tests for service manager handling of standalone services
  • Integration tests for end-to-end standalone service creation
  • Integration tests for annotation precedence and inheritance behavior
  • Integration tests for transition scenarios (standalone ↔ service network modes)

Automation added to e2e:
Yes - Integration tests have been added covering:

  • Standalone service creation and verification
  • Annotation precedence testing (Gateway vs Route level)
  • Service transition scenarios
  • Service ARN surfacing in route status

Will this PR introduce any new dependencies?:
No new dependencies. The feature uses existing Kubernetes annotations and AWS VPC Lattice APIs that are already in use by the controller.

Will this break upgrades or downgrades. Has updating a running cluster been tested?:
No breaking changes. The feature is fully backward compatible:

  • Existing routes without annotations continue to work exactly as before
  • New annotation support is additive and optional
  • Graceful handling of annotation transitions ensures no service disruption
  • Controller upgrade/downgrade scenarios have been tested

Does this PR introduce any user-facing change?:
Yes - This introduces new annotation-based configuration options for users.

Add support for standalone VPC Lattice services via annotations. Users can now create VPC Lattice services without automatic service network association by adding `application-networking.k8s.aws/standalone: "true"` annotation to Gateway or Route resources. Route-level annotations take precedence over Gateway-level annotations. VPC Lattice service ARNs are now surfaced in route annotations for external integrations. This feature is fully backward compatible and existing deployments continue to work unchanged. 

Do all end-to-end tests successfully pass when running make e2e-test?:
Yes - All existing e2e tests pass, and new integration tests for standalone functionality have been added and are passing.

Ran 110 of 110 Specs in 5485.152 seconds SUCCESS! -- 110 Passed | 0 Failed | 0 Pending | 0 Skipped --- PASS: TestIntegration (5485.16s) PASS ok github.com/aws/aws-application-networking-k8s/test/suites/integration 5486.311s 

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@rlymbur rlymbur enabled auto-merge September 18, 2025 23:05
@rlymbur rlymbur changed the title Issue/691 Support Standalone Service Creation Sep 18, 2025
@rlymbur rlymbur changed the title Support Standalone Service Creation Support Standalone Service Creation & Surface Service ARN Sep 18, 2025
@rlymbur rlymbur self-assigned this Sep 18, 2025
Copy link
Contributor

@mikestvz mikestvz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor comments

return false
}

// Trim whitespace to be more forgiving of user input
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's combine this with previous if?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, I will address this in the next revision.

pkg/k8s/utils.go Outdated
}

// Convert to lowercase for case-insensitive comparison
switch strings.ToLower(trimmed) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are we thinking for a different set of values in the future? If not why do we need a switch?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, this is overkill now. I'll simplify it.

docs/faq.md Outdated

1. **AWS RAM sharing** to share the service with other accounts/VPCs
2. **VPC peering or Transit Gateway** for network connectivity
3. **Manual service network association** in target VPCs

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. AWS RAM sharing to share the service with other accounts to associate with service networks
    2.remove VPC peering or Transit Gateway for networking connectivity. Standalone Lattice services resolve to 169.254.171.0/24, which are not routable.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have removed this wording in the latest revision.

Comment on lines +215 to +218
The controller will:
1. Remove existing service network associations
2. Keep the VPC Lattice service running
3. Update the route status

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will have to make sure that the service is removed only from the Gateway that is set to stand-alone, as the same service could belong to other Gateways that are not standlone.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added detailed steps on how to mitigate this and correctly share with RAM manually.

## Limitations

- Standalone services are not discoverable through service network DNS resolution
- Service network policies do not apply to standalone services

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

qualify that service network policies do not apply to standalone services only in the Gateways/service networks they are disconnected from. If the same service is also in a different Gateway/service network, the policies on those Gateways/service networks apply.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I clarified this in the latest revision.


- Standalone services are not discoverable through service network DNS resolution
- Service network policies do not apply to standalone services
- Cross-VPC communication requires explicit service sharing or alternative connectivity No newline at end of file

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

requires explicit service sharing and/or association with service networks.
Remove "alternate connectivity" as there is no other way to connect than through a service network

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have updated this wording.

value: /networked
backendRefs:
- name: networked-service
port: 80 No newline at end of file

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

an example of httpsroute and TLSroute would be helpful with the TLS certs and how they can be added as well the same way as a connected service.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added additional examples now.

Copy link
Contributor

@mikestvz mikestvz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@rlymbur rlymbur added this pull request to the merge queue Sep 24, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Sep 24, 2025
@rlymbur rlymbur added this pull request to the merge queue Sep 24, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Sep 24, 2025
@rlymbur rlymbur added this pull request to the merge queue Sep 24, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Sep 24, 2025
@rlymbur rlymbur added this pull request to the merge queue Sep 25, 2025
Merged via the queue into aws:main with commit 5375bad Sep 25, 2025
2 checks passed
@rlymbur rlymbur deleted the issue/691 branch September 25, 2025 23:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

3 participants