DEV Community: John Ajera

Why does my AWS SSO session die so fast? (And how to change it in the console)

John Ajera — Fri, 17 Apr 2026 21:13:08 +0000

Why does my AWS SSO session die so fast? (And how to change it in the console)

Ever open the AWS access portal, click into an account, get a few things done, grab coffee, come back—and your session is gone? You sign in again through IAM Identity Center (what people still call SSO), mutter something about timeouts, and move on.

I used to assume AWS was just being strict for security. Partly true. The other part is boring: the permission set is probably still on the default session length, which is often one hour. Once you know that, fixing it is a few clicks in the console. No Terraform, no CLI—just the UI.

1. Overview

What you are changing: Session duration on an IAM Identity Center permission set (how long console and CLI sessions issued through that set stay valid before you must re-authenticate through the portal).
Why it felt short: Default duration for a new permission set is commonly 1 hour unless someone already raised it.
What this article is not: IAM roles in accounts, temporary credentials from sts:AssumeRole in automation, or Control Tower landing zone knobs—only Identity Center permission sets.

2. Prerequisites

You can sign in to the AWS Management Console for the organization that owns IAM Identity Center (often the management or delegated admin account where the directory lives).
Your user (or role) has permission to edit permission sets (for example an IAM Identity Center administrator).

3. Open the permission set

3.1 Go to IAM Identity Center

In the console, open IAM Identity Center (search IAM Identity Center in the top search bar if the console layout moves again).

3.2 Open Permission sets

Choose Permission sets in the left navigation. Select the permission set you actually use for day-to-day access (for example AdministratorAccess, PowerUser, or a custom name your org created).

4. Edit session duration

4.1 Edit settings

On the permission set details page, choose Edit (sometimes shown as Edit configuration depending on the console version).

4.2 Find session duration

Look for Session duration (wording may be Session length or similar). You will see a value in hours (or a dropdown bounded by what Identity Center allows for that permission set).

Pick something that matches how you work—for example 8 hours for a normal workday—without ignoring your org’s security policy. Shorter is generally safer for high-privilege sets; longer is more convenient and widens the window if a session is misused.

4.3 Save

Save the change. Existing sessions do not always pick up the new limit immediately; people may need to sign out of the access portal and sign in again (or wait for the current session to expire) before the new duration applies.

5. Summary

Short timeouts after portal login are often just the permission set default (commonly one hour), not a mystery AWS punishment.
IAM Identity Center → Permission sets → your set → Edit → Session duration → save. Re-login if you do not see the new behavior yet.

6. References

Configure session duration for AWS IAM Identity Center (AWS Documentation)

Unenroll a Control Tower sandbox member with the AWS CLI

John Ajera — Thu, 16 Apr 2026 09:28:40 +0000

Unenroll a Control Tower sandbox member with the AWS CLI

You enrolled a member account into AWS Control Tower (for example a sandbox workload account) and later want it not governed by the landing zone anymore. The console path is Organization then Unmanage. This article is the CLI path: terminate the Control Tower Service Catalog provisioned product that represents account enrollment, without closing the AWS account.

1. Overview

Goal: Unenroll (unmanage) one member account so Control Tower removes its controls and Service Catalog enrollment, while keeping the account open in AWS Organizations.
Mechanism: Terminate the CONTROL_TOWER_ACCOUNT provisioned product whose name looks like Enroll-Account-<12-digit-account-id>, with --retain-physical-resources so the account itself is not deleted.
Where it runs: Management account credentials with permission to Service Catalog APIs (and typically Organizations read if you verify parent OU afterward).
Region: Use your Control Tower home region (often where Account Factory and enrollment products live). Examples below use ap-southeast-2; substitute yours if different.

2. Prerequisites

Management account access (for example IAM Identity Center admin role on the org payer).
AWS CLI v2 configured for that account (aws sts get-caller-identity shows the management id).
The member account id you are unmanaging (12 digits).
Patience: termination is asynchronous; poll describe-record until SUCCEEDED or diagnose FAILED.

3. Confirm identity and region

3.1 Caller identity

export AWS_PROFILE=your-management-profile

aws sts get-caller-identity

Confirm Account is the organization management account.

3.2 Control Tower home region

If you are unsure which region holds enrollment products, try the region where you normally open Control Tower and Account Factory, then continue in Section 4 using that --region.

4. Find the enrollment provisioned product

4.1 Scan provisioned products

scan-provisioned-products returns up to 20 items per call (use PageToken if you have many). Filter by eye or script for Enroll-Account-<your-member-id>.

REGION=ap-southeast-2

aws servicecatalog scan-provisioned-products \
  --region "$REGION" \
  --page-size 20 \
  --output json

4.2 Identify the fields you need

From the matching object, note:

Id — the provisioned product id (example shape: pp-xxxxxxxxxxxxx).
Name — often Enroll-Account-405087531484 style.
Type — should include CONTROL_TOWER_ACCOUNT for the enrollment product you want to end.

If nothing appears in the first page, paginate with --page-token from the response, or confirm region and that the account was enrolled through Control Tower (not only moved under an OU in Organizations without enrollment).

5. Terminate the provisioned product (unenroll)

Use a unique --terminate-token per attempt (idempotency). --retain-physical-resources keeps the AWS account; Control Tower still tears down CT-managed resources it owns for that enrollment.

REGION=ap-southeast-2
PP_ID=pp-jxuf4ldvkwxxc

aws servicecatalog terminate-provisioned-product \
  --region "$REGION" \
  --provisioned-product-id "$PP_ID" \
  --terminate-token "unenroll-$(date +%s)" \
  --retain-physical-resources \
  --output json

The response includes RecordDetail.RecordId (example shape: rec-xxxxxxxxxxxxx).

6. Wait for the record to finish

describe-record uses --id set to the record id (not --record-id on the CLI).

REGION=ap-southeast-2
RECORD_ID=rec-tupynci5numpi

aws servicecatalog describe-record \
  --region "$REGION" \
  --id "$RECORD_ID" \
  --query 'RecordDetail.{Status:Status,Errors:RecordErrors}' \
  --output json

Poll until Status is SUCCEEDED. If FAILED, read RecordErrors and fix permissions or open an AWS Support case for Service Catalog / Control Tower as appropriate.

7. Verify organization placement

After a successful unmanage, the account usually moves under the organization root (no longer under a Control Tower-registered OU for that enrollment). Confirm with Organizations:

MEMBER_ID=405087531484

aws organizations list-parents --child-id "$MEMBER_ID"

Expect Type ROOT for the parent you care about when the account has been moved out of Control Tower-managed OUs per product behavior.

Also expect: Control Tower removes AWSControlTowerExecution from the member when it cleans up. If you manage that role elsewhere (for example Terraform in a factory repo), run your pipeline again so intent matches reality.

8. Console alternative

If you prefer the UI: Unenroll an account — Control Tower console, Organization, expand the OU, select the account, Unmanage, wait until status shows Not enrolled.

9. Summary: Copy-paste

Replace REGION, PP_ID, AWS_PROFILE, and optionally MEMBER_ID for checks.

export AWS_PROFILE=your-management-profile
REGION=ap-southeast-2

aws sts get-caller-identity

aws servicecatalog scan-provisioned-products \
  --region "$REGION" \
  --page-size 20 \
  --output table

PP_ID=pp-REPLACE_ME
aws servicecatalog terminate-provisioned-product \
  --region "$REGION" \
  --provisioned-product-id "$PP_ID" \
  --terminate-token "unenroll-$(date +%s)" \
  --retain-physical-resources \
  --output json

RECORD_ID=rec-REPLACE_ME
aws servicecatalog describe-record \
  --region "$REGION" \
  --id "$RECORD_ID" \
  --output json

MEMBER_ID=405087531484
aws organizations list-parents --child-id "$MEMBER_ID"

10. Troubleshooting

Issue	What to try
`scan-provisioned-products` returns no `Enroll-Account-…`	Wrong `REGION`; use Control Tower home region. Or the account was never enrolled via Control Tower (only placed in an OU with Organizations).
`terminate-provisioned-product` access denied	Principal lacks Service Catalog terminate permissions in the management account.
`describe-record` `FAILED`	Read `RecordErrors`; may be Control Tower internal constraint, SCP, or account state.
`ParamValidation` on `describe-record`	Use `--id`, not `--record-id`, for `record-id` style values.
Account should stay in a specific OU after unenroll	Unmanage moves the account to root per AWS docs; move it again with `aws organizations move-account` if your org design requires a different OU.

11. References

Unenroll an account (Control Tower User Guide)
Unenroll an account in Service Catalog (terminate provisioned product)
TerminateProvisionedProduct (API reference)
DescribeRecord (API reference)
MoveAccount (Organizations API, if you relocate after unenroll)

IAM Identity Center account assignments for Terraform member accounts

John Ajera — Wed, 15 Apr 2026 19:27:14 +0000

IAM Identity Center account assignments for Terraform member accounts

Once sandbox and development member accounts exist in AWS Organizations (for example from Terraform as in a companion article on that layout), they do not automatically appear in the AWS access portal. IAM Identity Center (successor to AWS SSO) shows an account only when there is an account assignment: a user or group mapped to a permission set in that account. This guide explains that model and shows a compact Terraform pattern: look up the SSO instance, resolve an existing permission set and group by name, and create aws_ssoadmin_account_assignment for each member account. It assumes a Control Tower–friendly landing zone where Identity Center is already enabled in the organization management account; it does not rehash Organizations account creation itself.

1. Overview

Problem: New member accounts have root users and OrganizationAccountAccessRole, but directory users do not see the accounts in the access portal until assignments exist.
Approach: Terraform calls SSO Admin and Identity Store in the region where Identity Center is enabled, then creates one assignment per account (sandbox and dev) for the same group and permission set.
How this article reads: The Terraform below uses fixed illustration values (region, permission set name, group display name) and no count, toggles, or precondition blocks so the flow is easy to scan. In a real repo you usually add variables, optional count, and guardrails; a short note after the snippet calls that out.
Scope: Group principals and an existing permission set by name; creating permission sets or SCIM groups is out of scope here.

2. Prerequisites

IAM Identity Center enabled in the org (management account or documented delegated admin); you know the region where the portal was turned on (often the home region you use for admin work).
At least one permission set already defined (for example AdministratorAccess or AWSPowerUserAccess) and one group with a known display name in the Identity Center directory.
Terraform 1.5+ and hashicorp/aws provider 5.x (examples below use patterns compatible with that stack).
The IAM principal that runs Terraform must be allowed SSO Admin and Identity Store actions used by the provider (see §6). The same principal typically already has Organizations access if this module also manages accounts.
Member account ids from Terraform outputs (or the console) for sandbox and dev.

Background: IAM Identity Center and Terraform aws_ssoadmin_account_assignment.

3. How the portal decides what to list

Flow (ASCII):

  User opens access portal URL
           |
           v
  IAM Identity Center  ---- evaluates  ---->  Account assignments
  (directory + permission sets)              (group X + permission set P + account A)
           |
           v
  User sees account tiles only where an assignment exists for that user or their groups

Account assignment ties three things together: principal (here a group), permission set (IAM role shape in the target account), and target (AWS account id). Without that row, the account stays invisible in the portal for directory users even if the account is healthy in Organizations.

4. Terraform shape

SSO Admin and Identity Store APIs are invoked in the region where IAM Identity Center is enabled. The snippet uses an aliased provider with a literal region so it is obvious what to change first if your portal runs elsewhere (for example us-east-1).

Replace for your org: ap-southeast-2, AdministratorAccess, AWSControlTowerAdmins, and ensure aws_organizations_account.sandbox_1 / dev_1 match your module (or substitute 12-digit account ids).

provider "aws" {
  alias  = "identity_center"
  region = "ap-southeast-2"
}

data "aws_ssoadmin_instances" "this" {
  provider = aws.identity_center
}

data "aws_ssoadmin_permission_set" "assignment" {
  provider = aws.identity_center

  instance_arn = one(data.aws_ssoadmin_instances.this.arns)
  name         = "AdministratorAccess"
}

data "aws_identitystore_group" "assignment" {
  provider = aws.identity_center

  identity_store_id = one(data.aws_ssoadmin_instances.this.identity_store_ids)

  alternate_identifier {
    unique_attribute {
      attribute_path  = "DisplayName"
      attribute_value = "AWSControlTowerAdmins"
    }
  }
}

resource "aws_ssoadmin_account_assignment" "sandbox_1" {
  provider = aws.identity_center

  instance_arn         = one(data.aws_ssoadmin_instances.this.arns)
  permission_set_arn   = data.aws_ssoadmin_permission_set.assignment.arn
  principal_id         = data.aws_identitystore_group.assignment.group_id
  principal_type       = "GROUP"
  target_id            = aws_organizations_account.sandbox_1.id
  target_type          = "AWS_ACCOUNT"
}

resource "aws_ssoadmin_account_assignment" "dev_1" {
  provider = aws.identity_center

  instance_arn         = one(data.aws_ssoadmin_instances.this.arns)
  permission_set_arn   = data.aws_ssoadmin_permission_set.assignment.arn
  principal_id         = data.aws_identitystore_group.assignment.group_id
  principal_type       = "GROUP"
  target_id            = aws_organizations_account.dev_1.id
  target_type          = "AWS_ACCOUNT"
}

principal_type can be USER if you resolve a user and pass that principal id instead; groups are a common default for team access.

Production note: Real modules usually parameterize the region, permission set name, and group display name (for example with variables), and sometimes wrap assignments in count or use lifecycle.precondition so you never plan with an empty group name or enable SSO changes by mistake. The literal version above is only for reading the happy path.

5. IAM permissions for the Terraform principal

Your role or user needs API access for read paths (instance, permission set, group lookup) and write paths (CreateAccountAssignment, DeleteAccountAssignment on destroy). Typical action families include SSO Admin (sso:ListInstances, sso:DescribePermissionSet, sso:CreateAccountAssignment, …) and Identity Store (identitystore:GetGroupId, identitystore:DescribeGroup, …). Tighten ARNs and actions in a real policy; start from the Terraform plan error messages if something is missing.

6. Summary: Copy-paste

After pasting the resources into your root module and fixing the illustration strings:

export AWS_PROFILE=YourManagementProfile
terraform plan
terraform apply

Confirm in IAM Identity Center → Multi-account permissions → AWS accounts (wording varies by console revision) that assignments exist for sandbox and dev. Ask a member of the group to open the access portal and verify two new account tiles (after propagation, which can take a short time).

7. Troubleshooting

AccessDenied on sso:ListInstances: The caller’s policy omits SSO Admin permissions, or Terraform is using the wrong region for the aliased provider.
GetGroupId validation / empty attribute: attribute_value for the group was empty or wrong; set it to the exact display name from IAM Identity Center → Groups.
Permission set not found: The name in aws_ssoadmin_permission_set does not match any permission set name in your directory (names are not always identical to AWS managed policy names in the console).
Group not found / ambiguous display name: DisplayName must be unique enough for the lookup; prefer the exact string from Groups in the console.
Account still missing in portal: Assignment targets the wrong account id; user is not in the assigned group; or propagation not finished yet.

8. References

Terraform member accounts for a Control Tower sandbox OU and a custom dev OU

John Ajera — Wed, 15 Apr 2026 19:06:36 +0000

Terraform member accounts for a Control Tower sandbox OU and a custom dev OU

If you already run a landing zone where the sandbox organizational unit (OU) exists under AWS Control Tower, you may still want additional member accounts created and updated with Infrastructure as Code instead of only the console. This guide walks through a small Terraform root module pattern: one account in the existing sandbox OU (by id) and one in a Terraform-managed Development OU, with remote state in S3. The real repository may add optional guards or integrations beyond Organizations account creation; this post focuses on that core path. Continuous delivery (for example GitHub Actions and OIDC) is left for a separate article.

1. Overview

Goal: Repeatable AWS Organizations member accounts for sandbox and development, tagged and placed under the right OUs.
Where it runs: The management account (or another principal with Organizations APIs and trust to create accounts).
State: Encrypted S3 backend with a lock compatible with modern Terraform S3 native state locking.
Credentials: Use whatever your team standardizes on for interactive or manual applies (for example an IAM role in the management account via SSO or assume role). The snippets below do not depend on a specific client tool beyond the Terraform CLI.

2. Prerequisites

An AWS Organization with permission to create accounts and OUs from the account where you run Terraform.
The organizational unit id for the sandbox OU where the first account should live (in a Control Tower setup this OU already exists; you copy its id from the console or CLI).
Two unique root user email addresses that are not already used as the root email of any AWS account (plus-addressing on a single mailbox is fine).
An S3 bucket for Terraform state (create it out of band or in another stack); the IAM principal you use for terraform apply needs read/write to that bucket and key (and any KMS key policy if you use SSE-KMS).
Terraform 1.5+ and the hashicorp/aws provider (5.x in the example below).

Useful background: AWS Organizations User Guide and the Terraform resources aws_organizations_account and aws_organizations_organizational_unit.

3. Architecture

Terraform runs in the management account (from your workstation or any runner with the right credentials). It reads the organization root, creates (or refreshes) a Development OU, creates two member accounts, and persists state in S3.

Flow (ASCII):

  Operator / runner                    Management account              AWS Organizations
  ----------------                     ------------------              -----------------

  Terraform CLI  ------------------>  Terraform run  ------------->  S3 (remote state)
  (plan / apply)                           |
                                           (Organizations API)
                                                |
                                                v
                                         Organization root
                                              |
                      +-----------------------+-----------------------+
                      |                                               |
                Sandbox OU                                     Development OU
              (already exists,                         (created by Terraform)
               e.g. Control Tower)
                      |                                               |
                      v                                               v
              Sandbox member account                         Dev member account

4. Terraform building blocks

4.1 Provider and versions

Pin Terraform and the AWS provider; set the region your team uses for the provider (Organizations APIs are global in behavior, but the provider still needs a region).

provider "aws" {
  region = var.region
}

terraform {
  required_version = ">= 1.5.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.98.0"
    }
  }
}

4.2 Data sources

Read the current account and the organization so you can anchor the root id for new OUs.

data "aws_caller_identity" "current" {}

data "aws_organizations_organization" "current" {}

4.3 Locals: sandbox OU id and tags

The sandbox account is placed under an OU that already exists (for example one created by Control Tower). That OU’s id is environment-specific; store it in locals (or a variable) instead of hard-coding in multiple resources.

locals {
  # Example: existing sandbox OU — replace with your OU id from Organizations or Control Tower.
  sandbox_ou_id = "ou-xxxx-xxxxxxxx"

  tags = {
    owner     = "example"
    service   = "core"
    terraform = "true"
  }
}

The Development OU, by contrast, is created by Terraform in the next subsection.

4.3.1 Reusing the Control Tower sandbox OU (tradeoffs)

There is no universal right answer; it is a tradeoff your team agrees on.

When reusing the existing sandbox OU tends to make sense:

Alignment with landing zone: Control Tower (or your design) already defined a sandbox OU for experimental workloads; putting Terraform-created members there keeps the same guardrails and enrollment model as other sandbox accounts.
Less OU sprawl: You avoid a parallel “sandbox” tree that confuses auditors or operators.
Speed: The OU already exists; Terraform only needs a stable id (locals.sandbox_ou_id), not another OU resource.

When a different OU might be a better fit:

Isolation: You want a dedicated OU for platform or CI-owned sandboxes so Service Catalog / Account Factory sandboxes stay separate from Terraform-vended ones.
Different SCPs: The Control Tower sandbox OU carries service control policies you do not want on these accounts; a separate OU can carry different SCPs.
Operational clarity: You prefer one automation path per OU so it is obvious how an account was created.

Neither choice is inherently wrong. The existing sandbox OU is a reasonable default for consistency and shared sandbox policy; another OU is equally valid when separation or policy needs differ. Document the choice in your runbook so future readers know why the id is what it is.

4.4 Development organizational unit

Create an OU under the organization root (first element of roots).

resource "aws_organizations_organizational_unit" "development" {
  name      = "Development"
  parent_id = data.aws_organizations_organization.current.roots[0].id

  tags = merge(local.tags, {
    Name = "Development"
  })
}

4.5 Member accounts

Each member account needs a unique root email, the standard OrganizationAccountAccessRole name (so administrators can assume into the account from the org), a parent OU, and tags. Ignore iam user access to billing if your org policy manages that outside Terraform.

Below, sandbox_1 uses local.sandbox_ou_id; dev_1 uses the Development OU resource id. The lifecycle block here is the minimal pattern for teaching; a production repo might add other lifecycle rules.

resource "aws_organizations_account" "sandbox_1" {
  name      = "example-sandbox-1"
  email     = var.sandbox_account_email
  role_name = "OrganizationAccountAccessRole"
  parent_id = local.sandbox_ou_id

  tags = merge(local.tags, {
    Name        = "example-sandbox-1"
    environment = "sandbox"
  })

  lifecycle {
    ignore_changes = [iam_user_access_to_billing]
  }
}

resource "aws_organizations_account" "dev_1" {
  name      = "example-dev-1"
  email     = var.dev_account_email
  role_name = "OrganizationAccountAccessRole"
  parent_id = aws_organizations_organizational_unit.development.id

  tags = merge(local.tags, {
    Name        = "example-dev-1"
    environment = "dev"
  })

  lifecycle {
    ignore_changes = [iam_user_access_to_billing]
  }
}

4.6 Remote state backend

Point the backend at your bucket, key, and region. use_lockfile enables S3-native locking in supported Terraform versions.

terraform {
  backend "s3" {
    bucket       = "your-tf-state-bucket"
    key          = "account-factory/terraform.tfstate"
    region       = "ap-southeast-2"
    encrypt      = true
    use_lockfile = true
  }
}

4.7 Variables and tfvars

At minimum, pass the two root emails. Optionally override region.

variable "region" {
  description = "AWS region for the provider."
  type        = string
  default     = "ap-southeast-2"
}

variable "sandbox_account_email" {
  description = "Root email address for the sandbox AWS account."
  type        = string
}

variable "dev_account_email" {
  description = "Root email address for the development AWS account."
  type        = string
}

Example terraform.tfvars (keep out of version control if it is sensitive):

sandbox_account_email = "you+sandbox@example.com"
dev_account_email     = "you+dev@example.com"
# region = "ap-southeast-2"

4.8 Outputs

Expose organization metadata, OU ids, and account ids and ARNs for downstream stacks or runbooks.

output "organization_id" {
  value = data.aws_organizations_organization.current.id
}

output "development_ou_id" {
  value = aws_organizations_organizational_unit.development.id
}

output "sandbox_account_id" {
  value = aws_organizations_account.sandbox_1.id
}

output "dev_account_id" {
  value = aws_organizations_account.dev_1.id
}

5. Summary: Copy-paste

From the module root, with credentials for the management account (for example AWS_PROFILE):

export AWS_PROFILE=YourManagementProfile
terraform init
terraform plan
terraform apply

Keep root emails stable; changing an account’s root email later is a manual process. Review terraform plan output before apply, and use your team’s normal change control for production organizations.

6. Troubleshooting

EmailAlreadyExists / account creation fails: The root email is already tied to another AWS account. Pick a new unique address (plus-addressing helps).
AccessDenied on Organizations: The caller is not in the management account or the principal lacks Organizations permissions for the operations in your plan.
S3 backend errors: Bucket name, key, region, or KMS policy mismatch; the principal needs list/get/put on the state prefix and lock object if used.
Wrong sandbox OU: The sandbox account lands in the wrong OU when local.sandbox_ou_id is incorrect; re-read it from Organizations or your landing zone console.

7. References

GitHub Webhook Secrets and the Terraform Public Registry

John Ajera — Tue, 14 Apr 2026 20:15:29 +0000

GitHub Webhook Secrets and the Terraform Public Registry

New semver tags in GitHub can fail to appear on registry.terraform.io when the Terraform Registry webhook’s Secret in GitHub no longer matches what the registry uses to verify deliveries. GitHub signs each delivery with that secret; the registry must validate the signature with the same value. This article states that model, what breaks when the two sides diverge, and how to recover using HashiCorp’s documented steps.

1. Overview

Model: GitHub computes an HMAC signature for webhook payloads (see Validating webhook deliveries). The registry endpoint must verify it using the same secret tied to your module’s integration.
Failure mode: Updating Secret only under GitHub → Settings → Webhooks changes what GitHub signs with. The registry does not read that field from your repo; it keeps the secret from the integration that created or last reconciled the hook. Signatures then fail and new versions do not publish.
Recovery: Keep a single webhook to https://registry.terraform.io/hooks/github, run Resync Module from the registry UI, then confirm deliveries: push a new semver tag or use GitHub’s Redeliver on a failed delivery for the tag push you still want published (same payload, signed again with the current secret). If publishing still fails, use registry support.

This guide is for the public Terraform Registry and public GitHub modules. Terraform Enterprise and other private registries use different hosts and procedures.

2. Prerequisites

Module already published on the Terraform Registry from a public GitHub repository
Permission to use Manage Module on the module page and to edit Webhooks on the GitHub repository (Settings → Webhooks)
A semver tag to test with (push a new one, or reuse an existing tag whose registry publish failed and still needs to succeed), per module publishing

3. What not to do

Do not paste a new random value into the webhook Secret in GitHub alone, expecting the public registry to pick it up. There is no documented self-serve screen on the registry where you paste the same value to pair it. Unilateral edits in GitHub desynchronize signing and verification.

If you already did that, treat the next sections as recovery, not prevention.

4. Recovery: one webhook, then Resync

Per the Terraform registry FAQ, Resync for a module makes the registry ensure the repository has a webhook for automatic publishing and reconciles version gaps. The FAQ also recommends fixing webhook problems before relying on resync alone.

Open Settings → Webhooks on the GitHub repository.
Leave exactly one active webhook whose payload URL is https://registry.terraform.io/hooks/github. If several point there, delete the extras (the FAQ calls out duplicate hooks as a cause of publishing issues).
On registry.terraform.io, open the module → Manage Module → Resync Module. Wait for completion; avoid starting overlapping resyncs.
Confirm the hook: Open the webhook → Recent Deliveries on GitHub.
- Push a new semver tag and check that the new delivery succeeds (typically HTTP 200), then confirm the version on the module page, or
- Redeliver a failed delivery whose payload is still the tag push for the semver version you want. GitHub sends the same event body again; signatures use the webhook Secret as it is after your fixes, so this can publish that version without another tag. Use the delivery row that matches the correct tag ref.

Redeliver instead of a new tag

Yes — that is an acceptable approach when the semver tag already exists and the only problem was the webhook (for example signature failure after a bad secret edit). Redeliver is a normal GitHub feature for retrying a delivery; you are replaying the same push event the registry would have seen on a successful first attempt, not inventing a new release artifact in Git.

Prefer a new tag when you need a new module version anyway, when there is no failed delivery to replay (nothing reached GitHub’s hook list), or when you want a straight-line test from “tag push” to “delivery” without hunting history.

Prefer redeliver when bumping the version number would be artificial (the tag is already the release you mean) and you only need the registry to accept the same event again after fixing the hook.

If a single hook and resync do not restore publishing, contact registry support.

5. Configuration checks

Use these when deliveries succeed but versions still look wrong, or as routine verification:

Payload URL: https://registry.terraform.io/hooks/github (HTTPS, that host, that path).
Tags: Semantic version identifiers only, optional leading v. Other ref names do not create registry versions.
Events: The hook must receive events for the activity that publishes versions (for example push events that include tag pushes). Overly narrow event filters can skip the tag you care about.

6. Summary: Copy-Paste

Push a new version tag when you prefer a fresh event (adjust remote and tag):

git tag v1.0.1
git push origin v1.0.1

Open repository webhooks (replace OWNER and REPO):

https://github.com/OWNER/REPO/settings/hooks

After opening the Terraform Registry webhook there, use Recent Deliveries → a failed row → Redeliver when you have already fixed the hook and want to retry the same tag event without pushing another tag.

7. Troubleshooting

Symptom	Likely cause	What to try
No new registry version after a tag push	Missing or failing webhook, duplicate hooks, or signature failure after a secret-only GitHub edit	One hook to `registry.terraform.io/hooks/github`, Resync Module, then push a new semver tag or Redeliver the failed delivery for that tag; re-check Recent Deliveries and the module page
Recent Deliveries show errors after changing Secret in GitHub	GitHub and registry no longer share the same secret	Dedupe hooks, Resync Module; if still failing, registry support
Delivery succeeds but no version	Invalid tag shape or delay	Fix tag to semver; wait; Resync if needed
Multiple registry webhooks	Stale or conflicting registrations	Delete duplicates, Resync per FAQ

8. References

Publish modules — naming, tags, Resync Module
Terraform registry FAQ — Resync, duplicate webhooks, versions not appearing
Validating webhook deliveries — GitHub signatures and the webhook secret
Redeliver a delivery for a repository webhook — API equivalent of the Redeliver control in the delivery UI

AWS IAM Identity Center: Custom Access Portal URL

John Ajera — Tue, 14 Apr 2026 12:11:29 +0000

AWS IAM Identity Center: Custom Access Portal URL

After you enable IAM Identity Center, the default AWS access portal URL uses an opaque subdomain under awsapps.com. You can replace that prefix once with a custom access portal URL so sign-in links are easier to recognize and communicate. This guide walks through what that means, how to set it in the console, and what to verify afterward.

1. Overview

This article covers how to:

Understand the difference between the default and custom access portal URL (https://…awsapps.com/start)
Customize the subdomain once from the IAM Identity Center console (no separate AWS charge for this step)
Confirm sign-in still works and refresh bookmarks, runbooks, and onboarding docs that referenced the old URL

It does not cover bringing your own DNS name (for example sso.example.com); the portal stays on *.awsapps.com.

2. Prerequisites

Management account (or delegated admin where your org’s Identity Center instance lives) with permission to change Identity Center settings
IAM Identity Center enabled for the organization
Console access in the Identity Center Region (the region shown as primary for your instance; for example ap-southeast-2)
A stable subdomain label you are willing to keep: AWS documents that you cannot edit the access portal URL after you customize it

3. What changes when you customize the URL

Default vs custom

By default, the portal looks like:

https://xxxxxxxxxx.awsapps.com/start

After customization it becomes:

https://your-subdomain.awsapps.com/start

Only the first label (the part before .awsapps.com) changes. The path /start and the fact that traffic uses HTTPS to awsapps.com stay the same.

One-time operation

AWS states clearly: if you change the AWS access portal URL, you cannot edit it later. If the Customize control does not appear under the portal URL in the dashboard, the URL has already been customized. Treat the choice like a permanent hostname for your organization.

Not the same as “Instance name”

The Instance name in Settings summary is a console-friendly label. The access portal URL is what users type or bookmark. You can set both; they serve different purposes.

4. Customize the access portal URL (console)

Open the IAM Identity Center console.
Select the Region where your Identity Center instance is registered if the console prompts you (must match your instance’s primary region).
In the navigation pane, open Dashboard.
In Settings summary, find the AWS access portal URL and choose Customize (only shown if customization is still available).
Enter your desired subdomain and save.

When the operation completes, use the new URL to open the access portal and confirm the sign-in page loads.

5. After you save

Tell your users the new portal URL and ask them to update bookmarks.
Update internal documentation, wiki pages, and new-hire instructions that still point at the old hostname.
If you use CLI or IDE profiles that reference the portal URL (for example AWS CLI aws configure sso / sso_start_url), align those configs with the new URL on each machine.
If anything in your IdP or application configuration hard-coded the old portal URL, plan a coordinated update (uncommon for the bare portal hostname, but easy to miss in custom integrations).

6. Summary: Copy-Paste

Customizing the subdomain is a console workflow; there is no documented AWS CLI parameter to set the access portal hostname after the fact. You can still list your instance from the CLI (replace the region with your Identity Center region):

aws sso-admin list-instances --region ap-southeast-2

Example sign-in URL pattern after customization (replace your-subdomain):

https://your-subdomain.awsapps.com/start

7. Troubleshooting

Issue	What to try
Customize does not appear	The portal URL may already be customized. AWS does not offer a console option to change it again.
Console shows the wrong account or empty Identity Center	Use the organization management account (or the account where the instance was created) and the correct region.
Users see errors after the change	Confirm they use the new `https://…awsapps.com/start` URL, clear old bookmarks, and refresh SSO/CLI `sso_start_url` values.

8. References

Customizing the AWS access portal URL (IAM Identity Center User Guide)
Setting up and using the AWS access portal
IAM Identity Center pricing

Configuring AWS Business Support+

John Ajera — Mon, 13 Apr 2026 23:21:19 +0000

Configuring AWS Business Support+

AWS Business Support+ is AWS’s paid support tier that combines 24/7 expert access, AI-assisted troubleshooting, Trusted Advisor and health-oriented guidance, and targeted initial response commitments for business-critical issues (see official plan page for current feature wording and pricing). This guide focuses on how to turn it on and who can do it: console enrollment, organization-wide versus single-account subscription, IAM for the Support Plans console, and Organizations SCP pitfalls when regions are restricted.

1. Overview

Open the AWS Support Plans console and upgrade from Basic to Business Support+
Choose organization-wide (management account, Organizations all features) or account-only enrollment
Grant IAM access to change plans (supportplans:* or AWS managed policies) and fix SCP denies if Support Plans fails in member accounts
Know how to downgrade (console path) and where to compare pricing before you confirm

2. Prerequisites

Root user or an IAM principal allowed to change support plans (see Manage access to AWS Support Plans)
For organization-level Business Support+: the account must be the Organizations management account, with all features enabled for the organization
Billing in good standing; paid support has a minimum one-month commitment (Support FAQs)

3. Subscribe from the Support Plans console

Open the console

Optional but recommended before you subscribe:

Choose Compare all Support plans and features to line up Business Support+ against other tiers
Use Pricing calculator (in the console) to estimate support charges from expected monthly AWS usage

Upgrade from Basic to Business Support+

Steps follow Changing AWS Support plans:

In the AWS Business Support+ section, choose Get started
Choose scope:
- My organization — only if you use AWS Organizations with all-feature mode; only the management account can enroll the whole org. New accounts created in the org are automatically on Business Support+. In the console, My organization is disabled when it does not apply (for example, you are signed in to a member account, Organizations is not in use, or all features are not enabled for the organization)
- My account — subscribe this account only
Review plan details and pricing (AWS Support pricing)
Accept the subscription terms (checkbox)
Choose Confirm upgrade

After enrollment: confirm the tier in AWS Support Center (the console shows your current plan) and verify you can open a support case with the severity options you expect.

4. IAM: who may view or change the plan

Users need supportplans API permissions. Common actions (docs):

supportplans:GetSupportPlan — view current plan
supportplans:StartSupportPlanUpdate — start an upgrade or downgrade request
supportplans:GetSupportPlanUpdateStatus — poll update status

AWS managed policies (names may evolve; confirm in IAM):

AWSSupportPlansFullAccess — change plans
AWSSupportPlansReadOnlyAccess — view only

Example read-only custom policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "supportplans:Get*",
        "supportplans:List*"
      ],
      "Resource": "*"
    }
  ]
}

Example full access (delegate carefully):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "supportplans:*",
      "Resource": "*"
    }
  ]
}

5. Organizations: SCPs and global services

If member accounts see errors even with correct IAM, an SCP that denies by Region can block Support Plans because it is a global console/API.

Per Manage access to AWS Support Plans, add supportplans:* to the NotAction list on any broad Region-deny SCP (exact structure depends on your org’s policy layout). If you use AWS Control Tower Region deny controls, read AWS guidance on drift before hand-editing SCPs, because repairs can revert custom exceptions.

6. Downgrades and higher tiers

Downgrade from Business Support+: on Manage Support Plans, use Review downgrade in the Basic Support section (Changing AWS Support plans)
Enterprise Support or Unified Operations: use Contact sales in the console; Enterprise downgrades go through your TAM
Account leaves the org after org-level Business Support+: AWS documents that the account drops to Basic support

7. Optional follow-on configuration

These are not strictly “subscription” steps but are how teams use paid support day to day:

AWS Support App in Slack — create and update cases from Slack
AWS Support API — automate case operations (separate IAM/service permissions)
Trusted Advisor and AWS Health — visible in console once the plan includes them; use Trusted Advisor and AWS Health docs for check types and alerts

Promotional trial or pricing offers change over time; use the Business Support+ plan page and in-console offer links for current eligibility and refund rules.

8. Summary: Copy-Paste

Console entry points (sign in first):

https://console.aws.amazon.com/support/plans/home
https://console.aws.amazon.com/support/home

IAM: attach AWSSupportPlansFullAccess to a named role used only for billing/support changes, or merge the JSON examples in section 4 into your least-privilege model.

Organizations: if Region-deny SCPs exist, ensure supportplans:* is excluded from the deny per AWS documentation.

9. Troubleshooting

Access Denied on Support Plans: Attach AWSSupportPlansFullAccess (or equivalent supportplans:*) to the role or user; confirm you are not using a member account when only the management account may enroll the org.

Member account cannot open the page: Check SCP Region denies and add supportplans:* to NotAction as documented; verify Control Tower drift if that platform manages SCPs.

Wrong scope after the fact: Org-wide subscription is a management-account decision; single-account subscription does not extend to siblings. Adjust scope only by following AWS change plan / downgrade flows and org enrollment rules.

Charges surprise you: Revisit the console Pricing calculator and Support pricing; support fees are separate from service usage on the bill.

10. References

Greenfield EKS: Choosing Standard EKS vs EKS Auto Mode Without Legacy Baggage

John Ajera — Tue, 07 Apr 2026 23:35:59 +0000

Greenfield EKS: Choosing Standard EKS vs EKS Auto Mode Without Legacy Baggage

If you are standing up your first Amazon EKS cluster and you are not dragging along years of Terraform modules, custom AMIs, or a mandated node strategy from another team, the choice between Standard EKS (you own how nodes are provisioned and wired) and EKS Auto Mode (AWS runs more of that for you) is mostly about defaults: speed and delegated operations versus transparency and fine-grained control. This article is a practical decision guide for that greenfield scenario—what differs, how to think about cost and maintenance, and how to separate the EKS operating model from optional add-ons you install on top.

Source: What is Amazon EKS? (AWS Documentation).

1. Overview

This guide helps you decide, for a new cluster with no legacy constraints:

What Standard EKS and EKS Auto Mode each optimize for in the first weeks and months
How to compare cost at a high level (control plane, compute, Auto Mode management fees, and people time)
Who runs what (nodes, scaling, ingress/LB), including an AWS-documented checklist of what Auto Mode manages as built-in infrastructure
A short rubric for “default to Auto Mode” versus “start explicit with managed node groups”

2. Prerequisites

Familiarity with containers and the idea of a Kubernetes control plane versus worker nodes
Access to current Amazon EKS pricing and EKS Auto Mode documentation for numbers and feature details that change over time
No assumption that you already run Karpenter, managed node groups, or a corporate standard—this article assumes greenfield

3. Name the two starting paths

Same managed control plane; who owns the node story is what splits the paths.

Side-by-side

	Standard EKS	EKS Auto Mode
You choose	How nodes are created and scaled: managed node groups, self-managed nodes, or later Karpenter	Less DIY wiring; AWS runs more of lifecycle + integration (docs)
Mental model	“These are my instances / ASGs, my scaling and upgrade path”	“AWS-shaped automation; fewer knobs, less assembly”
APIs you will see (examples)	EC2, MNG, launch templates, plus whatever provisioner you pick	Platform-oriented CRDs such as `NodePool` / `NodeClaim`, `NodeClass`, `CNINode`, LB-related types—exact set varies by version

Standard EKS — responsibility flow

+-------------------------------+
| AWS: Kubernetes API           |  (managed control plane)
+-------------------------------+
              |
              v
+-------------------------------+
| You: pick node strategy       |
| MNG / self-managed / Karpenter|
+-------------------------------+
              |
              v
+-------------------------------+
| Workloads / Pods              |
+-------------------------------+

EKS Auto Mode — responsibility flow

+-------------------------------+
| AWS: Kubernetes API           |  (managed control plane)
+-------------------------------+
              |
              v
+-------------------------------+
| AWS: node lifecycle +         |
| integrations (opinionated)    |
+-------------------------------+
              |
              v
+-------------------------------+
| Workloads / Pods              |
+-------------------------------+

Same for both: observability, backups, secrets, RBAC, network policy, ingress, and mesh are still yours. Picking a mode ≠ production-ready.

4. Cost at a glance

Pricing moves; always verify against the Amazon EKS pricing page. The figures below use US West (Oregon) On-Demand rates at the time of writing and a small greenfield scenario: one cluster, three worker nodes (m5a.xlarge).

Estimated monthly AWS bill

Line item	Rate	Standard EKS	Auto Mode
Control plane	$0.10 / cluster / hr	~$73	~$73
EC2 instances (3 x `m5a.xlarge`)	$0.172 / instance / hr	~$377	~$377
Auto Mode management	$0.02064 / instance / hr	--	~$45
AWS invoice total		~$450	~$495

Source for *$0.02064 / hr** (Auto Mode) and $0.172 / hr (EC2) for m5a.xlarge: AWS Example 4: EKS Auto Mode on Amazon EKS pricing (US West Oregon, On-Demand). Auto Mode fees are per instance type; use that page or the AWS Pricing Calculator for EKS for other shapes.*

Auto Mode adds roughly 10-12% to the AWS bill in this scenario. The management fee is billed per-second (one-minute minimum) and applies regardless of EC2 purchase option (On-Demand, Reserved, Savings Plan, or Spot).

Watch out for extended support. If you let a Kubernetes version drift past standard support (14 months), the cluster fee jumps to $0.60 / hr (~$438 / month). Plan upgrades regardless of mode.

What the invoice does not show

Hidden cost	Standard EKS	Auto Mode
Engineer time building node automation, LB controller Helm charts, upgrade runbooks	Higher -- you build and maintain the glue	Lower -- AWS ships more of that glue
Incident cost when nodes misbehave, AMIs drift, or scaling stalls	Yours to debug end-to-end	Shared with AWS; fewer levers but also fewer moving parts you wrote
Idle capacity from over-provisioned groups or generous defaults	Risk if you set scaling bounds loosely	Risk if Auto Mode defaults are generous for your workload

Bottom line: the ~$45 / month management fee in this example is roughly one hour of a platform engineer's loaded cost. If Auto Mode saves more than that in reduced toil per month, it pays for itself. If your team already has solid automation and rarely touches nodes, Standard keeps the invoice leaner.

5. Who runs what—and what the first year feels like

The choice shows up in division of labor: who keeps nodes, scaling, and traffic into the cluster healthy. That is what fills your calendar in months six through twelve—upgrade planning and Helm charts on one side, AWS platform changes and support cases on the other—not an abstract “mode” badge.

Where the work lands

Area	Standard EKS (typical greenfield)	EKS Auto Mode
Nodes and scaling	You pick the mechanism—managed node groups, self-managed nodes, or Karpenter—and you own upgrades, behavior, and capacity tuning	AWS delivers a more integrated node and scaling experience; you align with Kubernetes objects and practices AWS documents for Auto Mode instead of assembling the same stack yourself (Auto Mode)
Ingress and load balancers	Teams usually install and operate something like AWS Load Balancer Controller—chart upgrades, compatibility with new cluster versions, incidents when labels or annotations drift	More of that integration is AWS-operated for Auto Mode, so you typically spend less time babysitting that slice—still read AWS release notes when the platform changes

Standard EKS in practice

Clarity and skill-building: Obvious ownership (“we chose MNG / Karpenter / …”), strong learning for engineers who will live in AWS and Kubernetes, and a concrete story when auditors ask what creates instances.
Recurring toil: Upgrade choreography across the control plane version, node AMIs, and add-on compatibility; deliberate choices for scaling bounds and instance families; ongoing ownership of ingress/LB tooling unless you outsource it elsewhere.

EKS Auto Mode in practice

Less assembly, faster baseline: Shorter path to a working data plane, fewer Terraform or CloudFormation resources tied to node plumbing, and less day-to-day ownership of the LB integration layer described above.
Tradeoff: Fewer levers when behavior surprises you; success depends on solid observability (logs, metrics, tracing) and comfort escalating or adapting when AWS-owned behavior changes.

What Auto Mode treats as managed infrastructure (AWS checklist)

AWS describes these as built-in cluster capabilities, not as separate EKS console add-ons you install and version yourself. This is the high-level list from Automate cluster infrastructure with EKS Auto Mode and the Automated components section there—use the docs for the latest detail and limits.

Compute and nodes

Data-plane EC2 instances (Bottlerocket-based variants): AMI selection, locked-down OS (SELinux enforcing, read-only root), no direct SSH or SSM to nodes
Security and lifecycle: patching and upgrades with minimal disruption; maximum node lifetime (default up to 21 days) so nodes are replaced regularly
Accelerated workloads: GPU-related kernel drivers and plugins (for example NVIDIA and AWS Neuron)
Spot: handling of Spot interruption notices and EC2 instance health signals

Scaling

Karpenter-style autoscaling: reacts to unschedulable Pods, adds capacity, and removes or consolidates nodes when demand drops

Load balancing

Elastic Load Balancing tied to Kubernetes Service and Ingress objects: provisions and manages ALB and NLB resources and scales them with cluster demand

Networking

Pod and Service networking, including IPv4/IPv6 and use of secondary CIDRs where needed for Pod IP space
Network policy enforcement for Pods
Cluster DNS (local DNS for the cluster)

Storage

EBS CSI-class block storage as a managed capability
Ephemeral storage defaults on nodes (volume type, size, encryption, and cleanup behavior on termination—per AWS documentation)

Identity

EKS Pod Identity: you do not install the EKS Pod Identity Agent yourself on Auto Mode clusters (AWS documents that it is not required in this model)

Neither mode delivers “production in a box.” Metrics, secret rotation, mesh, policy engines, backups, and business-specific operators remain your software lifecycle unless you adopt separate managed services.

Avoid the “busy cluster” trap. A Standard environment can look heavier because it has more add-ons (monitoring, GitOps, security tools). That says what you installed, not that Standard is inherently more capable than Auto Mode. Judge the choice on who operates nodes and built-in integrations, not on how crowded the UI feels.

6. Decision rubric (greenfield, no baggage)

Lean toward EKS Auto Mode when:

The team is small and the priority is shipping a standard container platform quickly
Workloads are typical Linux containers without exotic kernel, sysctl, or custom AMI requirements today
You are comfortable adopting AWS-shaped APIs for nodes and integrations for the next phase of growth
You prefer fewer moving parts you must patch and tune in the first year

Lean toward Standard EKS (often with managed node groups first) when:

You want maximum transparency into every layer for training, compliance groundwork, or multi-cloud discipline
You already know you need specific instance families, purchase options, or strict cost caps encoded explicitly from day one
You expect to standardize on an in-house or community node provisioning story (for example Karpenter you fully control) and want to learn that model without an additional management layer

Default suggestion for a true greenfield product team: if your main risk is slow delivery and operational overload, EKS Auto Mode is often the better starting default; if your main risk is understanding and owning every dependency for regulatory or career reasons, Standard EKS with managed node groups is a clean teaching path. You can revisit the choice after the team has real production traffic and metrics.

7. Troubleshooting: common misconceptions

“Auto Mode is more Kubernetes.” It is more AWS-managed automation exposed through Kubernetes APIs, not a superset of every optional addon.
“Standard is cheaper.” Invoice lines can be lower; total cost may not be once you count engineering time and incidents for a small team.
“We picked a mode, so we are secure and observable.” RBAC, network policy, secrets, auditing, and monitoring are still your design choices.
“Our Standard cluster has more moving parts, so it must be better.” Often that is more optional software you added—not proof that Standard beats Auto Mode; see section 5.

8. References

What is Amazon EKS?
Amazon EKS pricing (see Example 4: EKS Auto Mode for per-instance-type Auto Mode fees used in section 4)
EKS Auto Mode
Learn how EKS Auto Mode works (deeper component topics)
Amazon EKS best practices
Managed node groups
Karpenter

Argo CD and AWS CodeConnections: The Upside, the Redeploy Pain, and How I Fixed It

John Ajera — Sat, 28 Mar 2026 10:46:16 +0000

Argo CD and AWS CodeConnections: The Upside, the Redeploy Pain, and How I Fixed It

I run Argo CD on Amazon EKS using the managed Argo CD capability and AWS CodeConnections for Git. CodeConnections has been a clear win for day-to-day operations. Then I had to recreate the connection (new resource, new identity in the URL). Every Application went to Sync: Unknown until I updated URLs in two places—Git and the live cluster—and fixed ApplicationSets so they stopped writing the old URL back. This article leads with why I still choose CodeConnections, then what breaks on redeploy, then what I did when it inevitably happened, in that order.

1. Why CodeConnections is worth it for Argo CD on EKS

No SSH keys or personal tokens in the cluster. Argo pulls Git using IAM: the capability role is allowed to use the connection (UseConnection, GetConnection). You are not copying PATs into Secrets or rotating leaked keys because someone printed kubectl get secret.

One connection, many repos. The HTTPS URL includes your account, region, a connection UUID, and then owner/repo. Same connection, different path segment for each repository. Setup details and Terraform patterns are in Argo CD on EKS: Git repo access with AWS CodeConnections and Terraform.

Fits how enterprises already govern access. Connections are AWS resources; approval and auditing live next to the rest of your cloud controls.

That does not mean zero tradeoffs. Managed Argo CD often applies one Git credential broadly (for example every github.com fetch through Kustomize can inherit it). If that bites you, vendoring or URL strategy fixes it—see Why Your Kustomize Remote Bases Break on Managed Argo CD (and How to Fix It). The tradeoff this article focuses on is different: replacing the connection.

2. What actually hurts when you update or redeploy the connection

The Git URL Argo uses is not abstract. It embeds a connection UUID in the path. A new connection is a new UUID. Anything that still points at the old path keeps asking AWS to authorize the wrong resource, so repo fetch fails and sync never reconciles.

Pain point one — Git only is not enough. Your GitOps repo is the source of truth, but Kubernetes already has Application and ApplicationSet objects applied yesterday. Their spec.source.repoURL (and generator URLs on sets) stay on the old string until something updates them. Pushing Git does not retroactively patch those CRs.

Pain point two — ApplicationSets fight you. Many sets declare repoURL twice: on the git generator and again on the template. If you patch child Applications but leave the set on the old URL, the controller reconciles and puts the old URL back on the apps.

Pain point three — Terraform layout. If CodeConnections and the EKS cluster share one tangled module and state, recreating the connection can feel like you are planning half the platform when you only wanted a new Git pipe. I now prefer the connection (and its IAM attachment) in something standalone, with outputs the cluster stack consumes—so the next rotation is a smaller blast radius.

What this is not. If Argo shows forbidden listing some API group (for example heavy CRD surfaces from controllers like ACK), that is usually cluster RBAC / EKS access policies for the Argo identity, not the CodeConnections URL. Fix that on its own; do not confuse it with a UUID swap.

Do not mass-delete Applications to “fix” a bad URL. Workloads may still be fine; you risk prune tearing down real resources. Fix the URLs.

3. Prerequisites

kubectl against the cluster, with permission to read and patch applications and applicationsets in the Argo CD namespace (below I use argocd, the usual default)
Rights to commit and push every Git repo that hardcodes the CodeConnections URL
The new clone URL or at least the new UUID from the AWS Console or Terraform output

4. If it happens to you: what worked for me

These steps assume you already know the old and new connection UUID (search your shell history, Terraform state, or an old Application YAML). The host pattern is documented in the CodeConnections and EKS guides linked at the end.

Step A — Fix Git first, everywhere

Search across all repos that participate in GitOps—not only the “main” infra repo:

rg 'codeconnections\.' --glob '*.yaml' --glob '*.yml' --glob '*.tf' --glob '*.md'

Update bootstrap Application manifests, every ApplicationSet generator and template repoURL, any child Application checked in with a literal URL, and docs or scripts that build repository secrets. Commit and push.

Step B — Patch Applications in the cluster

Still in a broken state, the cluster cannot always sync from Git, so you patch live objects once. Set shell variables to your real values (namespace if not argocd, old UUID, new UUID):

NS=argocd
OLD_UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee
NEW_UUID=ffffffff-eeee-dddd-cccc-bbbbbbbbbbbb

List apps whose single spec.source.repoURL still contains the old UUID:

kubectl get applications -n "$NS" -o json | jq -r --arg u "$OLD_UUID" \
  '.items[] | select(.spec.source.repoURL // "" | contains($u)) | .metadata.name'

For each name, the safest approach is to take the existing URL from the object and swap the UUID in the shell, then merge-patch:

app=my-app
oldurl=$(kubectl get application "$app" -n "$NS" -o jsonpath='{.spec.source.repoURL}')
newurl="${oldurl//$OLD_UUID/$NEW_UUID}"
kubectl patch application "$app" -n "$NS" --type merge -p "{\"spec\":{\"source\":{\"repoURL\":\"$newurl\"}}}"

If you use spec.sources (multi-source), repeat the idea per entry that points at CodeConnections.

Step C — Patch ApplicationSets (do not skip this)

Confirm the old UUID still appears on spec (ignore status for a moment):

kubectl get applicationsets -n "$NS" -o yaml | rg "$OLD_UUID"

To replace the UUID everywhere under each set’s JSON (review before you run this in production—I exported one set first and eyeballed it):

for name in $(kubectl get applicationsets -n "$NS" -o json | jq -r --arg u "$OLD_UUID" \
  '.items[] | select(.. | strings? | contains($u)) | .metadata.name' | sort -u); do
  kubectl get applicationset "$name" -n "$NS" -o json | \
    jq --arg o "$OLD_UUID" --arg n "$NEW_UUID" \
    'del(.status) | walk(if type == "string" then gsub($o; $n) else . end)' | \
    kubectl replace -f -
done

The walk replaces every occurrence of the old UUID string in that JSON. Pick a UUID substring unique to the connection so you do not hit unrelated fields.

Step D — Refresh and converge

Hard refresh apps in the UI or CLI, then let GitOps catch up. If Git still cannot be fetched until one app is fixed, patch your bootstrap Application (the one that applies the rest of the tree) to the new URL first, then repeat the rest—classic chicken-and-egg.

5. Troubleshooting

Application stuck deleting

kubectl patch application my-app -n argocd -p '{"metadata":{"finalizers":null}}' --type=merge

I deleted an app and it came back

An ApplicationSet owns it (ownerReferences). Fix the set and Git; deleting the app alone will not stick.

6. References

Host a Static Site on EC2 with Terraform (VPC, Optional ALB)

John Ajera — Sat, 28 Mar 2026 08:54:20 +0000

Host a Static Site on EC2 with Terraform (VPC, Optional ALB, Session Manager)

For static sites, S3 + CloudFront is usually the better default. This post points at a small Terraform demo and pulls a few excerpts from main.tf, variables.tf, iam.tf, and user_data.tftpl. Full layout: tf-aws-ec2-static-demo (local path ~/workspace/jdevto/tf-aws-ec2-static-demo if you keep it beside this blog repo). S3 + CloudFront with Terraform: art0018.

Overview

The demo provisions a VPC, nginx on Amazon Linux 2023, index.html (AZ + private IP from IMDSv2), and robots.txt. use_alb=false (default): one instance in one public subnet; clients hit :80 on the instance public IP (CIDR from allowed_http_cidr). use_alb=true: internet ALB across az_count ≥ 2 public subnets; az_count instances in private subnets (one per AZ), NAT for egress, no instance public IP; instances register to one target group with HTTP / health check expecting 200; instance SG allows :80 from the ALB SG and from the VPC CIDR. enable_ssm=true (default): Session Manager with AmazonSSMManagedInstanceCore—no SSH in the template.

locals {
  subnet_count   = var.use_alb ? var.az_count : 1
  instance_count = var.use_alb ? var.az_count : 1
}

variable "az_count" {
  default = 3
  # ...
  validation {
    condition     = var.az_count >= 1 && var.az_count <= 6 && (!var.use_alb || var.az_count >= 2)
    error_message = "az_count must be between 1 and 6, and at least 2 when use_alb is true (ALB requirement)."
  }
}

Why EC2?

Learning stack (Terraform + VPC + optional ELB), policy that prefers VPC-hosted sites, temporary lift-and-shift, or a box that might grow non-static behavior later. None of that makes EC2 the default for a pure static site.

VPC

Every instance is in a VPC and a subnet (EC2-Classic is gone for new accounts). The demo creates its own VPC—public subnets always; private subnets + NAT when use_alb=true.

Architecture

use_alb = false
  +----------+   :80 (public IP)   +----------------+
  | Clients  | ------------------> | EC2 (nginx)    |
  +----------+                     +----------------+

use_alb = true
  +----------+   :80   +-----+   :80   +----------------+
  | Clients  | ------> | ALB | ------> | EC2 × az_count |
  +----------+         +-----+         | (private)      |
                                      +----------------+

NAT is billed when the ALB path is on. Repeated curl to the ALB can show different AZ / private IP in index.html as backends rotate. user_data fills those fields via IMDSv2 after nginx is up:

IMDS_TOKEN=$(curl -sS -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
PRIVATE_IP=$(curl -sS -H "X-aws-ec2-metadata-token: $IMDS_TOKEN" \
  "http://169.254.169.254/latest/meta-data/local-ipv4")
AZ=$(curl -sS -H "X-aws-ec2-metadata-token: $IMDS_TOKEN" \
  "http://169.254.169.254/latest/meta-data/placement/availability-zone")

main.tf — placement and bootstrap:

resource "aws_instance" "web" {
  count = local.instance_count

  subnet_id              = var.use_alb ? aws_subnet.private[count.index].id : aws_subnet.public[0].id
  vpc_security_group_ids = [aws_security_group.instance.id]
  user_data              = templatefile("${path.module}/user_data.tftpl", { enable_ssm = var.enable_ssm })
  user_data_replace_on_change = true
  iam_instance_profile   = var.enable_ssm ? aws_iam_instance_profile.ssm[0].name : null
  # ...
}

main.tf — instance ingress (ALB on) and target group health check:

dynamic "ingress" {
  for_each = var.use_alb ? [1] : []
  content {
    description     = "HTTP from ALB security group (forwarded client traffic)"
    from_port       = 80
    to_port         = 80
    protocol        = "tcp"
    security_groups = [aws_security_group.alb[0].id]
  }
}

dynamic "ingress" {
  for_each = var.use_alb ? [1] : []
  content {
    description = "HTTP from VPC for ALB health checks and internal probes"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = [aws_vpc.main.cidr_block]
  }
}

resource "aws_lb_target_group" "web" {
  count = var.use_alb ? 1 : 0

  port             = 80
  protocol         = "HTTP"
  protocol_version = "HTTP1"
  # ...

  health_check {
    enabled             = true
    protocol            = "HTTP"
    port                = "traffic-port"
    path                = "/"
    matcher             = "200"
    interval            = 15
    timeout             = 10
    healthy_threshold   = 2
    unhealthy_threshold = 3
  }
}

Session Manager

Agent + AmazonSSMManagedInstanceCore; user_data.tftpl via templatefile so #!/bin/bash is at column 0 (indented heredoc in Terraform often breaks the shebang). With enable_ssm, the template pulls the SSM Agent RPM from S3 and starts the service. Use the AMI’s curl—do not dnf install curl on AL2023 (conflicts with curl-minimal, set -e aborts before nginx). Egress: NAT or SSM VPC endpoints. Docs: agent install, status. Your principal needs ssm:StartSession; Session Manager plugin for CLI. After apply, wait for Online in Fleet Manager; with use_alb=true, use instance_ids or ssm_start_session_command (first instance). %{ if enable_ssm ~} … %{ endif ~} wraps the SSM block in the template.

iam.tf:

resource "aws_iam_role_policy_attachment" "ssm_core" {
  count      = var.enable_ssm ? 1 : 0
  role       = aws_iam_role.ssm[0].name
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}

user_data.tftpl (SSM path):

#!/bin/bash
# Column-0 shebang required: indented Terraform heredocs break #!/bin/bash and cloud-init may skip the script.
set -eux
# Do not `dnf install curl` here: AL2023 ships curl-minimal; installing full curl conflicts and aborts the whole script under set -e.
SSM_RPM=""
case "$(uname -m)" in
  x86_64) SSM_RPM="https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm" ;;
  aarch64) SSM_RPM="https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_arm64/amazon-ssm-agent.rpm" ;;
  *) echo "Unsupported arch for SSM agent RPM"; exit 1 ;;
esac
curl -sS -o /tmp/amazon-ssm-agent.rpm "$SSM_RPM"
dnf install -y /tmp/amazon-ssm-agent.rpm
rm -f /tmp/amazon-ssm-agent.rpm
systemctl enable amazon-ssm-agent
systemctl restart amazon-ssm-agent

robots.txt

Crawler hint file—not security. The demo writes:

User-agent: *
Allow: /

user_data.tftpl:

cat >/usr/share/nginx/html/robots.txt <<'ROBOTS'
User-agent: *
Allow: /
ROBOTS

Google: robots.txt.

Run it

git clone https://github.com/jdevto/tf-aws-ec2-static-demo.git
cd tf-aws-ec2-static-demo
terraform init && terraform apply

ALB (needs ≥2 AZs; default az_count is 3):

terraform apply -var="use_alb=true"
# terraform apply -var="use_alb=true" -var="az_count=2"

Wait 1–2 minutes after first boot for user_data. user_data_replace_on_change = true replaces instances when the template changes. Variables: repo README.

variable "use_alb" {
  type    = bool
  default = false
}

variable "allowed_http_cidr" {
  type    = string
  default = "0.0.0.0/0"
}

variable "enable_ssm" {
  type    = bool
  default = true
}

terraform output verify_commands
# use_alb=false:
curl -sS "http://$(terraform output -raw instance_public_ip)/robots.txt"
# use_alb=true (no instance public IP):
# curl -sS "$(terraform output -raw website_url_alb)/robots.txt"
terraform output -raw ssm_start_session_command

Troubleshooting

Issue	Check
Timeout / connection refused	`use_alb=true`: use ALB URL, not instance IP. `false`: SG, `allowed_http_cidr`, `user_data`, `instance_public_ip`.
ALB unhealthy / 502	SG :80 from ALB + VPC; `/` returns 200. `cloud-init-output.log`: failed `user_data` (e.g. `dnf install curl` vs `curl-minimal`).
Apply limits	Other region/account or limit increase.
SSM offline / denied	`enable_ssm`, agent time, `ssm:StartSession`, outbound to SSM (NAT or endpoints).

References

Using GoAccess to View nginx Logs

John Ajera — Sat, 28 Mar 2026 08:54:19 +0000

Using GoAccess to View nginx Logs

GoAccess is a fast terminal and HTML log analyzer for nginx access logs (requests/sec, status codes, top URLs, referrers, user agents). This guide covers installation, optional S3 download, and typical run modes.

1. Overview

Install GoAccess (package manager, source, or jdevto/cli-tools script)
Optional: sync logs from S3 when they are not on the machine you analyze from
Run TUI, HTML report, live tail, or compressed input; use COMBINED or COMMON to match nginx log_format

Skip §4 if logs are already on disk.

2. Prerequisites

Readable nginx access logs (usually combined or common format)
sudo for distro package installs
S3 (optional): AWS CLI v2 and s3:GetObject / s3:ListBucket for the prefix you use

3. Install GoAccess

Fedora / RHEL / CentOS Stream

sudo dnf install -y goaccess

Debian / Ubuntu

sudo apt update && sudo apt install -y goaccess

goaccess --version

Newer or custom build: official build instructions.

jdevto/cli-tools installer (optional)

Builds from the official tarball; details and env vars in install_goaccess.md.

bash <(curl -s https://raw.githubusercontent.com/jdevto/cli-tools/main/scripts/install_goaccess.sh) install

bash <(curl -s https://raw.githubusercontent.com/jdevto/cli-tools/main/scripts/install_goaccess.sh) uninstall

4. Optional: Download nginx Logs from S3

Single file

mkdir -p ~/nginx-logs
aws s3 cp s3://my-bucket/path/to/access.log ~/nginx-logs/access.log

Key is .gz only: download, decompress, or stream without extracting:

aws s3 cp s3://my-bucket/path/to/access.log.gz ~/nginx-logs/access.log.gz
gzip -d ~/nginx-logs/access.log.gz
# or: zcat ~/nginx-logs/access.log.gz | goaccess - --log-format=COMBINED

Prefix (many files)

mkdir -p ~/nginx-logs
aws s3 sync s3://my-bucket/nginx-logs/ ~/nginx-logs/

Replace bucket and prefix. If you only have *.gz, after sync use zcat ~/nginx-logs/*.gz > ~/nginx-logs/merged-access.log (order across files may not be chronological) or decompress then merge plain *.log.

Merge plain logs (optional)

cat ~/nginx-logs/*.log > ~/nginx-logs/merged-access.log

5. Run GoAccess

Match --log-format to nginx (COMBINED is the usual default).

Terminal UI

goaccess /var/log/nginx/access.log --log-format=COMBINED

HTML report

goaccess /var/log/nginx/access.log --log-format=COMBINED -o report.html --no-parsing-spinner
xdg-open report.html

Live log

tail -f /var/log/nginx/access.log | goaccess - --log-format=COMBINED

Common log format

goaccess /var/log/nginx/access.log --log-format=COMMON

Custom log_format: map fields with GoAccess custom format tokens.

Compressed on disk

zcat /var/log/nginx/access.log.*.gz | goaccess - --log-format=COMBINED

6. Summary: Copy-Paste

sudo dnf install -y goaccess
mkdir -p ~/nginx-logs && aws s3 sync s3://YOUR_BUCKET/YOUR_PREFIX/ ~/nginx-logs/   # optional
goaccess /var/log/nginx/access.log --log-format=COMBINED
goaccess /var/log/nginx/access.log --log-format=COMBINED -o report.html --no-parsing-spinner && xdg-open report.html
tail -f /var/log/nginx/access.log | goaccess - --log-format=COMBINED

7. Troubleshooting

Parsed 0 lines / wrong numbers: Log line shape ≠ COMBINED/COMMON. Compare head -1 to nginx log_format and adjust --log-format.

Permission denied on log: sudo goaccess ..., fix group on log files, or copy the log to your home directory.

S3 Access Denied: IAM on bucket/prefix; check AWS_PROFILE / role.

Live tail idle: Confirm nginx access_log path and read permissions on the active file.

8. References

Using GoAccess to View nginx Logs

John Ajera — Sun, 22 Mar 2026 23:22:42 +0000

Using GoAccess to View nginx Logs

1. Overview

Install GoAccess (package manager, source, or jdevto/cli-tools script)
Optional: sync logs from S3 when they are not on the machine you analyze from
Run TUI, HTML report, live tail, or compressed input; use COMBINED or COMMON to match nginx log_format

Skip §4 if logs are already on disk.

2. Prerequisites

Readable nginx access logs (usually combined or common format)
sudo for distro package installs
S3 (optional): AWS CLI v2 and s3:GetObject / s3:ListBucket for the prefix you use

3. Install GoAccess

Fedora / RHEL / CentOS Stream

sudo dnf install -y goaccess

Debian / Ubuntu

sudo apt update && sudo apt install -y goaccess

goaccess --version

Newer or custom build: official build instructions.

jdevto/cli-tools installer (optional)

Builds from the official tarball; details and env vars in install_goaccess.md.

bash <(curl -s https://raw.githubusercontent.com/jdevto/cli-tools/main/scripts/install_goaccess.sh) install

bash <(curl -s https://raw.githubusercontent.com/jdevto/cli-tools/main/scripts/install_goaccess.sh) uninstall

4. Optional: Download nginx Logs from S3

Single file

mkdir -p ~/nginx-logs
aws s3 cp s3://my-bucket/path/to/access.log ~/nginx-logs/access.log

Key is .gz only: download, decompress, or stream without extracting:

aws s3 cp s3://my-bucket/path/to/access.log.gz ~/nginx-logs/access.log.gz
gzip -d ~/nginx-logs/access.log.gz
# or: zcat ~/nginx-logs/access.log.gz | goaccess - --log-format=COMBINED

Prefix (many files)

mkdir -p ~/nginx-logs
aws s3 sync s3://my-bucket/nginx-logs/ ~/nginx-logs/

Merge plain logs (optional)

cat ~/nginx-logs/*.log > ~/nginx-logs/merged-access.log

5. Run GoAccess

Match --log-format to nginx (COMBINED is the usual default).

Terminal UI

goaccess /var/log/nginx/access.log --log-format=COMBINED

HTML report

goaccess /var/log/nginx/access.log --log-format=COMBINED -o report.html --no-parsing-spinner
xdg-open report.html

Live log

tail -f /var/log/nginx/access.log | goaccess - --log-format=COMBINED

Common log format

goaccess /var/log/nginx/access.log --log-format=COMMON

Custom log_format: map fields with GoAccess custom format tokens.

Compressed on disk

zcat /var/log/nginx/access.log.*.gz | goaccess - --log-format=COMBINED

6. Summary: Copy-Paste

sudo dnf install -y goaccess
mkdir -p ~/nginx-logs && aws s3 sync s3://YOUR_BUCKET/YOUR_PREFIX/ ~/nginx-logs/   # optional
goaccess /var/log/nginx/access.log --log-format=COMBINED
goaccess /var/log/nginx/access.log --log-format=COMBINED -o report.html --no-parsing-spinner && xdg-open report.html
tail -f /var/log/nginx/access.log | goaccess - --log-format=COMBINED

7. Troubleshooting

Parsed 0 lines / wrong numbers: Log line shape ≠ COMBINED/COMMON. Compare head -1 to nginx log_format and adjust --log-format.

Permission denied on log: sudo goaccess ..., fix group on log files, or copy the log to your home directory.

S3 Access Denied: IAM on bucket/prefix; check AWS_PROFILE / role.

Live tail idle: Confirm nginx access_log path and read permissions on the active file.