CDK does a lot more than just be an object oriented abstraction. Often times one of the constructs in CDK actually makes many different underlying AWS resources

CDK does a lot more than just be an object oriented abstraction. Often times one of the constructs in CDK actually makes many different underlying AWS resources. In CloudFormation its always a 1:1 mapping: one CloudFormation resource typed out as YAML, one resource created on your AWS account. In CDK you can make something like "LoadBalancedFargateService" and just plug in the path to your local Dockerfile, and it builds and uploads the image to ECR, makes a Fargate service, makes a load balancer, connects the service to the load balancer, and returns the URL to you. The other power of CDK is it sets things up right out of the box. Rather than having to explicitly created all your autoscaling rules it can create sensible default ones for you automatically. It also automatically creates the right IAM rules, and security group rules that you would otherwise have to define manually. As a whole I'd say comparing CloudFormation and CDK is like comparing assembly language and C++. You could write your code as a bunch of hand rolled ASM for the most control, but realistically that's not feasible for large projects as its error prone, slow, and quickly gets unwieldly. CDK is like higher level C++ that synthesizes back down into the lower level assembly language that creates all those cloud resources