Escape Deployment Hell: IaC, CDK, Ephemeral Environments, and the Pragmatic Path to Platform Power

Another Friday afternoon, another deployment fire. If this sounds familiar, you're not alone. On too many projects, the chasm between application code and infrastructure management breeds manual configuration nightmares, crippling complexity, and agonizingly slow development cycles. But what if your team could sidestep this chaos, focusing on building features instead of constantly battling deployment gremlins?

The solution lies in integrating Infrastructure as Code (IaC) with your application code, to support ephemeral environments. When every feature can be realistically tested in isolation and infrastructure changes are transparent, tested, and automated the benefits are transformative:

• Slash Debugging Time: Catch infrastructure and compatibility issues immediately.
• Boost Team Velocity: Eliminate bottlenecks and enable parallel development without conflicts.
• Keep Crises Small: Switch focus easily without disrupting existing goals.
• Enhance Release Confidence: Test so that "it passed QA" actually means "it will work in production" without creating a QA bottleneck.

This approach is more than just good DevOps; it's the heart of modern platform engineering. Platform engineering is essential to prevent agile methodologies from becoming chaotic, as it equips teams with the framework and discipline to build and manage ephemeral environments vital for isolated testing and rapid, controlled iteration. That impact is why Gartner identifies Platform Engineering as a top technology trend (Gartner, 2023: Top 10 Strategic Technology Trends for 2024). By leveraging tools like AWS CDK, you can achieve many of the coveted benefits of a full-scale Internal Developer Platform (IDP) without the overwhelming cost and complexity, putting true platform power within reach.

Key Ideas

• End Frustrating Software Releases: Many teams struggle with slow, error-prone software releases because their testing setups create bottlnecks and don't match the real, live system.
• Develop and Test New Features Perfectly with "Pop-Up" Systems: Called "Ephemeral Environments" built using Infrastructure as Code (IaC) these are a temporary replica of the live system created for every new feature. This allows each update to be tested thoroughly and safely in isolation before it goes live, after which the temporary system disappears.
• Build Your System Setup with Code, Not Clicks: The magic behind these pop-up systems is defining all the necessary IT infrastructure (servers, databases, networks) using code that lives alongside application code in the same repo — called "Infrastructure as Code" or IaC. This automates the creation of consistent, reliable development and testing environments every time.
• A Practical Path to Power: Instead of building or buying a massive, complex internal system — often called an Internal Developer Platform — tools like AWS Cloud Development Kit (CDK) allow DevOps teams and app developers to use their existing coding skills to set up and manage these automated environments. This makes the benefits of faster, more reliable deployments accessible to more teams without overwhelming cost or effort.

The Painful Path to Ephemeral Environments

My passion for ephemeral environments isn't just theoretical; it's forged from real-world deployment pain early in my career. I vividly recall working on a Python web application where our traditional approach to testing using a single, IT maintained, shared staging environment led to constant headaches, stemming from two core, intertwined problems.

First, there is the issue of environment divergence. Our staging environment was supposed to be a twin of the production configuration, the place where we could confidently say, "If it works here, it'll work live." But because both staging and, at times, production received manual tweaks or patches that weren't always replicated across both, they would inevitably drift apart. These subtle inconsistencies were a minefield. So, as developers, we'd push our code from our local setups to the mainline branch, and it would be deployed to staging for "final" validation. But occasionally, tests would pass on staging, and everything would seem fine. The real pain would come later: we'd promote that 'staging-approved' code to production, only for critical bugs to suddenly surface. These were the issues that left us scrambling to figure out a hotfix or rollback to rescue production.

The other issue is the chaos and bottlneck invited by our single, mainline-focused testing envrionment. We would merge multiple, distinct features together into the mainline branch for testing. If a problem surfaced there — and it often did — everything was entangled, leading to frantic pre-release 'cherry-picking' sessions or just outright delaying the whole batch. Yet, the relentless pressure to ship sometimes meant we would need to push those changes to production with less testing than they really needed. I still feel that knot of anxiety tightening in my stomach, knowing we were rolling the dice. And the 'day-after' scrambles: as panicked messages came in about 'Users are seeing unexpected errors!'. It was always all hands on deck—a blur of late nights and urgent calls, trying to diagnose issues that had been masked by our process, then facing the horrible choice: attempt a risky, rushed hotfix, or execute a full, rollback that took working features down with the bad. This exhausting cycle shattered client trust and turned release schedule into guesswork.

After enduring these twin challenges, the migration to ephermeral environments created wonderful new results. 'Works on my machine' finally translated reliably to 'works in integration,' because each test environment was an automated replica of production. And because every feature was tested thoroughly in its own dedicated space before merging to mainline, the bottlenecks and release fire-drills vanished. Our release predictability dramatically improved, restoring client trust and confidence. I have no interest in ever returning to the stress of unreliable staging, mainline blockages, and anxious stakeholder conversations.

The Allure — and Cost — of the Internal Developer Platform (IDP)

The desire to solve these kinds of problems at scale often leads organizations to consider creating an Internal Developer Platform (IDP). IDPs aim to streamline developer workflows by providing centralized tooling, self-service capabilities for infrastructure, standardized deployment pathways, and reduced cognitive load, thereby significantly improving Developer Experience (DevEx) — aligning nicely with CNCF's Platform Engineering Maturity Model. However, building and maintaining a truly comprehensive IDP is a massive undertaking. As Atlassian describes, an IDP is "a self-service interface between developers and the underlying infrastructure, tools, and processes required to build, deploy, and manage software applications... providing developers with a unified interface or portal where they can access everything they need to build, test, and deploy applications. This platform is typically tailored to a company's specific needs, integrating various tools, services, and workflows into a cohesive, user-friendly system." (Source: Atlassian - Internal Developer Platform). This vision of a unified, all-encompassing system often requires dedicated platform teams, significant upfront investment, and ongoing operational effort, making it a substantial commitment. This is where a more pragmatic, developer-centric approach can offer a compelling alternative.

A Pragmatic Path: AWS CDK for Developer-Empowered Platforms

You don't always need a heavyweight IDP to achieve many of its core benefits. The philosophy behind tools like AWS CDK is to empower teams and developers by leveraging their existing skill sets. As highlighted in Working backwards: The story behind the AWS Cloud Development Kit:

CDK is an open source software development framework that lets developers define cloud application resources using familiar programming languages, so they do not have to learn a new domain-specific language. The AWS CDK lets developers manage those resources in the same way that they manage their application code, ensuring visibility, reproducibility, and repeatability, and it is part of how modern applications treat their infrastructure as code.

This approach is key to making Infrastructure as Code truly accessible and is a game-changer for practices like creating dynamic, ephemeral deployment environments. This drastically reduces the boilerplate and complexity compared to writing raw AWS CloudFormation or other declarative IaC tools like Terraform or Kubernetes.

Here's how AWS Cloud Development Kit (CDK) helps achieve this:

• Familiar Languages: Developers define cloud infrastructure using languages like TypeScript, Python, Java, C#, or Go, complete with the benefits of their existing IDEs, linters, and testing frameworks.
• High-Level Constructs: CDK provides well-architected building blocks (L2/L3 constructs) like ApplicationLoadBalancedFargateService which can deploy a containerized application behind a load balancer with just a few lines of code. This drastically reduces the boilerplate and complexity compared to writing raw AWS CloudFormation or Kubernetes YAML.
• Reusability and Standardization: Teams can create their own custom CDK constructs that encapsulate organizational best practices for security, networking, and application deployment. For example, an "OurStandardWebService" construct could pre-configure logging, monitoring, and IAM permissions.
• Full Programming Power: Because it's "just code," you can use loops, conditionals, and software design patterns to create dynamic and sophisticated infrastructure definitions.
• Synthesis to CloudFormation: Under the hood, CDK applications synthesize into AWS CloudFormation templates. This means you get the robust, declarative provisioning engine of CloudFormation, ensuring predictable and repeatable deployments, but with a far superior developer experience.
• Managed Services: Committing to a certain amount of AWS platform lockin lets the team leverage all the engineering AWS puts into the platform making security, scalability and reliabilty easier to achieve at a smaller scale.

Sidebar: Industry Insights from ThoughtWorks Technology Radar Vol. 32, 2025

• Branch-per-Environment Approaches: "Branch-per-environment strategies offer teams the ability to manage complex deployments by maintaining distinct code branches for each environment, facilitating isolated testing and improved reliability."
• Internal Developer Platforms (IDPs): "IDPs streamline developer workflows by providing centralized tooling and self-service capabilities, reducing cognitive load, and standardizing deployments."

While this article isn't a tutorial on using AWS CDK (plenty of excellent resources exist for that, which you can explore in further reading below), the practical application of this approach transforms the development workflow. When a developer initiates a new feature by creating a Git branch, the CDK deployment (IaC) code, which lives directly alongside the application code within that same branch, is deployed. Immediately the ephemeral environment is created. This means QA, product managers, or other stakeholders can "take a quick look" at any point, fostering early feedback and collaboration without waiting for a developer to manually provision or deem it "ready" — while letting the developer validate his code in a production-like environment immediately. I advocate strongly for this approach where the environment is created and destroyed automatically. However, a more manual process where the developer decides when to create and destroy the ephemeral environment is also easy and viable with this technology.

Bundle and Deploy Containerized Backend Quickly

In CDK, a small block of python code defines, builds and deploys a containerized, load balanced web backend. This code can be in any of a variety of different languages. For our example, we'll be using Python:

fargate = ecs_patterns.ApplicationLoadBalancedFargateService(
    self,
    'apiFargate',
    cpu=self.config.get('fargate_cpu', 256),
    desired_count=self.config.get('fargate_desired_count', 2),
    task_image_options=ecs_patterns.ApplicationLoadBalancedTaskImageOptions(
        image=ecs.ContainerImage.from_asset(
            directory=self.project_dir,                    
        ),
        container_port=self.config.get('fargate_container_port', 80),
        enable_logging=self.config.get('fargate_enable_logging', True),
        environment={
            'FRONTEND_URL': self.url,
            'DB_URI': f'{self.rds_url}',
            'COMPANY_ID': '9999999999999',
            'DB_NAME': 'tracker',
            'QBO_CLIENT_ID': 'XXXXXXXXXXXXXXXXXXXXXXXXXX',
            'ENVIRONMENT': 'production' if self.stage == 'production' else 'sandbox',
            'GITLAB_URL': 'https://xxx.xxx.net',
            'GITLAB_CLIENT_SECRET_NAME': 'gitlab-client-secret',
            'GITLAB_AUTH_SECRET_NAME': 'gitlab-auth-secret',
            'QBO_SECRET_NAME': 'qbo-auth-secret',
            'KEYCLOAK_USERNAME_MIMIC': 'gitlabdev_dev',
        },
        secrets={
            'DB_PASSWORD': ecs.Secret.from_secrets_manager(self.rds_secret, field='password'),
            'DB_USERNAME': ecs.Secret.from_secrets_manager(self.rds_secret, field='username'),
            'QBO_CLIENT_SECRET': ecs.Secret.from_secrets_manager(self.qbo_client_secret, field='client_secret'),
        }
    ),
    memory_limit_mib=self.config.get('fargate_memory_limit_mib', 512),
    public_load_balancer=self.config.get('fargate_public_load_balancer', False),
    redirect_http=False,
    enable_execute_command=self.config.get('fargate_enable_execute_command', False),
    health_check_grace_period=Duration.seconds(self.config.get('fargate_health_check_grace_period', 60)),
    max_healthy_percent=self.config.get('fargate_max_healthy_percent', 200),
    min_healthy_percent=self.config.get('fargate_min_healthy_percent', 50),
    vpc=self.vpc,            
)

A significant advantage emerges when infrastructure needs to evolve for a new feature: Any necessary changes to the IaC — perhaps a new database, a different type of compute resource, or adjusted network configurations — are made right there in the feature branch, directly coupled with the application code changes they support. This keeps infrastructure modifications perfectly synchronized and isolated until they are ready for review by DevOps, IT, and SecOps/DevSecOps stakeholders. Once approved, these integrated changes are pushed upstream. This principle of colocation extends to security and configuration management; by leveraging AWS IAM for precise permissions and defining infrastrucure configurations as code within the same repository (Morris 2021), the entire environment setup becomes version-controlled, transparent, and consistently reproducible. Furthermore, for robust separation, production deployments are typically targeted to an entirely separate AWS account, providing strong isolation from development and staging activities—a best practice easily facilitated by this CDK methodology.

Committing to a vendor integrated technology stack like AWS and CDK allows teams to achieve a rich, deeply integrated deployment system with notably lower initial setup, ongoing maintenance, and operational costs. The inherent tradeoff is, of course, a degree of vendor lockin. However, for many organizations, particularly those operating at a scale where the agility, speed, and managed service benefits outweigh concerns about portability, this is often a pragmatic and highly effective strategic decision. Ultimately, this tight coupling of application code, IaC, configuration, and an automated environment lifecycle, all managed within the developer's familiar toolkit, is what empowers teams to build, test, and release software with greater confidence and velocity. This practice, where Git serves as the single source of truth for both application and infrastructure, and automated processes manage deployments, is a core tenet of GitOps, a key modern continuous delivery pattern.

Sidebar: Does an Onprem Deployment Mean This Won't Work for Me?

This pipeline — built using all the practices discussed above — is for a project where production deployments are to a secure network environment with no connection to AWS and a requirement for manual production deployments. Despite that, the pipeline completes a complex build and test process validating the build for the unique operational and security needs of the project. Thus providing the team with reliable, on demand, ephemeral test environments and ensures that production releases are reliable and verified.

Addressing Common Ephemeral Environment & IDP Challenges with a CDK-Based Approach

While full-fledged IDPs aim to solve many operational complexities, the path to their implementation, or even to robust ephemeral environment strategies, presents significant hurdles to organizations. For instance, Qovery's article, 'Challenges to Anticipate When Transitioning to an Internal Developer Platform', outlines several such difficulties. A well-implemented CDK strategy for ephemeral environments, however, can addresses many of these challenges at a fraction of the cost and effort.

1. Challenge: Environment Variables and Configuration Management

• The Hurdle: Managing distinct configurations, secrets, and dynamic URLs across numerous ephemeral environments can be complex.
• CDK Mitigation: AWS CDK can seamlessly integrate with services like AWS Systems Manager Parameter Store or AWS Secrets Manager. For each ephemeral environment, CDK code can create and populate uniquely named parameters/secrets (e.g., DATABASE_URL_feature_xyz). The application code within that environment is then configured to read these specific parameters. Dynamic values, like the DNS name of a load balancer created by CDK for that environment, can be directly injected as environment variables into the application's container definition or written to Parameter Store for the application to fetch.
• Low Cost: This leverages robust, built-in AWS services, managed as code within the CDK app, requiring minimal additional tooling.

2. Challenge: Technical Implementation Challenges

• The Hurdle: Setting up the initial automation for ephemeral environments can require significant effort and expertise in containerization and infrastructure tools.
• CDK Mitigation: CDK and its close coupling with AWS managed services significantly lowers the barrier. Instead of wrestling with verbose YAML or JSON, developers use familiar programming languages and high-level abstractions. While cloud and IaC knowledge is still needed, for a Python or TypeScript developer, learning to use CDK with the support of a DevOps team and leveraging AWS managed services often presents a gentler learning curve and operational model than becoming a Kubernetes or raw CloudFormation expert. Reusable constructs can encapsulate complex patterns, further simplifying adoption.
• Low Cost: Capitalizes on existing developer skill sets. The need for a large, specialized platform team is reduced, especially for initial setup, as developers can own more of their infrastructure story.

3. Challenge: Security and Compliance Challenges

• The Hurdle: Ensuring data protection, implementing role-based access control (RBAC), meeting compliance standards (GDPR, HIPAA, PCI DSS), and maintaining audit trails in transient environments.
• CDK Mitigation: Security is defined in code aka "Policy as Code". IAM roles and policies granting least-privilege access can be crafted with precision for each ephemeral stack. Security groups, network ACLs, VPC configurations, and data encryption settings (e.g., KMS keys for S3 buckets or RDS instances) are all explicitly declared in CDK are created and destroyed as needed alongside that environment. When needed, DevOps experts can step in alongside the dev team to implement appropriate security and permissions strategies, with SecOps stakeholders reviewing the results, all seamlessly before the changes get pushed upstream. This makes meeting compliance goals significantly easeir. All changes are version-controlled, and AWS CloudTrail provides an audit log of all API calls made by CDK (via CloudFormation).
• Low Cost: Leverages AWS's robust security infrastructure and compliance certifications. "Security as code" makes policies transparent, reviewable, and repeatable. This 'security as code' approach embodies the shift left security principle, integrating security considerations early in the development lifecycle.

4. Challenge: Resource Management

• The Hurdle: Potential for resource wastage due to orphaned resources if environments aren't torn down properly, and the need to balance resource allocation.
• CDK Mitigation: The cdk destroy command is the counterpart to cdk deploy. By integrating this command into CI/CD pipelines (e.g., on branch merge/delete), automated cleanup is enforced. CDK applications should also systematically apply tags (e.g., environment:feature-xyz, created-by:pipeline) to all resources, facilitating cost tracking and identification of any stray resources. Event Bridge and Dead Letter Queues ensure that DevOps will be notified of automation failures.
• Low Cost: Automation is the key. The risk of manual error leading to forgotten resources is greatly diminished.

5. Challenge: Team Adoption

• The Hurdle: Training teams on new ephemeral workflows and fostering a cultural shift from persistent to disposable environments.
• CDK Mitigation: Because CDK uses familiar programming languages, developers are often more comfortable and quicker to adopt it. They can understand, and even contribute to, the infrastructure code more readily than if it were in a DSL or complex configuration format. The "it just works" experience for spinning up an environment for their branch significantly smooths adoption. With DevOps experts, who are specialists in this strategy, setting up the initial project with a ready-to-use pipeline and supporting any complex infrastructure changes, the learning curve for the development team is minimal.
• Low Cost: Reduced learning curve for developers who already code. The infrastructure becomes less of a "black box."

6. Challenge: Integration Complexity

• The Hurdle: Integrating ephemeral environment provisioning into existing Continuous Integration/Continuous Delivery (CI/CD) pipelines and ensuring compatibility with development tools.
• CDK Mitigation: While AWS CDK integrates seamlessly with AWS native CI/CD services like CodePipeline, its command-line interface (CLI) is also designed for broader automation. This means it can be readily incorporated into established CI/CD systems your team might already use, such as GitHub Actions, GitLab CI, or Jenkins, typically by invoking shell commands. Stack outputs can then be consumed by subsequent pipeline stages, ensuring a smooth workflow regardless of your chosen CI/CD tooling.
• Low Cost: Strong native integration with the AWS ecosystem and straightforward CLI-based integration for other systems, offering flexibility.

7. Challenge: Build vs. Buy Decision Point

• The Hurdle: Deciding between building a custom ephemeral environment solution (resource-intensive) or using third-party services (potential external dependencies and less customization).
• CDK Mitigation: CDK offers a compelling middle ground. By committing to AWS, you are essentially "building" your platform definition with the powerful, managed services and abstractions provided by AWS and the CDK framework. This allows you to leverage AWS's vast engineering investment directly, meaning there's significantly less undifferentiated heavy lifting for your team to fund and build from scratch when composing and configuring high-level AWS services.
• Low Cost: You leverage AWS's massive investment in its cloud services and the open-source CDK, getting a significant head start compared to a pure custom build, while retaining more control and customization than many off-the-shelf IDP products.

By thoughtfully applying CDK, many of the advantages of an IDP—developer self-service, automation, consistency, and speed—become accessible without the monumental effort of building or buying a full-scale platform from day one.

Enhanced Testing and Collaboration with CDK-Driven Ephemeral Environments

The CDK-driven approach to ephemeral environments isn't merely a technical exercise; it delivers substantial, practical benefits that directly enhance both the quality of testing and the efficiency of team collaboration. By defining each environment as code, directly alongside the application, teams can test early, often, and with a high degree of realism.

One of the most immediate advantages is the early detection of incompatibilities between the application and its underlying infrastructure. Because each feature branch can have its own distinct, CDK-defined environment, any infrastructure changes required for that feature are tested in isolation. This means issues that might arise from, say, a new database version or an altered network configuration are identified and resolved within the context of that feature's development, long before they could impact a shared staging environment or, worse, production. Furthermore, this isolation ensures that individual bugs or incomplete features on one branch don't derail the work of others. Developers can confidently experiment and iterate, knowing their environment is a safe sandbox, preventing the all-too-common scenario where one person's unstable code destabilizes a shared testing ground and blocks overall team progress. This is a practical application of shift left testing.

This ability to spin up and tear down environments on demand also translates to greater agility when priorities shift. If a new, urgent task arises, a dedicated environment for it can be provisioned quickly via CDK without disrupting ongoing work or requiring complex manual reconfiguration of existing test setups. While development or feature-branch environments might sometimes run lighter configurations to optimize costs, the core software stack and its interaction with the CDK-defined infrastructure remain consistent, ensuring that testing efforts are meaningful and translate reliably to production.

The power of this approach truly shines during high-pressure situations, as illustrated by a common scenario: deploying a critical hotfix. As a team lead, I vividly recall the stress of needing to push an urgent fix to production. In the past, deploying this to a shared staging environment was fraught with risk, potentially destabilizing ongoing testing for the next major release. Coordinating a "quiet period" with everyone anxiously watching was never pleasant. With CDK-managed ephemeral environments, the experience is entirely different. QA can spin up a pristine, production-like environment in minutes, validate the hotfix in complete isolation, and confidently give the green light, all while the main testing tracks for upcoming features remain undisturbed. This agility and safety proved invaluable for managing risk and has now become a cornerstone of our everyday development. Feature branches consistently receive isolated and thorough QA, resulting in seamless release cycles that often go unnoticed — a mark of true success.

Beyond these direct testing benefits, integrating IaC code (via CDK) side-by-side with application code fosters a more collaborative and transparent development culture. When infrastructure definitions are visible and version-controlled within the same repository, developers gain a clearer understanding of the operational aspects of their features and feel more empowered to suggest improvements or identify potential issues early. DevOps and SecOps teams can more easily review infrastructure changes as part of the standard code review process, ensuring consistency, adherence to best practices, and preventing configuration drift. This shared ownership transforms infrastructure from a siloed concern into a team-driven, continuously improved asset, aligning perfectly with the DevOps philosophy.

Conclusion: The Best of Both Worlds Without the Big IDP Bill

Adopting a strategy where Infrastructure as Code, particularly using a powerful framework like AWS CDK, lives alongside your application code isn't just a technical nicety; it's a fundamental shift towards more agile, reliable, and developer-centric software delivery. This approach allows teams to spin up and tear down fully independent, production-like ephemeral environments for every feature branch, pull request, or hotfix.

The outcome is a development lifecycle supercharged with early feedback, isolated testing, and dramatically reduced integration risks. While the dream of a comprehensive Internal Developer Platform is appealing, the reality is that many of its most impactful benefits — developer self-service for environments, robust automation, enhanced collaboration, and deployment consistency — can be achieved with significantly less overhead. By empowering developers with tools like AWS CDK that leverage their existing programming skills, organizations can cultivate a "platform thinking" mindset and realize tangible improvements in speed and quality, without the substantial cost and complexity often associated with building a full-blown IDP.

Optimizing Git Branching Strategy

The moments I appreciate most about our deployment strategy aren't dramatic near-misses or tense rollbacks — it's exactly the opposite. It's when I realize I've gone a month without needing to micromanage merges or fret about someone accidentally pushing half-tested code to production. Thanks to reliable ephemeral environments defined in CDK and a clear branching policy, our team knows exactly what's expected. New features get smoothly tested, merged, and deployed without fuss. This frees me up to do the part of my job I love the most: crafting features that delight users and occasionally earn some kudos from colleagues.

Next Step with Ephemeral Deployments and CDK

Here is a roadmap to implementing the practices discussed in this article:

Further Reading

• Forsgren, Nicole, et al. Accelerate: The Science of Lean Software and DevOps. IT Revolution, 2018.
• Beyer, Betsy, et al. Site Reliability Engineering: How Google Runs Production Systems. O’Reilly Media, 2016.
• Kim, Gene, et al. The DevOps Handbook. 2nd ed., IT Revolution, 2021.
• Morris, Kief. Infrastructure as Code. 2nd ed., O’Reilly Media, 2021.
• Cloud Native Computing Foundation, Technical Advisory Group App Delivery. Platform Engineering Maturity Model. Cloud Native Computing Foundation, Oct. 2023, https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/.
• Thoughtworks. Technology Radar Vol. 32. Thoughtworks, Apr. 2025, https://www.thoughtworks.com/en-us/radar
• Kraja, Iris, et al. "Multi-branch pipeline management and infrastructure deployment using AWS CDK Pipelines." AWS DevOps Blog, Amazon Web Services, 22 Dec. 2022, https://aws.amazon.com/blogs/devops/multi-branch-pipeline-management-and-infrastructure-deployment-using-aws-cdk-pipelines/.
• AWS Community Builders. "DevSecOps with AWS- Ephemeral Environments – Creating test Environments On-Demand - Part 1." DEV Community, 15 Oct. 2023, https://dev.to/aws-builders/devsecops-with-aws-ephemeral-environments-creating-test-environments-on-demand-part-1-54il.