Executive Summary
Bauer Media Group operates a large European media estate of more than 600 magazines, over 400 digital products and 50 radio and television stations, run across data centres and AWS accounts in the United Kingdom, Germany and Poland. Its AWS transformation brought this application portfolio together while keeping the regional teams and business units that run each service.
For Bauer, resilience had to become a property of the whole platform, built into every publishing, digital and shared-service workload it carried. Epitechnic established a common AWS landing zone that reduced the risk created by fragmented governance, uncontrolled network paths, inconsistent access and recovery data held too close to production.
The result is a single AWS organisation covering the whole estate, a network design that contains failure before it spreads, and disaster recovery data held independently of production. Governance coverage reached 100% of Bauer's AWS accounts, continuous compliance moved from 62% to 98%, and detection latency for security and operational conditions fell from 24 hours to under 5 minutes.
Business Challenge
Bauer's technology function had grown the way its brands had, independently, by country. The UK, Germany and Poland each ran their own AWS environments under separate master-payer accounts, with a third environment alongside them. Different teams managed accounts, connectivity and access patterns, which made it difficult to apply one standard of account governance, logging, security policy and operational ownership across the group.
Three pressures made this unsustainable. Regional teams needed a way into a shared platform without an unnecessary rebuild of the identity and network integrations they already depended on. Recovery data sat close enough to production that a production-account compromise, accidental deletion or configuration fault could also remove the ability to recover. And as the estate grew, with more than 200 applications migrating from UK, German and Polish data centres, governance needed a way to scale alongside it.
Success Criteria
- One AWS organisation covering every account, regardless of which country or business unit created it
- Federated identity with least-privilege access, replacing inconsistent regional access patterns
- Controlled, redundant network paths that contain a failure before it spreads
- Disaster recovery data held independently of the production account it protects
- A repeatable operating model so governance holds as new accounts and products are added after the first migration wave
- Measurable, evidenced improvement in compliance and detection
Epitechnic Approach
Epitechnic treated this as a governance and architecture problem together. Epitechnic built on the AWS organisation, Control Tower deployment and Azure AD federation that Germany already operated from its Hamburg data centre connectivity, and extended it to bring in the relevant UK accounts. That avoided negotiating a new standard separately with three regional teams, each with its own priorities and legacy constraints.
Reusing an established governance boundary meant the migration didn't need to rebuild identity and network integrations that already worked. It also meant the resulting model had a real operational home from day one, backed by connectivity and identity integrations Germany was already running in production.
Solution
One control plane for many teams
Separate billing and governance boundaries across Germany, the UK and the group's third environment made it difficult to apply consistent policy, logging and account provisioning group-wide. Epitechnic turned the AWS organisation into a reusable platform service: Control Tower Account Factory as the approved route for every new account, with standard naming, contact details, tagging and permission sets; a master account owning organisation-wide policy, provisioning and StackSets; a Log Archive account retaining central CloudTrail and Config records; and an Audit account giving security teams controlled access across the estate.
Publishing, digital-product and shared-service teams continue to run their own applications, but inside organisation, account and organisational-unit boundaries that limit blast radius and make ownership visible. All of Bauer's AWS accounts are now inside this common governance model.
A network designed to contain failure
Independently managed connectivity meant a network or Availability Zone failure in one region had no consistent, group-wide answer. Epitechnic connected spoke VPCs in the UK and Germany through AWS Transit Gateway, routed all traffic through a single Inspection VPC applying Network Firewall policy, and separated ingress and egress traffic into their own VPCs, so north-south routes are governed centrally across the whole estate. Critical VPCs use redundant subnets across two Availability Zones, Direct Connect is the preferred path to Bauer's data centres, and VPN provides failover.
Every migrated workload is inspected against one corporate security standard, whichever region built it, and the network stays usable if an individual route or Availability Zone is affected.
Recovery data held outside the account it protects
Recovery points sat close enough to production that a compromise, accidental deletion or configuration fault in the production account could also threaten the ability to recover. Epitechnic built a separate disaster-recovery account to a one-business-day Recovery Time Objective, a 24-hour Recovery Point Objective and a 30-day backup-retention period. Aurora databases are protected by scheduled AWS Backup recovery points copied into an encrypted vault in the DR account through a cross-account restore role; static content is protected by Amazon S3 versioning and cross-region replication into a separate DR bucket; and Lambda configuration is held as CloudFormation templates so application components can be recreated on demand. CloudWatch alarms and SNS notifications give early warning of a failed backup or a recovery-control condition.
Recovery no longer depends on the production account remaining trustworthy. Routine verification, including simulated backup failure, keeps the recovery path tested and current.
An operating model that scales with the estate
There was no repeatable way to bring new or existing accounts into the governed platform as the estate grew, only the design used for the first migration wave. Epitechnic combined account provisioning, Azure AD role mapping, network routing, logging, encryption and governance controls into a single onboarding path, with changes managed through Terraform or CloudFormation, stored in encrypted, S3-backed state and subject to policy validation and GitOps change control. The programme brought in a UK pilot account, shared services, the international security team, publishing accounts and digital products including the BauerMedia Careers Portal, GRAZIA Digital Edition and the group's ePublishing titles.
The control baseline is now a repeatable path Bauer can reuse every time it adds a service or account.
Outcomes
Governance coverage: 100% of Bauer's AWS accounts brought under the common governance model.
Compliance: Continuous configuration evaluation replaced uneven manual checking, moving compliance from 62% to 98%.
Detection: Security and operational conditions are now identified in under 5 minutes, down from 24 hours, giving time for a coordinated response.
Audit readiness: Central evidence and automated controls cut preparation time for formal reviews by 80%.
Operational scale: More than 200 applications migrated from UK, German and Polish data centres without major incidents, while the shared control plane continued to expand.
Why It Worked
A single Inspection Hub and a shared governance model only stay effective if new accounts join through the same path as the first ones did. Building the onboarding process itself, provisioning, identity, network, logging and change control together, is what let the platform sustain its governance coverage and compliance level as Bauer kept adding accounts and products after the first migration wave.
Regional and product teams kept ownership of their applications throughout. What changed underneath them were the platform foundations they could depend on: governed accounts, controlled connectivity, federated access, continuous telemetry and independently recoverable data.
Key Takeaways
Challenge: A decentralised AWS estate across the UK, Germany and Poland, with separate governance, connectivity and access patterns, and recovery data held too close to the production it was meant to protect.
Approach: Epitechnic extended Bauer's existing German AWS organisation into a shared landing zone, built a network design that contains failure, separated recovery data into its own account, and made onboarding repeatable through infrastructure as code.
Outcomes: 100% governance coverage, compliance moved from 62% to 98%, detection latency cut from 24 hours to under 5 minutes, and 80% less preparation time for formal reviews.
Lessons: A governance standard only holds at scale if the path for bringing in new accounts is as disciplined as the design used for the first ones.