Feature Request: Enable Cost Attribution via Tagging for Bedrock Inference Profiles and Textract Adapters

[DavidArangoM]

First of all, thanks for the great work on this solution — it has been very helpful for accelerating document processing workloads on Amazon Web Services.

We are currently using this solution in a multi-project environment and have identified a gap related to cost attribution and usage tracking for AI services.

🚨 Problem Statement

The current implementation appears to use default configurations when invoking:
• Amazon Bedrock
• Amazon Textract

Because of this:
• All usage is aggregated at the account/service level
• There is no clear way to attribute costs per project / tenant / workflow
• Cost analysis via AWS Cost Explorer becomes limited and indirect

🎯 Proposed Feature

We would like to request support for:

1. Bedrock Inference Profiles
   • Allow configuration and usage of inference profiles when invoking Bedrock models

2. Textract Adapters
   • Add support for Textract adapters in document processing flows

that will give us the opportunity to tag the profile and the adapter and see that in cost explorer

💡 Suggested Implementation Approach

Some ideas that could make this flexible and extensible:

Add configuration options (e.g., in stack parameters or config files) to:
• Specify Bedrock inference profile IDs
• Specify Textract adapter IDs
•
Pass these values dynamically through the pipeline:
• Step Functions / Lambda layers
• Service integration calls

[rstrahan]

Hi @DavidArangoM Thanks for this! I'm glad you are finding the project to be useful!

Regarding your asks:

1. Support for Bedrock Inference Profiles: You can do this today

Step 1 — Create an application inference profile in the Bedrock console:

• Go to Amazon Bedrock Console → Inference → Inference profiles → Create inference profile
• Select the foundation model currently used in the IDP solution
• Tag it as needed.

Step 2 — Update the config (no code change needed):

• In the IDP accelerator, go to View/Edit Configuration
• Toggle to JSON View or YAML View (see screenshot shared)
• Find the model ID or standard cross-region inference profile ID in the relevant processing step sections (classification, extraction, assessment, etc.)
• Replace it with the new application inference profile ARN
• Click Save Changes

Does this work.. I will add this process to our docs, since I realize we could make it more clear.

2. Support for Textract Adapters: Not supported directly today..
BUT you could use the recently added Inference Lambda Hook mechanism..
Take a look at the docs and samples: https://github.com/aws-solutions-library-samples/accelerated-intelligent-document-processing-on-aws/blob/main/docs/lambda-hook-inference.md

1. You can write your own Lambda (comply with naming restriction) that accepts the payload we would send (converse API style) and coverts it to Textract payload (with Adaptor config added), calls Textract, formats response.
2. Select 'Bedrock' for OCR backend, Select 'LambdaHook' for model_id, and enter the ARN of your function.
   Now OCR taks will be sent to your Lambda instead of directly to Textract

LMK if these approaches work.
Many Tx!

[DavidArangoM]

Hi @DavidArangoM Thanks for this! I'm glad you are finding the project to be useful!

Regarding your asks:

1. Support for Bedrock Inference Profiles: You can do this today

Step 1 — Create an application inference profile in the Bedrock console:

• Go to Amazon Bedrock Console → Inference → Inference profiles → Create inference profile
• Select the foundation model currently used in the IDP solution
• Tag it as needed.

Step 2 — Update the config (no code change needed):

• In the IDP accelerator, go to View/Edit Configuration
• Toggle to JSON View or YAML View (see screenshot shared)
• Find the model ID or standard cross-region inference profile ID in the relevant processing step sections (classification, extraction, assessment, etc.)
• Replace it with the new application inference profile ARN
• Click Save Changes

Does this work.. I will add this process to our docs, since I realize we could make it more clear.

2. Support for Textract Adapters: Not supported directly today.. BUT you could use the recently added Inference Lambda Hook mechanism.. Take a look at the docs and samples: https://github.com/aws-solutions-library-samples/accelerated-intelligent-document-processing-on-aws/blob/main/docs/lambda-hook-inference.md

1. You can write your own Lambda (comply with naming restriction) that accepts the payload we would send (converse API style) and coverts it to Textract payload (with Adaptor config added), calls Textract, formats response.

2. Select 'Bedrock' for OCR backend, Select 'LambdaHook' for model_id, and enter the ARN of your function.
   Now OCR taks will be sent to your Lambda instead of directly to Textract

LMK if these approaches work. Many Tx!

Hello @rstrahan thank you for your suggestions, here my comments:

### Bedrock
1- Bedrock approach worked, however we got permissions error trying to access to the inference profile:

Bedrock error: AccessDeniedException - User: arn:aws:sts::<ACCOUNT_ID>:assumed-role/<STACK_PREFIX>-PATTERN2S-SummarizationFunctionRole-xx/<STACK_PREFIX>-PATTERN2STAC-SummarizationFunction-xx is not authorized to perform: bedrock:InvokeModel on resource: arn:aws:bedrock:us-east-1:<ACCOUNT_ID>:application-inference-profile/<INFERENCE_PROFILE_ID> because no identity-based policy allows the bedrock:InvokeModel action

and same for AssessmentFunctionRole

What did I do?
I follow your steps and on each configuration where it made reference to any Bedrock model, I changed it to a specific inference profile with the corresponding tags to track the cost.

Solution?
We solve them with a custom policy (see code below) but that will be great if we can include it in the default stack (this repository)
data "aws_iam_policy_document" "lambda_bedrock" { statement { sid = "BedrockInvokeModel" effect = "Allow" actions = [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ] resources = [ "arn:aws:bedrock:*::foundation-model/*", "arn:aws:bedrock:*:${var.account}:inference-profile/*", "arn:aws:bedrock:*:${var.account}:application-inference-profile/*" ] } }

2- Cache optimization
I saw in the log the below message:
Removed <<CACHEPOINT>> tags for unsupported model arn:aws:bedrock:us-east-1:<ACCOUNT_ID>:application-inference-profile/<INFERENCE_PROFILE_ID>

I just want to confirm, Does that mean that I lost the prompt caching optimization ability (Bedrock's Prompt Caching feature) and probably it will come with slightly higher latency and cost on repeated calls?

Textract

We are still evaluating the option.. I will let you know the result soon

Thanks regards

[rstrahan]

Hi @DavidArangoM

1. The permission issue for Inference Profiles was fixed in PR fix(iam): add bedrock application-inference-profile to lambda executi… #236 (v0.5.2).
   Can you confirm if you are using latest release and still see this issue?

2. Good catch.. Yes, we strip out CACHEPOINT tags for models that do not support prompt caching.. the InferenceArn does not match any of the models we know to support caching, and so we remove the CachePoints by default.

We could change this logic to include CachePoints by default when using inferenceArns but that would fail if the infererenceArn references a model that does not support prompt caching.

Perhaps a better fix would be to use the Bedrock GetInferenceProfile API to resolve what base model the profile wraps, then check that base model against the supported list.

What do you think? I can try to get this fix into the release for Friday.

[rstrahan]

Implemented fix for caching - see #281
In develop branch, staged for v0.5.7 release.