Every team at ARGLabs needs its own AWS accounts, and they all need to look the same: the same access controls, the same network baseline, the same security guardrails. Doing that by hand, account after account, environment after environment, is how drift and mistakes creep in. BigBang is the answer to that problem. It is the process the Cloud Team uses to hand a team a complete, standards-compliant set of AWS accounts, built entirely as code, in minutes, with zero manual contact.
TFMOD: BigBang IAM
Creating a BigBang member account is only half the job. Once the account exists, something has to deploy applications into it without handing out account-wide admin rights. This Terraform module owns the IAM side of every BigBang-generated account: it is meant to be the single place where all identity and access for those accounts is defined. Today it provisions one thing well, the deployer role used to ship containerized apps to ECS, and it is built to grow into the home for any future IAM needs of BigBang accounts.
002 – Shared network account
The Shared Network account is owned by the Cloud Team and exists to do one thing well: provide shared connectivity that the rest of the ARGLabs organization can consume. Instead of every account building and maintaining its own network, this account builds the baseline once and shares it through AWS Resource Access Manager (RAM).
ARGLabs Highlights
What ARGLabs has to offer.
Infrastructure
- Shared network architecture to reduce costs by eliminating NAT gateways and transit gateway charges between environments
Deployment
- Isolated environments (dev, staging, production) fully managed through code
- Multiple parallel deployments of the same application within the same environment: sandbox, QA, homolog, prd1, prd2, and more
- Scheduled destroy and recreation of entire environments to reduce costs and maintain freshness
- GitOps-driven infrastructure using Terraform. Git as the source of truth, every change tracked, reviewed, and auditable
Monitoring
- CloudWatch dashboards tailored to your application and infrastructure metrics
- Proactive monitoring alerts to catch issues before they impact users
Applications
- A sample application designed to exercise and validate auto-scaling policies and monitoring configurations in real conditions
AI
- AI-assisted troubleshooting to diagnose incidents faster and reduce mean time to resolution
- AI-powered infrastructure coding to accelerate Terraform and IaC development
ARGLabs References
Public resources
Terms and Definitions
- ARGLabs name: Its named after my name (Andre “Ramoni” Guimaraes) and “Labs”, that stands for “Do not reproduce it exactly like this in production. If you need help, pay me a pizza.”.
ARGLabs Index, RoadMap and ChangeLog
App Team
- ☐ Team accounts
- ☐ First team app
Cloud Engineering Team
- ☐ Team accounts
- ☐ Team service: VPN
Shared accounts
- ☐ Shared network account
- ☐ Shared monitoring account
Terraform Modules and main projects
- ☐ AWS Account Creation
- ☐ IAM
- ☐ AWS Config
- ☐ BigBang project
Deployment definitions
- ☐ Deployment pipeline
- ☐ Environments
Cloud Infrastructure definitions
- ☐ Networking
- ☐ CIDR Control
- ☐ DNS domains for internal use
Project Bootstrap
- ☑ Main Account first pipeline (by pipeline) – Main account
- ☑ Main Account IaC and Pipeline pre-requisites – Main account pre-requisites
001 – Main account first pipeline
The Main Account is the root of the ARGLabs AWS Organization, but it is intentionally minimal. It does not run any workloads. Its only job is to host the pieces that have to live at the very top of the tree: the organization structure, the identity provider for everyone who logs into AWS, and the company’s main domain.
000 – Main account pre-requisites
We aim to do everything as code in ARGLabs, but at the very first moment we cannot even run pipelines. There is no IAM role for Bitbucket to assume, no S3 bucket to store Terraform state, and no policies to authorize anything. This project breaks that chicken-and-egg cycle by provisioning the foundational pieces every other ARGLabs project depends on.
ARGLabs is Being Rewritten Again
After years of iterating on the same foundation, ARGLabs is getting a full rewrite and this time, AI is at the center of it.
With the advancements in AI tooling, I can now move faster, build smarter, and dedicate more focused time to what actually matters: shipping meaningful infrastructure work. The old repositories have been archived under a legacy project, nothing is lost, but everything going forward will be net-new.
The way accounts, teams, and workflows are structured will also evolve to better fit this AI-augmented world. Less friction, more signal. Automation that used to take days of setup will be handled in minutes, freeing up time for higher-level architectural decisions and real problem solving.
This also means the projects themselves will change in nature. Expect more composable modules, cleaner interfaces, and infrastructure that is genuinely designed for teams working alongside AI agents, not just humans.
Stay tuned, new repositories are coming soon.
Cloud as an Operating System
My view of the cloud is fundamentally different from most people around me. They see it as an opportunity to build better infrastructure. I don’t. I see the cloud as the operating system that will run services and applications for me.
ECS or EKS: Native cloud containers or kubernetes ?
There’s a lot of articles comparing the two and telling you about their differences and when you should go with one or another. I’ll make it slightly different.
I’ll tell you what I want to accomplish considering technology, culture, operations, costs, support and compliance and what is my choice to do so.
I want to provide developer teams a platform so they can easily build, deploy and run their apps in compliance with the Cloud Engineering Team’s best practices and Security Team’s policies.
Speedup cloud usage, cloud services details abstraction, best practices and security policies enforced, costs and permissions controlled with no bureaucracy and 100% cloud provider support.
ARGLabs fictitious company
So you are a newcomer on our company. Congratulations !
Our DevOps culture
We like the DevOps “You build it, you run it.” culture.
It means that our Cloud Engineers (call them DevOps, SRE, infrastructure guys or whatever you want), will help you with the basic cloud infrastructure on which your applications will run, but they won’t be called to solve your apps problems and incidents, so please, take the ownership of everything you bring up on the cloud, including costs, incidents etc.
Cloud Engineers can always help you with architecture decisions and deployment pipelines, but once it’s running, it’s up to you to keep things up.
Why a .church domain ?
Because churches are places of faith.
I love IaC. I really do IaC. I think I understood what we can really do with IaC.
But I’ve seen many “good practices” out there that I thought aren’t good enough, many written by famous people and others even by the tool suppliers themselves.
In fact, everyone can write and publish anything and call it a “best practice”, and in fact, it could be for them, for many reasons. Good practice is what works best for your way of working.
ARGLabs is my church because this is where I’m going to show what I believe are best practices for the work I do.
In ARGLabs Church, I am the law (as Rodrigo Goes says 🙂 ).
These are not intended to be best practices for everyone.
What is ARGLabs ?
Take ARGLabs as a fictional company where we’ll be running some applications like a real company
And with “real company” we mean that we’ll bring up everything needed to run our applications.
Every tech company “just” need to “run their applications”. By design, no specific tools are needed as long as the chosen tools meet the applications needs. With that in mind, we’ll choose the simplest tools and only those which allow us to configure them as code.
So what makes ARGLabs worth it, and why you would read more about it ?
Our tech design principle is: “If it can’t be done as code, it cannot be done.”
With that, many other benefits come along:
- Knowledge is written down in code and no more in anyones head.
- Disaster recovery or any number of dev/testing environment is just a matter of cost, but without managing effort.
And countless benefits more. Majority of them already included by the above mentioned (please don’t ask me to tell you every single benefit. If you can’t see them, maybe you should ask you tech staff after reaching us)
We’ll use many tools (where a free account could meet our needs) that a real company would use.
We’ll try to have every tech stuff a modern company usually have:
- Public and private applications
- Deployment pipelines, CI/CD
- Monitoring tools and metrics
- Incident Management
- Communication platform and integrations
ARGLabs 