AWS MCP Server in New European Regions: Connect Agents to the Cloud with Clear Permissions

AWS MCP Server is a managed server that allows development agents to interact with AWS services through authorized tools. Geographic expansion makes other regional endpoints available, but it does not change the principle: the agent must only receive the permissions necessary for the task.

The 2 October 2026 AWS added six regions: Singapore, Sydney, Tokyo, Ireland, London and Oregon. Frankfurt was already available; Milan does not appear among the additions. For an Italian company it is an infrastructural news, to be evaluated together with the location of its systems and internal rules. Official announcement.

The most reasonable use to start is to help the team read configurations, gather information and prepare interventions. An agent capable of proposing an amendment should not automatically obtain the right to apply it. The distance between these actions is the center of the project.

What is MCP for when your company uses AWS?

MCP defines a way to present tools and context to an AI application. In the case of AWS MCP Server, the typical recipient is a development agent who needs to work in the cloud. It is not an already trained chatbot about the company's procedures and does not replace the system administrator.

A manager can request a reconnaissance of resources relevant to an application or help to understand a configuration. To respond, the agent uses tools exposed by the server. Actual access depends on authentication and permissions, not just the text of the request. The AWS Guide to Linking describes the setup and authentication modes.

The distinction between model and tools is also useful outside of AWS. A model can include a request without having access to the data needed to run it. The guide to AI agents explains this step: a system becomes operational when it can use tools, but precisely for this reason it must be checked on the effects of actions.

Which region to choose for the MCP server?

The availability of a European endpoint may be relevant for a company with infrastructure or operational requirements in Europe. However, it is necessary to distinguish the place where the request is addressed to the server from the place where the resources concerned reside. Choosing an endpoint is not automatically the same as moving applications, data, and logs.

For new regions, the source to use is the dated release announcement. The consulted setup guide retains an earlier list with Virginia and Frankfurt: that table should not be read as a denial of expansion nor used to invent endpoints. The operational step requires verification of the updated documentation and the client actually adopted. AWS Regional Expansion.

Ireland and London also require separate assessments in corporate policies. It is not enough to call them both European to close the verification of treatments. Supplier, contract, transmitted data, any services involved by the agent and retention of results should be considered. Geographic choice is a part of the design, not a conformity formula.

Do OAuth and SigV4 have the same controls?

Documentation describes authentication paths with OAuth and SigV4. It is not advisable to consider them interchangeable without analyzing clients, identities and operating modes. A connected access to a user and a signed access with AWS credentials must be governed in their specific context. Documented Modes.

In particular, the documented ability to hide writing tools in read-only mode concerns the SigV4 path. It should not be promised generically for any client or configuration. And hiding a command in the interface does not replace an authorization policy: permissions must prevent action even when an unexpected request reaches the level below. AWS Setup and Controls.

An initial configuration should identify who uses the agent, what accounts they can query, what resources fall within the perimeter, and what operations are excluded. If these answers remain vague, the technical link can work while the project remains risky. The cloud manager must be able to revoke access without depending on the memory of the first tester.

How to separate reading, proposing and modifying the cloud?

This subdivision is a proposed operating method, not a set of product guarantees. It helps to prevent an ambiguous request, such as "system the environment", from becoming too broad an authorization. Each step should produce an understandable result even for those who did not participate in the conversation.

When the goal is to reach internal business management software, the problem changes. AgentCore Gateway with Private TLS It's about access to private tools and APIs for agents. AWS MCP Server described here is about interacting with the cloud: the two roles can live together, but they're not the same function.

Hypothetical scenario: a software house reads customer environments

Let's imagine a small software house that manages AWS applications for different customers. It wants to help developers rebuild the environment of a single application before an intervention. The pilot only exposes information relevant to the authorized account and environment, avoiding indistinct access to the entire portfolio.

The agent prepares a summary of the read configurations and reports the points to be verified. It does not modify resources and does not copy unnecessary credentials or application content into the results. The developer checks the summary and decides whether to open an intervention proposal in the normal team procedure.

It's a hypothetical scenario, not a client case. The test should include an attempt to consult an excluded environment, a write request and a question formulated with the wrong name of the client. The correct result can be a rejection. The value of the link also lies in making the boundaries visible, not just in facilitating allowed requests.

Hypothetical scenario: an e-commerce prepares a technical check

An Italian e-commerce can ask their team for an infrastructure check before a campaign. The agent collects the status of the authorized resources and helps organize the verifications, while the responsibility for the capacity and release remains with the technical staff. It is not assumed that the MCP server can predict commercial traffic.

The proposals produced are compared with real configurations and existing procedures. A hint of deleting, resizing, or opening accesses should be carefully reviewed. The fact that the proposal is consistent with a textual description does not prove that it is correct for that application.

This is also a hypothetical example. The pilot can compare inventory completeness, environmental errors, and evidence quality. No savings, continuous availability or performance improvements are promised. The Guide to AI Agents for Companies helps define more precise goals of "putting AI in the cloud".

What data can come out during an analysis?

Cloud configurations can contain internal names, architecture details, customer references, and operational information. Even when no application documents are read, the result of an inventory can be sensitive. Before linking, it is necessary to decide what data can be transmitted to the model and where the summaries can end.

The context of a conversation can be copied into a ticket, saved in logs, or shared with another tool. The control must then follow the entire path. The practical principle is to return to the agent the minimum necessary for the task and to retain proportionate evidence, without transforming any analysis into an export of the environment.

The theme links to the AI Data Security and the controls described for Claude Managed Agents and Network Access. In both cases, being able to reach a destination does not mean having any reason to send it any information. Authorization should be thought of together with the flow of data.

What to check before enabling scriptures?

Open the list for cloud link review

Identify clients, authentication methods, AWS accounts, allowed environments and excluded data. Test both authorised and unauthorised read requests. Check that unauthorised writes are blocked by permissions. Prepare access revocation, accessible logs and a change-review procedure before expanding the scope.

The test should not stop at the message "successful connection". You need to control what the agent actually sees, what it tries to call, and what the server refuses. A harmless question can produce too extensive results; an ambiguous question can direct you to the wrong account. These cases should be observed with identity and test permits.

The agent's environment must also be controlled. The theme of GitHub Copilot local sandbox shows another level of defense: limiting the process that executes tools. A local sandbox and cloud permissions protect different surfaces, so the presence of one doesn't make the other unnecessary.

Where are you wrong when the link works right away?

The first mistake is to use broad credentials to avoid obstacles to testing. The pilot becomes apparently simple, but does not prove that the flow works with the correct permissions. When the accesses are then restricted, the agent's results and behavior change. Better to immediately test the intended identity for real use.

The second is to confuse a list of regions with a data policy. The third is to read a well-written proposal as a technical verification. The fourth is to enable changes without being able to reconstruct who requested them and what evidence. They are errors specific to an operating assistant, because the text can become action.

It is also advisable to prepare for the failure of integration. If an endpoint changes, a session expires, or a permission is revoked, the agent must explain the limit without simulating a result. The team should know which channel to use to continue the work. A clearly interrupting assistant is more manageable than one who fills the voids with assumptions.

How to document a proposal before execution?

A proposed amendment should indicate the observed problem, the resources involved and the expected outcome. The team must be able to distinguish what the agent read from what he deduced. If a configuration appears unusual, it does not automatically mean that it is wrong: it may respond to a requirement that is not present in the conversation.

It is useful to ask for a description of the expected effect and the dependencies involved. A seemingly local change can affect applications, accesses, or recovery procedures. Human review should not be limited to the syntax of the proposed command: it must check whether the intervention really responds to the problem and whether it is appropriate for that environment.

The restoration must be prepared before the application. It is necessary to know which previous state to keep and how to verify it after a possible return. Here too the agent can help organize the information, but must not turn a plausible explanation into a guarantee. Whoever performs the intervention remains responsible for the chosen procedure.

To maintain continuity, the documentation may retain a short note with subsequent request, evidence, decision, and verification. You don't need to save every word of the conversation. An essential trace allows a colleague to understand why a decision has been made and what to check if a problem appears. It is especially useful when multiple people use the same agent on distinct environments.

Emergency access must remain separate from daily use. If an incident requires greater permissions, the exception should have a defined purpose, duration, and a manager. Stable expansion of the agent's rights to resolve a single obstacle makes it harder to rebuild the original perimeter and repeat checks later.

A useful check is to ask a colleague outside the test to read the proposal and rebuild the perimeter. If it fails to distinguish accounts, resources, and expected action, the documentation must be clarified prior to execution. This evidence makes the review concrete.

How to turn regional expansion into a useful project?

The initial choice should be a restricted, repeatable, and controllable cloud task: reading an environment, preparing a reconnaissance, or accompanying a diagnosis. You define identity, permissions, and expected result; then you evaluate whether the managed server makes that task easier in the business context.

The cost must include the entire architecture adopted, including AWS tools, model, and services involved. The regional ad does not offer a universal price of the project and this article does not hire one. Prior to adoption, the updated official documentation and account conditions must be checked.

If you want to connect an agent to the cloud with a perimeter readable by your team, the design of Giallo custom software can start from a read-only inventory and a reviewable intervention proposal. The choice of the region comes within this design, along with responsibility, access and verification of the result.