<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Ron Flax</title>
    <description>The latest articles on DEV Community by Ron Flax (@ronflax).</description>
    <link>https://dev.to/ronflax</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3821126%2F48ee5786-0b72-47b0-9676-312ea6f3094d.jpg</url>
      <title>DEV Community: Ron Flax</title>
      <link>https://dev.to/ronflax</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/ronflax"/>
    <language>en</language>
    <item>
      <title>Cloud Savant: Turning AWS Cloud Signals into Clear Next Steps</title>
      <dc:creator>Ron Flax</dc:creator>
      <pubDate>Thu, 11 Jun 2026 19:07:21 +0000</pubDate>
      <link>https://dev.to/ronflax/cloud-savant-turning-aws-cloud-signals-into-clear-next-steps-3hi4</link>
      <guid>https://dev.to/ronflax/cloud-savant-turning-aws-cloud-signals-into-clear-next-steps-3hi4</guid>
      <description>&lt;p&gt;AWS teams have no shortage of dashboards.&lt;/p&gt;

&lt;p&gt;Cost Explorer. Security Hub. Compute Optimizer. Trusted Advisor. Well-Architected reviews. CloudWatch. Organization views. Budget alerts. Resource inventory. The list keeps growing.&lt;/p&gt;

&lt;p&gt;The problem is not a lack of data.&lt;/p&gt;

&lt;p&gt;The problem is that AWS cost, security, reliability, and operational signals are often scattered across accounts, regions, services, and tools. That makes it hard for cloud teams to answer the questions that matter most:&lt;/p&gt;

&lt;p&gt;What changed?&lt;br&gt;
What is driving spend?&lt;br&gt;
Where are the risks?&lt;br&gt;
What should we fix first?&lt;br&gt;
And how do we explain the next step clearly enough that someone can act on it?&lt;/p&gt;

&lt;p&gt;That is the problem &lt;a href="https://cloudsavant.info" rel="noopener noreferrer"&gt;Cloud Savant&lt;/a&gt; was built to solve.&lt;/p&gt;

&lt;p&gt;Cloud Savant gives AWS admins, cloud engineers, FinOps teams, and technical leaders a clearer way to understand AWS account health from a mobile-first experience. It combines AWS cost visibility, forecasting, usage optimization, security posture, and Well-Architected-style health signals into prioritized findings that are designed to be acted on — not ignored.&lt;/p&gt;

&lt;p&gt;Instead of forcing teams to dig through disconnected dashboards, Cloud Savant focuses on the next best action.&lt;/p&gt;

&lt;h2&gt;
  
  
  From visibility to action
&lt;/h2&gt;

&lt;p&gt;Most AWS environments accumulate complexity over time.&lt;/p&gt;

&lt;p&gt;Unused resources sit quietly. Spend trends move before anyone notices. Security drift happens across accounts. Reliability gaps are easy to miss until they become operational issues. Well-Architected concerns may be known in theory, but not consistently reviewed or prioritized.&lt;/p&gt;

&lt;p&gt;Cloud Savant helps organize those signals into clear findings across three major areas:&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Health&lt;/strong&gt; — Well-Architected trends, pillar scoring, and account-level cloud posture.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Security&lt;/strong&gt; — Risky configurations, exposed services, drift, and severity-based prioritization.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;FinOps&lt;/strong&gt; — Spend drivers, forecasts, savings coverage, usage optimization, and waste signals.&lt;/p&gt;

&lt;p&gt;The goal is simple: help AWS teams see where attention is needed and understand what to fix next.&lt;/p&gt;

&lt;h2&gt;
  
  
  Read-only by design
&lt;/h2&gt;

&lt;p&gt;One of the most important parts of Cloud Savant is how it connects to AWS.&lt;/p&gt;

&lt;p&gt;Cloud Savant uses a read-only CloudFormation-based onboarding process. That means customers can connect an AWS account or AWS Organization without granting the application permission to change resources.&lt;/p&gt;

&lt;p&gt;The role is designed for analysis, discovery, and visibility — not mutation.&lt;/p&gt;

&lt;p&gt;That matters because cloud teams need insight without introducing unnecessary operational risk. Cloud Savant collects summarized signals and findings, then presents those results in a way that helps teams make better decisions.&lt;/p&gt;

&lt;h2&gt;
  
  
  Built for AWS admins on the move
&lt;/h2&gt;

&lt;p&gt;Cloud issues do not always wait until someone is sitting at a desk.&lt;/p&gt;

&lt;p&gt;Cloud Savant is designed for iPhone, iPad, Android, and web-based visibility, giving teams a fast way to check cloud health, security, and cost posture wherever they are.&lt;/p&gt;

&lt;p&gt;That does not mean replacing the AWS Console or enterprise reporting systems. It means giving cloud teams a high-signal view that helps them quickly understand where to focus.&lt;/p&gt;

&lt;p&gt;For many teams, the most valuable cloud insight is not another chart.&lt;/p&gt;

&lt;p&gt;It is a clear answer to: “What needs my attention right now?”&lt;/p&gt;

&lt;h2&gt;
  
  
  Why this matters
&lt;/h2&gt;

&lt;p&gt;Cloud cost, security, and reliability are increasingly connected.&lt;/p&gt;

&lt;p&gt;A forgotten NAT Gateway may be a cost issue.&lt;br&gt;
An unattached EBS volume may be waste.&lt;br&gt;
An overly permissive security group may be risk.&lt;br&gt;
A missing backup configuration may be reliability exposure.&lt;br&gt;
A lack of tagging may weaken both governance and FinOps reporting.&lt;/p&gt;

&lt;p&gt;Cloud Savant brings these signals together so teams can move from scattered visibility to prioritized action.&lt;/p&gt;

&lt;p&gt;That is especially useful for organizations managing multiple AWS accounts, growing cloud footprints, or lean teams that need to stay ahead of waste, risk, and drift without spending hours manually correlating findings.&lt;/p&gt;

&lt;h2&gt;
  
  
  Cloud Savant in one sentence
&lt;/h2&gt;

&lt;p&gt;&lt;a href="https://cloudsavant.info" rel="noopener noreferrer"&gt;Cloud Savant&lt;/a&gt; is a mobile-first AWS cloud health, security, and FinOps application that helps teams connect read-only AWS accounts, identify prioritized findings, and understand what to fix next.&lt;/p&gt;

&lt;p&gt;Learn more at &lt;a href="https://cloudsavant.info" rel="noopener noreferrer"&gt;cloudsavant.info&lt;/a&gt;.&lt;/p&gt;

</description>
      <category>productivity</category>
      <category>security</category>
      <category>aws</category>
      <category>mobile</category>
    </item>
    <item>
      <title>Cross-Account AWS Visibility at Scale: Lessons from Building a Mobile-First Health and Cost Monitoring Platform</title>
      <dc:creator>Ron Flax</dc:creator>
      <pubDate>Fri, 13 Mar 2026 01:24:16 +0000</pubDate>
      <link>https://dev.to/ronflax/cross-account-aws-visibility-at-scale-lessons-from-building-a-mobile-first-health-and-cost-14n9</link>
      <guid>https://dev.to/ronflax/cross-account-aws-visibility-at-scale-lessons-from-building-a-mobile-first-health-and-cost-14n9</guid>
      <description>&lt;p&gt;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.&lt;/p&gt;

&lt;h2&gt;
  
  
  The Architecture Problem
&lt;/h2&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;The role in each member account looks roughly like this:&lt;/p&gt;

&lt;p&gt;Trust Principal:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;arn:aws:iam::&amp;lt;master-account-id&amp;gt;:role/CloudSavantAnalyzer
Permissions: ReadOnlyAccess + CostExplorer read
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;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.&lt;/p&gt;

&lt;h2&gt;
  
  
  Onboarding at Scale with StackSets
&lt;/h2&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;h2&gt;
  
  
  Analysis Architecture
&lt;/h2&gt;

&lt;p&gt;Once cross-account access is established, the analysis pipeline needs to handle several domains independently:&lt;/p&gt;

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

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;h2&gt;
  
  
  Accessing Your Findings
&lt;/h2&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;br&gt;
What This Looks Like in Practice&lt;/p&gt;

&lt;p&gt;A typical analysis pass across a moderately complex AWS environment surfaces things like:&lt;/p&gt;

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

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fzbw6386ufk7kshfzu1gx.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fzbw6386ufk7kshfzu1gx.png" alt=" " width="800" height="1731"&gt;&lt;/a&gt;If any of this architecture approach is useful for your own tooling, happy to go deeper on any of the patterns described. If you'd rather just use the finished product, &lt;strong&gt;Cloud Savant&lt;/strong&gt; is available on the iOS App Store, with a companion web portal for desktop access.&lt;/p&gt;

</description>
      <category>aws</category>
      <category>ios</category>
    </item>
  </channel>
</rss>
