Infrastructure as Code Built and Run for Software Teams
Your cloud account can be rebuilt from your repository, and every change is a Terraform plan your engineers read before a person you name approves it. In Dallas-Fort Worth, ITECS covers importing hand-built accounts, locked remote state, a plan per pull request and reusable modules. It also covers scheduled drift checks, who keeps console write access, and Terraform or OpenTofu.
- Who it is for
- Platform leads who own the cloud accounts
- What ITECS builds
- Terraform or OpenTofu code and shared modules
- What ITECS runs
- Applies and drift checks in your pipeline
- Pricing
- Custom-scoped. The assessment's written plan orders the work and prices its first piece, before any code is written. How a code build is quoted
- After launch
- ITECS runs it, or your team does with runbooks
Scope
What ITECS puts under code
The code lives in your repositories and the state in your cloud account. ITECS opens the pull requests, and your engineers decide what merges.
- Hand-built accounts
- ITECS imports what the account already runs, foundations first, and leaves out what you are retiring. An import records an existing resource in state and changes nothing in the account.
- Remote state
- State is Terraform's record of what it manages. It sits in a backend in your cloud account, locked from the first day so two applies cannot run at once. Only the apply job writes to it.
- Plan and apply
- Every pull request gets a Terraform plan posted beside the code. That plan is the change's test, since reviewers see what will change in the account before anything merges.
- Reusable modules
- Networks, roles and service stacks are written once and reused in staging and production. The environments differ only where their inputs say so.
- Drift checks
- A refresh-only plan runs on a schedule and compares the account with what the last apply recorded. When the two differ, the drift owner you name decides what happens next.
- Console access
- Console write access narrows to a few named people. When one of them changes something there, the next drift check shows it, and your drift owner opens a ticket for it.
- Terraform or OpenTofu
- ITECS writes for either tool. The fit depends on the hosted features you use, what your CI and policy tools support and what procurement requires. You choose, and ITECS records why.
Scenario
A console-built account that outgrew its Terraform files
Illustrative planning scenario, not a reported client result or a named public case study.
- Starting point
- A software company's AWS account was built in the console over the years by people who have since left. A few Terraform files exist and no longer match it. A change that passed in staging broke production, because nobody knew the two environments differed. A new platform lead wants the account in code with no outage.
- Scoped outcome
- ITECS puts remote state with locking in place first, then imports the account in dependency order until the Terraform plan shows zero changes. Staging and production are built from the same modules and differ only where their inputs say so. Drift checks are scheduled, and the platform lead names the few who keep console write access.
Approach
Bringing a live account under code
Each import batch is applied only once its Terraform plan proposes nothing beyond the imports themselves, so production runs as before.
Inventory the account
With read access to the account and your repositories, ITECS lists every resource the account runs and reads the Terraform files that exist. You decide what stays out.
Put state in place
Remote state with locking goes in before the first import, in a backend inside your account, so every later run works from one shared record.
Import in order
Networks and identity come in first, then the services on them. ITECS trims the code Terraform generates for each import, and a reviewer on your team signs off each batch's pull request.
Zero-change plan first
Each batch is reworked until its plan shows zero changes. The assessment's written plan lists the resources that cannot be imported, and you decide how to rebuild each one.
Name the drift owner
You name the person who decides each drift, and the checks are scheduled. From then on, a fix for drift is a pull request like any other change.
Change loop
How a change reaches your account
Nothing applies until your approver clears the diamond. Drift goes back to Plan, above the review and your approver, so a fix for drift passes the same two people as any change. The loop keeps running after the build is done.
Your repository
Write
An engineer changes the code on a branch and opens a pull request. Provider and module versions are pinned, so a new release cannot change what the code does unreviewed.
Output: Change in a pull request
Plan
The pipeline runs a Terraform plan against the live account and posts it on the pull request. It lists what will be created, changed or destroyed.
Output: Posted plan
Review
Your engineers read the plan beside the code. A replacement or a destroy is called out, and the reviewer confirms it is meant before the merge.
Output: Reviewed plan
Your pipeline
Apply
After the merge, the apply waits in the pipeline for your approver. It applies a saved plan, and Terraform refuses one made stale by a later change.
Output: Applied change
Held for your approver
Your cloud account
State
The apply holds a lock on the shared state while it runs, and the pipeline queues a second apply until the lock clears. The state then records what the account holds.
Output: Updated state
Drift check
On a schedule, a refresh-only plan compares the account with what the last apply recorded and changes neither. When they differ, your drift owner decides.
Output: Scheduled drift report
Drift: plan again
Dashed: the apply held for your approver. Left line: drift goes back to Plan.
Deliverables
What lives in your repositories and your account
- Terraform or OpenTofu code for every imported resource, in your repositories.
- Modules for networks, roles and service stacks, with the inputs each environment sets.
- A state backend in your account, with locking, versioning and encryption at rest.
- Pipeline jobs that post a Terraform plan on each pull request and run the apply after approval.
- A drift schedule, a runbook for each drift decision and the list of who keeps console write access.
- ITECS's own access defined in the code, so removing it is one reviewed change.
Where it fits
What the code connects to
Your platform lead sets the import order from the assessment's inventory. The pipeline runs every Terraform plan and apply, and a cluster is one of the things the code defines.
- DevOps assessment
- Inventories what your accounts run and names what cannot be imported, so your platform lead can set the import order.
- DevOps services
- Observability, managed DevOps and the other services ITECS builds and runs.
- CI/CD pipelines
- Plans and applies run as pipeline jobs that reach your cloud with short-lived credentials instead of stored keys.
- Kubernetes platforms
- The cluster, its node pools and its networks are defined in this code, and they change through the same loop.
- Linux server support
- After the apply, ITECS's Linux practice on itecsonline.com can own patching and support for each Linux server the code builds.
- Sign in to Terraform state with OIDC
- The OIDC article shows how to give the state backend its own roles in place of stored keys, with state write access kept for the apply job.
Pricing
How a code build is quoted
Infrastructure code work is custom-scoped. The quote follows from what the assessment finds in your accounts.
- Assessment
- The first step. Its scope and price are agreed on a call, and the assessment's written plan orders the work and prices the first piece.
- What moves the quote
- The accounts and environments in scope, the resources to import, the modules to write and the pipelines the applies run in.
- Code build
- Each piece is quoted before it starts, beginning with the accounts you choose to bring under code first.
- Managed DevOps
- A retainer for the applies and drift checks ITECS runs, with after-hours cover for failed applies and emergency console changes.
- Cloud and tool licenses
- Cloud usage, state storage and tool subscriptions such as HCP Terraform are billed to you directly, unless a proposal says ITECS passes them through.
AI package prices on this site do not apply to this work.
FAQ
Infrastructure as code FAQ
What do infrastructure as code services include?
Infrastructure as code services, often bought as Terraform consulting, put your cloud in code that a pipeline applies. ITECS covers importing hand-built accounts, locked remote state, a Terraform plan on every pull request and reusable modules. It also covers scheduled drift checks, who keeps console write access, and Terraform or OpenTofu. It works in your accounts, in Dallas-Fort Worth and across the United States.
Can a hand-built account come under code without downtime?
In most cases, yes. An import records an existing resource in state and changes nothing in the account. ITECS applies each batch only once its plan shows zero changes. When an account is too tangled to import cleanly, the assessment says so. Your platform lead then chooses between importing it and building a new account in code and moving workloads across.
Should we use Terraform or OpenTofu?
Both read the same configuration language and providers, and ITECS works in either. HCP Terraform's hosted features count for Terraform, and OpenTofu can encrypt state and plan files. Your CI and policy tools and your procurement rules weigh in too. You make the call, and the assessment's written plan records it.
How do you catch drift, and who decides what to do about it?
A refresh-only plan runs on a schedule. It compares the account with what the last apply recorded and changes neither. When they differ, your drift owner decides. They accept the change, by recording it in state and matching the code to it, or they overwrite it by applying the code.
Will you lock us out of the console?
Your engineers keep read access. Write access narrows to a few named people, for emergencies and for anything the code does not cover yet. A console change shows up in the next drift check, and your drift owner opens a ticket to bring the code in line.
Will ITECS write modules our team can reuse?
Yes. Modules cover what every environment repeats, such as networks, roles and service stacks, and each environment sets its own inputs. They are versioned in your repositories, so your engineers can build the next environment from them without ITECS.
Where does the state live, and who can change it?
In a storage backend inside your own AWS or Azure account. Locking stops two applies from running at once. The plan job can read the state, and only the apply job can write it. Earlier versions are kept, so a bad write can be rolled back.
Should we hire a platform engineer instead?
Hire one if you can keep them. The gap is that one engineer becomes the only reviewer, approver and drift owner, and applies wait while they are on leave. ITECS has run managed IT and security since 2002 with a 24/7 NOC. Under managed DevOps, it finishes a failed apply or an emergency console change at night and logs it as a ticket. A new hire later takes over the code and the runbooks together.
Find out what your account runs
Bring the account list, any Terraform files you have and the last change that broke something by surprise. You decide what comes under code first, and the assessment's written plan records it and quotes it.