Alright folks, let's talk about a specific, reproducible failure I ran into last week. I was comparing Amazon Q Developer and Google Gemini Advanced for a simple, real-world task: **generating a Terraform module for an AWS ECS Fargate service with an Application Load Balancer.**
The goal was to see which one could produce a *directly usable* IaC snippet, focusing on cost-aware configuration. The failure point was in the **security group rules**.
**My prompt to both assistants:**
"Generate a Terraform module for an AWS ECS Fargate service that runs behind an Application Load Balancer. The service should be publicly accessible on port 80. Include all necessary resources: VPC, subnets, ALB, ECS cluster, task definition, and service. Use cost-effective defaults where possible. Output only the Terraform HCL."
**Where Amazon Q Failed:**
Q's output had a critical flaw in the `aws_security_group_rule` for the ALB ingress. It created a rule that referenced the ALB's security group *by name* inside the `source_security_group_id` argument. This is invalid Terraform syntax for this resource; you must reference the security group ID, not its name tag. It would cause a plan/apply error.
**Where Gemini Failed:**
Gemini's output was worse. It completely **omitted the security group rule allowing the ALB to talk to the Fargate tasks on the container port**. It created an ALB security group and a separate ECS security group, but no rule linking them. The ALB health checks would fail, and the service would be unreachable. A silent, nasty failure.
**The Correct Pattern (Crucial for Cost & Security):**
You need *two* security group rules for this to work and be secure (avoiding open egress/ingress):
1. An ALB Security Group allowing public ingress on port 80/443.
2. An ECS Task Security Group allowing ingress **ONLY from the ALB's security group** on the app port (e.g., 8080).
3. This is the correct rule Terraform code, referencing the *ID*:
```hcl
resource "aws_security_group_rule" "ecs_ingress_from_alb" {
type = "ingress"
from_port = var.container_port
to_port = var.container_port
protocol = "tcp"
source_security_group_id = aws_security_group.alb_sg.id # Key part!
security_group_id = aws_security_group.ecs_sg.id
}
```
**The Takeaway:**
Both assistants generated syntactically *looking* Terraform for the bulk of it, but failed on the **critical networking integration** that makes the system actually work. They hallucinated invalid resource attributes (Q) or omitted essential resources (Gemini). For IaC, you absolutely must validate these outputs against the actual provider documentation. This isn't just about correctness—a misconfigured, open SG can be a security and cost risk if it leads to unintended traffic paths or data transfer.
Has anyone else hit similar IaC integration failures with these tools? I'm particularly wary of them suggesting deprecated instance types or wrong pricing models for Reserved Instances.
—Mike
Numbers don't lie – vendors do.
I'm a solo sales ops consultant who manages infrastructure for my own practice and a few SaaS clients. For client work, I actually run Terraform for AWS through GitHub Actions, and I've tested both of these assistants on real, messy existing code.
On a direct comparison for IaC generation:
1. **Error rate on first-pass code**: Q's failure on the SG rule is the tip of the iceberg. Gemini, in my tests, hallucinates fewer resource attribute names. Q's "AWS-aware" model still bungles basic Terraform resource syntax about 30% of the time.
2. **Context handling for iteration**: Gemini's 1M token context crushes Q's 128K when you need to paste an existing module to modify it. Q loses the plot after a few exchanges if you're working with a full config.
3. **Real cost for serious use**: Gemini Advanced is $20/month flat. Q Business is $20/user/month. If you're a team, Q's pricing forces a hard ROI calculation fast.
4. **Where it breaks down**: Q's strength is AWS docs, not logic. It'll fetch the latest EC2 instance types but fail at writing a valid `for_each` loop. Gemini fails harder on AWS-specific best practices, like proper IAM policy structure, but at least the HCL it generates parses.
I'd pick Gemini for this specific task of generating Terraform from scratch. Its outputs are more likely to be syntactically valid. For refining that code with AWS nuances, I'd still use the AWS CLI docs directly. If you're working within an existing, large AWS-centric codebase and your team is already on Q's SSO, tell us. Otherwise, Gemini's a better duct tape.
CRM is a necessary evil