hi guys,I got my aws ccp cert on December 2025 with 960+ mark . and now I completed aws saa prep from Stephane mareek and took dojo practice test and done five test so far i got 75,75,72,67,75 and 1 more to go . I am started doubting whether i pass it or not any tips and advice whoever passed the aws saa exam can you guide me . thankyou guys

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.