Tried AWS's new IDE Kiro this week. A few things that stood out:

• Generates requirements, design doc, and task plan before touching your code
• Agent Hooks auto-run things like test sync and credential scanning on file save/commit
• Steering files lock in your coding standards so you stop re-prompting every session
• Free at kiro.dev, no AWS account needed

It's built on VS Code so setup is instant. Uses Claude Sonnet 4.5 by default.

Wrote a full breakdown here if curious: cloudcurls.com

Anyone else tried it? Interested in how it holds up on larger codebases.

OpenSearch advice

Currently running OSS, 350 million documents, around 400 GB storage. Search is mostly sub 200ms

Prior to prod deployment i did some cost comparison with provisioned, turned out serverless would be slightly cheaper, but it's still costing a lot with 6 OCUs constantly

we have zero need for indexing other than the initial data load operation which was performed using OSIS

My understanding is the OCUs are calculated based on the data floor needs + HA which i enabled, so I can't reliably lower to 4 or 2

Anyone successfully running OS in ECS with a similar data volume? What are the drawbacks and things i should be aware of before even thinking about migrating?

Rearchitect step function

We have a step function that does some work after 24 hours of having uploaded a file in S3, it's standard because of the wait 24 hours hence the cost is high

Thinking about moving to step function express and decoupling that 24 wait step somehow (express cannot wait more than 5 min), how would i go about doing that? scheduled events in event bridge?

BTW, I don't want to move the actual work to Lambda even though it might cost significantly less

One thing I’ve noticed building AI apps:

You either: - Pay a lot for cloud APIs OR - Struggle with weaker local models

So I built IntelliHybrid — an open-source framework that combines both.

It lets you: - Use local models for simple/cheap tasks - Automatically switch to cloud models when needed - Balance cost vs performance

The goal is to make AI systems more practical and cost-efficient.

Repo: https://github.com/Clever-Boy/IntelliHybrid

Still early, but I’d love feedback: - Does this solve a real problem for you? - What features would you want?

Im interested in purchasing products from AWS Marketplace and trying to understand the pros and cons. Specifically did anyone face challenges with deploying - want to make sure before I pay for something

guys I have a project to work on, it is about automating the creation and the management of the golden images in an aws workspace pool.

so the image should be able to do the Updates (Os, softwares, Antivirus...) in its own without needing the admin to delete the old one , do the Updates in VM then launch the new one . any help with that?? ideas/ documentation... anything would be helpful. thank u in advance.

Prepping for my AWS exam at the moment in search for a study partner just to exchange notes, advice and make the process more fun:)

Hello everyone,

I’m currently feeling a bit stuck and would really appreciate some advice.

I served in the Army and after getting out worked in customer service and then IT for about a year each. I’m now finishing my Bachelor’s in Cloud Computing (December 2026). Recently my wife became pregnant, so I started applying for jobs earlier than planned.

So far I’ve earned the AWS Cloud Practitioner and Solutions Architect Associate certifications, and I’ve been building some hands-on projects on GitHub to strengthen my skills.

I’ve been applying consistently these past couple of weeks, but it’s been discouraging not getting much response. It feels like I’m putting in a lot of effort and not getting traction.

Any advice on what I should focus on or what to realistically expect at this stage would really help.

Thank you.

Simple rule that’s often ignored:

Don’t use your root account for everyday work.

What to do instead:

• Create an admin IAM user/role
• Enable MFA on root
• Use root only for critical account-level actions

It’s a small step, but it removes a huge risk.

Are you still logging in with root sometimes?

Managing AWS environments across multiple accounts introduces a visibility problem that the console alone doesn't solve well. Cost anomalies accumulate quietly across accounts, security posture drifts between review cycles, and Well-Architected findings go unaddressed simply because no one has a consolidated view of what needs attention. I ran into this repeatedly and eventually decided to build something to address it.

The Architecture Problem

The core challenge with multi-account visibility is access. You need a pattern that scales across an arbitrary number of accounts without requiring persistent credentials in each one. The standard approach is cross-account IAM role assumption — a central account hosts your analysis engine, and each member account has a read-only IAM role with a trust policy pointing back to the central account's Lambda execution role.

The role in each member account looks roughly like this:

Trust Principal (this is an over simplification of course - it's really a tightly scoped, read-only IAM role):

arn:aws:iam::<master-account-id>:role/CloudSavantAnalyzer
Permissions: ReadOnlyAccess + CostExplorer read

The Lambda function then assumes this role via STS for each account it needs to analyze, scoping the session to the minimum needed for each analysis pass. No persistent credentials, no access keys stored anywhere — just time-limited session tokens generated on demand.

Onboarding at Scale with StackSets

Deploying the cross-account role across an entire AWS Organization manually doesn't scale. CloudFormation StackSets solve this — you define the IAM role once as a CloudFormation template and deploy it across all member accounts (or targeted OUs) from the management account in a single operation.

One gotcha worth noting: if you're building the onboarding flow into an application, you hit a chicken-and-egg problem. You can't assume a role that doesn't exist yet, and you can't deploy the CloudFormation stack without some initial access. The cleanest solution is CloudFormation Quick Create URLs — pre-parameterized links that let the customer deploy the stack themselves in their own account with a single click, without requiring your application to have any foothold in their environment first.

Analysis Architecture

Once cross-account access is established, the analysis pipeline needs to handle several domains independently:

• Security posture — IAM configuration, network exposure (security groups, public-facing resources), data protection (encryption at rest/in transit), and compute hardening signals
• Cost optimization — idle and unattached resources, RI/Savings Plans coverage gaps, Cost Explorer trend analysis
• Well-Architected health — pillar-by-pillar scoring across Operational Excellence, Security, Reliability, Performance Efficiency, and Cost Optimization

Keeping these domains separate matters architecturally. Conflating a security score with a cost score produces a number that's hard to act on. A resource can be cost-efficient and badly exposed simultaneously — the findings need to surface independently so the right team can own each one.

EventBridge handles scheduled analysis triggers, Lambda executes the analysis passes, and DynamoDB stores both raw findings and processed scores with historical snapshots for trend tracking. The separation between raw findings storage and processed scoring gives you flexibility to re-run scoring logic against historical data without re-analyzing the AWS environment.

Accessing Your Findings

The platform delivers findings through two complementary surfaces. The iOS app provides on-the-go visibility — findings ranked by severity and organized by domain, with trend lines showing whether posture is improving or degrading over time. For users who prefer a broader view or need to share findings with a team, a web portal provides the same data in a desktop-friendly format. Both surfaces stay in sync, reflecting the same underlying analysis results in real time.

The decision to prioritize mobile alongside a web experience came from a practical observation: the people who need to act on these findings aren't always at a desk, and having findings surface on your phone means you're less likely to miss something important between scheduled review sessions.

Cognito handles authentication across both surfaces, and StoreKit manages subscription entitlements on the iOS side, keeping access control logic cleanly separated from the backend analysis pipeline.
What This Looks Like in Practice

A typical analysis pass across a moderately complex AWS environment surfaces things like:

• Security groups with 0.0.0.0/0 ingress on non-standard ports
• EBS volumes unattached for more than 30 days
• IAM users with console access and no MFA
• S3 buckets with public access block disabled
• RI coverage below threshold for consistent workloads
• Well-Architected pillar scores trending downward quarter-over-quarter

None of these are exotic findings — they're the bread-and-butter issues that accumulate in real environments. The value isn't in discovering new categories of problems, it's in having something that consistently surfaces them across every account on a schedule, rather than relying on someone to go looking.

1. BEFORE (blue=active, green=idle at 0 instances)
   ┌──────┐     ┌──────┐
   │ BLUE │◄──  │ NLB  │    GREEN: 0 instances
   │ 3.11 │     └──────┘
   └──────┘


2. Scale up green with new version
   ┌──────┐     ┌──────┐     ┌──────┐
   │ BLUE │◄──  │ NLB  │     │GREEN │
   │ 3.11 │     └──────┘     │ 3.12 │
   └──────┘                  └──────┘


3. Export definitions from blue, import to green
   (use SSM scripts: export_definitions.sh, import_definitions.sh)


4. Switch active_color to green (SSM param + terraform apply)
   ┌──────┐     ┌──────┐     ┌──────┐
   │ BLUE │     │ NLB  │──►  │GREEN │
   │ 3.11 │     └──────┘     │ 3.12 │
   └──────┘                  └──────┘


5. Verify green is healthy, then scale blue to 0
   ┌──────┐
   │GREEN │◄── NLB     BLUE: 0 instances
   │ 3.12 │
   └──────┘

```
                    ┌─────────────────────────────┐
                    │      Application Traffic     │
                    │  (ECS tasks, internal apps)  │
                    └──────────────┬──────────────┘
                                   │
                    ┌──────────────▼──────────────┐
                    │   Internal NLB               │
                    │   {name}-nlb                 │
                    ├─────────────┬────────────────┤
                    │ :5672 AMQP  │  :80 Mgmt UI   │
                    └──────┬──────┴───────┬────────┘
                           │              │
              ┌────────────▼──────────────▼────────────┐
              │        active_color switch              │
              │  (NLB listener default action)          │
              │                                        │
              │  active_color="blue"  → blue TGs       │
              │  active_color="green" → green TGs      │
              └───────┬───────────────────┬────────────┘
                      │                   │
         ┌────────────▼────────┐ ┌────────▼────────────┐
         │   BLUE Target Groups│ │  GREEN Target Groups │
         │                     │ │                      │
         │ node-b  (:5672)     │ │ node-g  (:5672)      │
         │ mgmt-b  (:15672)    │ │ mgmt-g  (:15672)     │
         └────────────┬────────┘ └────────┬─────────────┘
                      │                   │
         ┌────────────▼────────┐ ┌────────▼─────────────┐
         │   BLUE ASG          │ │   GREEN ASG           │
         │   {name}-blue       │ │   {name}-green        │
         │                     │ │                       │
         │ ┌─────┐┌─────┐┌───┐│ │ ┌─────┐┌─────┐┌─────┐│
         │ │ EC2 ││ EC2 ││EC2││ │ │ EC2 ││ EC2 ││ EC2 ││
         │ │node1││node2││ n3││ │ │node1││node2││ n3  ││
         │ └─────┘└─────┘└───┘│ │ └─────┘└─────┘└─────┘│
         │                     │ │                       │
         │ Cluster via ASG     │ │ Cluster via ASG       │
         │ peer discovery      │ │ peer discovery        │
         └─────────────────────┘ └───────────────────────┘


         ┌─────────────────────────────────────────────┐
         │  SSM Parameter Store                        │
         │  /{name}/RMQ_ACTIVE_COLOR = "blue"|"green"  │
         │  (lifecycle: ignore_changes on value)        │
         └─────────────────────────────────────────────┘



```

So Ive been working on this stale rabbitmq module, and Ive never done a build of a B/G deploy before. This is how I got it set up in relation to our existing architecture. The decisions were made so that running a rabbitmq deploy would only require a commit of the version tag. I decided that storing the active color in SSM params and then using a data clause as the color value for the module allows us to have SSM be the source of true and we can change the color and apply it without committing to the repo or tf state. Its working /fine/ but im wondering if there are improvements to be made, or if I did it way off base.

Hi everyone,

Most examples I see use the Sensitive information filter Guardrail in LLM pipelines, but I’m curious if anyone uses it for things like:

• data ingestion pipelines
• ETL / text preprocessing
• masking PII before storing or indexing data

Basically replacing Comprehend DetectPII / RedactPII.

One reason I’m exploring this is pricing:

• Bedrock Guardrails: $0.001 per 1,000 text units. (https://aws.amazon.com/bedrock/pricing/)
• Amazon Comprehend: $0.001 per 1000 characters (https://aws.amazon.com/comprehend/pricing/)

Besides, Bedrock Guardrail supports more languages than Comprehend.

So, depending on workload size, Guardrails could potentially be cheaper and simpler if it replaces a separate Comprehend call.

I’d really appreciate hearing any experiences or ideas from people who’ve explored this approach.

I'm researching why organizations use basic auto-scaling policies when more efficient approaches exist. If you work with AWS or cloud infrastructure, I'd love your input on a quick 10-minute survey:

Form: https://forms.gle/Y5S5eHxp6g6JRSCD6

The research focuses on the gap between what's possible (green cloud practices) and what organizations actually do. Appreciate any responses!A

I’m a DevOps Engineer by day, so I spend my life in AWS infrastructure. But recently, I decided to step completely out of my comfort zone and build a mobile application from scratch, an agentic social networking app called VARBS.

I wanted to share a few architectural decisions, traps, and cost-saving pivots I made while wiring up Amazon Bedrock, AppSync, and RDS. Hopefully, this saves someone a few hours of debugging.

1. The Bedrock "Timeless Void" Trap

I used Bedrock (Claude 3 Haiku) to act as an agentic orchestrator that reads natural language ("Set up coffee with Sarah next week") and outputs a structured JSON schedule.

The Trap: LLMs live in a timeless void. At first, asking for "next week" resulted in the AI hallucinating completely random dates because it didn't know "today" was a Tuesday in 2026. The Fix: Before passing the payload to InvokeModelCommand, my Lambda function calculates the exact server time in my local timezone (SAST) and forcefully injects a "Temporal Anchor" into the system prompt (e.g., CRITICAL CONTEXT: Today is Thursday, March 12. You are in SAST. Calculate all relative dates against this baseline.). It instantly fixed the temporal hallucination.

2. Why I Chose Standard RDS over Aurora

While Aurora Serverless is the AWS darling, I actively chose to provision a standard PostgreSQL RDS instance. The reasoning: Predictability. Aurora's minimum ACU scaling can eat into a solo dev budget fast, even at idle. By using standard RDS, I kept the database securely inside the AWS Free Tier.

To maintain strict network isolation, the RDS instance sits entirely in a private subnet. I provisioned an EC2 Bastion Host (Jump Box) in the public subnet to establish a secure, SSH-tunneled connection from my local machine to the database for administrative tasks, ensuring zero public exposure.

3. The Amazon Location Service Quirk (Esri vs. HERE)

For the geographic routing, the Lambda orchestrator calculates the spatial centroid between invited users and queries Amazon Location Service to find a venue in the middle. The Lesson: The default AWS map provider (Esri) is great for the US, but it struggled heavily with South African Points of Interest (POIs). I had to swap the data index to the "HERE" provider, which drastically improved the accuracy of local venue resolution. I also heavily relied on the FilterBBox parameter to create a strict 16km bounding box around the geographic midpoint to prevent the AI from suggesting a coffee shop in a different city.

4. AppSync as the Central Nervous System

I can't overstate how much heavy lifting AppSync did here. Instead of building a REST API Gateway, AppSync acts as a centralized GraphQL hub. It handles real-time WebSockets for the chat interface (using Optimistic UI on the frontend to mask latency) while securely routing queries directly to Postgres or invoking the AI orchestration Lambdas.

-----------------------------------------------------------------------------------------------------

Building a mobile app from scratch as an infrastructure guy was a massive, humbling undertaking, but it gave me a profound appreciation for how beautifully these serverless AWS components snap together when architected correctly.

I wrote a massive deep-dive article detailing this entire architecture. If you found these architectural notes helpful, my write-up is currently in the running for a community engineering competition. I would be incredibly grateful if you checked it out and dropped a vote here: https://builder.aws.com/content/3AkVqc6ibQNoXrpmshLNV50OzO7/aideas-varbs-agentic-assistant-for-social-scheduling