Manual vs Terraform: What's the Best AWS Workflow for Data Engineers?

Wondering whether to build your AWS infrastructure manually or with Terraform? Learn the pros, cons, and best practices for data engineers working with AWS services like S3, Lambda, Glue, and Step Functions.

Terraform vs manual AWS diagram

Last updated: July 04, 2025

Introduction: Terraform or Manual AWS? Every Engineer Hits This Crossroads

When I first started building cloud pipelines as a data engineer, I dove into the AWS Console and began clicking through tutorials. I spun up an S3 bucket, wrote a Lambda function in the inline editor, and copied JSON into IAM policies without really knowing what they did. It worked, kind of. But when I wanted to recreate that project later, I couldn’t remember half the steps I took.

That’s when I heard about Terraform.

But I asked the same question you’re probably asking:

“Should I build everything manually first, or should I use Terraform from the beginning?”

This article explores both sides, with practical guidance on when and how to use Terraform effectively, especially in AWS data engineering workflows.


Manual AWS Setup: The Good, The Bad, The Clicky

Pros:

  • Faster to experiment: Great for learning services like Glue, Lambda, or Step Functions hands-on.
  • Visual feedback: See what you’re building immediately.
  • Quick debugging: Easier to inspect logs and tweak values manually.

Cons:

  • No reproducibility: If something breaks or needs to be rebuilt, you’re back to square one.
  • Permission drift: Manually attached policies become hard to track.
  • Zero version control: Your infra lives in your memory, not in Git.
  • Scaling pain: Impossible to scale to multi-environment (dev/stage/prod) setups cleanly.

Manual is fine for prototypes. But once your pipeline matures, it becomes technical debt.


Terraform-First Workflow: AWS the Right Way

Pros:

  • Declarative infrastructure: Everything is reproducible, testable, and trackable in version control.
  • Modular reusability: Use modules to share logic across environments.
  • Team-friendly: Multiple engineers can understand and collaborate on infra.
  • Tagging and cost control: Easier to manage costs with consistent tagging and policy enforcement.

Cons:

  • Learning curve: Understanding Terraform syntax, state files, and IAM roles can be overwhelming.
  • Slower iteration: Takes longer to prototype new AWS services unless you know what to expect.

Real AWS Example: Data Pipeline with Manual First, Terraform Later

Here’s how many data engineers approach a project like a stock price ETL pipeline:

Phase 1: Manual (Exploration)

  • S3: Create bucket for raw data
  • Lambda: Use API to fetch data and store in /raw/
  • Glue: Build a PySpark script to transform JSON to Parquet
  • Athena: Manually define schema, query outputs
  • Step Functions: Connect steps manually to test flow

You learn fast, but you forget faster.

Phase 2: Incremental Terraform Adoption

module "s3" {
  source = "./modules/s3"
  bucket_name = var.bucket_name
}

module "lambda" {
  source = "./modules/lambda"
  bucket_name = module.s3.bucket_name
  api_key     = var.api_key
}

module "glue" {
  source = "./modules/glue"
  bucket_name = module.s3.bucket_name
}

You start with S3 and Lambda, then add Glue and Step Functions. Use terraform plan -target=module.lambda to test in isolation.


Best Practices for Using Terraform as a Data Engineer

1. Start Small, Then Expand

Don’t Terraform your entire cloud from day one. Begin with a working manual prototype. Once stable, convert to IaC.

2. Use IAM Least Privilege from the Start

Avoid * policies in Terraform. Write and test scoped roles and validate with CloudTrail or AWS Access Analyzer.

3. Modularize Reusable Components

Encapsulate each major service (S3, Lambda, Glue) into its own module. This keeps things testable and composable.

4. Leverage Tags and Outputs

Use tags consistently and expose key output values for debugging or referencing across modules.

5. Schedule & Orchestrate with Step Functions + EventBridge

You can trigger your Terraform-provisioned pipeline daily using cron expressions like:

schedule_expression = "cron(0 6 * * ? *)"  # 6 AM UTC

What About Athena and Schema Evolution?

Use Terraform to define Glue Catalog Tables for Athena, but beware of schema drift. If your JSON structure changes, keep Athena queries resilient by defining them with serde options or partition-aware layouts (like symbol=date folders).


Key Takeaways: Build It, Then Code It

  • Manual AWS is great for learning but not for scaling.
  • Terraform makes your infrastructure repeatable, shareable, and safer.
  • For data engineers, the best path is usually manual-first, Terraform-second.
  • Use Terraform to solidify knowledge and productionize your pipeline.
  • Start modular, test with -target, and iterate.

Final Thoughts

The real world is messy. Start with exploration, then enforce structure. Terraform is not just a tool, it’s a way of thinking. Once your AWS data workflow works manually, freeze it in Terraform and build the foundation for scale.



Frequently Asked Questions

Q: Should I use Terraform or manual AWS when building my first data pipeline?
A: Start manually to learn the services, but use Terraform to scale, document, and secure your infrastructure in production.
Q: Can I mix manual AWS setup and Terraform in one project?
A: Yes, but it's best to migrate manual components into Terraform incrementally for consistency and automation.

Want to keep learning?

Explore more tutorials, tools, and beginner guides across categories designed to help you grow your skills in real-world tech.

Browse All Categories →