DEV Community: John Ajera

Embed a public GA4 dashboard with Looker Studio

John Ajera — Sun, 27 Sep 2026 02:04:52 +0000

Embed a public GA4 dashboard with Looker Studio

Goal: open https://your.domain/stats and see three GA4 embeds (this year to date monthly, last 30 days daily, top URLs this week). One Looker Studio report per chart: three Public shares, three embed URLs. No Analytics login for viewers. No API keys.

You need gtag already on the site (GA4 static site setup). Know your Measurement ID (G-...).

1. Prerequisites

Browser signed into a Google account that can open your property in Google Analytics.
A folder you can deploy as the site (or add one HTML file to the host you already use).

2. Create the Looker Studio reports

Build three reports (one chart each). Shared create steps once; then configure each report.

Shared setup (first report)

Open https://lookerstudio.google.com/.
Click Create → Report (or Create a report / + Create new report on the home page).
First time only: complete account setup (country, company if asked, agree to terms) → Continue.
In Add data to report, choose Google Analytics.
Click Authorize if Data Studio asks to connect to your Analytics accounts.
Pick the property that matches your G-... Measurement ID → Add → Add to report.

If your property is missing from the list, that Google account cannot see GA4. Use the account that owns the property and start this section again.

For reports 2 and 3: Create → Report again. Reuse the same GA data source if Looker offers it; otherwise pick the same property.

Report A - `Site traffic - this year to date`

Rename Untitled Report to Site traffic - this year to date.
Keep one Bar chart (Add a chart → Bar chart / Column chart; delete other charts or tables). Monthly buckets read clearer as bars than a line.
Select the chart. Under Setup:
- Dimension: Date → granularity Year Month (or pick Year month as the X-axis / category dimension).
- Metric: Sessions.
- Default date range: Custom → This year to date.
Drag the chart to fill the canvas (full width and height, little empty margin).
Share menu → Invite people → Public → Viewer → Save.

Report B - `Site traffic - last 30 days`

Rename Untitled Report to Site traffic - last 30 days.
Keep one Time series (prefer this over a bar chart for ~30 days); delete extras. If you use a Bar chart, under Setup → Display turn Top N / Group the rest as "Others" off. Otherwise you only get 10 bars and a useless Others column.
Select the chart. Under Setup:
- Dimension: Date.
- Metric: Sessions.
- Default date range: Custom → Last 30 days.
Drag the chart to fill the canvas.
Share → Invite people → Public → Viewer → Save.

Report C - `Top URLs - this week`

Rename Untitled Report to Top URLs - this week.
Keep one Table (Add a chart → Table; delete extras).
Select the table. Under Setup:
- Dimension: Page location (full URL, so subdomains do not collapse into the same path).
- Metric: Views.
- Sort by Views descending.
- Rows per page: 10 (or Top N = 10; leave Group the rest as "Others" off).
- Default date range: Custom → Last 7 days.
Drag the table to fill the canvas.
Share → Invite people → Public → Viewer → Save.

Note: if local preview uses the same G-..., top rows may show localhost or 127.0.0.1. Optional chart filter: Hostname does not equal localhost (add another for 127.0.0.1 if needed). Skip if that traffic is not an issue for your site.

3. Get the embed URLs

Do this for each report:

Open the report → Share menu → Embed report.
Turn Enable embedding on.
Uncheck Show report navigation in embedded mode.
Leave Embed Code selected (or Embed URL; same link either way).
Copy only the URL inside src="...". It must contain /embed/reporting/ (not plain /reporting/).

Example shape:

https://lookerstudio.google.com/embed/reporting/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee/page/XXXXX

The dialog may show datastudio.google.com instead of lookerstudio.google.com; either host is fine. You need three URLs for the next section.

4. Add `/stats` on the site

Create a file the host serves at /stats (for a plain static host: stats/index.html in the published root).

Replace each PASTE_EMBED_URL_* with the matching URL from section 3:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <meta name="robots" content="noindex, nofollow" />
    <title>Site traffic</title>
  </head>
  <body>
    <iframe
      src="PASTE_EMBED_URL_A"
      title="Site traffic - this year to date"
      style="width:100%;height:60vh;border:0"
      allowfullscreen
      loading="lazy"
    ></iframe>
    <iframe
      src="PASTE_EMBED_URL_B"
      title="Site traffic - last 30 days"
      style="width:100%;height:60vh;border:0"
      allowfullscreen
      loading="lazy"
    ></iframe>
    <iframe
      src="PASTE_EMBED_URL_C"
      title="Top URLs - this week"
      style="width:100%;height:60vh;border:0"
      allowfullscreen
      loading="lazy"
    ></iframe>
  </body>
</html>

Do not add /stats to the site nav. Deploy (or refresh local preview).

CSP: if an iframe is blank and DevTools says blocked by Content-Security-Policy, add this and redeploy:

frame-src https://lookerstudio.google.com https://datastudio.google.com;

5. Check it worked

Open https://your.domain/stats in a private/incognito window (not signed into Google). You should see all three embeds.

If one is missing or shows a sign-in wall, fix that report's share/embed (sections 2-3) and update its iframe src. Later chart edits stay in Looker Studio; the site keeps the same URLs unless you change a report.

6. Troubleshooting

What you see	What to do
Sign-in wall on `/stats`	That report: Share → Invite people → Public → Viewer → Save
Empty chart	Confirm `G-...` on the live site; Realtime in Analytics; correct property. Avoid Last year if the property is new (that is the previous calendar year, not a rolling year)
Top URLs show `localhost` / `127.0.0.1`	Optional: filter those hostnames out (see Report C note)
Bar chart shows a huge Others	Turn off Top N / Group the rest as "Others" (or use a time series)
Iframe blocked	Section 4 CSP `frame-src`; redeploy
Chart looks tiny	In that report, resize the chart to fill the canvas

7. References

Connect your phone to Kiro Crew (Windows)

John Ajera — Sun, 20 Sep 2026 10:17:11 +0000

Connect your phone to Kiro Crew (Windows)

Part 2 of Kiro Crew on Windows (install + CLI + Builder ID). The dashboard is localhost:5476—your phone cannot open that. Crew’s official path uses Tailscale Serve (HTTPS inside your private tailnet), guided from the UI.

This is not Telegram/Slack, and not a public Cloudflare/ngrok tunnel. There is no Kiro Crew app on iPhone or Android.

1. Overview

PC: Connect your phone → Finish setup → install/sign in Tailscale → enable HTTPS if asked → Set up & show QR.
Phone: install Tailscale → allow VPN → sign in (same account)—not the Crew QR.
With Tailscale connected on the phone, scan the Crew QR (or open the token link).
Keep the PC awake; laptop sleep = phone offline.

2. Prerequisites

Part 1 done: Crew desktop up (All systems running on Overview).
Phone (iOS or Android) that can install Tailscale.
Browser for Tailscale sign-in / admin when prompted.

3. Open Connect your phone

Crew sidebar → Connect your phone.

Dialog Use Kiro Crew on your phone. If remote access is not ready: Remote access is not set up yet. Finish setup to get a scannable code.

Click that row (Finish setup).

That only opens Settings → Overview. It does not install Tailscale or show a QR yet. Crew’s dialog says “scan with your camera”; it does not spell out Tailscale-on-phone—do that before the Crew QR (step 6).

4. Install Tailscale on the PC

Overview may show Setup needed / Download Tailscale. Use Crew’s button, or the official stable installer:

https://pkgs.tailscale.com/stable/tailscale-setup-latest.exe

Prefer the browser (Save link / open the URL), or Windows curl.exe:

curl.exe -L "https://pkgs.tailscale.com/stable/tailscale-setup-latest.exe" -o "$env:USERPROFILE\Downloads\tailscale-setup-latest.exe"
Start-Process "$env:USERPROFILE\Downloads\tailscale-setup-latest.exe"

Agree to the license → Install (UAC).

Installation Successfully Completed → Close.

Welcome to Tailscale → Get Started.

Join your network → Sign in to your network (browser SSO). Same account you register with. Web Machines stays empty until the PC app finishes sign-in—use the app, not Add first device in the admin console.

Browser Connect device (PC name → your tailnet) → Connect. (No screenshot—page shows account and hostname.)
Connect to your tailnet devices → Close (tray icon manages Tailscale day to day).

Confirm the PC under Machines.

Tailscale Personal is free for this (PC + phone = user devices). Prefer Serve (private) over Funnel (public).

5. Enable HTTPS (one-time)

MagicDNS is usually already on. HTTPS Certificates often need a one-time enable:

Open DNS.
Confirm MagicDNS is enabled (button reads Disable MagicDNS…).
HTTPS Certificates → Enable HTTPS… → Enable.
The dialog warns that cert names (e.g. machine-name.tail….ts.net) go in a public Certificate Transparency ledger—normal for Let’s Encrypt; Serve still stays inside your tailnet.
Crew Overview → Re-check.

6. Set up & show QR (PC), then phone

Overview card: Phone access · Setup needed — allow access by this computer’s network name — Set up & show QR / Re-check.

If HTTPS still blocks the card, finish §5 → Re-check.
Set up & show QR once (Windows may need elevation for Tailscale Serve).

Crew enables Tailscale origin, restarts the Gateway, runs Serve (443 → local dashboard), and shows a short-lived sign-in QR. Do not screenshot or publish that QR—it embeds a live session token.

Phone (iOS or Android)—Tailscale first, Crew QR second:

Install Tailscale (App Store / Play Store).
Allow VPN / VPN configuration when asked.
Sign in with the same account as the PC. Tailscale does not use the Crew QR for this step.
Leave Tailscale connected.
Scan the Crew QR with the system Camera (or open the https://…/?token=… link in the mobile browser). Mint a fresh QR if the old one expired.
Dashboard loads. Optional: Add to Home Screen (PWA).

Do not open the bare MagicDNS hostname without a token. Create sign-in link in the first Crew dialog is a fallback after remote access works—it does not replace Tailscale.

7. CLI alternative (desktop install)

The Setup.exe build does not put kirocrew on PATH. Use the bundled CLI if the UI sticks (Admin PowerShell if Serve needs elevation):

$kc = "$env:LOCALAPPDATA\Programs\KiroCrew\resources\backend-dist\kirocrew-backend\bin\kirocrew.cmd"
& $kc config set dashboard.tailscale.enabled true
& $kc restart
& $kc tailnet up
& $kc token
& $kc tailnet status

Command	Role
`… enabled true`	Trust Tailscale Serve origin (once)
`tailnet up`	Publish HTTPS → dashboard (URL alone has no session)
`token`	Prints `https://…/?token=…` for the phone

& $kc tailnet down stops publishing without clearing the enabled flag.

8. Sessions

Piece	Typical duration	Notes
QR / link click window	Minutes	Mint again if stale
Access cookie	Up to ~20h	Short-lived access
Refresh cookie	~30 days idle	Phone can stay signed in

Config: %USERPROFILE%\.kiro\crew\.

9. Summary

1. Part 1: Crew + kiro-cli on Windows
1. Connect your phone → Finish setup → Tailscale on PC → Connect
1. Admin DNS: Enable HTTPS → Re-check
1. Set up & show QR
1. Phone: Tailscale + VPN + same account → then scan Crew QR

curl.exe -L "https://pkgs.tailscale.com/stable/tailscale-setup-latest.exe" -o "$env:USERPROFILE\Downloads\tailscale-setup-latest.exe"
Start-Process "$env:USERPROFILE\Downloads\tailscale-setup-latest.exe"

10. Troubleshooting

Issue	Fix
Finish setup “does nothing”	It only opens Overview—install Tailscale next
Failed to fetch / gateway stuck on :5476	Restart PC; confirm Overview loads
`kirocrew` not found in PowerShell	Expected for Setup.exe—use bundled `kirocrew.cmd` path in §7
Card stays Setup needed	PC Tailscale signed in; HTTPS enabled; Re-check
Crew QR scan does nothing	Tailscale connected on phone first; use Camera/Safari/Chrome; mint a fresh QR
Phone login screen only	Open token/QR URL, not bare hostname
Serve permission error	Admin PowerShell for `tailnet up`
Laptop sleep	Keep PC awake or use an always-on host later

11. References

Install Kiro Crew on Windows

John Ajera — Sun, 20 Sep 2026 05:38:56 +0000

Install Kiro Crew on Windows

Part 1 of Kiro Crew on Windows. Kiro Crew is a local agent Gateway + dashboard. It talks to the LLM through Kiro CLI (ACP). This is not the Kiro IDE.

Next: connect the dashboard from your phone with Tailscale (Part 2 of this series).

1. Overview

Install KiroCrew-Setup.exe (Gateway bundled; no Python needed).
First launch: install Kiro CLI, then kiro-cli login (Builder ID in this guide).
State: %USERPROFILE%\.kiro\crew\ (survives uninstall).

2. Prerequisites

Windows 10/11 x64
Browser for Kiro sign-in
Network (installer + ~610 MB embedding model on first start)

3. Download

Direct stable installer (~260 MB, always latest):

https://download.crew.kiro.dev/desktop/stable/latest/KiroCrew-Setup.exe

Prefer the browser (Save link / open the URL)—usually faster than PowerShell.

CLI: use Windows curl.exe, not Invoke-WebRequest (IWR is slow on large files):

curl.exe -L "https://download.crew.kiro.dev/desktop/stable/latest/KiroCrew-Setup.exe" -o "$env:USERPROFILE\Downloads\KiroCrew-Setup.exe"
Start-Process "$env:USERPROFILE\Downloads\KiroCrew-Setup.exe"

4. Install

Run KiroCrew-Setup.exe.
SmartScreen: More info → Run anyway only for this official signed build.
Welcome → Next.

Choose Only for me (default, no UAC) or Anyone who uses this computer → Install.

Wait for install to finish.

Leave Run KiroCrew checked → Finish.

Uninstall: Settings → Apps → Kiro Crew. Does not delete %USERPROFILE%\.kiro\crew.

5. First launch

App starts the Gateway, then opens setup.

Leave Crew open. Install Kiro CLI in PowerShell. Source of the one-liner: kiro.dev/cli (Crew’s Open Kiro CLI setup only opens that page).

irm 'https://cli.kiro.dev/install.ps1' | iex

Crew shows Sign in to Kiro (CLI Complete). This guide uses Builder ID:

kiro-cli login

Back in Crew → Check again. Continue past Privacy, then Tell Kiro about you → Continue.

Dashboard opens (app UI or http://localhost:5476).

6. Summary: Copy-Paste

curl.exe -L "https://download.crew.kiro.dev/desktop/stable/latest/KiroCrew-Setup.exe" -o "$env:USERPROFILE\Downloads\KiroCrew-Setup.exe"
Start-Process "$env:USERPROFILE\Downloads\KiroCrew-Setup.exe"

1. Setup → Only for me → Finish → Launch
1. irm 'https://cli.kiro.dev/install.ps1' | iex
1. kiro-cli login
1. Check again → Privacy → Tell Kiro about you → Continue
1. Chat (app or http://localhost:5476)

7. Troubleshooting

Issue	Fix
SmartScreen	Official CDN link above; Run anyway only for that signed build
CLI missing / no `acp`	Re-run `irm 'https://cli.kiro.dev/install.ps1' \
Sign-in stuck	{% raw %}`kiro-cli login` in a new PowerShell window, then Check again
Uninstall left data	Expected—delete `%USERPROFILE%\.kiro\crew` manually

8. References

Kiro Crew
Installation
Stable Setup.exe
Kiro CLI
KiroCrew releases
Part 2 of this series: Connect your phone to Kiro Crew (Windows)

Set up Google Analytics 4 on a static site (gtag, CSP, and Amplify)

John Ajera — Sat, 29 Aug 2026 08:02:37 +0000

Set up Google Analytics 4 on a static site (gtag, CSP, and Amplify)

You want page views on a static personal site (for example an Amplify-hosted home page). Google Analytics 4 (GA4) is free and not a Google Cloud product - you sign in with a normal Google account, create an Analytics account and property, then put a Measurement ID (G-...) on the site.

This guide walks through console setup, a complete one-page smoke test you can deploy as-is, and the Amplify Content-Security-Policy gotcha that blocks fonts, theme toggles, and Analytics if you forget it.

Icons for Amplify and CloudFront come from AWS Icons (AWS Architecture Icons; use per AWS Trademark Guidelines). GA4 is not a Google Cloud product, so there is no matching icon in GCP Icons - the last hop is a plain GA4 label.

1. Overview

Create a GA4 account (label only) and property for your site.
Choose data-sharing options (optional extras for Google).
Pick business objective Understand web and/or app traffic.
Add a Web data stream and copy the Measurement ID.
Deploy a full HTML smoke-test page with gtag (then wire production the same way).
Allow Google Tag Manager, Analytics, and (if used) Google Fonts in your CSP.
Confirm with GA Realtime or the tag Retest UI.

2. Prerequisites

A public HTTPS host you control (this walkthrough uses AWS Amplify Hosting).
A Google account with access to Google Analytics.
Ability to publish a static HTML file and edit Amplify custom headers / CSP.
Optional: Terraform or Console access if Amplify headers are managed as infra.

3. Create the GA4 account and property

Open Google Analytics → Admin → Create → Account (or start the guided setup).
Account name is only a label (for example johna.kiwi or your name). It is not a GCP project ID.
Create a property for the site (property name can match the domain).
Complete business details as prompted.

  Google Analytics hierarchy
  -------------------------
  Account          "johna.kiwi"          <-- folder / org label
    Property       "johna.kiwi"          <-- one site (or app)
      Data stream  Web / johna.kiwi      <-- where G-XXXXXXXX lives

GA sits next to Ads / Tag Manager / Search Console. You do not need a Google Cloud billing account for basic page-view tracking.

4. Account data sharing settings

You will see checkboxes such as:

Setting	Typical choice for a personal site
Google products and services	Off
Modeling contributions and business insights	Optional (on or off)
Technical support	Off unless you need Google support access
Recommendations for your business	Off

Turning all of them off still allows basic hits, pages, and referrers. These controls are extra sharing with Google, not a requirement to collect page views.

5. Business objectives

Select Understand web and/or app traffic.

Skip leads, sales, and engagement unless you care about those recommended report packs. You can change suggestions later; page views still work either way.

Then Create.

6. Start collecting data: Web stream

Choose platform Web (not Android / iOS).
Website URL: your apex, for example https://johna.kiwi.
Stream name: something clear, for example johna.kiwi.
Create the stream and copy the Measurement ID (G-XXXXXXXX).

  Stream URL says:     https://johna.kiwi
  Hits actually come:  wherever this exact G-XXXXXXXX script runs

  johna.kiwi          [tag]  --> counted
  staging.johna.kiwi  [   ]  --> not counted (unless you add the tag)
  labs / guides       [   ]  --> not counted (unless you add the tag)

Subdomains are not auto-tracked from DNS alone. Same Measurement ID on each host = one property; different IDs = separate properties.

7. Smoke-test page (full HTML)

Do not start with a half snippet in an existing theme. Save this as index.html, replace G-XXXXXXXX, and deploy it (Amplify, S3 website, GitHub Pages, or any static host). Then open the live URL and check Realtime.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>GA4 smoke test</title>
    <meta name="description" content="Minimal page to verify Google Analytics 4 gtag.">
    <!-- Google tag (gtag.js) -->
    <script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXX"></script>
    <script>
      window.dataLayer = window.dataLayer || [];
      function gtag() {
        dataLayer.push(arguments);
      }
      gtag("js", new Date());
      gtag("config", "G-XXXXXXXX");
    </script>
    <style>
      body {
        font-family: system-ui, sans-serif;
        max-width: 40rem;
        margin: 3rem auto;
        padding: 0 1rem;
        line-height: 1.5;
      }
    </style>
  </head>
  <body>
    <h1>GA4 smoke test</h1>
    <p>
      If this page is public over HTTPS and CSP allows
      <code>googletagmanager.com</code>, a hit should appear in
      Analytics Realtime within a minute.
    </p>
    <p>Measurement ID on this page: <code>G-XXXXXXXX</code></p>
  </body>
</html>

That is enough to prove the tag. After it works, copy the same <script> block into your real site's <head> (and 404.html if you want those hits).

7.1 Amplify: inject only on production

For a real app like johna.kiwi, keep the smoke-test pattern in spirit: put gtag in HTML at build time from an env var so staging stays clean.

  Amplify main branch env
  -----------------------
  GA_MEASUREMENT_ID = G-XXXXXXXX
  SITE_ENV          = production

  build step
  ----------
  if GA_MEASUREMENT_ID set  -->  write gtag into index.html / 404.html
  else                      -->  leave markers empty (staging / PR)

Example branch env:

GA_MEASUREMENT_ID=G-XXXXXXXX
SITE_ENV=production

Local check:

GA_MEASUREMENT_ID=G-XXXXXXXX npm run build
# confirm index.html / 404.html contain gtag and your G- id

Unset the var and rebuild to clear markers for local preview.

8. Content-Security-Policy (the usual failure mode)

The HTML can be perfect and GA still says tag wasn't detected. Strict Amplify CSP is usually why - and it also breaks Google Fonts and inline theme scripts.

If your Amplify header still looks like this:

default-src 'self'; style-src 'self'; font-src 'self'; ...

you will hit exactly the left-hand failures above. Use an allow-list closer to this (adjust to your needs):

default-src 'self';
script-src 'self' 'unsafe-inline' https://www.googletagmanager.com;
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
img-src 'self' data: https://www.google-analytics.com https://www.googletagmanager.com;
font-src 'self' https://fonts.gstatic.com;
connect-src 'self' https://*.google-analytics.com https://*.analytics.google.com https://www.googletagmanager.com;
object-src 'none';
base-uri 'self';
form-action 'self';
frame-ancestors 'none';
upgrade-insecure-requests

Update Amplify App settings → Custom headers, then redeploy the branch so CloudFront picks up the new policy. Confirm with:

curl -sI https://your.domain/ | grep -i content-security-policy

If you manage Amplify with Terraform, do not put custom_headers in lifecycle.ignore_changes unless you intentionally manage CSP only in the Console. Ignoring headers for "YAML vs JSON drift" means CSP fixes never apply via CI/CD.

9. Verify

Hard-refresh the live site (cache can keep an old CSP).
DevTools → Network: gtag/js?id=G-... should be 200, not blocked (blocked requests often show provisional headers).
Analytics → Reports → Realtime, or the setup Retest button for your domain.
If you use a theme toggle in inline JS, it should work once script-src allows 'unsafe-inline' (or move scripts to same-origin .js files).

It can take a short time for the first hit to show; Realtime is the quick check.

10. Summary: copy-paste

1. Measurement ID (Amplify main env):

GA_MEASUREMENT_ID=G-XXXXXXXX

2. Full smoke-test page: use the index.html in section 7 (replace every G-XXXXXXXX).

3. Confirm CSP after deploy:

curl -sI https://your.domain/ | grep -i content-security-policy

4. Optional: gtag-only fragment for an existing layout's <head>:

<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag() {
    dataLayer.push(arguments);
  }
  gtag("js", new Date());
  gtag("config", "G-XXXXXXXX");
</script>

11. Troubleshooting

Symptom	Likely cause	Fix
GA: tag wasn't detected	CSP blocks googletagmanager or inline script	Loosen CSP; redeploy; hard-refresh
Fonts fail in Network	CSP `style-src` / `font-src` self-only	Allow fonts.googleapis.com and fonts.gstatic.com
Theme / dark mode toggle dead	Inline script blocked by CSP	Allow `'unsafe-inline'` under `script-src`, or use an external JS file
Tag in HTML but Retest fails	Old CSP still on CloudFront	Redeploy branch after header change; wait for cache miss
Staging shows no gtag	Env only on `main`	Expected if you inject only when `GA_MEASUREMENT_ID` is set
Subdomain traffic missing	No tag on that host	Add the same Measurement ID to that site's HTML
Smoke page works, real site fails	Real site CSP stricter than smoke host	Align custom headers; compare `curl -sI` on both

12. References

EKS Metrics: Amazon Managed Prometheus vs Self-Managed Prometheus

John Ajera — Sat, 23 May 2026 23:58:14 +0000

EKS Metrics: Amazon Managed Prometheus vs Self-Managed Prometheus

Once your cluster is running workloads, you need a metrics backend: something that scrapes (or receives) time series, stores them, and powers dashboards and alerts. On AWS the fork is usually Amazon Managed Service for Prometheus (AMP)—a managed, Prometheus-compatible store—or self-managed Prometheus in the cluster (Helm chart, operator, or agent + remote storage).

This article is a practical decision guide for that choice on EKS, especially when you are not migrating a decade of PromQL dashboards and recording rules. It covers what each path optimizes for, how cost shows up on the invoice versus in engineer time, how alerting differs, and a short rubric for defaulting to AMP, self-managed, or a hybrid (remote_write).

1. Overview

This guide helps you decide, for a new or early EKS observability stack:

What AMP and self-managed Prometheus each own (ingest, storage, query, alerting)
How to compare cost at a high level (ingestion, storage, queries, and cluster resources)
How to measure or estimate active series and ingestion before you pick a tier
What you still run in-cluster either way (exporters, scrape config, ADOT)
When a hybrid (Prometheus in-cluster → AMP via remote_write) is the least painful path

2. Prerequisites

Familiarity with Prometheus concepts: scrape targets, labels, TSDB retention, PromQL
An EKS cluster (Standard or Auto Mode) with a plan for who operates platform add-ons
Current Amazon Managed Service for Prometheus pricing and AMP documentation—limits and pricing change over time

3. Name the two starting paths

Both paths speak Prometheus (PromQL, exposition format, alert rule semantics). The split is who runs the TSDB and query API.

Side-by-side

	Amazon Managed Prometheus (AMP)	Self-managed Prometheus (in-cluster)
AWS runs	Ingestion pipeline, durable TSDB, query plane (serverless-style ops)	—
You run	Collectors/agents, scrape or receive config, IAM, workspace wiring	Prometheus server (often StatefulSet), PVCs, upgrades, HA, backups
Typical ingest	AWS Distro for OpenTelemetry (ADOT) collector, Prometheus agent mode, or `remote_write` from an in-cluster server	In-cluster scrape of ServiceMonitors, Pod annotations, static targets
Alerting	AMP managed Alertmanager and/or route to SNS; Grafana alerting is a separate choice	Alertmanager you deploy (often same Helm release or a sibling chart)
Dashboards	Often Amazon Managed Grafana or self-hosted Grafana with AMP as datasource	Grafana (or similar) pointing at in-cluster Prometheus Service
Multi-cluster	Natural fit: one workspace per env/region or federation patterns with less TSDB ops	Per-cluster Prometheus + optional Thanos/Mimir if you outgrow one server

AMP — responsibility flow

+-------------------------------+
| EKS: workloads + exporters    |
| (node-exporter, kube-state,   |
|  app /metrics, ADOT collector)|
+-------------------------------+
              |
              | remote_write / ADOT pipeline
              v
+-------------------------------+
| AWS: AMP workspace (TSDB +      |
| PromQL query API)             |
+-------------------------------+
              |
              v
+-------------------------------+
| You: Grafana / AMP Alertmgr / |
| SNS routes, dashboards, SLOs  |
+-------------------------------+

Self-managed — responsibility flow

+-------------------------------+
| EKS: Prometheus server        |
| (scrape + TSDB on PVC/emptyDir)|
+-------------------------------+
              |
              v
+-------------------------------+
| EKS: Alertmanager (optional)  |
| receivers → Slack/PagerDuty   |
+-------------------------------+
              |
              v
+-------------------------------+
| You: Grafana, rule lifecycle, |
| upgrades, capacity, backups   |
+-------------------------------+

Same for both: You still own what gets scraped, label cardinality, RBAC for the UI, and runbooks when alerts fire. Picking AMP does not remove the need for good metric and alert design.

4. Cost at a glance

Pricing moves; verify against AMP pricing and your EC2/EBS bill for self-managed. Think in three buckets: ingestion, storage/retention, queries (AMP) versus compute + disk + people (self-managed).

AMP (managed)

Cost driver	What drives it up
Ingested samples	Short scrape intervals, high-cardinality labels, many targets
Storage	Long retention, high churn, many series
Queries	Heavy Grafana dashboards, ad-hoc PromQL, recording rules evaluated in AMP

AMP can be cheap at small scale and expensive when cardinality explodes (unbounded pod labels, high-cardinality HTTP paths, per-UUID labels). Cost guardrails (sampling, relabel drops, allowed metric lists) matter more than on a single dev cluster where you only notice disk growth.

Self-managed (in-cluster)

Cost driver	What drives it up
EC2 / Karpenter nodes	CPU/memory for Prometheus replicas and rule evaluation
EBS (or equivalent)	TSDB size × retention; compactions and WAL
Engineer time	Chart upgrades, PVC expansion, HA drills, backup/restore testing

A minimal HA self-managed stack (two Prometheus replicas, anti-affinity, 20–50 Gi PVCs each, small Alertmanager) is often tens of dollars per month in AWS resources for a small cluster—before counting on-call and upgrade work. The invoice line is predictable; the hidden cost is operational.

Bottom line: AMP trades variable, usage-based spend for less TSDB operations. Self-managed trades fixed-ish infra cost for more control and more chores. Neither removes the need to design metrics carefully.

5. How to check and estimate your usage

Cost conversations are easier when you separate active series (how many distinct time series the TSDB holds) from ingestion rate (how many samples per second you push—what AMP bills most directly).

What counts as one series

A time series is one metric name plus one unique label set. Example: http_requests_total{method="GET",status="200",pod="abc"} is one series. More pods, paths, or IDs in labels → more series.

Rough scale tiers (planning only)

These are order-of-magnitude guides, not limits:

Tier	Active series (ballpark)	Typical EKS picture
Small	~1k–5k	Minimal scrape (little kube-state-metrics, no full cAdvisor), or aggressive `metric_relabel_configs` drops
Medium	~10k–30k	node-exporter + kube-state-metrics + kubelet/cAdvisor + apiserver on a small cluster (handful of nodes, tens of pods)
Large	50k+	Full default chart scrape, many microservices, per-path HTTP metrics, or duplicate exporters

A standard platform scrape (kube-state-metrics, kubernetes-nodes-cadvisor, apiserver, node-exporter) on a small cluster often lands above 10k even when it still feels “small” operationally—measure rather than assuming the 1k tier.

Turn series into ingestion (AMP-style math)

At a steady scrape interval, each active series produces about one sample per scrape:

samples_per_second ≈ active_series ÷ scrape_interval_seconds

Examples at 30s scrape:

Active series	~samples/s	~samples/month (30 days)
1,000	~33	~86M
10,000	~333	~864M
25,000	~833	~2.2B
50,000	~1,667	~4.3B

Use 86,400 × 30 seconds per month for back-of-envelope planning. If jobs use different intervals, sum per job or use a weighted average.

Back-of-envelope before deploy

List scrape jobs and estimate series per target:

Source	How to estimate
node-exporter	~400–1,000 series × node count (disks and NICs add labels)
kube-state-metrics	~20–40 series × pod count, plus Deployments, PVCs, HPA, PDB, …
kubelet / cAdvisor (`kubernetes-nodes-cadvisor`)	Often the largest bucket—scales with containers, not just nodes
apiserver	Often thousands of series (histogram buckets and verb/resource labels)
Application `/metrics`	Highly variable—histograms and high-cardinality labels dominate

active_series ≈ Σ (targets × series_per_target)   # plus a little for Prometheus self-metrics

Churn (pods created and destroyed) affects AMP storage more than steady active series; dynamic fleets need headroom.

How to check (self-managed Prometheus already running)

Port-forward to the Prometheus server (adjust namespace and service name to match your install):

kubectl -n prometheus port-forward svc/prometheus-server 9090:80

Headline count — TSDB stats API:

curl -s http://127.0.0.1:9090/api/v1/status/tsdb | jq '.data.numSeries'

Same value in the UI: Status → TSDB Stats. The metric prometheus_tsdb_head_series tracks it over time.

Top metrics by cardinality (can be expensive on very large TSDBs—use in non-prod or off-peak):

curl -sG 'http://127.0.0.1:9090/api/v1/query' \
  --data-urlencode 'query=topk(20, count by (__name__) ({__name__=~".+"}))' \
  | jq '.data.result[] | {metric: .metric.__name__, series: .value[1]}'

Top scrape jobs (find what to trim):

curl -sG 'http://127.0.0.1:9090/api/v1/query' \
  --data-urlencode 'query=topk(10, count by (job) ({__name__=~".+"}))' \
  | jq '.data.result[] | {job: .metric.job, series: .value[1]}'

In the UI: Status → Targets shows per-target health and last scrape size—useful when a single job spikes.

How to check (AMP)

CloudWatch metrics on the AMP workspace (ingestion and active series—see Monitor AMP).
AWS console → AMP workspace usage views for growth over time.
If you use ADOT or remote_write, the sender (collector or in-cluster Prometheus) still exposes scrape stats—debug cardinality at the source before it hits the workspace.

What usually blows up series count

High-cardinality labels — pod, url, trace_id, unbounded user_id on high-volume metrics.
Duplicate scrape — EKS addon node-exporter and Helm node-exporter, or two Prometheus replicas each scraping everything without needing two full TSDBs for AMP.
Histograms — each bucket, plus _sum and _count, is multiple series per logical metric.
Full cAdvisor / apiserver defaults with no relabel drops.

After you have numSeries and the top two job values, you can map yourself to the small / medium / large table above and plug numbers into the samples per month formula for AMP pricing.

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

Where the work lands

Area	AMP	Self-managed
TSDB durability & scaling	AWS	You (PVC size, retention flags, compaction behavior)
Prometheus version upgrades	Managed compatibility window	You (Helm chart / operator upgrades, CRD drift)
Scrape discovery	You (collector config, EKS receivers, ServiceMonitor CRDs)	You (same; often more familiar with `prometheus.yml` in-cluster)
Recording / alerting rules	AMP rule groups or in-cluster evaluation + `remote_write`	Native `serverFiles` / PrometheusRule CRDs in Git
Long-term retention / global view	AMP + optional export; or Mimir/Thanos later	Add Thanos/Mimir/Cortex when one server is not enough
UI for debugging	Grafana → AMP; limited “SSH into Prometheus”	`kubectl port-forward` to `:9090`—fast for platform engineers

AMP in practice

Less toil on TSDB HA, backups, and “disk full” pages for the metrics store
Strong fit for org-wide standards and IAM-bound workspaces
Watch ingestion billing and cardinality; use ADOT/Prometheus relabeling deliberately
Alertmanager behavior is AWS-shaped—read AMP Alertmanager docs before assuming OSS Alertmanager feature parity

Self-managed in practice

Full control of scrape config, rule files, federation, and “break glass” PromQL on localhost
Familiar path: prometheus-community/prometheus Helm chart, GitOps overlays per cluster
Recurring work: chart bumps with Kubernetes upgrades, PVC growth, proving Alertmanager HA, securing the Prometheus UI (it has no built-in auth—use network policy, private ingress, or an auth proxy)
EKS add-ons can cover node-exporter (managed addon) while you keep a narrow Prometheus release for the server and rules—avoid duplicating the same metrics twice

7. EKS-specific wiring (both paths)

Neither option removes in-cluster collection:

Component	Typical role
Metrics server	HPA CPU/memory—not a Prometheus replacement
prometheus-node-exporter	Node/host metrics (DaemonSet or EKS managed addon)
kube-state-metrics	Kubernetes object metrics (Deployment, Pod, PVC, …)
CoreDNS / kubelet / apiserver	Cluster health; scrape config or ADOT receivers
Application `/metrics`	Your SLOs and business metrics

AMP path: deploy ADOT (or Prometheus in agent mode) with remote_write to the AMP workspace endpoint; use EKS Pod Identity or IRSA for SigV4 authentication.

Self-managed path: enable targets in Helm values or the Prometheus Operator; pin kube-state-metrics and exporters intentionally so you do not scrape the same series twice.

Hybrid (common): run a small in-cluster Prometheus for fast local debugging and federation-style rules, remote_write aggregates or critical series to AMP for org dashboards and long retention. You pay complexity once, not double storage for every raw sample.

8. Alerting and Grafana

Topic	AMP	Self-managed
Rule evaluation	AMP rule groups and/or in-cluster Prometheus firing → AMP	Prometheus `alerting_rules.yml` / PrometheusRule CRDs
Alert routing	AMP Alertmanager, SNS, EventBridge; fewer “random webhook” examples in AWS docs	Alertmanager receivers (Slack, PagerDuty, Opsgenie) in Git—with secrets via External Secrets
Grafana	Managed Grafana with AMP datasource is the path of least resistance	Platform Grafana in-cluster; datasource = Prometheus Service DNS
Double paging	Risk if both AMP rules and Grafana unified alerting fire on the same metric	Risk if both Prometheus and Grafana own the same alerts—pick one owner

9. Decision rubric (greenfield)

Lean toward AMP when:

You want no StatefulSet TSDB to babysit and are fine with usage-based metrics cost
Centralized observability across many accounts/clusters matters soon
You will standardize on ADOT / AWS observability patterns and Managed Grafana
The team is small and should not own Prometheus compaction, PVC resize, and version skew

Lean toward self-managed Prometheus when:

You need maximum control (custom scrape hooks, exotic service discovery, air-gapped patterns)
Most engineers live in port-forward PromQL and Git-managed prometheus.yml / rules
Predictable infra cost matters more than eliminating ops (small cluster, disciplined cardinality)
You already run kube-prometheus-stack patterns and want one chart to own rules + Alertmanager

Lean toward hybrid when:

You need in-cluster debugging and org-wide long retention or dashboards in AMP
You are migrating: start self-managed, remote_write to AMP, cut over Grafana datasources, then shrink in-cluster retention

Default suggestion for a greenfield EKS platform team: if nobody wants to own TSDB operations, start with AMP + ADOT and Managed Grafana; if the team is building GitOps muscle on platform charts and wants the fastest “see /targets and /rules locally” loop, self-managed with a narrow chart (server + optional Alertmanager, exporters wired deliberately) is a solid teaching path. Revisit when cardinality, retention, or multi-cluster pain appears.

10. Troubleshooting: common misconceptions

“AMP means we don’t run anything in the cluster.” You still run collectors/exporters and own cardinality.
“Self-managed is always cheaper.” EBS + replicas can be modest; engineer time and incident cost often dominate.
“We installed the prometheus-node-exporter EKS addon, so we have Prometheus.” The addon is node metrics, not the TSDB server.
“Grafana alerting replaces Prometheus/Alertmanager.” It can—but two owners for the same alert is how you get double pages.
“remote_write is free duplication.” It is not; you pay network, ingest, and often double evaluation unless you design what gets forwarded.

11. References

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.

DEV Community: John Ajera

Embed a public GA4 dashboard with Looker Studio

Embed a public GA4 dashboard with Looker Studio

1. Prerequisites

2. Create the Looker Studio reports

Shared setup (first report)

Report A - Site traffic - this year to date

Report B - Site traffic - last 30 days

Report C - Top URLs - this week

3. Get the embed URLs

4. Add /stats on the site

5. Check it worked

6. Troubleshooting

7. References

Connect your phone to Kiro Crew (Windows)

Connect your phone to Kiro Crew (Windows)

1. Overview

2. Prerequisites

3. Open Connect your phone

4. Install Tailscale on the PC

5. Enable HTTPS (one-time)

6. Set up & show QR (PC), then phone

7. CLI alternative (desktop install)

8. Sessions

9. Summary

10. Troubleshooting

11. References

Install Kiro Crew on Windows

Install Kiro Crew on Windows

1. Overview

2. Prerequisites

3. Download

4. Install

5. First launch

6. Summary: Copy-Paste

7. Troubleshooting

8. References

Set up Google Analytics 4 on a static site (gtag, CSP, and Amplify)

Set up Google Analytics 4 on a static site (gtag, CSP, and Amplify)

1. Overview

2. Prerequisites

3. Create the GA4 account and property

4. Account data sharing settings

5. Business objectives

6. Start collecting data: Web stream

7. Smoke-test page (full HTML)

7.1 Amplify: inject only on production

8. Content-Security-Policy (the usual failure mode)

9. Verify

10. Summary: copy-paste

11. Troubleshooting

12. References

EKS Metrics: Amazon Managed Prometheus vs Self-Managed Prometheus

EKS Metrics: Amazon Managed Prometheus vs Self-Managed Prometheus

1. Overview

2. Prerequisites

3. Name the two starting paths

Side-by-side

AMP — responsibility flow

Self-managed — responsibility flow

4. Cost at a glance

AMP (managed)

Self-managed (in-cluster)

5. How to check and estimate your usage

What counts as one series

Rough scale tiers (planning only)

Turn series into ingestion (AMP-style math)

Back-of-envelope before deploy

How to check (self-managed Prometheus already running)

How to check (AMP)

What usually blows up series count

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

Where the work lands

AMP in practice

Self-managed in practice

7. EKS-specific wiring (both paths)

8. Alerting and Grafana

9. Decision rubric (greenfield)

10. Troubleshooting: common misconceptions

11. References

Report A - `Site traffic - this year to date`

Report B - `Site traffic - last 30 days`

Report C - `Top URLs - this week`

4. Add `/stats` on the site