The project
Smava GmbH is an online credit comparison platform. It allows customers to compare different loan and credit conditions and close contracts via their platform. smava runs most production services in a hybrid environment consisting of a data center and multi-AWS accounts. To supply a secure, production-ready migration environment and multi-account strategy that aligned with AWS best practices. kreuzwerker helped smava to create an AWS Landing Zone environment. Security, compliance and governance at scale in the cloud was addressed. Furthermore, kreuzwerker migrated a smava cloud-native, microservices-based application to the new environment.
Solution
The first step was to analyze the existing infrastructure by joining workshops, calls and deep-dive through the documentations. Next, we started with the AWS accounts’ structure, network setup, software architecture, operating module and CI/CD tooling.
To align smava’s AWS multi-account environment with AWS well-architected patterns, automate the setup of multi-account services, and implement preventive and detective security controls, kreuzwerker designed the Landing zone solution structure using AWS Control Tower in the existing smava AWS Organization.
smava has dramatically increased its cloud engineering know-how through the support of kreuzwerker/AWS, and is now able to independently develop its cloud infrastructure as well as its design. Michael Alers – Vice President Platform - smava GmbH
In the design stage, kreuzwerker used a re-platforming migration strategy to migrate smava’s microservice-oriented applications to AWS by applying a few cloud optimizations without changing the core application architecture. A defense-in-depth approach was also applied in order to use all available security mechanisms in different layers of the application.
In the next step, kreuzwerker implemented the proposed landing zone solution by implementing AWS Control Tower, AWS Security Hub, AWS GuardDuty, which provides the following key features:
- Govern at scale, multi-accounts environment using AWS Organization.
- Centralized identity management using AWS SSO and federated access to the AWS accounts using AWS SSO and OKTA.
- Centralized CloudTrail, and AWS Config logging in Amazon S3.
- Pre-configured preventive and detective Guardrails.
- Delegate AWS Security Hub and AWS GuardDuty administration of all member accounts to the management AWS account.
- AWS Security Hub and AWS GuardDuty are enabled in all AWS member accounts.
Infrastructure provisioned as code using reusable modules of Terraform. Each activity is represented as a sub-project aligned with its pipeline using Jenkins for CI/CD and Bitbucket repository as source control and split Terraform scripts into multiple states. This setup allows smava to manage the small, fast-changing subset of the infrastructure resources, requiring limited permissions without any effect on the other parts of the infrastructure. Furthermore, smava can control all Terraform states of all children accounts from one central location.
As a microservices-based, cloud-native application, kreuzwerker leveraged AWS managed services that can be used without having to take of the underlying infrastructure administration, to deploy smava application in AWS using the following resources:
- AWS Fargate to host docker-based backend and frontend microservices.
- AWS Aurora for the data layer.
- ECS Service Discovery & Route53, for microservices discovery.
- Internal Application Load Balancer in front of frontend microservice.
- AWS API Gateway with VPC private link and AWS WAF integration to securely expose the service externally.
Right from the start, kreuzwerker worked closely with the Smava team to enable them to manage the operations on their own after the end of the project. From the organizational and project perspective, kreuzwerker and Smava lead the project with a manager from each side working closely with the operations team and passing information from the executive side timely and often and vice-versa.
So the team could set priorities quickly to new, more critical tasks. Furthermore, from the beginning, kreuzwerker had full support from the management side, which was crucial for moving quickly and removing roadblocks to make this project a success on-time and within budget constraints. Especially at the end of the project, this was crucial to its success.
kreuzwerker shared its knowledge during workshops, daily stand-ups, open discussion calls, screen sharing sessions, and voice calls. All analysis and design work steps were documented in smava’s Confluence. The code and documentation were maintained in the smava Git repository, and as the project progressed, the smava team carried out more tasks.
From the cultural perspective, the kreuzwerker engineers gave smava’s operations team confidence with best practices in AWS multi-account setups by moving forward with proposals, explanations, and implementations yet without interfering with existing production workloads in a brownfield environment.
Advantages
smava now has a production-ready, secured, compliant, multi-account environment with the possibility of defining detective and preventive guardrails that can be implemented on each account within smava’s AWS Organization. Furthermore, smava’s microservices-based, the cloud-native application is migrated to AWS and can be used as a pilot application for future migrations.
Conclusion
kreuzwerker and smava solved many technical challenges together including; adopting AWS Landing zone using AWS Control Tower in smava’s existing AWS Organization, pulling Docker images from smava’s private repository and centralizing network traffic in shared networking AWS accounts.
smava’s team can now register and move their existing AWS accounts to the new environment and continue migrating other applications to the AWS cloud.