What breaks when Lambda resources are imported into Terraform manually?

Manual imports often break at scale because the process is slow, repetitive, and prone to human error. Teams can miss function settings, misalign resource state, or leave gaps between deployed Lambda resources and Terraform configuration. Those errors reduce confidence in the codebase and make later drift detection and remediation more difficult across serverless environments.

Why This Matters for Security Teams

Manual Lambda imports are not just an IaC nuisance. They create a trust gap between what AWS is actually running and what Terraform believes exists. Once that gap appears, teams can no longer rely on plan output, drift checks, or change reviews to tell the full story. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts, and the same visibility problem often shows up in serverless resources and their execution identities.

Security teams usually feel the impact first when a function works in production but its permissions, environment variables, or event triggers were never captured in state. That means the imported resource may look managed while still carrying hidden risk. The issue is especially relevant in environments that also rely on secrets stored in code or config, a pattern NHI Mgmt Group discusses in the Ultimate Guide to NHIs. A manual import can appear successful and still leave the governance model incomplete, which is why drift and misconfiguration tend to persist until an incident forces discovery. In practice, many security teams encounter broken assumptions about Lambda ownership only after an unexpected permission change or failed remediation has already occurred.

How It Works in Practice

terraform import only maps an existing AWS object into state; it does not reconstruct the full intent of the original configuration. For Lambda, that matters because the function is rarely a single resource. It can depend on execution roles, log groups, event source mappings, versions, aliases, provisioned concurrency, environment variables, and permissions. If any of those pieces are omitted from the code after import, Terraform may still show a clean state while the deployed system remains partially unmanaged.

The practical failure pattern is usually one of three things: incomplete resource modeling, state mismatches, or hidden defaults. A team may import the function, but not its related IAM role or trigger source. Or the code may define settings that differ from the live Lambda, causing the next apply to overwrite production behaviour unexpectedly. This is why infrastructure teams often pair import work with external verification from the AWS API and a strict review process grounded in the NIST Cybersecurity Framework 2.0, especially around asset inventory and change control.

For serverless estates, the safer pattern is to treat import as discovery, not completion:

• Inventory the Lambda and every attached control plane dependency before importing.
• Compare live settings to Terraform code field by field, not just resource by resource.
• Import or recreate related IAM, event, and logging resources in the same change set.
• Run drift detection after import and again after the first controlled apply.

This is consistent with broader NHI guidance on visibility and lifecycle control in the Ultimate Guide to NHIs, because a serverless function is only as governed as its execution identity and attached secrets. These controls tend to break down when teams import many functions at once across multiple accounts because state ownership, naming collisions, and hidden dependencies become difficult to reconcile.

Common Variations and Edge Cases

Tighter import control often increases engineering overhead, requiring organisations to balance speed against configuration fidelity. That tradeoff becomes sharper in mature serverless environments where Lambda functions are generated by pipelines, shared across accounts, or wrapped by frameworks that abstract the underlying AWS resources.

There is no universal standard for how much of a Lambda should be imported versus recreated, but current guidance suggests favouring explicit ownership of execution role, triggers, and environment configuration whenever security or compliance matters. Functions with aliases, versions, or weighted routing are especially easy to mis-handle because the imported resource may reflect only the live version, not the deployment contract. Event-driven systems also create edge cases where one missing mapping leaves the function technically imported but operationally disconnected.

Another common issue is secrets exposure. If the imported function relies on hard-coded values or inline environment variables, the import can preserve insecure design rather than fix it. NHI Mgmt Group has documented how secret sprawl and hard-coded credentials contribute to real-world exploitation, including in the Gladinet Hard-Coded Keys RCE Exploitation case study. Manual imports can also mask inherited risk from older IAM patterns, so the better approach is to normalize the function into code, then validate every dependency before declaring the import complete. In practice, partial imports fail most often when legacy functions, shared roles, and opaque deployment tooling collide in the same account.

Related resources from NHI Mgmt Group

• What breaks when existing RDS resources are not managed in Terraform?
• What breaks when a restore creates new resources in a Terraform-managed environment?
• What breaks when mesh resources are managed manually instead of through a declarative workflow?
• What breaks when cache resources are not accurately represented in Terraform state?