Researchers reported Friday that TeamTNT is using compromised AWS credentials to attack AWS cloud environments via the cloud platform’s application programming interface. The threat actors are now also targeting the credentials of 16 additional applications, including the AWS apps as well as Google Cloud credentials.

The researchers said the threat actors can now identify all identity and access management (IAM) permissions, elastic computer cloud instances, S3 buckets, CloudTrail configurations, and CloudFormation operations granted to the compromised AWS credentials.

This attack was significant because in hitting Google Cloud it represents the first time attackers have targeted IAM credentials on compromised cloud instances outside of AWS. Although it’s still possible that TeamTNT could target the IAM credentials of Microsoft Azure, Alibaba Cloud, Oracle Cloud, or IBM Cloud using similar methods, Unit 42 researchers have yet to find evidence that there has been an attack on the other cloud providers. TeamTNT first started collecting AWS credentials on cloud instances they had compromised as early as August 2020.

In a blog post, Palo Alto’s Unit 42 researchers said these latest discoveries followed the threat group having targeted Kubernetes clusters and creating a new malware called Black-T that integrates open source cloud-native tools to advance its cryptojacking operations.

Yaniv Bar-Dayan, co-founder and CEO at Vulcan Cyber said any enterprise using cloud services needs to understand that offloading compute and storage infrastructure to a cloud provider doesn’t mean offloading cloud security. Companies still need to apply a comprehensive vulnerability management and mitigation plan to all cyber resources utilized by a company, including cloud apps.

“Cloud vulnerabilities are not the same as application vulnerabilities and both require different remediation and mitigation actions to protect from organizations like TeamTNT,” Bar-Dayan said. “We agree with Unit 42 researchers and reiterate the immediate need to protect cloud infrastructure using the appropriate remediation steps common to cloud environments such as configuration changes, compensating controls, and workarounds.”

TeamTNT starts by infiltrating a public cloud environment – with AWS by far the most prevalent target, though Google Cloud was hit this time around – and builds a map of the environment which includes scraped credentials, workloads, and storage, said Oliver Tavakoli, CTO at Vectra.

“All this represents the equivalent of establishing a base camp prior to climbing a high summit,” Tavakoli said. “Then the insertion of cryptomining software begins with TeamTNT counting on the fact that target organizations won’t notice the uptick in usage charges for a while.”

SANTA CLARA, Calif., May 27, 2021 /PRNewswire/ — Palo Alto Networks (NYSE: PANW), the global cybersecurity leader, today announced the release of Yor, an open-source tool that automatically tags cloud resources within infrastructure as code (IaC) frameworks Terraform, AWS CloudFormation, and Serverless Framework YAML. Yor automates the tedious work of manually tagging cloud resources, helps security teams trace security misconfigurations from code to cloud, and enables highly effective GitOps across all major cloud providers.

“Effective infrastructure tagging is critical to tracking cost allocation, access control, operations, and of course security in the cloud,” said Barak Schoster, chief architect at Palo Alto Networks. “To date, this has been an all-too-manual process for developers, with each cloud provider and organization having different standards and naming conventions. By automating standardized tagging, Yor provides visibility and traceability from IaC configuration to cloud resources in production.”

Organizations can run Yor across all infrastructure resources to retroactively assign ownership and other meaningful tags based on IaC and git history data. Yor can also be built into the continuous integration and continuous delivery (CI/CD) lifecycle for improved traceability as infrastructure is modified and created. Having consistent tagging will make it simple to trace any misconfigurations back to the original code owners and editors, reducing the time to patch.

The Cloud Security Alliance noted in its recent report The State of Cloud Security Concerns, Challenges, and Incidents that misconfigurations were among the leading causes of breaches and outages as public cloud adoption doubled over the past two years. If a security team identifies a misconfiguration, having the tags for the developer owner simplifies triaging, so the ticket can be automatically assigned to the right developer. Yor’s use cases also extend beyond security by making it easier to tag resources to allocate costs from a finance and budgeting perspective.

“DevSecOps is about breaking down silos and improving productivity,” said Ismail Yenigul,open-source contributor and DevSecOps expert. “Imagine there is a SEV0 security incident — the last thing you want to do is spend hours identifying what caused a misconfiguration or track down the developer who wrote or modified the infrastructure code that is managed in Terraform, CloudFormation, or Serverless. Yor makes it possible to get answers to those questions immediately, for much more effective collaboration and faster mean time to resolution of incidents.”

Yor was built by Bridgecrew, the team behind the popular open-source IaC scanner Checkov which has been downloaded over 2 million times by developers. Bridgecrew was acquired by Palo Alto Networks in March 2021 and together they continue to invest in new and existing open source projects.

Yor is an open-source tool that automatically and consistently tags resources across infrastructure as code (IaC) frameworks (e.g., Terraform, CloudFormation, Kubernetes, and Serverless Framework). Yor enables version-controlled owner assignment and resource tracing-based git history. It also extends tag enforcement logic by loading external tagging logic into your CI/CD pipeline. For more information, visit www.yor.io.

Palo Alto Networks

Palo Alto Networks, the global cybersecurity leader, is shaping the cloud-centric future with technology that is transforming the way people and organizations operate. Our mission is to be the cybersecurity partner of choice, protecting our digital way of life. We help address the world’s greatest security challenges with continuous innovation that seizes the latest breakthroughs in artificial intelligence, analytics, automation, and orchestration. By delivering an integrated platform and empowering a growing ecosystem of partners, we are at the forefront of protecting tens of thousands of organizations across clouds, networks, and mobile devices. Our vision is a world where each day is safer and more secure than the one before. For more information, visit www.paloaltonetworks.com.

Palo Alto Networks, Prisma, and the Palo Alto Networks logo are trademarks of Palo Alto Networks, Inc. in the United States and in jurisdictions throughout the world. All other trademarks, trade names, or service marks used or mentioned herein belong to their respective owners.

The concept of shifting security left is not new, but historically this has meant little more than inserting security processes in the middle of development and slowing everything down. In this article, I’ll describe older shift-left methods that have not worked — and how a modern approach to shifting left can have a high impact on risk reduction and create a healthy balance of freedom and responsibility for cloud-native development teams.

I believe CISOs have no choice but to embrace this industry change. They must enable development teams to move faster while simultaneously reducing the catastrophic risk of deploying broken infrastructure.

The DevOps Shift-Left

Traditionally, for an application developer, the infrastructure you needed was a server. So you would file a ticket, and someone from the ops team would create a VM instance or order a physical server. Some number of days, weeks or months later, the server would be delivered through a combination of ClickOps, scripts and manual processes.

Today, modern application developers are directly provisioning applications to the cloud by using cloud platforms like AWS, Google and Azure without any additional assistance from IT or platform teams. Developers release and update software on demand in the cloud using continuous integration and continuous deployment (CI/CD) for rapid software releases and updates.

ow using declarative Infrastructure as Code (IaC) — things like Terraform, CloudFormation, Kubernetes manifests, Helm Charts, etc. — to automate the provisioning of their cloud infrastructure. The code manages the resources for their applications — servers, databases, networks, logs, application deployment and configurations — and reduces the burden for IT, Ops and site reliability engineering (SRE) teams.

This has shifted DevOps left and allowed developers to provision their own infrastructure using software development practices such as writing, testing and executing code. If they want to make changes or tear down the infrastructure, they code it, test it and then deploy the changes.

Volumetric Rise In Attack Surface

The power and scale of modern software development cycles adds a new risk dimension to security. Software provisioned with IaC can go from developer laptops to clouds to customers in seconds.

The problem is that there is often little to no room for traditional security intervention in this development process. Rapid deployment of IaC by multiple developers of varying skill and experience levels means there’s a high chance for mistakes. These problems manifest at runtime, where security teams have good visibility with solutions that detect configuration problems. The problem is that by this point, these problems can be difficult and costly to fix.

Last generation’s shift-left security has been trying to shift left for years. You can try to catch vulnerabilities and misconfigurations before they are exploited to reduce the risk of breaches in production. You can run a static analysis of application code and dynamic analysis of live applications, generate reports, pummel your ticketing systems for remediation work, and curse at false positives. It’s a frustrating process that was designed to work in slow multistep release cycles with defined approval gates. It requires pauses between deploys to complete security scans, and then it requires time for remediation activity to catch up.

Inserting security into development has also traditionally meant hiring and deploying software security experts into development teams. These experts may be available for a plethora of tasks: “threat modeling” new architectures, defining security features, consulting on risk priority, training up security champions and such. All of these tasks are costly and time-intensive.

On top of this, in most organizations I’ve worked with, security is vastly outgunned in headcount. Large development teams (DevOps, SREs, developers) that are armed with CI/CD and IaC are unstoppable. I’d estimate that the current industry ratio sits around 1.5 security experts per 100 software engineers. This model simply does not scale when companies are confronting modern decentralized development. To quote Bilbo Baggins in The Lord of the Rings, “I feel thin, sort of stretched, like butter scraped over too much bread.”

The Modern Shift-Left Security Strategy

A modern shift-left approach shifts security responsibilities to those creating software, the developers, and it shifts it to the beginning of the process when the developers are provisioning infrastructure. By testing Terraform and CloudFormation for security before execution, just as they would test their application code for quality and reliability, developers can make any fixes before committing code to production — where it could affect customers and result in data loss.

This shift weaves security into the existing CI/CD processes. Developers should leverage APIs to integrate security solutions into the tools they already use while giving security teams visibility into what has been tested and fixed. If there are issues, the security team should track them back to dev owners and establish policies and templates so that they don’t repeat the same mistakes. This approach could finally help security make a significant impact on reducing risk for cloud-native software development. Development teams don’t have to experience security as “yet another tool” or as “yet another process” that slows things down. Security should become a key aspect of the development process and enable developers to ship secure, reliable solutions without thinking too hard.

Fortinet announced new integrations with Amazon Web Services (AWS) to further provide customers with advanced security across their cloud platforms, applications, and network. Fortinet’s cloud security solutions – including its virtual next-generation firewall, FortiGate-VM and web application firewall (WAF), FortiWeb – are designed to protect workloads and business applications across on-premises data centers and cloud environments. Fortinet is continuing to provide a broad set of natively integrated security solutions using AWS to provide customers with full visibility and control of applications and centralized management across cloud and hybrid environments.

Rajesh Maurya, regional vice president, India and SAARC at Fortinet, said: “Enterprises are increasingly looking to integrate both native cloud security and Fortinet’s enterprise-class cloud security offerings to protect their workloads on AWS. Fortinet has always collaborated closely with AWS on security initiatives and we will leverage AWS Marketplace to further enable rapid deployment.”

The announcement builds on Fortinet’s existing collaboration with AWS. Fortinet delivers natively integrated and enhanced security for available AWS services, including Amazon GuardDuty, AWS CloudFormation and AWS Outposts. Supporting the broadest set of use cases, Fortinet’s Security Fabric offers customers with comprehensive security for AWS workloads including firewall, security gateway, intrusion prevention and web application security. AWS is also part of Fortinet Open Fabric Ecosystem, one of theindustry’s largest cybersecurity ecosystems

“For our customers deploying data and applications in AWS, S2 Global has been able to automate operations through the FortiGate-VM Next-Generation Firewalls to protect their VPC environments. With the FortiGate-VM seamlessly integrating with AWS CloudFormation, we’ve been able to create an automated setup for rolling out Fortinet solutions on AWS. Now it takes just a couple of minutes to spin up a new firewall and 40 minutes for an entire stack deployment when previously it would have taken hours. In doing so, we’ve reduced the risk of human error while freeing up time for our IT teams to focus on other business-critical operations,” said Nikolay Chigrin, senior system engineer, AWS at S2 Global.

What Is AWS CloudFormation?

AWS CloudFormation is Amazon’s native Infrastructure as Code (IaC) service. It lets you describe the AWS resources your application needs — EC2 instances, S3 buckets, RDS databases, IAM roles, VPCs, Lambda functions, and hundreds of other resource types — in a declarative template file. You hand that template to CloudFormation, and the service takes responsibility for creating, updating, and deleting the described resources in the correct dependency order.

Templates are written in either JSON or YAML. YAML is generally preferred for human-authored templates because it supports comments and is less verbose, but both formats are fully supported.

Core Concepts

Templates

A CloudFormation template is a text file that declares the desired state of your infrastructure. A minimal template has a Resources section; a production-quality template will also include Parameters, Mappings, Conditions, and Outputs.

# Minimal YAML example: a single S3 bucket
AWSTemplateFormatVersion: "2010-09-09"
Description: "Example — create an S3 bucket"

Parameters:
  BucketNameSuffix:
    Type: String
    Description: Suffix appended to the bucket name

Resources:
  MyBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub "my-app-${BucketNameSuffix}"
      VersioningConfiguration:
        Status: Enabled

Outputs:
  BucketArn:
    Value: !GetAtt MyBucket.Arn
    Export:
      Name: MyBucketArn

Stacks

When you deploy a template, CloudFormation creates a stack — a named collection of all the resources the template describes. The stack is the unit of management: you update a stack by submitting a revised template, and you remove all associated resources by deleting the stack. This makes clean teardown of temporary environments (feature branches, load tests, demos) trivially simple.

Change Sets

Before applying an update to a live stack, you can generate a change set — a preview of exactly which resources will be added, modified, or replaced. Reviewing a change set before executing it is a safety net that prevents accidental resource replacement in production.

Nested Stacks and Stack Sets

Nested stacks allow you to compose large architectures from smaller, reusable templates — for example, a shared networking template referenced by multiple application templates. Stack Sets extend this further, letting a single template be deployed across multiple AWS accounts and regions simultaneously, which is essential for multi-account landing zone patterns.

How CloudFormation Works: The Deployment Flow

1. Author the template — Write JSON or YAML describing your desired resources and their configuration.
2. Upload the template — Submit it via the AWS Console, the AWS CLI (aws cloudformation deploy), or an SDK call. Large templates are staged in S3 first.
3. CloudFormation builds a dependency graph — It determines the order in which resources must be created (e.g., a security group before the EC2 instance that references it).
4. Resources are provisioned — CloudFormation calls the underlying AWS APIs on your behalf. If any resource fails, the stack rolls back by default, leaving your environment in its previous known-good state.
5. Outputs are available — Values you export (ARNs, endpoints, etc.) are queryable by other stacks or CI/CD pipelines.

Key Benefits for DevOps Teams

Repeatability and Consistency

The same template deployed in development, staging, and production guarantees that all three environments are structurally identical. Configuration drift — where environments diverge over time due to manual changes — is eliminated as long as all changes flow through the template.

Version Control and Code Review

Because templates are plain text, they live in Git alongside application code. Infrastructure changes go through pull requests, code review, and automated linting (tools such as cfn-lint and cfn-nag exist specifically for this purpose). This gives you a full audit trail of who changed what and why.

Automated, Reliable Rollback

If a stack update fails partway through, CloudFormation automatically rolls back to the previous successful state. This is significantly safer than running imperative scripts that may leave resources in an unknown intermediate state when they fail.

Environment Replication and Scalability

Spinning up a complete copy of your infrastructure for a new region, a new customer, or a load test is a single command. Parameterize your templates (instance sizes, replica counts, environment names) and you can create arbitrarily many variations from the same source template.

No Extra Cost for the Service Itself

CloudFormation itself carries no additional charge beyond the AWS resources it provisions. You pay for EC2, RDS, or whichever resources the template creates — not for CloudFormation’s orchestration layer.

CloudFormation vs. Other IaC Tools

CloudFormation is not the only IaC option for AWS, and choosing the right tool matters.

CloudFormation is the lowest-friction choice for AWS-only environments because it has the deepest and most up-to-date resource coverage — new AWS services typically appear in CloudFormation on or near launch day. If you want to write infrastructure in a general-purpose programming language rather than YAML, the AWS Cloud Development Kit (CDK) is worth evaluating; it compiles down to CloudFormation templates under the hood.

Getting Started

1. Install the AWS CLI and configure credentials (aws configure).
2. Write a template — Start small. A single S3 bucket or EC2 instance is enough to learn the workflow.
3. Validate it locally: aws cloudformation validate-template --template-body file://template.yaml
4. Deploy it: aws cloudformation deploy --template-file template.yaml --stack-name my-first-stack --parameter-overrides BucketNameSuffix=dev
5. Inspect the stack in the AWS Console under CloudFormation to watch resource creation in real time.
6. Iterate — Modify the template, redeploy, and observe how CloudFormation computes the minimal set of changes required.

Practical Tips

• Use cfn-lint in your CI pipeline to catch schema errors and deprecated properties before deployment.
• Enable termination protection on production stacks to prevent accidental deletion.
• Use stack parameters and SSM Parameter Store references to avoid hard-coding environment-specific values in templates.
• Keep stacks small and focused — a networking stack, a data layer stack, and an application stack are easier to manage independently than one monolithic stack.
• Use DeletionPolicy: Retain on stateful resources (RDS, S3) to protect data if a stack is deleted.

Summary

AWS CloudFormation brings the discipline of software engineering — version control, code review, automated testing, repeatable deployments — to cloud infrastructure management. For teams running workloads exclusively on AWS, it is a natural first choice for Infrastructure as Code: it requires no third-party tooling, supports virtually every AWS service, and integrates directly with AWS IAM, CloudTrail, and CI/CD pipelines. Starting with a simple template and expanding incrementally is the fastest path to reliable, auditable infrastructure.

Three Approaches to AWS Config Rule Customization

Before diving into the details, it helps to understand the three available paths:

1. Console-based editing of managed rules — Rename rules, adjust trigger frequency, narrow the scope of configuration changes, and modify rule parameters directly in the AWS Config console. This is the quickest approach but offers the least flexibility.
2. CloudFormation template customization — Associate AWS Config managed rules with CloudFormation stacks to deploy and manage compliance checks as infrastructure as code. Ideal for repeatable environments and CI/CD pipelines.
3. Custom rules backed by AWS Lambda — Write a Lambda function containing the evaluation logic, then bind it to a new custom rule in AWS Config. This gives you full control over what constitutes compliance for any resource type or configuration state.

The console-based approach is straightforward and well-documented in the AWS console itself. The sections below cover approaches two and three in depth.

Customize AWS Config Rules with CloudFormation

AWS CloudFormation lets you model and provision AWS infrastructure using YAML or JSON templates. A template can define individual resources or a collection of related resources called a stack, which you create, update, and delete as a single unit. Embedding AWS Config managed rules inside a CloudFormation stack ensures that compliance checks are provisioned alongside the resources they govern.

Selecting a Managed Rule for CloudFormation Deployment

Navigate to the list of AWS Config managed rules in the console and identify the rule you want to apply. As a concrete example, consider the ec2-volume-inuse-check rule, which verifies that Amazon Elastic Block Store (EBS) volumes are attached to EC2 instances. This rule fires whenever a configuration is created or changed. It also supports a deleteOnTermination parameter that flags whether EBS volumes should be deleted when the associated EC2 instance is terminated—a useful cost-control measure.

At the bottom of the rule description page, you have two options:

• View — Downloads the CloudFormation template so you can inspect and edit it before deployment. You can then upload the template to an Amazon S3 bucket and launch it later from the CloudFormation console.
• Launch Stack — Opens the CloudFormation console directly with the template pre-loaded, prompting you to supply stack-specific details immediately.

Launching and Configuring the Stack

If you choose Launch Stack, the CloudFormation wizard walks you through naming the stack, setting rule parameters (for example, toggling deleteOnTermination to true or false), adding optional tags, and reviewing the configuration before creation. Once created, the customized managed rule appears in the AWS Config Rules page and begins evaluating resources immediately.

Using CloudFormation Stacks with AWS CodePipeline

A compelling use case for embedding Config rules in CloudFormation is CI/CD pipelines built on AWS CodePipeline. CodePipeline is a managed service for modeling and automating software release stages. Config can track changes to the pipeline itself—such as action definitions or component locations—while CloudFormation stacks that include Config managed rules can provision the hosting environment for each build in a repeatable, compliant way.

For example, a CodePipeline deploy stage can invoke a CloudFormation template that spins up compute, storage, and load-balancing resources, with embedded Config rules that immediately begin monitoring the new environment. When the stack is torn down, the Config rules are removed along with it, keeping your rules list clean.

Create Custom AWS Config Rules with AWS Lambda

AWS Config managed rules cover many common scenarios, but custom business logic often requires rules that do not exist in the managed catalog. For these cases, you can write an AWS Lambda function containing the compliance evaluation logic and associate it with a new custom rule in AWS Config.

It is important to understand the division of responsibility here: the Lambda function is not the rule itself—it is the logic that determines compliance. The rule in AWS Config defines the scope, trigger conditions, and parameters. The function performs the actual evaluation and reports results back to Config using the Config API.

Step 1: Create the Lambda Function

Sign in to the AWS Lambda console and confirm that your chosen region supports AWS Config custom rules. When creating the function, you can start from a blueprint such as config-rule-change-triggered, which provides a skeleton suited to configuration-change events. Key decisions at this stage:

• Name and runtime — Choose a descriptive name and select your preferred runtime (for example, Python or Node.js).
• Handler — Specify the entry-point handler that AWS Lambda will invoke.
• Execution role — Attach an IAM role that grants the function permission to call AWS Config APIs, specifically config:PutEvaluations, as well as read permissions on the resources it needs to evaluate.
• Permission policy template — Use the AWS Config Rules permission policy template available in the console to ensure the function has the correct permissions.

There is no need to configure Lambda triggers manually—AWS Config will invoke the function based on the trigger type defined in the custom rule. After creating the function, test it by running a configured test event in the Lambda console to verify it returns evaluations in the correct format before wiring it to a Config rule.

Step 2: Create the Custom Rule in AWS Config

Open the AWS Config console, go to the Rules page, and select Add rule, then Add custom rule. Fill in the following fields:

• Rule name and description — Use a name that clearly reflects what the rule evaluates.
• AWS Lambda function ARN — Paste the Amazon Resource Name of the Lambda function created in Step 1. This is the critical link between the rule and its evaluation logic. Ensure the function is in the same AWS region as the Config rule.
• Trigger type — Choose Configuration changes (fires when a resource configuration changes), Periodic (fires on a schedule), or both.
• Trigger scope and resource types — Narrow the rule to specific resource types or tags so Config only invokes the Lambda function when relevant resources change.
• Rule parameters — Define key-value pairs that the Lambda function reads at runtime to adjust its behavior without redeploying code. For example, a function that checks EC2 instance types might accept a parameter named desiredInstanceType with a value such as t3.medium.

Save the rule. It will appear on the Rules page, and AWS Config will begin invoking the Lambda function according to the defined trigger conditions. Evaluation results—COMPLIANT, NON_COMPLIANT, or NOT_APPLICABLE—will appear in the Config console alongside the rule.

Choosing the Right Approach

For most teams, a combination of all three approaches makes sense: managed rules handle baseline AWS best practices, CloudFormation integration keeps compliance checks tied to infrastructure lifecycle, and Lambda-backed custom rules encode the business-specific requirements that no managed rule can anticipate.

Summary

AWS Config is a flexible compliance monitoring service that goes well beyond its built-in managed rules. By combining CloudFormation-based deployment with Lambda-driven custom rules, DevOps teams can build a compliance framework that evolves alongside their infrastructure, enforces organization-specific policies, and integrates naturally into automated release pipelines.

Why Manual Compliance Fails in the Cloud

Traditional compliance workflows rely on documentation, periodic audits, and manual checks. In on-premises environments, infrastructure changes slowly enough that these processes can keep up. Cloud environments are fundamentally different: new resources can be provisioned in seconds, configurations can drift silently, and teams can scale infrastructure across multiple regions without centralized oversight.

The core disadvantages of manual cloud compliance include:

• Scale: Hundreds or thousands of resources across accounts and regions make manual auditing impractical.
• Speed: By the time a manual audit catches a misconfigured resource, it may already have been exploited or removed.
• Documentation gaps: Manual processes are prone to inconsistent record-keeping, which creates problems during formal audits.
• Human error: Checklists and spreadsheets introduce opportunities for oversight and inconsistency.

Organizations migrating to AWS need to rethink compliance as an automated, continuous process rather than a periodic manual activity.

Replacing Manual Processes with Managed Compliance Services

AWS offers several approaches to automating compliance. Options include AWS Partner Network solutions such as HPE Continuous Compliance and the use of Chef InSpec integrated with AWS Systems Manager. However, the most direct and native starting point is AWS Config with its managed rules, which requires no third-party tooling and integrates tightly with the rest of the AWS ecosystem.

The principle behind managed compliance services is straightforward: define the desired configuration state of your infrastructure, then continuously compare actual resource configurations against that desired state. Any deviation is flagged, logged, and optionally remediated automatically. This gives auditors a continuous, queryable compliance record rather than a point-in-time snapshot.

AWS Config: Core Concepts

AWS Config is a managed service that provides a detailed, continuously updated inventory of the resources in your AWS account — including EC2 instances, S3 buckets, security groups, IAM roles, VPCs, and more. It records how those resources are configured, tracks relationships between them, and maintains a historical timeline of configuration changes.

Key capabilities of AWS Config include:

• Configuration recording: AWS Config captures the state of supported resources whenever a change occurs, creating a detailed audit trail.
• Resource relationships: It maps how resources relate to each other — for example, which EC2 instances are associated with a given security group.
• Change notifications: Config can notify administrators via Amazon Simple Notification Service (SNS) when a resource is created, modified, or deleted.
• Compliance evaluation: Config evaluates resources against defined rules on a continuous or periodic basis and reports compliance status.

In practical terms, AWS Config acts as the monitoring, logging, and reporting backbone for your AWS compliance posture.

How AWS Config Rules Work

A Config rule defines a desired configuration setting for an AWS resource or for your entire account. AWS Config continuously evaluates each in-scope resource against every applicable rule. If a resource violates a rule — either at the moment of a configuration change or during a periodic evaluation — Config marks that resource as non-compliant and triggers an SNS notification to alert the responsible team.

Rules can be scoped to a specific resource type (for example, all EC2 instances) or applied account-wide. Evaluation can be triggered by configuration changes, on a defined schedule, or both.

AWS Config Managed Rules

AWS provides a library of managed rules — predefined compliance checks authored and maintained by AWS. These rules cover common security and operational best practices and can be enabled with minimal configuration. Administrators can also customize the parameters of managed rules to fit organizational requirements, though this is distinct from creating fully custom rules using AWS Lambda.

Managed rules are organized across several categories:

• Compute: EC2 instance types, AMI compliance, EBS encryption
• Storage: S3 bucket public access, versioning, server-side encryption
• Security, Identity, and Compliance: IAM password policies, root account MFA, CloudTrail enablement
• Network and Content Delivery: VPC flow logs, security group rules, unrestricted SSH access
• Management and Governance: Required tags, Config recorder status

As of the original publication date of this article (September 2019), AWS Config offered more than 100 predefined managed rules. The current number is larger; check the AWS documentation for the current list.

Example: Enforcing EC2 Instance Types

A practical example is the desired-instance-type managed rule. This rule checks whether EC2 instances in scope match a list of permitted instance types. If a developer launches an instance using an instance type not on the approved list — perhaps a large, expensive instance type that violates cost governance — Config marks the instance as non-compliant and sends an alert. The operations or security team can then investigate and take corrective action.

Similar rules exist for Amazon RDS, Redshift, S3, and IAM, providing broad coverage out of the box.

Getting Started: Enabling AWS Config Managed Rules

Follow these high-level steps to enable managed rules in the AWS Management Console:

1. Enable AWS Config in your account and region via the AWS Management Console, CLI, or CloudFormation. Configure an S3 bucket to receive configuration snapshots and an SNS topic for notifications.
2. Select a managed rule. In the Config console, navigate to Rules and choose Add rule. Browse or search the managed rule library to find the rule you want to apply.
3. Configure the rule scope. Specify which resource types the rule applies to and set any configurable parameters (for example, the list of permitted instance types for desired-instance-type).
4. Set the trigger type. Choose whether the rule evaluates resources on configuration changes, on a periodic schedule, or both.
5. Review compliance results. After the initial evaluation runs, the Config console displays each resource’s compliance status. Non-compliant resources are listed with the specific rule they violated.
6. Configure remediation (optional). AWS Config supports automatic remediation actions via AWS Systems Manager Automation documents, allowing you to automatically correct certain violations.

Beyond Managed Rules: Custom Rules and Automation

Managed rules cover a wide range of common compliance requirements, but every organization has unique policies that no predefined rule can anticipate. AWS Config also supports custom rules backed by AWS Lambda functions, giving you full programmatic control over compliance logic. You can also use AWS CloudFormation to deploy Config rules as infrastructure-as-code, ensuring your compliance posture is version-controlled and reproducible across accounts and regions.

Integrating AWS Config with AWS Security Hub, AWS CloudTrail, and Amazon EventBridge further strengthens your compliance posture by correlating configuration compliance data with security findings and enabling event-driven remediation workflows.

Summary

AWS Config managed rules provide a practical, low-friction entry point into continuous compliance on AWS. By replacing manual audits with automated, rules-based evaluation, teams can maintain a verifiable compliance record at the speed and scale the cloud demands. Start by enabling AWS Config in your account, selecting managed rules relevant to your compliance framework, and reviewing the initial compliance report — then expand coverage with custom rules and automated remediation as your program matures.

The Core Question: Declarative vs. Imperative Deployment

Before comparing the three services, it helps to understand the underlying deployment philosophy they share. You can provision AWS infrastructure using shell scripts full of AWS CLI commands—this is an imperative model where every step must be explicitly defined, error handling must be hand-coded, and scripts must be rewritten for each new application.

A more maintainable approach is declarative configuration: you describe the desired end state in a text file, and a deployment engine figures out how to reach that state, including error handling. All three services discussed here use this declarative model. The text files that describe your infrastructure can be stored in version control, enabling an infrastructure-as-code (IaC) workflow.

AWS CloudFormation: Deploying AWS Resources

CloudFormation is AWS’s foundational infrastructure-as-code service. You write a CloudFormation template—a JSON or YAML file—that declares which AWS resources your application needs. CloudFormation reads the template and provisions those resources in the correct order, handling dependencies automatically.

CloudFormation works well for:

• Deploying the AWS resource layer of an application (VPCs, subnets, security groups, RDS instances, S3 buckets, load balancers, etc.)
• Applications that are relatively static, where the entire infrastructure stack can be replaced on each update rather than patched in place
• Teams that need repeatable, version-controlled environment definitions

CloudFormation supports change sets, which let you preview proposed modifications to a running stack—such as adding or removing resources—before applying them. This gives operators an audit step before infrastructure changes take effect.

Key limitation: CloudFormation manages AWS resources at the provisioning level. It does not orchestrate configuration changes inside a running EC2 instance. For example, it cannot install new packages, update application configuration files, or restart services on an already-running server. Shell scripts can be embedded in CloudFormation user data, but their configuration capabilities are limited.

AWS OpsWorks: Configuration Management Inside EC2

AWS OpsWorks bridges the gap that CloudFormation leaves around in-instance configuration. OpsWorks provides managed versions of two popular configuration management tools—Chef and Puppet—as AWS services (OpsWorks for Chef Automate and OpsWorks for Puppet Enterprise). A third variant, OpsWorks Stacks, uses Chef cookbooks in a proprietary stack model.

OpsWorks handles:

• Initial deployment of applications onto EC2 instances, including OS-level configuration
• Ongoing configuration drift remediation—keeping instances in a defined state over time
• Application updates applied to running instances without replacing them
• Operating system package management, user accounts, file permissions, and service management

Use OpsWorks instead of CloudFormation alone when your application requires ongoing updates to the configuration of its EC2 instances—for example, rolling out new application versions, patching OS packages, or managing configuration files that change independently of the underlying infrastructure.

Combining CloudFormation and OpsWorks

For applications that use many AWS services and require detailed EC2 configuration management, CloudFormation and OpsWorks complement each other well. The recommended division of responsibility is:

In this model, CloudFormation bootstraps the OpsWorks stack as part of resource provisioning. Once EC2 instances are running, OpsWorks takes over to apply Chef recipes or Puppet manifests. When changes are needed, AWS resource changes go through CloudFormation change sets; application and OS changes go through OpsWorks. This separation of concerns keeps each tool focused on what it does best.

AWS Elastic Beanstalk: Managed Platform for Web Applications

Elastic Beanstalk takes a higher-level approach. Rather than requiring you to define individual AWS resources, Elastic Beanstalk is a platform-as-a-service (PaaS)-style provisioning service. You upload your application code, tell Elastic Beanstalk which platform to use (e.g., Python, Node.js, Java, Docker), and it provisions and configures the underlying infrastructure automatically.

Elastic Beanstalk automatically handles:

• Web server provisioning and configuration
• Auto Scaling group setup
• Load balancer configuration
• Health monitoring and alerting
• Log aggregation
• Rolling deployments and environment cloning

If your application is a self-contained web application or API and fits neatly within a supported Elastic Beanstalk platform, you may not need CloudFormation or OpsWorks at all. Elastic Beanstalk is the fastest path from code to a running, monitored web environment.

When to combine Elastic Beanstalk with CloudFormation: Most real-world applications need resources that Elastic Beanstalk does not manage on its own—a managed database (RDS), object storage (S3), a cache layer (ElastiCache), or a message queue (SQS). In these cases, use CloudFormation to define the full environment: let CloudFormation provision the Elastic Beanstalk environment alongside the supporting AWS resources. This gives you the convenience of Elastic Beanstalk for the application tier plus the full resource coverage of CloudFormation.

Decision Guide: Which Tool to Use

Use the following guidance to select the right tool or combination of tools for your use case:

• CloudFormation only — You need repeatable provisioning of AWS resources for a relatively static application, and you do not need to manage configuration inside EC2 instances beyond simple startup scripts.
• OpsWorks only (or OpsWorks + CloudFormation) — You have an application running on EC2 that requires ongoing configuration management, package updates, or application deployments to live instances. Add CloudFormation when you also have significant AWS resource dependencies.
• Elastic Beanstalk only — You are deploying a web application or API that fits a supported platform runtime and has minimal external AWS dependencies.
• Elastic Beanstalk + CloudFormation — Your web application needs Elastic Beanstalk’s managed platform conveniences but also depends on additional AWS resources such as RDS, S3, or ElastiCache that must be provisioned alongside it.

Summary Comparison

All three services support a declarative approach to infrastructure management and can be stored as code in version control. Choosing between them—or combining them—depends primarily on how much control you need over the underlying EC2 configuration, how complex your AWS resource dependencies are, and how quickly you need to get a web application running.

Background: Why CloudFormation Users Were Frustrated

AWS CloudFormation is one of the most widely used infrastructure-as-code (IaC) tools in the cloud ecosystem, allowing engineers to define and provision AWS infrastructure through declarative templates. However, for years, a persistent complaint from the CloudFormation community was that AWS’s own IaC tool lagged behind the pace of new AWS service releases — meaning engineers could not manage newly launched services through CloudFormation on day one of general availability.

In response to sustained user pressure, AWS released a public roadmap for CloudFormation in mid-2019, hosted on GitHub. The move was intended to give teams greater visibility into which CloudFormation resource types were being worked on and roughly when they might become available.

AWS evangelist Jeff Barr acknowledged the gap directly in a blog post at the time: “While our goal of providing 100% coverage remains, the reality is that it will take us some time to get there.” He attributed the lag to AWS prioritising scalability of the CloudFormation service itself over complete service coverage.

What the CloudFormation Public Roadmap Contains

The CloudFormation roadmap, modelled after a similar roadmap AWS had released for containers earlier that year, organises planned work into four status categories:

• Shipped: The CloudFormation resource type is complete and available for production use across all AWS public regions.
• Coming Soon: Work is well underway; expect availability within a few months.
• We’re Working On It: Active development is in progress, but on a longer timeline than “Coming Soon.”
• Researching: AWS has not yet determined how to implement the feature and is in an exploratory phase.

Importantly, the roadmap is scoped specifically to coverage updates for existing CloudFormation resource types and resource types with no existing CloudFormation support. It does not include information about AWS services that have not yet been publicly released.

AWS also made clear in its FAQ that specific release dates would not be provided on the roadmap, citing security and stability as primary priorities that could affect timelines.

Community Reaction: Cautious Optimism

Reaction from experienced AWS practitioners was generally positive but measured. Ryan Marsh, a DevOps and serverless coach at TheStack.io in Houston, offered qualified praise:

“This is exactly what we’ve been asking for, in lieu of same-day GA of course. Furthermore, we need to see more of this type of leadership with AWS’s various open source endeavors, many of which still feel controlled by the company — not the community — and yet have no public roadmap.”

Scott Piper, an AWS security consultant at Summit Route in Salt Lake City, took a more sceptical view of how much practical impact the roadmap would have:

“I think the increased transparency is good, although I wonder how many people actually monitor or care about it. I think most people have maybe one feature they want to have happen and so this gives them a better way of tracking the progress of that feature.”

Piper also raised a practical concern about the GitHub thumbs-up mechanism AWS uses to gauge user interest in features: “GitHub suffers from bots like every other social platform, and probably more so.” He suggested that for most customers, feature prioritisation at AWS still ultimately correlates with AWS spend — large enterprise customers with significant annual contracts having more direct influence over AWS engineering priorities than community votes.

CloudFormation vs. Terraform: The Coverage Gap Problem

The frustration driving the roadmap request was not merely academic. Several organisations reported that CloudFormation’s coverage lag had pushed them toward Terraform, the open-source IaC tool developed by HashiCorp. Because Terraform’s AWS provider is maintained by both HashiCorp and the community, it often gains support for new AWS services faster than CloudFormation itself does.

This is a notable irony: AWS’s own IaC tooling has at times provided less coverage of AWS services than a third-party tool. The public roadmap was partly AWS’s acknowledgement of this tension and an attempt to rebuild trust with teams who had already switched or were considering switching.

The CDK Factor: Has AWS Shifted Focus?

One context point worth understanding is that 2019 was also the year AWS launched the AWS Cloud Development Kit (CDK). CDK is an IaC framework that allows developers to define cloud infrastructure using familiar general-purpose programming languages — TypeScript, Python, Java, and others — rather than the JSON or YAML templates that CloudFormation requires.

CDK compiles down to CloudFormation templates under the hood, so it inherits CloudFormation’s coverage limitations. However, its developer experience is significantly different and was well received. Amazon CTO Werner Vogels, in an interview with TechTarget at the time, indicated that AWS had been directing more engineering attention toward CDK based on developer demand:

“I think overall, we’re on a good path — the right path. But I love the fact that there is a long list of requests for CloudFormation. It means that customers are passionate about it and want us to do more.”

For DevOps teams evaluating their IaC strategy, this raises a practical question: if AWS’s own engineering investment was increasingly going into CDK rather than raw CloudFormation template coverage, how quickly would the coverage gap actually close?

Key Takeaways for DevOps Engineers

• The roadmap provides visibility, not velocity guarantees. AWS explicitly declined to commit to specific release dates. Teams should treat the roadmap as a planning input, not a delivery contract.
• Scope is limited to existing services. If you are waiting for a brand-new, unreleased AWS service to get CloudFormation support, the roadmap will not tell you anything until that service is publicly available.
• Community input has limits. GitHub reactions do factor into prioritisation, but large enterprise spend is a more direct lever. Small teams should not assume a popular GitHub issue will move quickly.
• CDK is an alternative worth evaluating. If template verbosity is a pain point in addition to coverage, CDK’s programming-language-native approach addresses a different set of frustrations than raw CloudFormation.
• Terraform remains a valid option for coverage-sensitive workflows. For teams where day-one support of new AWS services is a hard requirement, Terraform’s provider ecosystem may still be a better fit.

Summary

The release of the AWS CloudFormation public roadmap in 2019 was a meaningful transparency improvement, responding directly to years of user criticism about feature lag. Hosted on GitHub and organised into four clear status categories, it gave CloudFormation users a structured way to track resource type coverage progress and provide feedback. However, the roadmap came with important caveats: no release dates, limited scope, and no explicit commitment to accelerated delivery. For DevOps teams building on AWS, it remains one useful signal among several when making IaC tooling decisions.

The Infrastructure-as-Code Landscape Was Evolving Fast

By mid-2017, IT operations teams were leaning heavily on infrastructure-as-code (IaC) tools to keep pace with the demands of DevOps. But the tools themselves were advancing almost as quickly as the applications they were meant to support — bringing both capability improvements and painful breaking changes.

Established players Chef and Puppet had recently restructured their products to support containers and the underlying infrastructure changes that came with them. Chef refactored its codebase into three major open-source projects and introduced Habitat, which many users were still trying to understand. Puppet published a roadmap for improved container support and was working toward a container management API. AWS CloudFormation, released in 2011, had been receiving roughly monthly feature updates in the preceding year.

Among newer entrants, Ansible — launched around 2012 and acquired by Red Hat in 2015 — had added network automation integrations and Red Hat CloudForms support for multicloud environments. HashiCorp Terraform, first released in 2014, had gained momentum quickly but had not yet reached a stable 1.0 release, leaving users to absorb breaking changes with each pre-1.0 update.

“It’s a rapidly evolving area, and a lot of companies are just getting into this space. Most of the people working with these tools are sys admins who are trying to figure out how to scale, rather than developers.”

Brandon Cipes, Managing Director of DevOps, cPrime

Most Teams Mix and Match IaC Tools

Few organizations relied on a single IaC tool. Most combined two or more, which added its own layer of complexity. A common pattern was to start with AWS CloudFormation — a natural first choice for companies building on AWS — and then layer in additional tools as infrastructure needs grew more complex or extended to other cloud providers.

CloudFormation’s verbosity and configuration demands were a recurring complaint. Its JSON (and later YAML) templates require precise parameter configuration, and a misconfigured template will often fail entirely rather than partially recover.

“It’s just not the most friendly tool in the world. It doesn’t use an easy-to-read language, it requires a lot of parameters to be set, and all of those parameters and details have to be very particularly configured or it will break.”

Brandon Cipes, cPrime

Despite its friction, CloudFormation couldn’t simply be abandoned. Its ubiquity within the AWS ecosystem meant teams had to remain fluent in it to collaborate effectively with the broader AWS community.

“CloudFormation is the lingua franca to exchange ideas about infrastructure and AWS resources. We definitely need to know the technology to be able to exchange ideas with the rest of the community because of its ubiquity.”

Joaquin Menchaca, DevOps Engineer, goBalto Inc.

Ansible’s Appeal — and Its Gaps

Ansible’s YAML-based approach made it attractive to teams that wanted their infrastructure definitions to sit naturally alongside application code. Its agentless architecture and low barrier to entry made it popular with sysadmins transitioning into DevOps roles.

However, some practitioners felt that Ansible’s investment in new areas — particularly network automation — was coming at the expense of progress elsewhere. Container support, for example, was seen as underdeveloped. Ansible Container, a project intended to give operators a familiar interface for container workflows, saw limited adoption in practice.

“Their efforts with Docker have been disappointing, as they focus more on Ansible Container projects. It begs the question, ‘Why not just use shell?'”

Joaquin Menchaca, goBalto Inc.

Terraform: Easier to Use, Harder to Upgrade

HashiCorp Terraform had built a following among DevOps teams who found its HCL (HashiCorp Configuration Language) significantly more readable than CloudFormation’s verbose JSON templates. Its cross-cloud provider model was another major draw: teams could manage AWS resources, Google Cloud infrastructure, monitoring services like Datadog, and more — all from a single, consistent configuration language.

“Terraform is a general language for working across clouds and various resources so that we can work with things like Datadog alerts, AWS resources or potentially spin up parts of Google’s cloud infrastructure, all from one place with one uniform configuration language.”

Calvin French-Owen, Co-founder, Segment

“CloudFormation makes you want to poke your eyes out, whereas Terraform is much simpler to understand.”

Calvin French-Owen, Segment

The trade-off was instability in pre-1.0 releases. HashiCorp’s 0.9 release, for example, significantly changed how remote state was stored and managed — a change that was necessary for teams sharing infrastructure, but required substantial rework to adopt.

“We have to reimplement a few things on our side as far as our workflow and re-educate ourselves to move our state as it is now to the 0.9 version.”

Dale Ragan, Senior Software Engineer, SAP Concur Technologies

Teams using Terraform Enterprise also reported bugs in remote state management, leading some to prefer self-managed state stored in Amazon S3 rather than relying on the managed offering.

“In some cases, we’ve found it’s not quite a first-class citizen compared to when we were managing state ourselves and putting it on S3.”

Calvin French-Owen, Segment

The Stateful vs. Stateless Debate

Terraform’s use of state files to track real-world infrastructure was one of its defining characteristics — and one of its most polarizing. Tools like Ansible, Chef, and Puppet had traditionally taken a stateless, declarative approach: describe the desired state of the system and let the tool reconcile the difference. Terraform broke from this convention by maintaining a state file that records what infrastructure exists.

Proponents argued that state tracking was genuinely useful: it let teams know exactly what resources existed, enabled remote state sharing across teams, and allowed infrastructure to be built incrementally on top of resources managed by others.

“Knowing about the resources you have is important, and state gives you that. Also, remote state is tracked to allow teams to build on top of infrastructure they may not control.”

Dale Ragan, SAP Concur Technologies

Critics were more cautious. A corrupted or out-of-sync state file could lead to destructive outcomes — including accidental deletion of infrastructure with a single command.

“Terraform is scary, because if the state is incorrect, you can destroy your entire organization’s infrastructure with a single command. Stateless has always been the preferred way to manage configuration, from CFEngine to Puppet, to Chef and to Ansible; Terraform broke away from this and tries to sell it as a feature.”

Joaquin Menchaca, goBalto Inc.

The mitigation, according to practitioners who had adopted Terraform at scale, was modularization. A well-structured, modular Terraform configuration limits the blast radius of any single operation — a monolithic configuration is far more vulnerable than one broken into composable, independently managed modules.

Where Terraform Fits — and Where It Doesn’t

The consensus among practitioners at the time was that Terraform was not a wholesale replacement for Chef, Puppet, or Ansible — it occupied a different part of the stack. Terraform excelled at provisioning and managing cloud infrastructure: spinning up VPCs, compute instances, DNS records, load balancers, and similar resources. Configuration management tasks — installing packages, managing services, applying OS-level configuration — remained the domain of Chef, Puppet, and Ansible.

“You could call Terraform a subset of Chef, Puppet and Ansible. It’s a tool people like to get infrastructure up quickly, cloud-agnostically, without having to build out all the other stuff those other products necessitate.”

Brandon Cipes, cPrime

In practice, many teams used Terraform to provision infrastructure and then handed off to Ansible or Chef for configuration management — combining the strengths of each tool while accepting the overhead of maintaining expertise across multiple systems.

Key Takeaways for IaC Practitioners

• No single tool does everything. Most mature DevOps shops combine IaC tools, using each where it fits best. Plan for multi-tool complexity from the start.
• CloudFormation’s ubiquity matters. Even if your team prefers other tools, understanding CloudFormation remains important for communicating infrastructure intent within the AWS ecosystem.
• Ansible is approachable, but watch the gaps. Its YAML syntax integrates well with application code, but container support and specific integration areas may lag.
• Terraform’s pre-1.0 releases carry real risk. Breaking changes between minor releases require disciplined upgrade processes and thorough testing before applying to production state.
• Modularize Terraform configurations early. Monolithic configurations amplify the risk of state-related failures. Decompose infrastructure into small, independently managed modules.
• State management is a first-order concern. Whether you store Terraform state in S3, Terraform Cloud, or another backend, ensure it is versioned, locked, and backed up before operating at scale.