We source, vet, and manage hiring so you can meet qualified candidates in days, not months. Strong English, U.S. time zone overlap, and compliant hiring built in.
.svg){kind=logo}
AWS Cloud Development Kit (CDK) is a framework for defining AWS infrastructure using programming languages like TypeScript, Python, and Go, rather than CloudFormation templates or point-and-click consoles. It's become the go-to tool for teams building modern cloud applications because it combines the power of infrastructure-as-code with familiar programming paradigms. Instead of writing YAML or JSON, developers use their language of choice to define cloud resources, validate them before deployment, and reuse patterns across projects.
CDK sits at the intersection of development and infrastructure operations. It generates CloudFormation templates under the hood but abstracts away the complexity, giving developers the same control without the boilerplate. Teams at companies like Airbnb, McDonald's, and Databricks use AWS CDK to provision entire architectures in hours instead of days. The framework includes pre-built constructs for common patterns (serverless applications, databases, networking) and allows teams to create custom constructs for company-specific standards.
The CDK ecosystem has grown significantly since its 1.0 release in 2019. CDK v2 stabilized the API and introduced better tooling for testing infrastructure code. GitHub shows over 12,000 stars for the aws-cdk repository, and npm downloads exceed 3 million per month, indicating strong adoption in enterprise and startup environments. The shift toward CDK represents a broader move away from template-based infrastructure toward code-driven, testable, and version-controlled infrastructure.
Hire an AWS CDK developer when you're building infrastructure for cloud-native applications, especially serverless systems, containerized microservices, or multi-environment deployments. CDK is the clear winner if your team already uses TypeScript or Python and you want infrastructure engineers to work in the same language as application code. It's also essential when you need infrastructure to be testable, reusable, and integrated with your CI/CD pipeline.
CDK is the right fit for teams migrating from CloudFormation, especially large organizations managing hundreds of stacks. Instead of wrestling with YAML, teams can use loops, conditionals, and object-oriented design to reduce repetition. If your company has grown beyond a few simple stacks and you need to enforce standards across teams (database naming conventions, security group rules, tagging strategies), custom CDK constructs let you encode those as code.
Don't hire for CDK if you're running a simple architecture with only a few static resources or if your team isn't comfortable with code-based infrastructure. CDK requires understanding both cloud concepts (VPCs, IAM, Lambda execution roles) and programming patterns (interfaces, inheritance, testing frameworks). Teams new to infrastructure-as-code might be better served starting with a simpler tool like Terraform, which has a more declarative learning curve.
Also be realistic about the AWS ecosystem itself. CDK is AWS-specific. If your company uses multi-cloud (AWS, Azure, GCP), you'll want terraform or Pulumi for portability. CDK developers tend to be strong full-stack engineers or platform engineers who understand both application code and cloud architecture. Pair them with AWS solution architects or platform leads who can establish company-wide CDK patterns and guardrails.
Must-haves: Strong proficiency in TypeScript or Python (whichever language your team uses), understanding of AWS core services (EC2, Lambda, RDS, S3, API Gateway), and practical CloudFormation knowledge. A good CDK developer can explain what CloudFormation template their CDK code generates and troubleshoot when CloudFormation failures occur. They should understand the construct library hierarchy and know when to use L1 (CloudFormation) constructs vs. L2 (AWS-specific) vs. L3 (patterns).
Nice-to-haves: Experience with testing infrastructure code using the aws-cdk assertions library, familiarity with CDK best practices like construct composition and context values, working knowledge of CI/CD pipelines (GitHub Actions, CodePipeline, GitLab CI), and experience creating custom constructs for a team or organization. Candidates who've built and shared reusable constructs within a company demonstrate architectural thinking.
Red flags: Developers who treat CDK as just another way to click-and-generate infrastructure, or who confuse CDK with Terraform. Watch for candidates who can't explain the relationship between CDK and CloudFormation, or who've only ever used `cdk init` templates without customizing constructs. Also be cautious about developers who've only worked with L1 constructs (raw CloudFormation) and haven't learned the higher-level abstractions that make CDK powerful.
Junior (1-2 years): Should have solid programming fundamentals in their chosen language (TypeScript or Python), understand basic AWS services, and be able to deploy simple applications using CDK. They might lean on examples and L2 constructs without fully grasping the underlying CloudFormation, but they should be able to read and debug existing infrastructure code.
Mid-level (3-5 years): Can design multi-environment architectures (dev, staging, prod) using CDK, create custom constructs for common patterns, and troubleshoot infrastructure failures. They understand context values, cross-stack references, and how to organize large CDK projects. They've likely contributed to a company's internal construct library or CDK best practices documentation.
Senior (5+ years): Architecting platform engineering solutions with CDK, designing construct libraries that scale across dozens of teams, and deeply understanding the relationship between CDK and CloudFormation. Senior CDK engineers lead infrastructure standardization efforts and mentor teams on when to use CDK vs. other tools.
Tell us about a time you refactored CloudFormation templates into CDK constructs. What was the benefit, and what challenges did you face? Look for candidates who highlight code reusability, testing, and reduced boilerplate. Strong answers mention specific patterns (e.g., converting a custom resource into a reusable construct) and acknowledge trade-offs (CDK adds another layer of abstraction to learn).
How do you approach designing infrastructure for a new microservice? Good candidates describe a process: understanding compute needs (Lambda vs. ECS), data layer (RDS vs. DynamoDB), networking, monitoring. They should mention how they'd use CDK to make this repeatable for future services. Top answers reference company-specific patterns or custom constructs.
Tell us about the most complex CDK application you've built. What made it complex? Listen for multi-environment setups, custom constructs, cross-stack references, or integration with existing infrastructure. Complexity signals growth in architectural thinking.
Describe a situation where you had to debug a CloudFormation failure caused by CDK code. How did you approach it? This tests their mental model of the CDK-to-CloudFormation relationship. Good answers describe reading generated templates, checking IAM permissions, and validating construct configuration.
How do you ensure infrastructure code quality and consistency across your team? Look for discussion of testing (aws-cdk assertions), code review practices, custom constructs as guardrails, and documentation. Senior candidates should mention linting, tagging strategies, or policy enforcement.
Explain the difference between L1, L2, and L3 constructs in CDK. When would you use each? L1 constructs map directly to CloudFormation resources (low-level control). L2 are AWS-specific helpers with sensible defaults (most common). L3 are patterns for complete solutions. Good answers explain the trade-off between ease-of-use and control.
How would you design a CDK project to manage infrastructure for 10 different microservices without duplicating code? Look for discussion of custom constructs, composition patterns, shared libraries, and context values. Candidates should describe creating a base service construct that teams can extend.
What's the purpose of CDK context values, and how would you use them to manage environment-specific configuration? Context values allow CDK to fetch runtime data (e.g., the latest AMI ID, availability zones in a region). Good candidates describe using context for environment-specific settings and acknowledging the limitations (context is cached locally).
You're migrating a complex CloudFormation template to CDK. How would you approach it? Look for a methodical approach: start with L1 constructs for a 1-to-1 mapping, then incrementally refactor to L2, identify opportunities for custom constructs, and test at each step. Top answers mention using the aws-cdk assertions library.
Describe a scenario where you'd choose Terraform over CDK. When does Terraform make more sense? Shows architectural judgment. Good answers mention multi-cloud, team familiarity, or the need for a simpler mental model. This also tests whether they're dogmatic about CDK.
Design a CDK stack for a serverless API (API Gateway, Lambda, DynamoDB, CloudWatch logs). Write the code for the Lambda function integration and DynamoDB table. Include error handling and basic monitoring. Scoring: Does the solution use appropriate L2 constructs? Are IAM roles correctly configured? Is the code reusable (e.g., could you easily extend it with additional functions)? Do they handle common gotchas like Lambda execution role permissions for DynamoDB?
LatAm AWS CDK Developer Rates (2026):
US-based AWS CDK Engineer Rates (2026, for comparison):
LatAm developers in countries like Brazil, Argentina, and Colombia offer 40-60% cost savings compared to US counterparts with equivalent experience and output. AWS CDK is increasingly in-demand, so experienced developers command premium rates within the LatAm market.
Latin America has become a hub for cloud infrastructure expertise. Brazil and Argentina host large AWS user groups, annual conferences, and a deep pool of developers who've worked on enterprise infrastructure projects. Most of South's AWS CDK developers are based in UTC-3 to UTC-5 time zones, giving US East Coast teams 6-8 hours of real-time overlap for pair programming, code reviews, and synchronous collaboration.
The LatAm tech ecosystem has strong university programs in computer science and mathematics, producing developers with the theoretical foundation required for infrastructure-as-code work. Companies like Globant, Accenture, and Mercado Libre employ thousands of engineers in Argentina and Brazil who specialize in cloud infrastructure and DevOps.
English proficiency is high among professional developers in the region, and cultural alignment with North American work practices is strong. LatAm developers are accustomed to asynchronous communication, pull request review workflows, and remote-first team structures. The region also has lower engineer turnover compared to the US, which is valuable for infrastructure teams where consistency and institutional knowledge matter.
From a cost perspective, hiring a mid-level CDK developer in Argentina or Colombia costs 50-60% less than equivalent US talent, without sacrificing code quality, architectural thinking, or communication. This makes it possible to build larger infrastructure teams, invest in infrastructure documentation and testing, or allocate engineering budget toward other priorities.
The South process is straightforward. You share your requirements: team size, project scope, seniority level needed, and tech stack preferences (TypeScript vs. Python, preferred AWS services). Our team searches our network of pre-vetted infrastructure engineers and identifies developers whose experience aligns with your needs.
You interview candidates directly. Our team does the heavy lifting upfront, screening for AWS knowledge, CDK proficiency, and communication skills. We typically present 3-5 qualified candidates within 5-7 days of initial requirements. You conduct technical interviews, code reviews, and culture fit conversations. We facilitate the entire process and answer questions about each candidate's background.
Once you've selected a candidate, you're matched with ongoing support. We handle payment processing, compliance, and international employment details. If the hire isn't a good fit within the first 30 days, we replace them at no additional cost. This guarantee aligns our incentive with yours: we win when you find the right person.
Ready to build your infrastructure team? Start the matching process with South today.
AWS CDK is used to define cloud infrastructure using code. Common use cases include provisioning serverless applications (Lambda, API Gateway, DynamoDB), containerized systems (ECS, Fargate), databases, networking, and CI/CD pipelines. It's especially useful when you need to manage multiple environments or enforce infrastructure standards across teams.
Use CDK if your team is comfortable with programming and wants to reduce boilerplate and increase reusability. Use CloudFormation directly if you prefer a declarative, template-based approach or if you need maximum control over every detail. CDK generates CloudFormation, so you're not losing power, just gaining abstraction.
CDK is better for developers than DevOps beginners. If you're new to infrastructure, start with a simpler tool like Terraform. If you're a developer new to cloud, CDK can be an excellent entry point because you use your existing programming skills.
TypeScript is more common in the CDK community and has better editor support and type safety. Python is fine if your team already standardizes on Python. The choice isn't critical; focus on team familiarity.
Typically 5-7 days from initial requirements to final candidate. Screening and technical interviews add 1-2 weeks. Full onboarding to productive contributor is usually 2-3 weeks.
CDK is AWS-specific and uses programming languages. Terraform is cloud-agnostic and uses a declarative DSL (HCL). Choose CDK if you're AWS-only and want to leverage your team's programming skills. Choose Terraform if you need multi-cloud support or prefer a simpler, more declarative model.
No. CDK is designed for AWS. For on-premises or multi-cloud, use Terraform, Ansible, or Pulumi.
CDK integrates with AWS Secrets Manager and Systems Manager Parameter Store. Store sensitive data in these services, not in your CDK code. Best practice is to reference secrets at deployment time and inject them into Lambda environment variables or application configuration.
Yes. CDK is a tool for people who understand cloud architecture. You need to understand IAM, networking, compute services, and databases. CDK makes infrastructure easier to manage, but it doesn't simplify cloud concepts.
South offers a 30-day replacement guarantee. If the hire doesn't work out, we replace them with another candidate at no cost. Our goal is to find the right person for your team.
Yes. South matches developers for full-time, part-time, and project-based engagements. Pricing adjusts based on commitment level.
Pair CDK developers with AWS knowledge of specific services (Lambda, ECS, RDS, DynamoDB), CI/CD expertise (GitHub Actions, CodePipeline), and Infrastructure as Code testing frameworks. If your team is building a platform, pair them with a platform engineer or DevOps lead.
