(bedrock): agent alias v2
Describe the feature
The current agent alias is not working as expected.
The expected behaviour for an agent alias when updated is the following:
- You update Agent → A new version is created → The alias is updated
- However there is no Construct/API available to create an agent version (JS API).
- This differs from other resources like Prompts, Guardrails, or Flows that have their own construct to create a new version. For Agent Aliases, the creation of a new version is tied to creation of a new alias.
- There is CreateFlowVersion, CreatePromptVersion, CreateGuardrailVersion. There is even a DeleteAgentVersion but there is no API to create an Agent version :interrobang:
- In the console it is possible to “edit” an alias and create a new version and update it in place.
- This differs from other resources like Prompts, Guardrails, or Flows that have their own construct to create a new version. For Agent Aliases, the creation of a new version is tied to creation of a new alias.
The current agent alias does not work as expected in the following situations:
- When the alias is named, the current construct cannot update the alias. This is due to the fact that the current construct tries to create a new alias, however due to the way CloudFormation handles updates, this change results invalid.
- AWS CloudFormation usually creates the replacement resource first, changes references from other dependent resources to point to the replacement resource, and then deletes the old resource (src). With a named resource, it is not possible to create the replacement resource as there is an attempt to create a new resource (the replacement one), with the same name of an existing one (the previous one, that hasn't been deleted yet).
- The current construct handles changes by creating a new alias, this causes the alias ID to change and thus may cause problems with downstream resources using the alias ID (this causes problems especially with agent collaboration).
Proposed Solution
RFC from the community.
Possible solution:
- Using a Custom Resource that with a Lambda creates a new temporary alias as a way to create a new version, get the new version number, delete the temp alias, and then update the current alias.
- We would rather avoid using custom resources.
Other Information
Explored options:
- Creating a new alias to every update (current implementation - problematic)
- Creating the agent alias pointing to the DRAFT version (the most up-to-date version)
- Agent Alias does not allow to point to the Draft version even though it is accepted by CFN spec.
- Using the agent TEST alias pointing to the DRAFT version
- Cannot be used for things like Agent Collaboration
Acknowledgements
- [ ] I may be able to implement this feature request
- [ ] This feature might incur a breaking change
Related issue -Issue 969.
The current implementation create a new alias with every redeployment without changing anything in the stack.
I would imagine that Agent Aliases should work similarly to Lambda Aliases. This may not be possible as the way that agent versions are handled doesn't seem to be complete due to there not being a CreateAgentVersion command as seen here. Associating Aliases to versions and being able to move an alias to another version much like with lambdas would be 'inline' with practices such as this.
Additionally there is a secondary dependency here with AgentCollaborations. I've seen this fail as well as an agent collaboration is tied to an alias so any attempt to delete an alias without first disassociating it from the collaboration will cause the a failure. I think handling the AgentVersion and AgentAlias associations again like Lambda Versions + Aliases would make the system more flexible. The Agent Collaboration for instance shouldn't need to know the agent version changed underneath since it is tied to an alias only and the invocation of the alias resolves itself to the proper agent version.
This same issue presents itself in the terraform-provider-aws support for bedrock agents as well and likely terraform-provider-awscc as this is auto-generated from the CFN definitions of resources. Related issue here https://github.com/hashicorp/terraform-provider-aws/issues/37321
We have to prepare the agent after modification of multiple resources in the terraform provider, so to me, for end users it would make sense for that to also create a new version and expose a latest version attribute that could be consumed by the alias resource to allow it to be updated in place pointing to the new version.
Any updates on this?
This issue is now marked as stale because it hasn't seen activity for a while. Add a comment or it will be closed soon. If you wish to exclude this issue from being marked as stale, add the "backlog" label.
Any plans on fixing this?
Or any known workaround?
This issue is now marked as stale because it hasn't seen activity for a while. Add a comment or it will be closed soon. If you wish to exclude this issue from being marked as stale, add the "backlog" label.
Closing this issue as it hasn't seen activity for a while. Please add a comment @mentioning a maintainer to reopen. If you wish to exclude this issue from being marked as stale, add the "backlog" label.