Skip to content
Talk to an architect
Platform and migration

Atlassian Data Center on AWS, from landing zone to run layer.

When Atlassian Data Center or the services around it run on AWS, Atlas Bench sizes the deployment, builds the landing zone, writes and runs the migration runbook, ties administrator access to IAM Identity Center and activity to CloudTrail, and supports the run layer afterwards.

Some estates keep Jira, Confluence, or Bitbucket on Data Center for a while longer and host it on AWS in the meantime. We size the deployment, build the landing zone under it, write the runbook that moves it, and keep it patched once it is there.

What it is

Data Center on AWS is rarely the final stop. It is where an estate waits while the app portfolio, a data residency review, or a renewal decides when Cloud happens, and that wait can outlast the project that started it. It still has to be built properly.

The shape is well understood: application nodes on EC2, or in an EKS cluster using Atlassian's Helm charts, a PostgreSQL database on RDS, shared home on EFS, and a load balancer in front. What goes wrong is decided in a hurry: instance sizes copied from the server being retired, production and test sharing one account, and database credentials nobody has rotated since cutover.

tiered support, with SLAs embedded architects the platform core escalation does not start from zero L1 L2 L3 L4

What it does

Sizing from your own load

Node counts, instance types, and database class come from the estate's real usage and Atlassian's Data Center scale guidance, not from the old server's specification.

A landing zone before the first node

Separate production and non-production accounts, private subnets for the application tier, and the network paths to your identity provider settled up front.

EC2 or EKS, chosen on purpose

Instances where the team wants hosts it can reason about; EKS with Atlassian's Helm charts where it already runs Kubernetes in production.

Where it fits

L2, platform and migration, with its access and its record held at L1 and L3. The nodes are platform. Who can administer them is answered in IAM Identity Center, and what anyone did to them is answered in CloudTrail.

L4

Agents and Automation

Rovo, Agents in Jira, Forge, MCP with Claude and Copilot, agent lifecycle, usage and cost governance.

Atlassian Anthropic
L3

Governance and Change

Permission architecture, audit and compliance, ITSM and change control, change management, strategic reporting and budgets.

Atlassian Guard Jira Service Management Strategy Collection Jira Align
L2

Platform and Migration

Migration of every kind, tool consolidation, licensing, standardization, the system of work.

Atlassian Miro AWS Azure
L1

Identity and Access

Human and non-human identity, SSO, SCIM, least privilege, access reviews, Guard cleanup, Agent SSO readiness.

Atlassian Guard Okta

load-bearing, bottom to top

What we do with it

Sizing and landing zone

Instance types, node counts, database class, and storage throughput sized to the estate, inside accounts and networks built for it.

Migration runbooks

A written, rehearsed runbook for moving from a data centre into AWS, or from AWS on to Cloud, with the cutover window and the rollback both tested.

IAM Identity Center and CloudTrail

Administrator access to the accounts assigned from your directory through IAM Identity Center, and a trail that attributes every console and API action.

Run-layer support

Upgrades, index rebuilds, node replacement, and the patch cadence Data Center depends on, handled as a standing service.

Where it earns its place

A server estate not ready for Cloud

Moving to AWS first ends the hardware dependency without forcing the Cloud decision early.

An AWS deployment built in a hurry

Production and test in one account, and an instance role that can reach far more than Jira ever needs.

Questions we get

Should Data Center go to AWS, or straight to Cloud?
Straight to Cloud when the app portfolio and residency requirements allow it. AWS first when they do not yet, with the first runbook written so the second move is shorter.
EC2 or EKS?
EC2, unless someone in your organization already operates Kubernetes in production. Atlassian's Helm charts pay off on EKS only when the cluster has an owner.
Do you take over the AWS account?
We run what the Atlassian estate needs inside it. The account, its billing, and its organization structure stay yours.

Licensing

Atlassian licenses Data Center separately from anything AWS bills. Hosting on AWS changes the infrastructure invoice, not the Atlassian subscription.

AWS's own page for AWS infrastructure, opens in a new tab

Find out what you are actually running.

Fixed scope. The assessment reads the estate as it is: instances, schemes, licensing, and the decisions a migration would force you to make anyway. You get the findings, the ownership gaps, and the order to close them in.

Get an agent readiness assessment

By sending this you agree to our privacy policy.

Not ready? Talk to an architect