An AWS Agent Landing Zone: The First Architecture Decisions

Table of contents

• What a landing zone decides
• Start with workload boundaries
• Choose an account structure
• Design identity around both workload and user
• Shape the network around required paths
• Make logs useful across boundaries
• Allocate costs to accountable units
• Worked example: a support-operations agent
• Failure analysis and counterexamples
• A decision worksheet for the first design review
• Summary and next steps

What a landing zone decides

An agent landing zone is the set of cloud boundaries and operating conventions that let an organization host agent workloads without deciding account, access, network, logging and cost questions from scratch for every new project. It is not an agent framework, a prompt, or a universal security configuration. It is an agreed starting architecture: where a workload lives, which identity it runs as, which paths it can use, what evidence it leaves, and who can explain its bill.

Those decisions matter because an agent can cross several operational boundaries during one business task. A request may originate in an application, invoke a model, retrieve information, call a business system and create a change that someone must later explain. This guide stays with the foundational AWS environment decisions around accounts, identity, network, logging and cost allocation. It does not specify tracing implementation, browser or code execution boundaries, or capacity planning; those require separate designs.

A landing zone should make safe choices easier while preserving room for teams to build. Too little structure produces inconsistent credentials, invisible traffic and shared costs. Too much central prescription can create a queue for every small change and encourage teams to route around the platform. The useful middle is a small number of durable boundaries, explicit exceptions, and a repeatable review that tests the proposed design against real request paths.

Account separation and ownership are organizational design concerns in AWS environments, not merely naming conventions. The account structure should therefore reflect who operates a workload and who carries responsibility for its changes, rather than being organized only around the current model or framework choice. AWS’s environment organization guidance provides the relevant background.

Start by writing down a workload boundary in plain language. For example: “The customer-support assistant may read approved case fields and draft a response; the case-management service remains responsible for authorizing and recording any update.” That sentence is not a substitute for implementation controls. It is a testable statement that helps decide which account, identity and network paths are needed—and which are not.

Start with workload boundaries

Before drawing accounts, distinguish the workload from the business action it helps perform. An agent workload is the deployed software and its runtime context. A business action is the requested operation against a system of record. The same workload may serve many users, but those users may have different authority. Conversely, two workloads may assist the same business process while needing different access because one only drafts and the other submits changes.

Create a short boundary record for each initial workload. Include its owner, environment, data classes it may receive, systems it needs to reach, whether it can request a change or perform one, and the team accountable for the downstream result. State what the workload cannot do as well as what it can. “Read case data” is incomplete if the design has not named which case fields, whose cases, and which service enforces that restriction.

Keep the first version specific enough to shape infrastructure but independent of a particular vendor feature. For example, record “outbound access to the approved model endpoint and the case API; no general-purpose internet path” rather than assuming every deployment will use the same network implementation. Record the identity that represents the deployed workload separately from the identity or authorization context that represents the requesting user. That distinction prevents a platform-level credential from silently becoming the business permission model.

The first design review should test a complete request path. Ask where the request enters, which workload receives it, how that workload is identified, how the business system decides whether the user may act, which network connections are necessary, and what records would help an operator investigate a failure. If the team cannot draw that path, account and firewall choices are likely to be guesswork.

A useful flow for the first review is deliberately small. The branch is about whether the team can identify and justify every required boundary, not whether the workload has every possible control in place on day one.

flowchart TD
  accDescr: Workflow stages and decisions: Name workload and owner, Map user and service paths, Choose account boundary, Assign workload identity, Allow required network paths, Record logs and cost owner, Unclear path: revise design. The adjacent text explains the conditions and exceptions.
  accTitle: An AWS Agent Landing Zone — The First Architecture Decisions workflow
    A["Name workload and owner"] --> B["Map user and service paths"]
    B --> C["Choose account boundary"]
    C --> D["Assign workload identity"]
    D --> E["Allow required network paths"]
    E --> F["Record logs and cost owner"]
    F --> G["Unclear path: revise design"]
    B --> G

The normal path moves from a named workload through its account, identity, network and operating records. The revision branch is important: if a user or service path is unclear, the answer is not to grant broad access temporarily and hope to narrow it later. Return to the boundary statement and resolve the missing owner, destination or authorization decision before treating the design as ready.

Choose an account structure

An account boundary should make an operational responsibility clearer. Ask whether the workload has a distinct owner, release process, data boundary, environment or cost responsibility that would be difficult to manage if it shared an account with neighboring systems. When several answers are yes, a separate account can provide a cleaner place to apply and review those boundaries. When a workload is a small component under the same team, release process and operating responsibility as an existing application, a new account may add administration without creating a meaningful separation.

A practical starting pattern is to separate production from non-production, then decide whether agent workloads belong in dedicated accounts or within the accounts of their owning products. This is a design choice, not a rule that all agents need their own account. Dedicated workload accounts can make ownership and cost attribution more legible; placing the workload with its product can keep operational responsibility close to the service it supports. The right answer depends on whether the boundary follows how the organization actually changes, supports and funds the system.

Avoid using account count as a proxy for security. A separate account that shares broad operational access, has no clear owner, and sends no useful records may be a weak boundary in practice. A shared account with distinct workload identities, narrow access, explicit network paths and clear operating ownership may be more controlled for a particular small deployment. The goal is not to maximize separation. It is to make access and accountability understandable at the level where a team can maintain them.

Use a small decision table to expose the tradeoff before selecting a pattern.

Design signal	Dedicated agent account is more compelling	Shared product account may be more practical
Operational owner	A distinct team operates the workload	The product team owns its full lifecycle
Release boundary	Changes are released and reviewed separately	The workload changes with the product service
Cost accountability	A separate budget owner needs a distinct view	The product already reports costs as one unit
Environment separation	Independent production controls are required	Existing product environments provide the needed split
Exception handling	Isolation is part of the intended boundary	A new account would duplicate controls without changing access

Treat this as a discussion aid, not a scoring formula. Two teams can reasonably choose different structures from the same signals because their support model or organizational ownership differs. Document the reason for the chosen boundary and the condition that would trigger a review—for example, a new team taking operational ownership or a workload moving from draft-only assistance to updates in a system of record.

Keep non-production useful but not casually privileged. A development environment may need representative flows and test data, but it should not inherit production access simply to make demos easier. If the development workload needs to demonstrate a production-like interaction, define a safe test destination and the specific data shape it accepts. This keeps a successful test from depending on a hidden production credential or a developer’s personal access.

Account naming, ownership records and environment labels should agree. If a cost report calls a workload “Support AI,” the account inventory should identify which team owns it, and the service desk should know where incidents go. Minor inconsistencies become consequential when an operator must determine whether an unfamiliar workload is abandoned, experimental or business critical. Set a naming convention that is simple enough for teams to apply without inventing local variants.

Design identity around both workload and user

Identity design needs at least two questions: what deployed workload is making a request, and which user or business context is entitled to the requested operation? A workload identity identifies the agent workload; it does not replace authorization for each user’s business actions. AWS’s explanation of agent identities makes that distinction explicit.

Translate the distinction into a request path. The workload presents an identity that lets infrastructure and downstream services recognize the calling workload. Separately, the business authorization decision must establish whether the requesting user may read or change the particular record. The business system, or an authorization component it trusts, should make that decision against the relevant user and resource context. Do not infer permission from the fact that a request came from an approved agent runtime.

A useful identity inventory has one row per workload and names its environment, owner, intended destinations, credential lifecycle owner, and permitted operation class. Avoid labels such as “agent role” without a workload name: such a label makes it difficult to tell whether two deployments should share authority. If a workload serves multiple products or business units, treat that as an explicit design decision. It may require distinct identities or a downstream authorization boundary that reliably distinguishes the contexts; do not assume a shared identity can safely stand in for separate users.

Prefer an identity boundary that maps to one operational responsibility. If a development assistant and a production assistant have different owners or permitted destinations, represent that difference in the design rather than relying on engineers to remember which environment they are using. Likewise, avoid credentials whose purpose is unclear or whose owner has left the team. Write down who can request a change to identity permissions and who checks that the destination remains necessary.

For a business operation that changes data, carry the identity context through to the point that decides and records the action. A common design mistake is to authorize the agent once at entry and then let a broad service credential perform any downstream update. The gap is that the downstream system may see only the shared service, not the user whose request caused the change. If the business system cannot evaluate the user context itself, define a narrow authorization handoff that a named system owns and that can be audited. The architecture review should trace one allowed and one denied example all the way to the system of record.

Make the permitted action legible in identity and service boundaries. A drafting workload should not receive a path to write records solely because another workload in the same account needs one. Separate read and write responsibilities where the operating design can support that separation. Where a single workload must both read and propose a change, distinguish proposing from executing: the authorization path for execution should be independently explicit, rather than implied by a successful read.

Shape the network around required paths

Network design starts with destinations, not with a generic statement that an agent “needs internet.” List the paths required for one representative request: entry point to workload, workload to model service, workload to approved business API, and any necessary path for logs or operational support. For each path, record its purpose, initiating side, destination owner and whether it is required at runtime. This inventory gives the platform team a basis for network controls without pretending one topology fits every organization.

Separate required service traffic from administrative access. A workload that needs to call a business API does not automatically need an operator’s management path, and an operator’s ability to diagnose a workload does not imply that the workload needs broad outbound access. Keep these flows distinct in the design record so that a troubleshooting convenience does not become an undocumented runtime dependency.

A network diagram should show trust boundaries, not just boxes. Mark where the workload runs, which destination is outside its account or operating boundary, and where a request is rejected if the destination is not approved. Name the owner of each destination. “Internal API” is not precise enough if several teams operate APIs with different data and change permissions.

For each proposed connection, ask what breaks if it is removed. If the answer is “the task cannot complete,” document the dependency and its owner. If the answer is “developers find setup less convenient,” consider a separate development-only path rather than widening production access. Record failure behavior too: if a destination is unavailable, should the workload stop, return a partial result, or queue a request for a person? The correct response depends on the business process, but it should not be decided accidentally by a network timeout.

Keep this guide’s network advice at the boundary-design level. Detailed tracing of model, tool and business-system requests has its own implementation concerns, covered in a separate guide to tracing AWS agent interactions. If the workload uses browser or code execution, treat those as distinct execution boundaries rather than quietly absorbing them into the general agent network diagram; the design of those boundaries deserves its own review.

Make logs useful across boundaries

A landing zone should make it possible to reconstruct what happened at the infrastructure and service boundary without claiming that infrastructure records alone explain a business decision. Decide which events each operating team needs to investigate: workload startup and configuration changes, identity-related changes, network or destination failures, and the outcome of a request as reported by the service that owns it. The precise event sources depend on the implementation, so define the questions first and then map them to available records.

Use a consistent workload identifier across the account inventory, deployment record, logs and cost view. Include environment and owner where those labels can be carried safely. If two workloads both emit records under a vague name such as “assistant,” an incident responder may be unable to distinguish production activity from a test run. Labels are not a substitute for access controls, but they reduce ambiguity during diagnosis and reporting.

Set a minimum operational record before the first production release. It should let an operator answer: which workload and environment was involved, when did the event occur, which destination was being used, what class of operation was attempted, and where can the responsible owner be found? Avoid placing sensitive request content into general operational logs by default. Decide which business record is authoritative for the content and result of an operation, and what limited references can connect an operational event to it.

Define retention and access by purpose. The team investigating runtime failures may need operational records, while a broader audience may only need aggregated service health or cost. Record who can read each category, how long it is retained under the organization’s policy, and who handles a request to investigate a historical event. Do not promise a retention duration without checking the organization’s actual operating and regulatory needs.

Test the logging design with a failure, not only a successful request. For example, simulate a denied destination or an unavailable business API in a controlled environment. Can the operator identify the workload, see the failure category, find the owner and determine whether a business record was created? If the evidence only shows that the model call completed, the operational story is incomplete. The test should also make clear which system owns the final business outcome.

Logging and tracing are related but not interchangeable. A useful landing-zone baseline provides consistent identity, environment and ownership context; a deeper tracing design follows individual agent steps and their relationship to business-system activity. Keep the boundary clean so teams do not mistake basic infrastructure records for end-to-end evidence of what a multi-step request did.

Allocate costs to accountable units

Cost allocation is an ownership design problem as much as a reporting problem. A line item that cannot be connected to a workload, environment and accountable team is difficult to use for a budget decision. Agree on the allocation unit before teams deploy: perhaps a product, a business service or a separately funded workload. The unit should match a real decision-maker rather than a label invented solely for a dashboard.

At minimum, identify the owner, environment, workload name and cost center or equivalent internal allocation label. Decide how shared platform costs will be handled. If a common network or observability layer supports several workloads, state whether those costs remain central, are allocated by an agreed rule, or are shown separately as shared infrastructure. Do not present an arbitrary split as measured consumption.

Separate direct attribution from allocation. Direct attribution means a charge is associated with a resource or boundary assigned to a workload. Allocation means a shared charge is distributed according to a chosen method. Both can be useful, but they answer different questions. A team should be able to tell whether a number reflects a workload-specific resource or a portion of a shared service, and how that portion was calculated.

Use a simple monthly review to catch ownership drift. Compare the cost view with the account and workload inventory. Investigate resources that have no owner, workloads whose environment label is missing, and shared costs whose allocation rule has changed. A small reconciliation is more useful than a complicated report no one trusts. It also surfaces deployments that have outlived their product experiment or moved to a new team without their cost record being updated.

For an illustrative calculation, suppose a hypothetical organization has a shared platform charge of $1,200 for a month and chooses to allocate it across three workloads by their share of recorded requests: 50%, 30% and 20%. The resulting allocations are $600, $360 and $240. Those figures are arithmetic examples, not AWS prices or a claim that request count is a good cost driver. If the workloads have materially different request complexity, the organization should choose a more defensible driver or keep the charge visibly shared rather than imply that request share measures consumption.

Cost reports can influence architecture, but they should not drive unsafe consolidation. Two workloads should not share an identity or account merely because that makes an allocation report shorter. Likewise, an account split should not be justified only by a desire for cleaner chargeback if the organization cannot operate the additional boundary. Use cost visibility to inform the account decision, not to replace the questions of ownership and access.

Worked example: a support-operations agent

Consider a hypothetical mid-market software company building a support-operations assistant. It summarizes selected case information and drafts a proposed response. In a later phase, the company may consider submitting a case update, but the first release is intended to draft only. The support platform team owns the workload; the case-management team owns authorization and record changes; finance wants to distinguish experimentation from production spend.

The first boundary statement is: “The production assistant may read the approved case fields needed for a response and return a draft to the support application. It does not submit case changes.” The statement names the workload’s limit and the business system’s role. The design team then records a separate future decision point: any move from drafting to submitting changes requires a new review of user authorization, identity context, network paths, logs and cost ownership. It is not a minor configuration toggle in this architecture.

For account structure, assume the support platform team operates the assistant separately from the case-management product, with its own production release process and cost owner. A dedicated production workload account is a defensible choice because it aligns the account boundary with a distinct operating owner and budget view. The team keeps development separate from production, uses representative non-production data, and avoids granting the development workload access to live cases merely to make demonstrations realistic. If the company instead operated the assistant as a small component in the case-management product’s existing lifecycle, colocating it could be reasonable; the deciding factor is operational responsibility, not the word “agent.”

For identity, the deployed assistant receives a workload identity that identifies this production workload to the services it calls. The support application also carries the requesting user context to the case system or to an authorization component the case team trusts. The case system remains responsible for deciding whether that user may access a particular case. Even though the first release only drafts, the team checks that the workload cannot turn its read access into an unreviewed write path through a broader shared service credential.

For network design, the team lists only the paths needed for a draft request: from the support application to the workload, from the workload to its approved model destination, and from the workload to the case API for selected reads. It records the owner of each destination and what the user sees if the case API is unavailable. It does not grant a general-purpose outbound path because “the agent may need it later.” If a future feature introduces another destination, the team updates the path inventory and reviews the boundary before deployment.

For logs, the team chooses a stable workload identifier and environment label that appear in the operational record and the account inventory. The failure exercise is a denied case API request. The operator should be able to identify the production workload, find the case team as destination owner and see that the read failed, without treating a generated draft as proof that a case was updated. The case-management record remains authoritative for any change; in this initial design, no update is expected.

For cost allocation, the production workload has a named product owner and a separate label from development experiments. The common platform share is reported as shared rather than split using an arbitrary request count until finance and engineering agree on a useful driver. The monthly review checks that the production account and workload label still point to the support platform team. This makes it possible to ask whether the product is worth operating without presenting an allocation estimate as exact consumption.

The example exposes the order of decisions. The account does not decide whether the user may update a case. The workload identity does not establish that user’s authority. A network path does not grant business permission, and an operational log does not prove a business result. Each boundary has a specific job; the architecture is coherent when those jobs connect without being confused.

Failure analysis and counterexamples

A common failure begins with a shared prototype account. The prototype becomes useful, a second team adds a workflow, and production traffic arrives before anyone revisits ownership. The account now contains workloads with different destinations and operators, while a single identity or cost label obscures which activity belongs to whom. During an incident, the team must first reconstruct what was deployed. The prevention is not necessarily to split every prototype immediately; it is to set a promotion trigger. A workload moving to production, changing owner, or requiring a new business system path should trigger an account and identity review.

Another failure is over-centralization. A platform team creates a separate account for every experiment, but product teams cannot manage routine deployment changes and the central group becomes a bottleneck. Teams then copy credentials into local environments or bypass the approved path to meet a deadline. In this counterexample, more account boundaries have not produced more effective control. Revisit whether the boundary matches operational ownership and give workload teams a supported path for ordinary changes, while retaining review for changes that alter access or destinations.

A third failure is treating workload recognition as user authorization. The agent is known to the infrastructure, so a downstream service accepts a broad operation under a shared service identity. A user who could not make the change directly may now cause it through the assistant. The design failed because it answered “which workload called?” but not “may this user perform this action on this record?” Trace the allowed and denied user cases through the business authorization point, and make the system of record’s decision—not the agent’s confidence or infrastructure identity—the relevant boundary.

A fourth failure is permissive networking added during debugging and never removed. The original symptom may have been a missing destination or an unavailable dependency, but broad access makes the workload harder to reason about and can conceal the actual dependency list. Record temporary changes with an owner and expiry, then verify removal in the release review. If a path is genuinely needed, name its purpose and destination rather than keeping a vague exception.

Logging can fail in a quieter way: every component emits records, but each uses a different workload name or timestamp convention and no record points to the owner. During a service interruption, engineers can see activity but cannot join it to the deployed workload or determine whether the business system accepted a change. Define a small shared set of identifiers and test a failure path before production. If the record is not useful to the on-call operator, adding more event volume is unlikely to fix the core issue.

Cost reporting can create false precision. A team distributes shared platform spend across workloads by request count, then interprets the resulting values as each workload’s actual consumption. If request shapes vary, that allocation can distort product decisions. Label the number as an allocation, explain its driver and review whether that driver remains appropriate. If no defensible driver exists, show the shared amount separately until the organization can improve attribution.

Workload scaling is another adjacent but distinct design question. An account and identity baseline should not be mistaken for a capacity plan; changes in concurrency or workload shape can introduce constraints that the ownership design does not answer. Use a separate analysis of agent workload scaling constraints when that question becomes material, rather than overloading the landing-zone review with unverified capacity assumptions.

A decision worksheet for the first design review

Use this worksheet to make the first architecture decision concrete. It is intended to be copied into a design record, not treated as a certification or a universal control checklist. A blank answer is a useful signal: it identifies what the team must decide before relying on the proposed boundary.

Workload and account

• Name the workload and operating owner. Use a name that will also appear in deployment records and cost reporting. Identify the team that handles routine operation, not only the project sponsor.
• State the allowed business purpose and explicit limit. Describe the data the workload may access and whether it can draft, recommend, submit or record an action. Avoid broad descriptions such as “support automation.”
• Choose the account boundary and explain why it follows ownership. Record whether production is dedicated or shared with a product, and identify the release, support or budget responsibility that makes the choice practical.
• Name the review trigger. Examples include a move to production, a new operator, a new destination, a shift from read to write, or an environment that begins carrying real business data.

Identity and network

• Name the workload identity and its owner. State which deployment it represents and which destinations it needs. Distinguish production from development where their permissions or owners differ.
• Trace user authorization to the business decision point. Show how the requesting user and resource context reach the service that decides whether the action is allowed. Record one allowed and one denied example.
• List each runtime network path and its purpose. Include the initiating workload, destination, destination owner and expected behavior if the path fails. Separate runtime traffic from administration.
• Remove assumptions disguised as future needs. If a destination is not required for the initial workload, leave it out and define how a future request to add it will be reviewed.

Logging and cost

• Specify the minimum useful operational record. An operator should be able to identify workload, environment, time, destination or failure category, and owner without relying on sensitive request content in general logs.
• Choose the authoritative business record. State which service establishes whether a business change occurred. Do not treat a successful model response or a workload log as proof of an external result.
• Assign a cost owner and allocation unit. Name the product, team or service that reviews direct costs and decide how shared platform charges are shown.
• Label estimates and allocations accurately. State the calculation driver and its limitations. Do not describe an allocated share as directly measured workload consumption.

Printable review summary

• Boundary is understandable: a reviewer can say what the workload is allowed to do and what it is not allowed to do.
• Account ownership is operational: the account choice reflects who releases, supports and funds the workload.
• Identity is not confused with business permission: the user-specific authorization decision is visible in the request path.
• Network paths are justified: each required destination has a purpose, owner and failure behavior.
• Records support diagnosis: a controlled failure can be investigated by the responsible team.
• Costs have an owner: direct charges and shared allocations are distinguishable and reviewable.

A design with unresolved items can still be a useful draft, but mark the open decision, its owner and the condition that blocks production use. Avoid replacing an unresolved decision with “temporary” broad access unless the exception is deliberately bounded, time-limited and reviewed before the workload depends on it.

Summary and next steps

The first AWS agent landing-zone decisions are organizational and operational: who owns the workload, which account reflects that responsibility, how infrastructure recognizes the workload, where user authorization is decided, which network paths are necessary, what records support investigation, and how costs map to a decision-maker. Treat these as connected boundaries, not as a checklist of unrelated cloud settings.

Begin with one representative workload and one complete request path. Write the allowed purpose, draw the account and destination boundaries, separate workload identity from user authorization, and test how a denied or unavailable dependency would appear to an operator. Then assign cost ownership and distinguish directly attributable charges from shared allocation. Revisit the design when the workload changes owner, environment, destination or ability to affect a business record.

For organizations building a repeatable implementation path across teams, cloud platform engineering can help shape the operating conventions and reusable boundaries behind that path. The next practical step is to bring the worksheet to a review with the workload owner, platform operator, business-system owner and finance representative, then record decisions and unresolved items in the workload’s design record.

Once the landing-zone boundary is clear, keep adjacent design questions in their proper scope: end-to-end request tracing, isolated browser or code execution, and workload scaling need their own analysis. That separation helps the landing zone remain a durable foundation instead of turning into a catch-all document whose most important decisions are hard to find.