AWSAWS Certified Generative AI Developer - Professional2026-102.4 Implement FM API integrations
Track inference jobs across worker retries
Completed by the knowledge check
Learning objective
Process long-running FM requests using SQS workers, completion tracking, correlation IDs, and idempotent retries.
Core idea
A long-running foundation model (FM) request needs a durable job contract that outlives the caller’s connection. Amazon SQS holds work for consumers; it does not represent your application’s completed result. Separate queue delivery, worker ownership, model invocation, and result publication so a retry cannot create a second business outcome.
Give every accepted job a stable application identifier and a completion record. Carry that identifier through the queue message, worker logs, model attempt records, and status response. A transport message ID identifies a message; an application job ID identifies the work across redelivery and resubmission.
Idempotency means repeating work does not repeat its externally visible effect. It does not mean an FM invocation always runs once. A worker can lose its response after the model has processed the request, leaving an uncertain outcome and possibly another billed invocation on retry.
How it works
Accept work under a stable identifier
Define an application record keyed by trusted tenant identity and a stable job_id. Example fields include request_hash, status, attempt_id, lease_until, result_ref, and error_code. These are your schema, not SQS fields. Store a hash of the normalized request so reusing an idempotency key with different input cannot silently retrieve an unrelated result.
Publish the work with SQS SendMessage. Put the stable identifier and input reference in MessageBody, or use MessageAttributes for correlation metadata. The returned MessageId confirms the transport message’s identity; it does not prove that a worker ran or completed inference. A status API should report your persisted job state rather than infer success from queue publication.
On a FIFO queue, sends with the same MessageDeduplicationId are accepted but duplicate messages are not delivered during the five-minute deduplication interval. This send-level window does not prevent redelivery after visibility expires, resubmission after the window, or a repeated model invocation by a worker. Keep the durable job record and conditional publication checks even when FIFO deduplication is enabled.
Creating the job record and sending the message are separate operations. Define recovery for the gap between them. For example, persist an application dispatch state and reconcile records that have not received confirmed queue acceptance. A repeated dispatch remains safe because all copies carry the same job identity. Do not describe two successful SDK calls as an atomic transaction.
Claim work and maintain a processing lease
SQS visibility timeout hides a received message while a consumer processes it. The default is 30 seconds. If the consumer does not delete it before visibility expires, another consumer can receive it. Standard queues use at-least-once delivery, so visibility is not an exclusive application lock.
Use DynamoDB UpdateItem with ConditionExpression to claim an eligible job and record an attempt_id and lease deadline. Require the expected status or an expired application lease. A ConditionalCheckFailedException means the attempted transition did not satisfy the condition; inspect the job state instead of treating it as a reason to invoke the model anyway.
For a polling worker, extend message visibility with ChangeMessageVisibility while useful processing continues. SQS limits visibility to 12 hours from the initial receipt; extensions do not reset that limit. Renew the application lease separately. One controls delivery timing, while the other controls who may publish the authoritative result.
For a Lambda SQS event source mapping, AWS recommends a queue visibility timeout of at least six times the function timeout, plus MaximumBatchingWindowInSeconds when using a batch window. This margin accommodates processing and throttling retries. It does not extend the function’s runtime.
Ordinary Lambda functions have a maximum timeout of 900 seconds, or 15 minutes. AWS documents a separate 5,400-second limit for qualifying asynchronous and event source mapping invocations on Lambda Managed Instances, with Amazon MQ and Amazon DocumentDB exceptions. Select the worker execution environment from the applicable limit and measured job duration; see 2.2.4 for Lambda invocation budgets. A job beyond its worker’s runtime needs another execution environment or smaller durable steps, not a longer SQS visibility timeout alone.
Publish completion before acknowledging delivery
After inference, validate the result and persist it under the job’s identity. Conditionally transition the job to succeeded only if the worker still owns the recorded attempt_id and valid lease. An expired worker must not overwrite a result published by its replacement.
A polling worker calls DeleteMessage after durable completion. With a Lambda event source mapping, successful processing lets Lambda remove the processed messages. If the worker crashes after publishing but before acknowledgment, redelivery reads the completed record and acknowledges it without invoking the model again.
For Lambda batches, enable FunctionResponseTypes: ["ReportBatchItemFailures"]. Return failed message identifiers through batchItemFailures, with each identifier in itemIdentifier, so successful records do not retry because a different record failed. An uncaught exception still fails the entire batch. With a FIFO queue, stop after the first failure and report failed and unprocessed messages to preserve ordering.
Configure a source-queue redrive policy with maxReceiveCount to move repeatedly unsuccessful messages to a dead-letter queue. For Lambda SQS processing, AWS recommends at least five receives. The application must also expose terminal failure or an explicit recovery state; moving a message does not automatically update your job record. See 2.4.5 for bounded SDK retries inside an attempt.
Key distinctions and trade-offs
Visibility versus ownership: Visibility reduces competing deliveries. A conditional job transition determines which worker may publish completion. Use both rather than trusting delivery timing as a lock.
Correlation versus deduplication: A shared identifier makes attempts traceable. Conditional state transitions and request matching make the repeated effect safe. A correlation field alone changes no execution behavior.
Exactly one publication versus exactly one invocation: A job record can select one authoritative result while a network failure still causes repeated inference. Keep attempt history so operators can distinguish duplicate compute from duplicate application completion.
Long visibility reduces premature redelivery but slows recovery after a crash. Renew a bounded lease according to expected work and recovery objectives instead of choosing the longest timeout by default.
Architecture / decision scenario
A contract-summary API accepts requests that can outlast an interactive connection. It records a tenant-scoped job, queues its ID through SendMessage, and returns that job ID for status polling. Repeating the same accepted request returns the same job; changing the request under that key is rejected.
A worker conditionally claims the job in DynamoDB, invokes the FM, and extends visibility if needed. It validates the summary, publishes the result, and conditionally records succeeded. If acknowledgment fails, the next delivery sees succeeded and skips inference. If the worker fails before publication, a replacement claims the expired lease and records a distinct attempt.
Short jobs use Lambda with configured visibility and partial batch responses. Jobs outside that execution budget use a longer-lived worker. Repeated failures reach the dead-letter queue, and recovery processing updates the completion record so callers do not poll an abandoned running state indefinitely.
Common exam traps
- Reporting completion because
SendMessagereturned aMessageId. - Using visibility timeout as a guarantee against duplicate processing.
- Treating FIFO
MessageDeduplicationIdas end-to-end idempotency. - Extending visibility to compensate for an insufficient worker runtime.
- Deleting the message before publishing durable completion.
- Assuming partial batch responses work without
ReportBatchItemFailures. - Letting an expired worker overwrite a replacement’s result.
What to remember
Track work with a stable application ID and a durable completion record. Use SQS visibility for delivery timing, conditional DynamoDB updates for ownership and publication, and acknowledgment only after the result is durable. Design retries for repeated effects and uncertain inference outcomes.
Knowledge check
Contract summaries are queued on an SQS standard queue and take several minutes each. Logs show two workers invoking the model for the same job and both writing a result. Which change ensures that only one attempt can publish the job’s result?
MessageDeduplicationIdUpdateItem on the job record decides which attempt owns the job and may publish. FIFO deduplication acts on sends, not on processing, and deleting on receipt loses the job if the worker crashes.A worker publishes a validated summary and conditionally marks the job succeeded, then crashes before deleting its SQS message. The message is delivered again. What should the next worker do?
succeeded record and delete the message without reinvokingA Lambda function consumes an SQS queue of inference jobs, and some jobs run for up to two hours. The team raised the queue’s visibility timeout to four hours, but those jobs still never finish. What change does the design need?
ReportBatchItemFailures so long jobs do not fail the batchJobs go to an SQS FIFO queue with the job ID as MessageDeduplicationId. A client resubmits an accepted request twenty minutes later, and the system produces a second summary. What prevents this?
MessageId as the job’s identifierMessageId identifies one transport message, not the work.