What IT services does AIATS provide?

AIATS provides comprehensive IT services including 24/7 helpdesk support, cloud solutions (AWS & Azure), business telecoms, network infrastructure, cybersecurity, disaster recovery, virtual desktop infrastructure (VDI), and ServiceNow implementation for UK businesses.

Where is AIATS located and what areas do you serve?

AIATS is headquartered in Swanley, Kent, and serves businesses across London, the South East, and the wider UK. We provide both on-site and remote IT support depending on your needs.

Do you offer a free IT evaluation?

Yes, AIATS offers a free, no-obligation IT evaluation where our experts assess your current infrastructure, identify opportunities for improvement, and provide a detailed roadmap with transparent pricing.

What is your response time for IT support requests?

Our consultants typically respond within 2 business hours for standard requests. For critical issues, we provide 24/7 monitoring and emergency support with rapid response times.

What industries does AIATS specialise in?

We serve Healthcare & NHS, Finance & Banking, Legal & Professional Services, Manufacturing, Retail & E-Commerce, Education, Logistics, Media & Entertainment, Real Estate, and Hospitality sectors.

Are you certified in cloud platforms like AWS and Azure?

Yes, our team holds certifications across major platforms including AWS, Microsoft Azure, ServiceNow, Cisco, and VMware. We are trusted partners for cloud migrations, management, and optimisation.

What is your uptime guarantee?

We maintain a 99.9% uptime across our managed services, with zero unplanned outages in the past 12 months. Our proactive monitoring ensures your business stays connected 24/7.

How do you ensure data security and compliance?

We implement enterprise-grade security measures including Zero Trust architecture, firewalls, VPNs, intrusion detection, and regular security audits. We help businesses achieve compliance with GDPR, ISO 27001, and Cyber Essentials.

Host MCP on Bedrock AgentCore Runtime

MCP servers need a real home

Most UK teams that adopt Model Context Protocol start the same way: a FastMCP process on a laptop, or a container on a shared EC2 box, pointed at by Claude Code or Cursor. That is fine for a spike. It is not fine for tools that can read tickets, open change windows or call payment APIs.

Amazon Bedrock AgentCore Runtime is AWS's managed answer for hosting those MCP servers as containerised workloads — with session isolation, scaling and CloudWatch observability — so coding agents and production agents share a governed tool plane.

What AgentCore Runtime expects

When you deploy an MCP server to AgentCore, the container must expose the MCP streamable-HTTP endpoint at:

0.0.0.0:8000/mcp

That matches the default path used by official MCP SDKs (including FastMCP). Clients then invoke the deployed runtime through the regional AgentCore invocations endpoint (ARN-encoded), authenticated with IAM SigV4 or OAuth bearer tokens (for example via Cognito).

Mode	Config	Use when
Stateless (recommended default)	`stateless_http=True`	Most tools; platform can manage session continuity headers
Stateful	`stateless_http=False`	Elicitation, sampling, or progress notifications that need sticky session state

Deploy path in practice

Author — Define tools with the MCP Python SDK (FastMCP) or TypeScript SDK.
Test locally — Run on localhost:8000 and validate with an MCP client or MCP Inspector.
Scaffold — Install the AgentCore CLI (npm install -g @aws/agentcore) then run agentcore create --protocol MCP (generates agentcore/agentcore.json and project layout).
Deploy — agentcore deploy packages dependencies, uploads to S3 and creates an AgentCore Runtime (you get a runtime ARN).
Invoke — Point approved agents at the invocations URL with the right qualifier (typically DEFAULT).

AWS publishes IAM and OAuth sample implementations under the MCP deployment patterns repository — start from those rather than inventing auth from scratch.

How this differs from AgentCore Gateway

Do not confuse the two:

Gateway turns your Lambdas / OpenAPI APIs into MCP tools for agents to call (managed MCP server in front of existing backends).
Runtime (this pattern) hosts your MCP server code as the workload — useful when the tool logic is custom, multi-step, or needs a dedicated container.

Many UK estates will use both: Gateway for commodity enterprise APIs, Runtime-hosted MCP for specialised diagnostic or domain tools (including patterns adjacent to the AWS MCP Server serverless Lambda diagnostics capability).

UK enterprise checklist

Security and identity

Prefer IAM SigV4 for service-to-service agents; use OAuth when human-delegated coding agents need user context.
Scope each runtime role to the minimum AWS APIs the tools need — no wildcard on production accounts.
Keep PII and payment tools in a separate runtime and account boundary from read-only observability utilities.

Operability

Wire CloudWatch metrics and logs to your existing observability stack on day one.
Version the container image; treat agentcore deploy like any other release (change ticket, rollback ARN).
Load-test cold starts for interactive IDE use cases — developers abandon tools that stall.

Governance

Register every production MCP endpoint in an internal catalogue (owner, data class, blast radius).
Block laptop MCP servers from production IdP / VPN paths once the AgentCore endpoint is live.
Align with your Bedrock Guardrails and AgentCore Identity plans so tool auth is not reinvented per agent.

A sensible 30-day cutover

Days 1–7 — Inventory MCP tools in use (personal configs included). Classify read-only vs mutating.

Days 8–14 — Move one read-only tool (for example config/diagnostics) to AgentCore Runtime with SigV4. Dual-run laptop vs Runtime for the pilot team.

Days 15–21 — Add one mutating tool behind stronger IAM and change-control. Document failure modes (timeouts, partial writes).

Days 22–30 — Retire the laptop endpoint for that team, publish the invocations URL to approved agents only, and schedule the next three tools through the same factory.

When not to use this pattern

Pure OpenAPI/Lambda backends with no custom MCP logic — prefer AgentCore Gateway.
Strict multi-cloud portability requirements — AgentCore is AWS-specific; accept that or keep a portable container you can also run on EKS.
Ultra-custom runtimes that need exotic OS packages AgentCore will not allow — validate image constraints early.

Bottom line

If MCP is becoming your enterprise tool bus, stop hosting it on developer workstations. Put the servers on AgentCore Runtime, authenticate properly, observe them like any other production service, and let Gateway handle the boring API wrapping. That is the difference between a demo and a platform UK risk teams will sign off.

Hosting MCP Servers on Amazon Bedrock AgentCore Runtime: A UK Production Pattern