Observe, estimate cost, and tear it all down

These steps were authored from current AWS documentation and the synthesized templates, not executed against a live account. The console paths, log group names, metrics, and teardown behavior below are verified against AWS (Amazon Web Services) documentation and the synthesized CloudFormation templates on 2026-07-15. Every result block is labeled as an output shape rather than a captured run. Operating and observing a deployed agent uses billable AWS resources; the teardown at the end stops those charges.

Outcome

By the end of this lesson you will know where the deployed agent’s behavior shows up — its logs, its traces, and its latency and token metrics — and how to read them without leaking sensitive request text. You will be able to name what drives cost and how long data is kept, and you will run the teardown that removes every resource this course created, then check that nothing tutorial-related is still billing.

This is the last lesson. It ends the way every billable step in this course ends: by cleaning up.

Mental model

In a visual automation tool, when a run misbehaves you open its run history: a list of executions, each showing which node ran, what it received, and where it failed. Cloud observability is that same idea, split across three CloudWatch surfaces you already have equivalents for:

• Logs are the detailed line-by-line record, like the expanded view of a single run. The runtime writes them to a log group named /aws/bedrock-agentcore/runtimes/<runtime-id>-DEFAULT — the exact name the agent stack pre-created in Lesson 8 so it could own the retention setting.
• Traces show one request’s path across steps — the agent turn, each tool call, the model call — like following one execution through your workflow’s nodes. AgentCore emits these in the OpenTelemetry (OTEL) format, an open standard for traces and metrics, which CloudWatch reads.
• Metrics are the aggregate numbers over many runs: session count, latency, duration, token usage, and error rate. This is the dashboard view, not the single run.

AWS gathers all three for agents in one place: the CloudWatch GenAI Observability view (Amazon CloudWatch console, “GenAI Observability” in the left navigation). It is the run-history screen for your deployed agent.

Where the analogy stops: a visual tool keeps run history for you automatically and briefly. In the cloud you decide what is collected, how long it is kept, and what it costs — which is why retention and redaction are part of this lesson, not an afterthought.

Find the logs, traces, and metrics

These paths are verified against AWS documentation on 2026-07-15; the screens below are described, not captured (output shape; not executed).

1. Logs. Open the CloudWatch console, go to Log groups, and open /aws/bedrock-agentcore/runtimes/<runtime-id>-DEFAULT, using the <runtime-id> from the RuntimeArn output in Lesson 9. Each invocation appends log events here. Retention is one month, because the stack set RetentionDays.ONE_MONTH on this group.
2. Traces and the dashboard. In the CloudWatch console, open GenAI Observability. Select your agent runtime to see per-session traces and the aggregate metrics — session count, latency, duration, token usage, and error rate. To emit richer application-level spans, AgentCore uses the OTEL standard; instrumenting the container with the AWS Distro for OpenTelemetry (aws-opentelemetry-distro) adds detailed spans, though the baseline runtime metrics appear without any extra code.
3. Metrics for one number over time. Any single metric (for example latency or token usage) can be charted from the CloudWatch Metrics screen if you want a focused graph rather than the full dashboard.

Least privilege, one more time

Lesson 8 showed the agent’s execution role granting exactly two extra statements: invoke one model family (named by ARN, an Amazon Resource Name) and use one memory (named by ARN). Operating the agent is the moment that scoping pays off. If a log or trace ever showed the agent attempting an action outside those two grants, that call would be denied by IAM (Identity and Access Management), not silently allowed — the boundary you read in the template is the boundary enforced at run time. The few wildcard resources that remain are all AWS-mandated for actions with no resource to name (listed statement by statement in infra/README.md), not broad grants.

Quotas

AgentCore applies service quotas — for example, a limit on the rate of InvokeAgentRuntime calls. When a call would exceed a quota, the API returns a ServiceQuotaExceededException (or a ThrottlingException for rate limits) rather than running. For the tutorial’s low volume you will not hit these, but the correct response in real use is exponential backoff and, if the ceiling is genuinely too low, a quota-increase request in the Service Quotas console — not removing your client-side limits. This is the cloud version of the bounded turns and retries you built into the agent in Lesson 7.

Cost model and retention

You are billed for what you use, with no upfront commitment. The shape of the cost — verified on 2026-07-15, with no dollar figures reproduced here — is:

• Model (Bedrock). Priced per million input and output tokens, input and output billed separately. Every invocation that reaches the model adds token cost. Source: aws.amazon.com/bedrock/pricing.
• Runtime (AgentCore). Metered per second by vCPU-hour and GB-hour of resources used while a session is actually serving a request; idle wait time is not charged as CPU. Source: aws.amazon.com/bedrock/agentcore/pricing.
• Memory (AgentCore). Short-term raw events are priced per event; long-term records are priced per record kept per month, plus retrieval volume. Same pricing page as the runtime.
• Logs (CloudWatch). Priced by data ingested and stored. Retention here is capped at one month. Source: aws.amazon.com/cloudwatch/pricing.

Retention and removal are set deliberately for a disposable environment: short-term memory events expire after 30 days (the stack set expirationDuration to 30, below the 90-day default), the runtime log group keeps logs for one month, and both — along with every other resource — carry a DESTROY removal policy so teardown deletes them. Nothing in this course is configured to keep data indefinitely.

Incident-safe debugging

When you read logs or traces to debug, protect the request text. The intake agent treats every request as untrusted data, and that includes not spraying it into logs. Two rules:

• Do not log raw prompt content, personal data, secrets, or credential-bearing headers. Log decisions and metadata — which system was looked up, whether the result was accepted or rejected, the stop reason, latency, token counts — not the full user text. If you must capture an example for debugging, redact it first.
• Log a correlation identifier, not the payload. A correlation id (for the intake agent, the runtime session id) lets you tie a log line, a trace, and a metric spike to the same request without storing what the request said. That is how you investigate an incident without turning your logs into a second copy of sensitive input.

These are the same boundaries from the agent engineering rules, now applied to operations: observability must not become a data-leak path.

Teardown

This is the step that stops the charges from Lesson 9. Run it from infra/:

npx cdk destroy WorkflowsToAgentsSite WorkflowsToAgentsAgent

CDK asks you to confirm each stack deletion; answer y. Naming both stacks removes everything the course deployed. (npx cdk destroy --all does the same for every stack in the app.)

This is the intended teardown; it was not executed here (output shape; not executed — procedure verified against infra/README.md and the synthesized deletion policies on 2026-07-15). From those policies, here is exactly what goes and what stays.

Removed automatically:

• The S3 (Amazon Simple Storage Service) site bucket and its contents (autoDeleteObjects empties it first).
• The CloudFront distribution, its Origin Access Control, and the rewrite function.
• The ECR (Elastic Container Registry) repository and its images (emptyOnDelete), so no agent image is left billing.
• The AgentCore Runtime.
• The AgentCore Memory, including its stored short- and long-term records, and its auto-created memory service role.
• The runtime log group.
• Every IAM role and policy the stacks created.

May remain by design — clean up manually if you want a spotless account:

• The CDK bootstrap stack (CDKToolkit), its assets S3 bucket, and the bootstrap ECR repository. These are shared infrastructure that cdk destroy does not touch; the zipped site/dist asset that BucketDeployment uploaded sits in that bootstrap bucket until you empty it or delete the bootstrap stack.
• Bedrock model access, a per-account setting you enabled in Lesson 2, stays enabled (it costs nothing on its own).
• Metrics and traces already emitted are account-level history and are unaffected by destroy; they age out on their own.

Verify removal

The checkpoint is: no tutorial resource remains except the shared bootstrap stack you were told to expect. Confirm it (output shape; not executed):

1. Stacks gone. From infra/, run npx cdk list to recall the names, then in the CloudFormation console confirm WorkflowsToAgentsSite and WorkflowsToAgentsAgent are no longer listed. CDKToolkit remaining is expected.
2. No agent image or memory. In the ECR console, confirm the workflows-to-agents-intake repository is gone. In the AgentCore console, confirm the runtime and the intake_memory memory are gone.
3. Optional deep clean. If you want nothing at all left, empty the bootstrap assets bucket and delete the CDKToolkit stack. Only do this if no other CDK project uses that account.

If both course stacks are gone and only the shared bootstrap remains, you have hit the final checkpoint: the tutorial’s billable footprint is back to zero.

Cleanup

Cleanup is this lesson, so there is nothing extra to remove — with one honest reminder. cdk destroy deletes the deployed stacks, but if you skipped the deep clean in the last step, the CDK bootstrap resources still exist. They cost very little (a near-empty S3 bucket and an ECR repository), but they are not nothing. Delete the CDKToolkit stack when you are certain no other CDK work in that account depends on it.

That is the whole path: you understood models and tools, built a bounded agent, gave it structured output, an allow-listed tool, and memory, tested its safety, described its cloud in code, deployed it, invoked it, and tore it down. You can now carry that same shape — deterministic gates around a bounded model, least-privilege infrastructure, and a real teardown habit — back into your own automation work.