AgentCore Runtime konfigurieren: Session-Lifecycle, Container-Backing, Memory

Hinweis: Dieser Artikel wurde mit Unterstützung von KI aus dem englischen Original übersetzt.

TL;DR: Ich habe AgentCore Runtime unter dem Harness dieses Projekts Block für Block konfiguriert – Session-Lifecycle, Execution Role, Modellauflösung, Container-Backing, Memory-Anbindung und Netzwerkmodus –, und fast jede Einstellung zeigte ihr eigentliches Verhalten erst bei einem echten Invoke, nicht in einem Schema oder auf einer Doku-Seite.

Teil 3 der Serie „Einen Partner-Sales-Agent auf Amazon Bedrock AgentCore bauen“, aufgebaut um ein reales Projekt: ein dialogbasierter Agent, der HubSpot CRM und AWS Partner Central für das Sales-Team eines AWS-Partners verbindet. Artikel 2 hat begründet, warum dieses Projekt seine Agent-Loop überhaupt einem gemanagten Harness überlässt; dieser Artikel konfiguriert diesen Harness gegenüber der Runtime, die ihn ausführt, Block für Block. Jede Einstellung lässt sich aus der AWS Management Console reproduzieren. Mein Terraform-Build ist ein Automatisierungs-Bonus – inklusive der Stellen, an denen die Automatisierung auf Probleme stieß, die ein Konsolen-Leser nie zu Gesicht bekommt.

Inhaltsverzeichnis

• Artikel 1: Zwei Systeme, ein Vertriebsprozess: Ein AWS-Partner-Agent auf Amazon AgentCore Harness
• Artikel 2: Warum ich keine eigene Agent-Loop geschrieben habe: Das Argument für AgentCore Harness
• Artikel 3: AgentCore Runtime konfigurieren: Session-Lifecycle, Container-Backing, Memory
• Artikel 4: Ein Gateway, sechs Tools: AgentCore Gateway als einziger Weg nach außen für Ihren Agent
• Artikel 5: Ein deterministisches Sicherheitsnetz für Ihren Agent: AgentCore Policy und Cedar
• Artikel 6: Einen Agent ohne Vektordatenbank grounden: AgentCore Managed Knowledge Base
• Artikel 7: Vom Firmennamen zum CRM-Datensatz: Eine AgentCore-Konversation, End-to-End (demnächst)

Ein Harness braucht bei der Erstellung genau zwei Werte: einen Namen und eine Execution Role. Alles andere, was dieser Artikel behandelt (die Modellreferenz, die Memory-Bindung, das Container-Image, die Skill, die Session-Limits, der Netzwerkmodus), lässt sich später anhängen. Ich habe den Agent iterativ gebaut und bin bei fast jedem Schritt auf Überraschungen gestoßen. Deshalb gehe ich die Ressource von außen nach innen durch und stelle jedem Block dieselbe Frage: Was macht das tatsächlich zur Laufzeit, und woher weiß ich das? Wo die Antwort aus einem echten Fehlschlag statt aus der Dokumentation stammt, sage ich das auch. Das betrifft den größten Teil dieses Artikels.

Session-Lifecycle: Wie lange ein Gespräch warm bleibt

Eine Harness-Session öffnet sich beim ersten Invoke und bleibt warm, solange weiterhin Calls eintreffen. Zwei Limits begrenzen sie: ein Idle-Timeout von 15 Minuten und eine maximale Lebensdauer von 8 Stunden [1]. Jeder InvokeHarness-Call setzt den Idle-Zähler wieder auf null zurück. Was eine Session vorzeitig beendet, ist eine Lücke zwischen Calls, niemals eine Anzahl von Turns: vierzig kurze Wechsel innerhalb von zehn Minuten lassen den Zähler bei null, während eine einzige 16-minütige Pause die Session beendet. Die 8-Stunden-Obergrenze ist das andere Limit und gilt unabhängig von der Aktivität.

In der Console liegen diese Limits in den Runtime-Umgebungseinstellungen des Harness, die sich ihre Parameter mit AgentCore Runtime selbst teilen: Idle Session Timeout, maximale Lebensdauer, Netzwerkkonfiguration, Dateisystemkonfiguration [1]. Ein Harness wird im Hintergrund von einer AgentCore-Runtime-Ressource getragen, was man auch zweimal im IAM-Grant- und Netzwerkbereich sieht. In meiner Demo laufe ich mit den Standardwerten.

Für eine Live-Demo übersetzen sich diese Zahlen direkt. Ein Vertriebsmitarbeiter kann eine Unterhaltung für bis zu 15 Minuten pausieren, Fragen aus dem Publikum entgegennehmen und mit vollständigem Session-Zustand fortsetzen. Eine längere Lücke oder die 8-Stunden-Obergrenze bedeutet, dass der nächste Invoke stillschweigend eine neue Session öffnet. Es gibt weder einen Fehler noch eine Warnung. Es gibt nur keine Kontinuität mehr und einen Agent, der plötzlich fragt, welche Opportunity gemeint war.

Das operative Risiko für einen Workshop ist entsprechend konkret: Achten Sie auf die Lücke zwischen dem letzten und dem nächsten Invoke. Ein 20-minütiger Q&A-Block setzt den Zustand mitten in der Präsentation zurück. Wer sich fragt, wie sich das lösen lässt: Die Antwort ist ein Langzeit-Memory, das Session-Grenzen von Haus aus übersteht.

Execution Role: eine Identität für alles, was der Agent tut

Alles, was der Agent zur Laufzeit tut, tut er als eine einzige IAM-Rolle. harness_exec ist die Execution Role des Harness und damit die Identität hinter den Bedrock-Modellaufrufen, den Memory-Lese- und -Schreibzugriffen sowie den SigV4-signierten Calls an das Gateway – dazu die ECR-Image-Pulls und die Observability-Writes, die die Runtime diagnostizierbar halten.

AWS dokumentiert den Basis-Fan-out einer Harness-Execution-Role über vier Services: AgentCore Identity für Workload Access Tokens, X-Ray für Sampling-Regeln und Traces, CloudWatch für Log-Gruppen und -Streams sowie ECR für Image- und Layer-Zugriff [2]. Dieses Projekt vergibt drei der vier und lässt Identity komplett aus. Die Outbound-Authentifizierung des Harness gegenüber dem Gateway ist eine getaggte Union aus drei Varianten: aws_iam (ein Boolean), none (ein Boolean) oder oauth mit einer Credential-Provider-ARN und Scopes. Nur die oauth-Variante verbraucht eine AgentCore-Identity-Ressource. aws_iam = true, was dieses Projekt setzt, ist ein in sich geschlossener SigV4-Signing-Modus: Der Harness signiert Gateway-Calls mit den Credentials seiner eigenen Execution Role und braucht nirgendwo eine Identity-Ressource.

In der Console ist die Execution Role ein einzelnes Feld im Harness-Formular. Ich habe pro Capability eine eigene Policy zugeschnitten:

Jeder Grant ist ein eigenes Policy-Dokument und eine eigene Role Policy, die nur die Actions auflistet, die eine Capability braucht, gegen eine ARN. Nirgendwo taucht eine Wildcard-Ressource auf, außer dort, wo das IAM-Modell eines Services es verlangt: ecr:GetAuthorizationToken ist eine Registry-Level-Action, die ECR nicht auf ein Repository scopen lässt [3], die X-Ray-Write-Actions nehmen keine Ressourcen-ARN, und cloudwatch:PutMetricData ist stattdessen per Condition auf den Namespace bedrock-agentcore beschränkt. Im gesamten Projekt gibt es genau eine weitere dokumentierte Ausnahme, den bedrock:AgenticRetrieveStream-Grant der Knowledge Base, der auf der Service-Rolle des Gateway liegt, weil AWS keine Beschränkung auf eine einzelne Knowledge Base unterstützt; Artikel 6 behandelt das.

Hier sehen Sie, wie eines dieser Paare im automatisierten Build aussieht. Das ist der Memory-Grant mit seiner Action-Liste:

data "aws_iam_policy_document" "harness_exec_memory" {  statement {    effect = "Allow"    actions = [      "bedrock-agentcore:CreateEvent",      "bedrock-agentcore:ListEvents",      "bedrock-agentcore:GetEvent",      "bedrock-agentcore:ListSessions",      "bedrock-agentcore:ListActors",      "bedrock-agentcore:RetrieveMemoryRecords",    ]    resources = [awscc_bedrockagentcore_memory.agent.memory_arn]  }}​resource "aws_iam_role_policy" "harness_exec_memory" {  name   = "agentcore-memory"  role   = aws_iam_role.harness_exec.id  policy = data.aws_iam_policy_document.harness_exec_memory.json}

Diese Policy existierte nicht von Anfang an. Mein erster Live-Smoke-Test scheiterte mit einer AccessDeniedException bei bedrock-agentcore:ListEvents gegen die ARN der angehängten Memory-Ressource, weil die Rolle zu diesem Zeitpunkt nur die Model-Invoke-Actions trug. bedrock-agentcore:* ist ein eigener IAM-Namespace, getrennt von bedrock:*, und nichts in der Toolchain markiert dessen Fehlen: terraform validate lief durch, der Plan war sauber, der Apply erfolgreich, und der Harness selbst wurde ohne Beanstandung erstellt. Die Lücke zeigte sich erst beim ersten echten Invoke, als 403.

Sobald Tools angehängt waren, rief der Harness das Modell nicht mehr über InvokeModel auf, sondern wechselte zu Bedrocks Operationen Converse und ConverseStream – zwei separate IAM-Actions, die der Rolle nie gewährt worden waren: eine weitere Live-AccessDeniedException. Beide Actions wurden in dieselbe Policy eingefaltet, die bereits den einfachen InvokeModel*-Grant trug, gegen dieselben ARNs (die Aufteilung zwischen Profil- und Region-ARN ist Thema von „Modellauflösung" weiter unten):

data "aws_iam_policy_document" "harness_exec_bedrock_invoke" {  statement {    effect = "Allow"    actions = [      "bedrock:InvokeModel",      "bedrock:InvokeModelWithResponseStream",      "bedrock:Converse",      "bedrock:ConverseStream",    ]    resources = [      "arn:aws:bedrock:eu-central-1:${data.aws_caller_identity.current.account_id}:inference-profile/eu.anthropic.claude-sonnet-5",      "arn:aws:bedrock:eu-central-1::foundation-model/anthropic.claude-sonnet-5",      "arn:aws:bedrock:eu-north-1::foundation-model/anthropic.claude-sonnet-5",      "arn:aws:bedrock:eu-south-1::foundation-model/anthropic.claude-sonnet-5",      "arn:aws:bedrock:eu-south-2::foundation-model/anthropic.claude-sonnet-5",      "arn:aws:bedrock:eu-west-1::foundation-model/anthropic.claude-sonnet-5",      "arn:aws:bedrock:eu-west-3::foundation-model/anthropic.claude-sonnet-5",    ]  }}​resource "aws_iam_role_policy" "harness_exec" {  name   = "bedrock-invoke"  role   = aws_iam_role.harness_exec.id  policy = data.aws_iam_policy_document.harness_exec_bedrock_invoke.json}

Derselbe Wechsel löste Bedrocks Marketplace-Subscription-Check für Drittanbietermodelle aus. Mit einer neuen Ressource in einer der jüngsten Releases des AWS-Terraform-Providers konnte ich das Modell auch per Terraform aktivieren (es gibt dafür auch eine Option in der AWS Management Console):

data "aws_iam_policy_document" "harness_exec_marketplace" {  statement {    effect = "Allow"    actions = [      "aws-marketplace:ViewSubscriptions",      "aws-marketplace:Subscribe",    ]    resources = ["*"]​    condition {      test     = "StringEquals"      variable = "aws-marketplace:ProductId"      values   = ["prod-4ezhkeia6k2cs"] # Claude Sonnet 5's marketplace product id    }  }}​resource "aws_iam_role_policy" "harness_exec_marketplace" {  name   = "marketplace-model-subscription"  role   = aws_iam_role.harness_exec.id  policy = data.aws_iam_policy_document.harness_exec_marketplace.json}

Der AgentCore-Gateway-Call brauchte bedrock-agentcore:InvokeGateway auf der ARN des Gateway:

data "aws_iam_policy_document" "harness_exec_invoke_gateway" {  statement {    effect    = "Allow"    actions   = ["bedrock-agentcore:InvokeGateway"]    resources = [aws_bedrockagentcore_gateway.agent.gateway_arn]  }}​resource "aws_iam_role_policy" "harness_exec_invoke_gateway" {  name   = "invoke-gateway"  role   = aws_iam_role.harness_exec.id  policy = data.aws_iam_policy_document.harness_exec_invoke_gateway.json}

Anfangs hatte ich einige Mühe herauszufinden, warum der Harness keine CloudWatch-Logs schrieb, bis ich erkannte, welche Berechtigungen fehlten. Das ist die einzige Policy in diesem Set mit mehr als einem Statement, weil Logs, X-Ray und der Metrics-Namespace jeweils eigene Scoping-Regeln haben:

data "aws_iam_policy_document" "harness_exec_observability" {  statement {    effect    = "Allow"    actions   = ["logs:CreateLogGroup", "logs:DescribeLogStreams"]    resources = ["arn:aws:logs:eu-central-1:${data.aws_caller_identity.current.account_id}:log-group:/aws/bedrock-agentcore/runtimes/*"]  }​  statement {    effect    = "Allow"    actions   = ["logs:DescribeLogGroups"]    resources = ["arn:aws:logs:eu-central-1:${data.aws_caller_identity.current.account_id}:log-group:*"]  }​  statement {    effect    = "Allow"    actions   = ["logs:CreateLogStream", "logs:PutLogEvents"]    resources = ["arn:aws:logs:eu-central-1:${data.aws_caller_identity.current.account_id}:log-group:/aws/bedrock-agentcore/runtimes/*:log-stream:*"]  }​  statement {    effect    = "Allow"    actions   = ["xray:PutTraceSegments", "xray:PutTelemetryRecords", "xray:GetSamplingRules", "xray:GetSamplingTargets"]    resources = ["*"] # X-Ray's write and sampling actions take no resource ARN  }​  statement {    effect    = "Allow"    actions   = ["cloudwatch:PutMetricData"]    resources = ["*"]​    condition {      test     = "StringEquals"      variable = "cloudwatch:namespace"      values   = ["bedrock-agentcore"]    }  }}​resource "aws_iam_role_policy" "harness_exec_observability" {  name   = "agentcore-observability"  role   = aws_iam_role.harness_exec.id  policy = data.aws_iam_policy_document.harness_exec_observability.json}

Fünf der sechs Policies hier kamen während der Fehlersuche dazu (RTFM). Nur der ECR-Grant wurde vorab hinzugefügt, bevor er hätte scheitern können, weil der Developer Guide die Anforderung klar benennt [3]. Für den Container habe ich folgende Berechtigungen ergänzt:

data "aws_iam_policy_document" "harness_exec_ecr" {  statement {    effect    = "Allow"    actions   = ["ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage"]    resources = [aws_ecr_repository.harness.arn]  }​  statement {    effect    = "Allow"    actions   = ["ecr:GetAuthorizationToken"]    resources = ["*"]  }}​resource "aws_iam_role_policy" "harness_exec_ecr" {  name   = "ecr-image-pull"  role   = aws_iam_role.harness_exec.id  policy = data.aws_iam_policy_document.harness_exec_ecr.json}

Modellauflösung: die Profil-ID, nicht die Modell-ID

Der Model-Block des Harness nimmt einen einzelnen ID-String entgegen. Dieses Projekt betreibt Claude Sonnet 5 über eu.anthropic.claude-sonnet-5, ein Cross-Region-Inference-Profil: Bedrocks Routing-Schicht, die den Traffic eines Modells über eine Reihe regionaler Endpunkte unter einer einzigen adressierbaren ID verteilt [4]. Dieses Profil routet über sechs Regionen: eu-central-1, eu-north-1, eu-south-1, eu-south-2, eu-west-1 und eu-west-3.

Die nackte Modell-ID schlägt fehl, und ich habe den Mechanismus direkt verifiziert: aws bedrock get-foundation-model meldet für die nackte ID bei inferenceTypesSupported nur ["INFERENCE_PROFILE"] und nichts sonst. Es gibt für dieses Modell keine On-Demand-Einzelregion-Invocation. Das Konfigurationsfeld würde die nackte ID akzeptieren, nichts validiert das beim Terraform-Plan, und jede Invocation würde dann daran scheitern, das Modell zu erreichen.

In der Console: Wählen Sie überall dort, wo der Harness eine Modell-ID verlangt, das Inference-Profil, nicht das Foundation Model. Die Cross-Region-Inference-Seite der Bedrock-Console listet die in Ihrer Region verfügbaren Profile mit Status und Routing-Zielen.

Die IAM-Konsequenz folgt auf dieselbe Weise, weil die Routing-Schicht verändert, was autorisiert wird. Bedrock prüft sowohl den Profil-Call als auch den regionalen Endpunkt, auf dem der Call landet, sodass der bedrock:InvokeModel*-Grant der Execution Role auf sieben ARNs scopt, nicht auf eine: die Inference-Profil-ARN, die account-scoped ist, plus die sechs zugrunde liegenden Foundation-Model-ARNs pro Region, die kein Account-Segment tragen, weil Foundation Models AWS-globale Ressourcen sind. Scopen Sie nur auf das Profil, und die Invocation scheitert in der jeweiligen Region, die der Router wählt.

Container-Backing und warum es hier existiert

Skills sind Dateisystem-Pfad-Artefakte. Ein rein deklarativer Harness hat kein Dateisystem, in das er sie legen könnte. Dieser eine Satz ist der gesamte Grund, warum der Harness dieses Projekts container-backed ist: Die BANT-Qualifizierungs-Skill (Budget, Authority, Need, Timeline) wird fertig in ein Image eingebacken ausgeliefert, und sonst brauchte nichts am Harness überhaupt einen Container.

Die Standard-Harness-Umgebung gibt dem Agent Python und Bash, was für die meisten Konfigurationen ausreicht [5]. Eine benutzerdefinierte Umgebung ist ein für linux/arm64 gebautes ECR-Image, und sie bringt ein Verhalten mit, das verändert, wie man über das Image nachdenkt: Der Harness überschreibt ENTRYPOINT und CMD des Containers, sodass Ihr Startbefehl nie läuft [5]. Der Container ist eine Dateisystem-Schicht, nicht mehr. Der eigene gemanagte Agent-Prozess des Harness – das Modell, die Tool-Blöcke, der System-Prompt – läuft von der Umstellung unberührt weiter; Ihre installierte Software, das Dateisystem und die Umgebungsvariablen stehen ihm einfach zur Verfügung. Mein Dockerfile besteht entsprechend aus zwei inhaltlichen Zeilen, einem FROM und einem COPY, ohne ENTRYPOINT und ohne Anwendungscode. Der einzige Vertrag, der zählt: Der konfigurierte Pfad der Skill muss byte-identisch mit dem COPY-Ziel sein [6]:

environment_artifact {  container_configuration {    container_uri = "${aws_ecr_repository.harness.repository_url}:${var.image_tag}"  }}​skill {  path = ".agents/skills/sales-methodology-implementer"}

Der Console-Weg ist: ECR-Repository erstellen -> Image pushen -> dann die Image-URI und den Skill-Pfad am Harness setzen.

Memory-Anbindung

AgentCore Memory gibt dem Harness zwei Schichten: kurzfristige Session-Events und langfristige Strategien, die dauerhafte Records aus diesen Events extrahieren. In der Console ist die Memory-Ressource ein eigenständiges Ding unter Build, erstellt mit einem Namen, einer Event-Retention-Periode und einer Reihe von Strategien. Der Harness bindet sie dann per ARN ein. Die Memory-Ressource dieses Projekts trägt alle vier eingebauten Langzeit-Strategien: semantic, summary, user preference und episodic mit einer Reflection-Konfiguration (ich wollte alles ausprobieren).

Console-Leser konfigurieren das in Formularen. Automatisierungs-Leser stoßen zuerst an eine Wand: Die Ressource aws_bedrockagentcore_memory von hashicorp/aws hat nirgendwo in ihrem Schema einen Memory-Strategy-Block. Nur das Cloud-Control-gestützte awscc_bedrockagentcore_memory von hashicorp/awscc modelliert die vier Strategien. Hier ist es, verdichtet auf die Form, die zählt:

resource "awscc_bedrockagentcore_memory" "agent" {  name                  = "partner_growth_agent_memory"  event_expiry_duration = 30​  memory_strategies = [    { semantic_memory_strategy = {        name                = "semantic"        namespace_templates = ["/strategies/{memoryStrategyId}/actors/{actorId}/semantic"]    } },    { summary_memory_strategy = {        name                = "summary"        namespace_templates = ["/strategies/{memoryStrategyId}/actors/{actorId}/sessions/{sessionId}/summary"]    } },    { user_preference_memory_strategy = {        name                = "user_preference"        namespace_templates = ["/strategies/{memoryStrategyId}/actors/{actorId}/preferences"]    } },    { episodic_memory_strategy = {        name                = "episodic"        namespace_templates = ["/strategies/{memoryStrategyId}/actors/{actorId}/sessions/{sessionId}/episodes"]        reflection_configuration = {          # must be the same as, or a prefix of, the episodic namespace above          namespace_templates = ["/strategies/{memoryStrategyId}/actors/{actorId}"]        }    } },  ]​  # The awscc provider cannot flatten memory_strategies back into state;  # without this, every plan re-proposes the same phantom change forever.  lifecycle {    ignore_changes = [memory_strategies]  }}

Die Namespace-Templates tragen die Design-Entscheidung. Schauen Sie, welche Strategien auf {actorId} und welche auf {sessionId} scopen. Semantische Fakten, Nutzerpräferenzen und episodische Reflexionen sind Aussagen über den Actor, also scopen sie allein auf {actorId}: Das gibt dem festen Demo-Actor echtes Cross-Session-Recall, bei dem der Vertriebsmitarbeiter den Browser schließt, morgen eine neue Session öffnet und der Agent trotzdem noch weiß, was er gelernt hat. Summaries und rohe Episodes sind Artefakte pro Konversation, also behalten sie {sessionId} in ihrem Pfad und sterben mit der Relevanz der Konversation. Diese Aufteilung ist ein Denkschritt, kein Default; die Templates werden leer ausgeliefert und zwingen einen, sie zu treffen.

Zwei Einschränkungen sind nirgendwo dokumentiert, weder in der CreateMemory-API-Referenz noch im CloudFormation-Resource-Schema, und beide zeigten sich erst als Live-ValidationExceptions [8]: namespace_templates ist trotz der Kennzeichnung als optional tatsächlich pro Strategie erforderlich (AWS' eigene durchgearbeitete Memory-Beispiele setzen es durchweg explizit, was den Befund bestätigt [9]), und der Reflection-Namespace der episodic-Strategie muss identisch mit dem episodic-Namespace selbst sein oder ein Präfix davon. Mein erster Versuch nutzte einen Geschwister-Pfad, und der Service lehnte ihn mit einer Fehlermeldung ab.

Bei der actorId hatte ich eine wichtige Erkenntnis: Ich habe diese ID in Terraform fest definiert. Auf dem deployten System übergibt jede Harness-Invocation pro Nutzer eine actorId (abgeleitet aus der verifizierten Cognito-Identität des Aufrufers, und dieser Wert pro Request – nicht dieser Default – isoliert das Memory der Nutzer voneinander).

Zur Validierung dieses Features: Um Cross-Session-Recall zu prüfen, habe ich eine Session erstellt und ein fiktives Beispiel genannt, an das sich der Agent erinnern sollte. Wenige Minuten später habe ich eine neue Session geöffnet und darum gebeten, sich an diese Tatsache zu erinnern. Es hat sehr gut funktioniert.

Dieselbe Memory-Ressource trägt auch das Session-History-Feature der Chat-UI, das Konversationen über eigene, separat gescopte Policies liest und löscht.

Netzwerkmodus: PUBLIC durch Weglassen

Hier ist ein Konfigurationsbefund, den ich nirgendwo aufgeschrieben gesehen habe: Im installierten Terraform-Provider gibt es überhaupt kein network_mode-Attribut auf der Harness-Ressource. Der PUBLIC-Netzwerkmodus wird ausgedrückt, indem der gesamte environment/network_configuration-Block weggelassen wird. Es gibt kein Enum zu setzen; der Block bleibt einfach ungeschrieben. Und Sie sollten auch nicht leichtfertig versuchen, die VPC-Variante zu schreiben: Das Setzen einer VPC-network_configuration löst im installierten Provider eine dauerhafte Taint-Schleife aus, ein zum Zeitpunkt dieses Artikels offenes Issue [11].

Ein Console-Leser begegnet dem nie. Die Console präsentiert den Netzwerkmodus als sichtbare Wahl zwischen public und VPC, und public zu wählen ist unspektakulär. Im automatisierten Build wirkt dieselbe Wahl wie etwas Fehlendes: Das Terraform nach einem Netzwerk-Block zu durchsuchen und nichts zu finden, ist die Konfiguration – kein Beleg dafür, dass ein Schritt übersprungen wurde. Die Gesamtform der Harness-Ressource macht den Punkt am besten, mit markierter Abwesenheit:

resource "aws_bedrockagentcore_harness" "agent" {  harness_name       = var.harness_name  execution_role_arn = aws_iam_role.harness_exec.arn​  model                { ... }   # model resolution, above  environment_artifact { ... }   # container backing, above  skill                { ... }  memory               { ... }   # memory attachment, above  tool                 { ... }   # the Gateway binding, article 4​  # Deliberately no environment / network_configuration block.}

Die beiden angebotenen Modi, public und VPC, gehören AgentCore Runtime selbst, das Runtime-Fundament scheint hier ein letztes Mal durch [12]. Ich hatte keinen Use-Case für den VPC-Modus, aber man könnte ihn nutzen, um auf private Ressourcen, interne APIs und nicht-serverlose Services zuzugreifen.

Übertragbare Muster

Fünf Gewohnheiten aus dieser Konfigurationsarbeit lassen sich über die Demo hinaus auf jeden AgentCore-Build übertragen.

• PUBLIC-durch-Weglassen. Der Netzwerkmodus ist kein Wert; er ist die Abwesenheit eines Blocks. Bevor Sie annehmen, ein Ressourcentyp brauche eine explizite Aus-Einstellung, prüfen Sie, ob der Provider den Default als weggelassenen Block statt als Enum modelliert.
• Der awscc-versus-aws-Provider-Check. hashicorp/aws bietet auf seiner Memory-Ressource keine Unterstützung für Memory-Strategien; nur hashicorp/awscc erreicht AgentCores Cloud-Control-gestützte Langzeit-Memory-API. Wenn eine Ressource in einem Provider unvollständig modelliert wirkt, prüfen Sie das Schema des Cloud-Control-Schwester-Providers, bevor Sie schließen, das Feature sei in Terraform nicht unterstützt.
• Eine gescopte Policy pro Capability, nicht eine rollenweite Policy. Jedes Paar aus Policy-Dokument und Role Policy gewährt genau die Actions, die eine Capability braucht, gegen eine ARN. Das kostet vorab mehr Dateien und zahlt sich aus, sobald Sie den Blast Radius eines einzelnen Service durchdenken oder eine Capability sauber löschen müssen.
• IAM legt jeweils einen 403 auf einmal offen, und terraform validate erkennt keinen davon. Ein sauberer Plan und ein sauberer Apply beweisen nichts über die Autorisierung zur Laufzeit in einem servicespezifischen Namespace wie bedrock-agentcore:*. Planen Sie nach jedem Apply, der eine neue Capability berührt, eine Live-Invoke-Debugging-Runde ein. In diesem Build fand dieser Durchgang fünf der sechs Policies der Execution Role.

Das Muster hinter allem

Tritt man einen Schritt von den Abschnitten zurück, wiederholt sich eine Form.

• Netzwerkmodus: Ich nahm an, eine Einstellung existiere, und die Wahrheit war ein fehlender Block.
• Memory-Strategien: Ich nahm an, der Standard-Provider decke die Ressource ab, und die Wahrheit war ein zweiter Provider aus Notwendigkeit.
• Die Execution Role: Ich nahm an, die dokumentierten Actions seien die vollständige Liste, und die Wahrheit kam nach und nach, ein Live-403 auf einmal, fünf Policies wert.

PUBLIC-durch-Weglassen, awscc-aus-Notwendigkeit und IAM-fand-einen-403-auf-einmal sind derselbe Befund unter drei verschiedenen Namen: Die naheliegende Annahme scheiterte, und der Live-Apply war es, der es aufdeckte. Keines davon zeigte sich bei Validierung, Planung oder Doku-Review. Jedes einzelne zeigte sich erst, als das deployte System tatsächlich zum Handeln gebracht wurde.

Das ist kein Argument gegen den Harness. Wenn die Runtime konfiguriert ist, läuft sie zuverlässig. Ich kann nur empfehlen, sich die Hände schmutzig zu machen und es selbst auszuprobieren.

Ich hoffe, dieser Artikel war hilfreich für Sie. Ich freue mich über Feedback, was Ihnen gefallen hat und was nicht, damit ich künftige Artikel verbessern kann.

Quellen

[1] Amazon Bedrock AgentCore Developer Guide: Session-Lifecycle von Harness/Runtime, idleRuntimeSessionTimeout und maxLifetime, sowie die Runtime-Umgebungsparameter, die mit AgentCore Runtime geteilt werden. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-lifecycle-settings.html

[2] Amazon Bedrock AgentCore Developer Guide: Basis-Berechtigungen der Execution Role für die Runtime (AgentCore Identity, X-Ray, CloudWatch, ECR). https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-permissions.html

[3] Amazon Bedrock AgentCore Developer Guide: privater ECR-Zugriff für benutzerdefinierte Container-Images, einschließlich des Registry-Level-Grants ecr:GetAuthorizationToken. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-security.html

[4] Amazon Bedrock User Guide: Cross-Region Inference und Inference-Profile. https://docs.aws.amazon.com/bedrock/latest/userguide/cross-region-inference.html

[5] Amazon Bedrock AgentCore Developer Guide: benutzerdefinierte Umgebung (Container-Images); die Standardumgebung mit Python und Bash, die Anforderung linux/arm64 und das Überschreiben von ENTRYPOINT/CMD. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-environment.html

[6] Amazon Bedrock AgentCore Developer Guide: dateisystempfad-basierte Skills und das Einbacken von Skill-Verzeichnissen in ein Container-Image. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-skills.html

[7] Terraform-CLI-Dokumentation: Resource Targeting (-target) als Mechanismus für Ausnahmefälle bei Ordering-Constraints. https://developer.hashicorp.com/terraform/cli/commands/plan#resource-targeting

[8] Amazon Bedrock AgentCore API-Referenz: CreateMemory und dessen Memory-Strategy-Input, in dem namespaceTemplates als optional gekennzeichnet ist. https://docs.aws.amazon.com/bedrock-agentcore-control/latest/APIReference/API_CreateMemory.html

[9] AWS Machine Learning Blog: "Amazon Bedrock AgentCore Memory: Building context-aware agents", dessen durchgearbeitete Beispiele die Namespace-Templates durchweg explizit setzen. https://aws.amazon.com/blogs/machine-learning/amazon-bedrock-agentcore-memory-building-context-aware-agents/

[10] GitHub, hashicorp/terraform-provider-aws Issue #48496: Die Harness-Ressource stürzt bei Plan/Apply ab, wenn der memory-Block weggelassen wird und der Harness auf gemanagtes Memory zurückfällt. https://github.com/hashicorp/terraform-provider-aws/issues/48496

[11] GitHub, hashicorp/terraform-provider-aws Issue #48159: Das Setzen einer VPC-network_configuration auf dem Harness verursacht eine dauerhafte Taint-Schleife. https://github.com/hashicorp/terraform-provider-aws/issues/48159

[12] Amazon Bedrock AgentCore Developer Guide: Netzwerkmodi (public und VPC) sowie die ENI-basierte Anbindung des VPC-Modus an Ihr VPC über die AgentCore-Service-Linked-Role. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agentcore-vpc.html

[13] Docker-Dokumentation: Multi-Platform-Builds mit buildx. https://docs.docker.com/build/building/multi-platform/