AWS → STACKIT SERVICE MAPPING

AWS vs STACKIT service mapping

Where every AWS service lands on STACKIT, and what the move takes. The mapping below is the one StackToIT decided for a real AWS estate, resource by resource.

The mapping of a real AWS estate

From the published StackToIT run on the AWS Retail Store Sample App: compute, data, messaging, identity, network and observability.

AWSSTACKIT targetMigration class
Amazon ECS cluster and servicesSTACKIT Kubernetes Engine (SKE)Replatform
Aurora PostgreSQLSTACKIT PostgreSQL FlexReplatform
Aurora MySQLSTACKIT MariaDBReplatform
Amazon DynamoDBSTACKIT MongoDB Flex (PostgreSQL Flex JSONB as the alternative)Redesign
Amazon OpenSearch ServiceSTACKIT OpenSearchReplatform
Amazon ElastiCache (Redis)STACKIT Key Value Store (Valkey)Reconfigure
Amazon MQSTACKIT RabbitMQReconfigure
Amazon EventBridge rulesApplication events over STACKIT RabbitMQRedesign
AWS IAM rolesSTACKIT service accounts and role assignmentsReconfigure
AWS KMS keysSTACKIT KMS key rings and keysReconfigure
AWS Secrets ManagerSTACKIT Secrets ManagerReconfigure
Amazon VPCSTACKIT Network Area and networksReconfigure
SubnetsSTACKIT networksReconfigure
Security groupsSTACKIT security groups and rulesReconfigure
Network ACLsSTACKIT security groups (stateful)Redesign
Internet and NAT gatewaysBuilt into the STACKIT networkReconfigure
Application Load BalancerSTACKIT Application Load BalancerReconfigure
Route 53 recordsSTACKIT DNS record setsReconfigure
VPN gatewaySTACKIT VPNReconfigure
CloudWatch log groupsSTACKIT LogsReconfigure
CloudWatch alarmsSTACKIT Observability alert rulesReconfigure

The class depends on the configuration of each resource. Your own run states the target and the reason for every resource in your estate.

What each migration class means for your plan

  • Direct

    Same service, same settings. The move is a deployment.

  • Reconfigure

    Same kind of service on STACKIT, with settings that change. Most network, identity and messaging resources land here.

  • Replatform

    A different managed service with the same role: ECS to Kubernetes, Aurora to PostgreSQL Flex or MariaDB.

  • Redesign

    No counterpart, so the architecture changes: DynamoDB access patterns or EventBridge routing are rebuilt on purpose.

  • Architect decision

    A question the code cannot answer, such as an enhanced-monitoring role, becomes a named decision for your team.

What the Retail Store run produced

The published run read the estate and ordered 44 units that are switched on in its configuration.

  • Classes

    34 units are Reconfigure, 9 are Replatform and 1, the DynamoDB carts table, is Redesign. None is a like-for-like Direct move. In this estate the network ACLs in the table above are switched off and the EventBridge rule exists only under a condition decided at plan time, so neither counts among the 44.

  • Domains

    Network 16, identity 15, compute 6, data 5, observability 1 and messaging 1.

  • Dependency waves

    The 44 units fall into nine waves of 9, 14, 7, 5, 3, 2, 2, 1 and 1, so foundations come before the databases and services that rest on them.

  • Confidence

    35 units are medium and 9 are low. The source ships no provider lock file, which caps the units of that provider at medium.

  • Draft

    Of 52 units considered, 38 produced Terraform, 11 needed no resource and 3 are manual work.

Where the five applications stand

StackToIT proposes the applications from the references in the source.

ApplicationStateWhy
cartsRedesignThe DynamoDB table needs a data-model change on MongoDB Flex
catalogBlockedThe OpenSearch engine is a downgrade from 3.3 to 2 until tested or decided
checkoutRedesignShares the DynamoDB redesign; clients need the TLS-only Valkey endpoint
ordersNot readyEnvironment values are required and the workload identity is undecided
uiNot readyThe workload identity is undecided and no functional check has run

From the published run; the states change as decisions are answered.

Proven on a real AWS estate

The AWS Retail Store Sample App, a public Terraform project from AWS, assessed by StackToIT and published in full, exactly as the run wrote it.

View Case Study
282
Terraform resource declarations analyzed
44
migration units identified
38
target units generated, from 52 considered
331
plan steps written

Questions architects ask

What replaces Amazon EKS and ECS on STACKIT?

STACKIT Kubernetes Engine (SKE). ECS services are replatformed to Kubernetes workloads; EKS clusters move to SKE clusters with their node pools.

What replaces Amazon RDS and Aurora?

PostgreSQL engines go to STACKIT PostgreSQL Flex, MySQL engines to STACKIT MariaDB, and SQL Server to SQLServer Flex.

Is there a DynamoDB equivalent on STACKIT?

No managed DynamoDB-compatible service exists, so StackToIT plans a redesign onto MongoDB Flex or PostgreSQL Flex with JSONB, with each table, key and index named.

Sources

Your next move: STACKIT.

Tell us about your estate. We show you what StackToIT delivers for it: target architecture, Terraform artifacts and a structured migration plan.