For about 1 year SCC Brasil worked together with the Carglass Germany internal IT Team on
their Migration to AWS
Carglass is the leading vehicle glass repair and replacement company across 25 countries,
like Germany, Austria, Belgium, France, Switzerland, Sweden, Brazil,
Chile and many
Also in Germany Carglass is the biggest company for windshield repair and replacement.
See company site:
Carglass was already in progress to migrate their On Premise infrastructure to AWS,
but did not have enough resources to proceed and complete the migration from OnPremise to
within the the ambitious schedule. Thats why we joined their team to support them achieving
They used EC2 to migrate OnPremise, VMs, which for example had 3rd party software running
The main business application was running on a Kubernets cluster, also on EC2 machines.
kubectl, so EKS was not used.
RDS was also used as backend for various applications.
AWS Lambda was used for processing of small tasks, basically for maintenance of the AWS
infrastructure, not for business logic yet.
CloudFormation was used as infrastructure as Code Tool.
The first action was analyze the current setup and define epics to optimize the aws
infrastructure and accelerate and complete the migration.
We focused than on IaC, the AWS Account Structure, Cost-Optimization, Improvement of RPO and
and of course on the ongoing Migration of resources still OnPremise
In this blog let's have a look on the most important epics
-Reorganize AWS Account Strucure
-Define and Improve Desaster Recovery Strategy and therefore RTO
-Strict usage of IaC - CloudFormation
Reorganize AWS Account Structure
The current setup already contained a Master Account and Stage Accounts
It is already a good practice to separate the stages in separate accounts, but since it was
neccessary to also grant acess to
external service providers to the accounts, the separation of all these parties on IAM level to
grant only rights to their servers and resources,
following the principle of least privilage, was quite difficult implementing on IAM and policy
The better approach was to define the account structure more granular and define more dedicated
accounts with its on IAM roles.
The AWS Whitepaper gives an example for a multi-account scenario.
Please have also a look in our blog about defining the multi account structure for your
AWS Multi Account Setup
We followed this example with small changes, which allowed for
example only the Network Adminstrator to make changes on Direct Connect, Transit Gateway and
On the other side, the LeadDevs and DevOps or Service Providers still could to assume a
in their Stage accounts.
The dedicated accounts where much more neatly, allowing the admins to stop or teminate manual
created test/poc resources.
Also consolidated billing helped the management to monitor the aws costs on a better
Define and Improve Desaster Recovery Strategy and therefore RPO and RTO
First we had to define the Expectations on RPO and RTO together with Carglass.
All RDS instances where already creating daily snapshots, also EBS volumes, so the RPO
was already quite well, here were only small improvements neccessary, for example on the RDS
Snapshot Settings and Scheduling.
The RTO left some potential for improvements
Not all resources where yet created with IaC (CloudFormation was used in general), some where
manually on the AWS Console, due to urgent requirements in the migration process.
Also some of the resources created with IaC were modified over the time manually on the AWS
due to urgent production issues, which caused drifts on some Stacks and therefore possible
problems when updating the resources by CloudFormation.
To allow the team to re-create all resources in the case of a desaster recovery and therefore
achieve a real short RTO, the strict usage of
IaC must be applied consequently.
Strict usage of IaC (CloudFormation) and deployment with Jenkins Pipeline
The CloudFormation Stacks were re-structured :
-The stacks were layered to better separate the logical and strucutural elements:
Please have also a look in our blog on structuring CloudFormation Templats to get
more informations about this :
How to organize CloudFormation Templates
A VPC Stack would now only contain VPC and Network resources, but no other resources like for
example S3 Buckets.
Therefore the application developers never had to touch VPC or Route53 Stacks, but only their
Application Layer Stacks.
-The stacks were ordered in the git repo by their layers to allow them to re-deploy in the
Cross-References with Outputs in Inputs Values were used, but in this case of course the Stack
containing the Output must be
-Some Stacks used in 3 Stage Accounts were unified to a single stack and parameterized instead
having 3 stacks with a lot of Copy & Paste.
- All Templates were deployed by Jenkins, Pipelines for CloudFormation Deployment were
- A Jenkins Pipeline to automatically create Deployment Pipelines for each Template and each
stage was coded in Groovy.
If a new Stack was added, this Pipeline must be triggered and it would create new Deployment
Pipelines for each stage
-Drift detection problems were sent by SNS Notifications to avoid new Drifts
The MAP programm was applied to the customer.
Since the customer migrated existing VMs/Servers from OnPremise to AWS, the AWS Migration
was a real good fit to save costs for Carglass.
See more infos on
AWS Migration Acceleration Program
After you create your server list in the migration hub and migrate to EC2, you can get discounts
resource on aws which is tagged with the correct map tags:
- Key: "aws-migration-project-id"
- Key: "map-migrated"
The EC2 instance sizes were optimized and Lambdas created to shut down and restart instances
needed 24/7, but only during business hours.
Read more about how to optimize costs on AWS in our blog Cost optimization
Training and documentation
SCC Brasil held a couple of AWS training sessions to the infrastructure team to enable them to
maintain the AWS infrastructure all
alone in the future.
Also a lot of documentation was written in the company Confluence, including Runbooks, Best
practices, Troube Shooting etc
We are glad to be able to support the Carglass Germany Team on their Cloud journey, it
was a lot of fun to work with the well skilled infrastructure team and hope all the Best for
them in the future.