--- title: "Internal Cloud Service Catalogue" description: "How an IT department offers cloud services as internal products: service catalogue structure, internal pricing, SLA definition, and the transformation from cost-centre to service-provider mentality." sidebar: order: 7 label: "Service Catalogue" source_url: "https://framework.stackit.cloud/adoption/adapting-operating-models/service-catalogue/" source_file: "docs/adoption/adapting-operating-models/service-catalogue.mdx" --- ## From IT department to internal cloud provider The cloud transformation fundamentally changes the role of the IT department. Instead of managing systems, platform services are provided. Instead of responding to tickets, products are offered that business units can consume themselves. This shift requires a service catalogue: the structured overview of all cloud services that IT offers internally — with clear service descriptions, prices, and quality commitments. Without a service catalogue, sprawl environments emerge where every team goes its own way, IT loses oversight, and costs grow uncontrolled. ## What a service catalogue delivers ![Service Catalogue Overview](./files/service-catalogue-overview.svg) **For business units:** A clear overview of what IT can offer, on what terms and at what quality level. No endless back-and-forth about which cloud services are permitted and which are not. **For the IT department:** Structured demand rather than ad-hoc requests. Plannable capacity. The basis for cost transparency and internal cost allocation. **For management:** Visibility of which services exist, what they cost, and which business units are using them. The basis for well-founded make-or-buy decisions. ## Five categories of a cloud service catalogue ### 1. Platform services — infrastructure as a product What STACKIT delivers, packaged as an internal offering with clear governance: | Service | Description | Internal SLA | Pricing model | | ------------------ | ----------------------------------------- | ------------------- | --------------------- | | Compute Standard | Virtual machines, standard tiers | 99.5% availability | per vCPU/month | | Kubernetes Managed | Managed Kubernetes cluster on STACKIT SKE | 99.9% control plane | per node hours | | Object Storage | S3-compatible object storage | 99.9% durability | per GB/month | | Managed Database | PostgreSQL/MySQL managed, daily backups | 99.5% availability | per RAM/storage | | Private Network | Dedicated VPC with firewalling | Best effort | flat rate per project | ### 2. Security services — security as standard Security is not ordered — it is part of every project. Nevertheless, there are optional add-ons: | Service | Description | Target audience | | ---------------------- | --------------------------------------------- | ------------------------- | | Vulnerability Scanning | Regular container and IaC scans | all production systems | | Secrets Management | Central vault for credentials and API keys | all teams with secrets | | PAM | Privileged access management for admin access | Tier 1 and Tier 2 systems | | Compliance Reporting | Automated evidence for GDPR, TISAX, BAIT | regulated workloads | ### 3. Data services — data as an asset | Service | Description | SLA | | ---------------------- | ------------------------------------------------------ | ----------- | | Data Lake Standard | STACKIT Object Storage with partitioning and catalogue | 99.5% | | Managed Analytics | On-demand analytics environments (Spark, Jupyter) | Best effort | | Data Pipeline Standard | Managed ETL infrastructure on STACKIT | 99% | ### 4. DevOps services — development platform | Service | Description | Target audience | | ---------------- | ------------------------------------------------------ | ----------------- | | CI/CD Platform | Managed pipelines with STACKIT registry and deployment | Development teams | | Dev Environments | Standardised development environments on demand | Developers | | IaC Templates | Validated Terraform modules for STACKIT resources | all cloud teams | ### 5. Support services — knowledge and help | Service | Description | Channel | | ------------------- | ------------------------------------------------------ | ----------------- | | Cloud Onboarding | Introduction for new teams: architecture, billing, IAM | Workshop (2 days) | | Architecture Review | Technical assessment of new workload concepts | async review | | FinOps Consulting | Cost analysis and optimisation recommendations | Monthly | | Incident Support | Escalation path for critical production incidents | Pager/Slack | ## Internal pricing — three models ### Model 1: Cost transparency (showback) IT shows each business unit what its cloud usage costs — without internal billing. Goal: create cost awareness without administrative burden. Suitable as a starting point. Behaviour change is slow because there is no direct financial incentive. ### Model 2: Internal cost allocation (chargeback) Costs are actually booked to cost centres. Business units are charged for their cloud usage. The strongest instrument for cost discipline. Requires clean tagging governance (project tag on every resource), a clear price catalogue, and alignment with finance on billing modalities. ### Model 3: Flat budgets with limits Business units receive a monthly cloud budget. Anyone who exceeds it escalates into an approval process. Resource limits are technically enforced. A combination of planning certainty for the finance department and autonomy for business units. ## SLA — what can be promised internally A service catalogue without SLAs is a wish list. Internal SLAs must be realistic: they should be slightly below the STACKIT SLAs, to leave buffer for operations, monitoring, and incident response. **Basic rule:** Internal availability SLA = STACKIT SLA minus 0.5 percentage points operational buffer. Response times clearly defined: | Severity | Definition | Response time | Resolution time | | ------------- | ---------------------------------------- | -------------- | --------------- | | P1 — Critical | Production outage, business-critical | 15 minutes | 4 hours | | P2 — High | Material impairment, workaround possible | 1 hour | 24 hours | | P3 — Medium | Partial impairment, workaround available | 4 hours | 72 hours | | P4 — Low | Cosmetic issue, no production impact | 1 business day | next sprint | ## Building the service catalogue — practical steps 1. **Inventory:** Which services does IT already deliver, structured or unstructured? What is most frequently requested? 2. **Portfolio decision:** Which services should be offered in standardised form? What remains project work on request? What is fundamentally declined? 3. **Create service descriptions:** Per service: name, description, included services, exclusions, pricing model, SLA, onboarding process. 4. **Define internal pricing:** In alignment with the finance department, based on STACKIT list prices plus internal operating effort. 5. **Publish portal or catalogue:** STACKIT offers service-account-based access that IT can configure as a self-service portal. Alternatively: a simple Confluence wiki as a starting point. 6. **Measure demand and iterate the catalogue:** Review quarterly: which services are being used? Which are not? What is missing?