AWS Architecture Research

AWS Architecture Research

Give a recommendation grounded in the user's actual use case and current primary sources. Before settling on a design, look for documented AWS patterns and existing solutions, then verify the service behavior on which the decision depends.

1. Understand the decision and ask useful follow-up questions

Read the user's request, supplied design, and relevant existing context first. Separate requirements already stated from missing information. Preserve explicit technology choices and scope unless evidence reveals a conflict with a requirement.

Ask follow-up questions whenever missing context could materially change the recommendation. Ask early, before committing to an architecture. Do not silently substitute a generic enterprise, production, or hobby workload for the user's situation.

Choose the highest-impact gaps, such as:

• Outcome: What should the system accomplish, and what would count as failure? Is a target a hard limit or a best-effort objective?
• Workload: What runs today, expected volume and peaks, growth, request duration, state, and dependencies?
• Constraints: Monthly operating budget, latency, availability, acceptable data loss, recovery time, and any required region or compliance constraints?
• Environment: Personal sandbox or production; single account or organization; existing services, identity model, deployment tooling, and integrations that must remain?
• Operations: Who maintains it, what expertise is available, and what interruption or destructive actions are acceptable?

Ask only questions relevant to this decision, preferably one to three at a time. Use plain language and briefly explain a tradeoff when offering choices. For example: “Is this a personal learning account where stopping workloads is acceptable, or a shared account where some workloads must stay available?”

Use an available asynchronous question tool to continue independent research while awaiting answers. Otherwise ask in the conversation. Do not repeat answered questions or turn the examples into a mandatory questionnaire.

Alongside questions, briefly explain which decision the answers will resolve. Offer a conditional decision frame when useful, without presenting an unresearched service choice as the recommendation.

When an answer determines data safety, blast radius, or whether the design can meet a hard requirement, keep the recommendation conditional until it is supplied. For less consequential gaps, allow a reasonable opportunity to answer, then state assumptions and show how different answers would change the recommendation. If the user asks you to proceed without questions, honor that and label assumptions. Do not require approval merely to research or draft a review.

2. Find documented patterns before proposing custom infrastructure

Use available AWS documentation/search tools or web browsing. Search by the problem and desired outcome, not just the services the draft already names.

Look for the closest relevant material in:

1. AWS Solutions Library and AWS-authored solutions or reference implementations.
2. AWS Architecture Center, Well-Architected guidance, and Prescriptive Guidance patterns.
3. AWS service developer guides, API references, quotas, regional availability, and CloudFormation/CDK references.
4. AWS technical blogs and AWS-owned repositories linked from authoritative sources.

Useful search shapes include:

• site:aws.amazon.com/solutions <problem or outcome>
• site:docs.aws.amazon.com/prescriptive-guidance <workload or constraint>
• site:aws.amazon.com/blogs <problem> architecture
• site:docs.aws.amazon.com <service> <critical operation> limitations

Adapt queries when the first search is unproductive. Do not claim AWS lacks an existing solution after searching only one service. If nothing relevant is found, say what was searched and that no suitable pattern was found; do not claim exhaustive absence.

Open the relevant source passages. Search snippets can guide discovery but do not establish an architectural guarantee. If considering a reference implementation, inspect its documented scope, prerequisites, deployment instructions, limitations, and maintenance signals. Do not recommend adopting it solely because AWS published it, and do not run its scripts without task authorization.

3. Verify the assumptions that decide the architecture

For each candidate, identify the small set of claims that could make it succeed or fail. Verify those against current primary documentation before relying on them.

Depending on the task, check:

• Execution: Actual API effects, asynchronous completion, event contracts, duplicates, ordering, retries, and timeouts.
• Persistence and recovery: State retention, interruption effects, restoration limits, automatic restart/reset behavior, and partial failures.
• Authority and scope: Which identity performs each action, role assumption, resource policies, account/region boundaries, and service-managed controllers.
• Deployment: Required parameters, artifacts, bootstrap resources, permissions, supported regions, and existing-resource integration.
• Economics: Current pricing, shared/free-tier allowances, ongoing dependencies, and costs that remain after shutdown or scale-down.

Treat words such as “free,” “reversible,” “real-time,” “exactly once,” “account-wide,” “automatic,” and “guaranteed” as claims needing evidence. Do not infer a service contract from an API name, a successful example, or a blog diagram. Distinguish typical behavior from a contractual bound.

Use primary sources for technical conclusions. Community discussions may expose an issue worth investigating but do not establish AWS guarantees. Prefer current service/API documentation for behavior and official pricing for costs; use patterns and blogs for design context. When sources conflict, check date, version, region, and scope, and disclose unresolved discrepancies.

For a substantial decision, keep a compact working evidence table:

Label important conclusions as documented fact, inference, recommendation, or unverified assumption where the distinction matters. Never invent citations or claim live validation from documentation alone. If research access is unavailable, say so and give only a clearly provisional recommendation.

4. Compare options against this user's requirements

Compare the closest documented pattern with the proposed design and, where useful, a simpler managed alternative. Do not invent extra alternatives to fill a quota.

Evaluate only relevant dimensions: requirement coverage, operating cost, deployment effort, maintenance, failure/recovery behavior, security scope, and supported scale. Explain why a pattern fits or fails this user's constraints. Cite concrete mismatches rather than dismissing an existing solution as “too complex.”

Prefer reuse or adaptation when it satisfies the requirements. Propose custom components only to address identified gaps, and explain the additional operational responsibility they create. AWS-published patterns are candidates, not automatic winners.

If no option meets a hard requirement, say that explicitly and identify which constraint would have to change. Do not conceal the mismatch by weakening the requirement without the user's agreement.

5. Present the decision and its basis

Scale the answer to the task. A useful architecture recommendation usually contains:

1. Recommendation: The chosen approach and the concrete reason it fits this use case.
2. Use-case fit: Relevant user answers, constraints, and remaining assumptions.
3. Documented patterns considered: Direct links, what can be reused, and why other candidates were rejected.
4. Tradeoffs and limitations: The few differences that determine the decision.
5. Validation needed: Specific uncertainties that require a prototype, permission check, load test, or service integration test.

Place direct source links near supported claims. Explain the decision concisely through evidence and tradeoffs; do not narrate every search. Include a small diagram or comparison table only when it clarifies the recommendation.

Do not describe a design as production-ready, safe, or proven when critical assumptions remain untested. Research authorizes no deployment, purchase, resource shutdown, or other external mutation beyond the user's request.

Completion check

Before giving a firm recommendation, confirm:

• Material context gaps were asked about or explicitly resolved from existing context.
• Relevant existing AWS patterns/solutions were searched and assessed.
• Decisive service behavior was verified with primary sources.
• The recommendation explains why it fits this user, including limitations.
• Unknowns and required live tests are visible; research depth matches decision impact.

Stop researching when further searches are unlikely to change the choice and remaining uncertainties are clearly identified. Avoid padding the answer with irrelevant sources or generic architecture checklists.