AWS Lambda on STACKIT: choose the container platform per function

The options for one function

Pick per function, not per estate. A queue worker, an HTTP function and a nightly job rarely want the same platform.

The Functions API row states what the run found. STACKIT's product overview listed no function service on 4 November 2026 (its runtime products are Cloud Foundry, Edge Cloud and Kubernetes Engine), and the stackitcloud/stackit provider, in the version the run used (0.121.0) and in 0.122.0, has no function resource.

A queue worker: the function and its trigger

Input written for this page and assessed on 4 November 2026. Left: a container-image function and its SQS event-source mapping. Right: the Cloud Foundry manifest StackToIT wrote for it, without the comment lines above it in the file.

resource "aws_lambda_function" "worker" {
  function_name = "orders-worker"
  role          = aws_iam_role.fn.arn
  package_type  = "Image"
  image_uri     = "123456789012.dkr.ecr.eu-central-1.amazonaws.com/orders-worker:1.4.0"
  memory_size   = 512
  timeout       = 60

  environment {
    variables = {
      QUEUE_URL = aws_sqs_queue.orders.url
    }
  }
}

resource "aws_lambda_event_source_mapping" "orders" {
  event_source_arn = aws_sqs_queue.orders.arn
  function_name    = aws_lambda_function.worker.arn
  batch_size       = 10
}

---
applications:
- name: "orders-worker"
  memory: 512M
  instances: 1 # one always-on instance; size from peak concurrency (App AutoScaler for elasticity)
  stack: cflinuxfs4
  buildpacks:
  - ((buildpack))
  no-route: true
  health-check-type: process
  env:
    "QUEUE_URL": ((orders_worker_queue_url))

• REDESIGN, confidence LOW

  Two findings stack up: an SQS event-source mapping has no trigger twin on STACKIT, and a container image gives a buildpack nothing to stage.

• The worker runs without a route

  The manifest sets no-route and a process health check, because nothing calls the worker over HTTP. The comments in the file mark these two attributes as unconfirmed against STACKIT’s own documentation.

• The queue moves with it

  The SQS queue is classed REPLATFORM, with a RabbitMQ instance drafted. Queue names and visibility timeout are not created; the consumer acknowledges instead.

A scheduled, HTTP-invoked function

The second function has a zip package, a schedule rule and a function URL. It is classed CONTAINERIZE with confidence MEDIUM. Right: its manifest, without the comment lines above it in the file.

resource "aws_lambda_function" "report" {
  function_name = "nightly-report"
  role          = aws_iam_role.fn.arn
  runtime       = "python3.12"
  handler       = "app.handler"
  filename      = "report.zip"
  memory_size   = 256
  timeout       = 300
}

resource "aws_cloudwatch_event_rule" "nightly" {
  name                = "nightly-report"
  schedule_expression = "cron(0 2 * * ? *)"
}

---
applications:
- name: "nightly-report"
  memory: 256M
  instances: 1 # one always-on instance; size from peak concurrency (App AutoScaler for elasticity)
  stack: cflinuxfs4
  buildpacks:
  - python_buildpack_offline

• Runtime mapped to a buildpack

  python3.12 maps to the offline Python buildpack. STACKIT lists that buildpack for the cflinuxfs4 stack, but not which Python versions it ships.

• The schedule becomes a CronJob

  The EventBridge rule is classed CONTAINERIZE and drafts an SKE cluster. The CronJob manifest itself is written by hand.

• IAM-protected URL, public route

  The function URL requires AWS IAM signing. A Cloud Foundry route is public, so the app must authenticate callers itself.

The platform blocks in Terraform

The two Terraform resources that carry these decisions: the organisation that hosts the apps and the cluster for containers. Spaces and apps are pushed with the cf tool, not Terraform.

resource "stackit_scf_organization" "migrated_apps" {
  project_id = var.project_id
  name       = "migrated-apps"
}

resource "stackit_ske_cluster" "containers" {
  project_id = var.project_id
  name       = "containers"
  node_pools = [{
    name               = "workloads"
    machine_type       = var.containers_machine_type
    minimum            = var.containers_nodes_min
    maximum            = var.containers_nodes_max
    availability_zones = var.availability_zones
  }]
}

How to decide for each function

• What invokes it?

  An HTTP caller fits a Cloud Foundry route. A queue needs a consumer loop. A schedule fits a CronJob. Everything that invoked the function in AWS has to be rebuilt; the manifests state that no trigger carries over automatically.

• How is it packaged?

  A zip package can go to a buildpack. A container image stays a container, so it goes to SKE.

• Does it need scale to zero?

  Cloud Foundry and SKE run instances you size. The per-invocation billing and scale-to-zero of Lambda do not carry over. Short, rare jobs need not hold an instance as a CronJob: they run only on schedule, on nodes the cluster already has.

• How long does a call run?

  The Lambda timeout is not carried: a manifest timeout is a start-up timeout. Put the limit into the application or the platform around it.

• What does it hold?

  The execution role becomes a service account or service credentials supplied through the environment. List what the attached policies allowed and grant the same on the STACKIT targets.

Questions platform teams ask

Sources

• AWS: Using Lambda with Amazon SQS
• STACKIT Docs: product overview
• STACKIT Docs: Containers and buildpacks
• STACKIT Docs: Offline buildpacks
• STACKIT Docs: Manifest files
• Terraform Registry: stackitcloud/stackit provider