CommPulse

I wanted to test one specific path: Amazon Bedrock AgentCore (AWS) | +-- MCP --> live exchange-rate tool | +-- A2A v1.0 --> Microsoft Foundry hosted agent (Azure) On July 29, 2026, that path worked end to end. An AgentCore-hosted Strands coordinator called a Microsoft Foundry agent over A2A v1.0, authenticated with Microsoft Entra, and compared the reply with an independent MCP conversion. For the smoke case, both sides converted 100 USD to EUR using a rate of 0.87873 and returned 87.87300 . The deterministic comparator reported zero relative difference and no warnings. This article shows how to run that demo and documents what failed on the way. The code is in xbill9/bedrock-foundry-a2a-currency . What the demo measures This is not intended to be a currency chatbot. Currency conversion gives the demo a small domain with exact arithmetic, a public data source, and answers that are easy to compare. The coordinator supports three modes: Mode Path mcp_only AgentCore calls the exchange-rate MCP tool a2a_only AgentCore delegates to the Foundry agent over A2A verified Both calls run concurrently and deterministic code compares the results The LLM selects and explains the workflow. It does not calculate the conversion or decide whether two amounts agree. Python Decimal does that: difference = abs ( primary . converted_amount - verifier . converted_amount ) relative_difference = difference / abs ( primary . converted_amount ) agreed = relative_difference <= Decimal ( " 0.005 " ) If the two sources disagree, the coordinator returns both quotes. It never asks a model which number looks better. Architecture CLI / test runner | | SigV4 v Amazon Bedrock AgentCore Runtime, us-east-1 Strands Agents coordinator, Amazon Nova Micro | +-- MCP stdio | | | +-- Frankfurter daily reference rates | +-- AWS Secrets Manager | | | +-- Entra service-principal credential | +-- Entra OAuth client-credentials exchange | +-- A2A v1.0 JSON-RPC | v Microsoft Foundry hosted agent, East US 2 Microsoft Agent Framework, gpt-5-mini | +-- MCP stdio | +-- Frankfurter daily reference rates The two agents use the same rate provider deliberately. This smoke test is about transport, authentication, tool use, and cross-framework agreement, not about reconciling different market feeds. Prerequisites You need: Python 3.11 or later Node.js 20 or later AWS CLI v2, authenticated to the target account Azure CLI 2.80 or later Azure Developer CLI ( azd ) with the Foundry agent extension permission to deploy AgentCore resources in AWS permission to create a Foundry project and hosted agent in Azure Install the AgentCore CLI and authenticate: npm install -g @aws/agentcore aws sts get-caller-identity az login azd auth login The Azure identity performing the deployment needs Foundry Project Manager on the Foundry project. Azure management-plane Owner or Contributor alone does not grant the data-plane agents/write action. Run the credential-free local checks Clone the repository and install into the current user's Python environment. The related benchmark repositories expose the same console-script names, so invoking modules from the intended checkout avoids accidentally running a sibling clone. git clone https://github.com/xbill9/bedrock-foundry-a2a-currency.git cd bedrock-foundry-a2a-currency pip3 install --user --break-system-packages -e ".[dev]" pip3 install --user --break-system-packages -r requirements.txt PYTHONPATH = . python3 -m pytest -q The July 29 build passed 66 tests. These cover the Decimal domain logic, MCP subprocess transport, failure policies, Entra credential parsing, and a Foundry-shaped authenticated A2A v1.0 server. Try the three modes with deterministic fixture rates: PYTHONPATH = . python3 -m coordinator.cli \ 100 USD EUR --mode mcp_only PYTHONPATH = . python3 -m coordinator.cli \ 100 USD EUR --mode a2a_only PYTHONPATH = . python3 -m coordinator.cli \ 100 USD EUR --mode verified --transport mcp-stdio --json Fixture results prove orchestration and protocol behavior. They are not financial quotes. Deploy the Microsoft Foundry peer The repository's deployment script packages the Foundry agent, provisions the project and gpt-5-mini model deployment, deploys the hosted agent, enables incoming A2A, and reads back the authenticated v1.0 agent card: ./infra/deploy_foundry_peer.sh The script prints an endpoint shaped like: https://<account>.services.ai.azure.com/api/projects/<project>/agents/currency-a2a-agent/endpoint/protocols/a2a Save it for the next steps: export CURRENCY_FOUNDRY_A2A_ENDPOINT = "https://<account>.services.ai.azure.com/api/projects/<project>/agents/currency-a2a-agent/endpoint/protocols/a2a" The card is not public. Foundry serves it at agentCard/v1.0 , and it requires an Entra bearer token just like the message endpoint. Before involving AWS, test the real Foundry peer from the local coordinator. The local path uses your ambient Azure CLI credential: CURRENCY_RATE_PROVIDER = frankfurter \ CURRENCY_FOUNDRY_A2A_ENDPOINT = " $CURRENCY_FOUNDRY_A2A_ENDPOINT " \ PYTHONPATH = . python3 -m coordinator.cli \ 100 USD EUR \ --mode verified \ --transport mcp-stdio \ --a2a-peer foundry \ --timeout-seconds 90 \ --json Expect mcp-stdio:frankfurter-live as the primary source and hosted-foundry-a2a as the verifier. Give the AWS runtime an Azure identity An AgentCore runtime has an AWS IAM role, but it has no Azure identity. Foundry does not accept an API key for incoming A2A. The demo uses a dedicated Entra service principal with Foundry Agent Consumer on only the Foundry project. Create that identity using your organization's normal process, grant the project role, and place the client secret in a protected local file. Then run: export AZURE_TENANT_ID = "<tenant-id>" export AZURE_CLIENT_ID = "<application-client-id>" export AZURE_CLIENT_SECRET_FILE = "/secure/path/to/client-secret" export CURRENCY_AZURE_SECRET_ID = "bedrock-foundry-a2a/azure-service-principal" ./infra/configure_azure_secret.sh That script stores a JSON credential in AWS Secrets Manager without putting the secret on the command line. It also prints the narrow IAM policy needed by the generated AgentCore execution role: { "Effect" : "Allow" , "Action" : "secretsmanager:GetSecretValue" , "Resource" : "<the-one-secret-arn>" } Do not place the client secret in agentcore.json . Runtime environment variables are visible through the control plane. Deploy the AgentCore coordinator Configure the AWS target and deploy once: ./infra/configure_aws_target.sh ./infra/sync_app.sh agentcore deploy -y agentcore status Grant the generated execution role the one-secret policy printed by configure_azure_secret.sh . Now point the runtime at Foundry and redeploy: export CURRENCY_AZURE_SECRET_ID = "bedrock-foundry-a2a/azure-service-principal" export CURRENCY_FOUNDRY_A2A_ENDPOINT = "https://<account>.services.ai.azure.com/api/projects/<project>/agents/currency-a2a-agent/endpoint/protocols/a2a" ./infra/point_coordinator_at_foundry.sh The script updates the local, account-specific runtime configuration, syncs the bundle, deploys it, checks status, and runs a smoke request. Keep the generated endpoint and account configuration out of Git. Run each hosted mode explicitly: agentcore invoke "Convert 100 USD to EUR in mcp_only mode." agentcore invoke "Convert 100 USD to EUR in a2a_only mode." agentcore invoke "Convert 100 USD to EUR in verified mode." Observed results These are the hosted smoke observations from July 29, 2026. They are not a latency distribution and should not be read as a platform benchmark. Mode Observed source Result Observed tool latency mcp_only mcp-stdio:frankfurter-live rate 0.87873 , amount 87.87300 about 4.2 s a2a_only hosted-foundry-a2a rate 0.87873 , amount 87.87300 about 18.8 s verified both sources zero relative difference, no warnings MCP about 3.1 s; A2A about 18.1 s The verified path runs both legs concurrently, so its tool time is dominated by the slower Foundry call rather than the sum of both calls. The important result is functional: AWS SigV4 invocation, Bedrock tool use, MCP stdio, AWS Secrets Manager, an Entra client-credentials exchange, Foundry agent-card discovery, and A2A v1.0 JSON-RPC all completed in one request. The full 38-case AWS-to-Foundry matrix, repeated warm/cold distributions, token use, and cloud cost have not been measured yet. Failures found while building it Foundry deployment returned 403 The Azure resource deployment succeeded, but hosted-agent creation failed with: Identity does not have permissions for Microsoft.CognitiveServices/accounts/AIServices/agents/write Assigning Foundry Project Manager at the project scope fixed it. Azure Owner did not imply this Foundry data-plane permission. The Foundry container never became ready The manifest passed an unset AZURE_AI_MODEL_DEPLOYMENT_NAME template value. The container exited with: ValueError: Model is required The model deployment is owned by the same manifest, so the fix was to set its known deployment name, gpt-5-mini , explicitly. The AgentCore A2A leg lacked aiohttp azure.identity.aio uses Azure Core's optional aiohttp transport. The first hosted invocation failed before token acquisition because aiohttp was not declared in the CodeZip application's own dependency manifest. Adding and locking aiohttp==3.13.3 in app/CurrencyCoordinator/pyproject.toml fixed the deployed runtime. Adding it only to the repository-root requirements file was not enough; CodeZip resolves the application bundle independently. Each of these interoperability failures now has a regression test or a manifest assertion. What A2A added For this small conversion, MCP alone was faster and sufficient. A2A added an independently hosted implementation, a separate model and framework, another tool invocation, and a distinct failure boundary. It also added real engineering work: cross-cloud identity and least-privilege role assignment authenticated agent-card discovery protocol-version pinning another cold-start boundary more dependency and deployment surfaces That overhead is worthwhile only if independent execution, failover, or cross-framework portability matters to the application. The demo now gives us a reproducible way to measure that tradeoff instead of treating an HTTP 200 as proof of interoperability.

The first time a Kyverno CLI test lied to me, I did not know it was lying. My suite went green. My PR merged. And the rule that was supposed to block a suspiciously permissive Deployment simply had not run against it in a cluster, because the policy referenced a GlobalContextEntry lookup and the CLI had no live Kubernetes API to resolve it against. So the engine did what the engine had always done in that spot: it skipped, and kyverno apply did not tell me. A CNCF blog post from July 22 walks through how a Kyverno contributor finally taught the CLI to fake production convincingly enough that offline tests for policies with those lookups stop lying. The gap the CLI had been papering over The post frames the underlying problem as an architectural mismatch. Kyverno's policy engine wants to talk to a live informer cache: unstructured resources wrapped in []interface{} slices, in exactly the shape a running controller receives them. In kyverno apply mode there was no informer cache, and any policy that reached for one, most commonly through GlobalContextEntry , would either panic outright or silently skip the rule. The tests kept passing. The rule kept not running. If you have ever added a lookup to a validating policy and then wondered why your local test never exercised it, this is the shape of the bug you were living with. The disguise, not a rewrite The author's move here is that the fix does not belong in the engine. The engine already knows how to talk to a live cache. What was missing was a translation layer between test data on disk and the shape the engine expects in memory. So they wrote one. Mock resources are decoded through runtime.RawExtension inside a new resolveResourcesMockData function, packed into the same []interface{} slices a real informer would return, and fronted by an in-memory fake dynamic client that stands in for the API server during kyverno apply . Nothing in the engine changes. It thinks it is talking to a cluster. I like this shape a lot. When a test tool starts hacking the code under test to be more testable, the tests get faster and the production behaviour starts to drift. This goes the other way. What lands in your test manifests The post lists the new fields your Kyverno test YAML can now carry: apiCallResponses , for canned responses to arbitrary API calls a policy makes. globalContextEntries , for the exact class of lookup that used to force a skip. resources and resourceFiles , for the mock inventory the engine reads through the fake client. jsonPayloads , an array of payloads for tests that need to fan out over multiple inputs. generatedResources , for verifying the multiple objects a generate policy actually produces. Two new CLI flags widen the surface further: --http-payload and --envoy-payload let you drive tests with the payload shapes Kyverno already handles at runtime. And CleanupPolicy and ClusterCleanupPolicy are now testable in dry-run mode, which closes a lifecycle gap the CLI had been carrying for a while. Why this matters at PR time This is about tests that mean something. A CI stage that runs your Kyverno policies against representative resources and either fails your PR or does not, without needing a live cluster or a kind sidecar, is the difference between finding out from your editor and finding out from the platform team next Wednesday. Every offline gate that quietly stopped running was a foot-gun. Closing that class of foot-gun is worth more than any raw-speed improvement I can remember shipping in this space. The honest rough edges A mock is still a mock. What the CLI now models faithfully is what the engine sees, not what a busy cluster actually does. Admission chain ordering, races between generate policies and their targets, and quota interactions that only bite under real controller latency are not in scope for this. You still want a smoke test in a real (probably ephemeral) cluster before you flip a policy to enforce. The other rough edge is that your test manifests get busier. Any fixture that used to pass by not exercising a lookup now has to declare the context that lookup would have found. That is more code to maintain, in exchange for tests that tell the truth. What I am watching next Whether the "fake the informer cache, do not touch the engine" pattern spreads. OPA/Gatekeeper has its own unit-test story built around conftest and Rego fixtures, and the trade-offs it makes for offline testing are different. If admission-control tooling across the ecosystem converges on standing up an in-memory API shape rather than skipping past the interesting rules, the meaning of "unit-testable policy" quietly changes underneath us. I would take that quiet change over another benchmark chart any day.

Hi everyone, so we're looking to better manage our AI spend across multiple dev teams mainly on how to deal with the fluctuating and unpredictable cost of it all. We've already set team / project specific API keys so we can track spend by project, so now I'm just looking for ways to manage the cost itself as a whole. I looked into LLM routers / gateways, mainly from seeing the Ramp Router announcement and it looked interesting to me from a cost cutting perspective. But I have 0 experience in using LLM routers so would love to hear from you guys. I'm open to other suggestions too of course, thanks! submitted by /u/Dangerous_End8856 [link] [comments]

I only have two VM's. I can see in Billing -> Reports I am getting charged $2/day for Persistent Disk. But I can't tell which VM is accounting for most of that charge. submitted by /u/imitation_squash_pro to r/googlecloud [link] [comments]

I know this is obsessive. That is the point. For time, my definition of a clean Windows installation was simple: Create an official Microsoft installation USB. Boot from it. Delete every partition. Install Windows. Sign in with a Microsoft account. Install Windows and Microsoft Store updates. Remove the applications I did not need. Install the drivers from my laptop manufacturer. Apply all my personal settings. Windows was clean, updated, and ready. Or at least, that was what I thought. The standard clean installation was not clean enough The first problem was driver installation. As soon as Windows connected to the internet, Windows Update started installing drivers automatically. After that, I installed the official driver packages from my laptop manufacturer’s website. This meant Windows could install one driver first, and then the manufacturer’s installer could install another version over it. Sometimes everything worked, but the process did not feel controlled. Windows Update also tried to install many updates, drivers, and Microsoft Store components simultaneously. This occasionally produced failed updates, retries, and unnecessary confusion. There was another issue: removing applications after they had already been installed did not feel truly clean. The applications had already been registered, initialized, and possibly updated. Uninstalling them afterward was not the same as preventing them from being installed in the first place. Improvement 1: Complete the first boot without internet My next method was: Install Windows → Complete OOBE using a local account → Enter the desktop without internet → Install the official laptop drivers from USB → Restart → Connect to Wi-Fi → Install Windows and Store updates → Remove unwanted applications → Apply my settings This was much better. Windows Update could not install random drivers before I installed the correct manufacturer drivers. It felt almost perfect. But it still was not perfect. When I finally connected to the internet, Windows still had to process a large cumulative update, smaller updates, driver checks, security updates, and Store updates at the same time. There were still occasional update errors and retries. Improvement 2: Install the large cumulative update offline I decided to integrate the latest large cumulative update into Windows before connecting the computer to the internet. The idea was simple: Install the large update offline → Boot Windows → Connect to the internet later → Download only the smaller remaining updates This significantly reduced the work Windows Update had to perform after the first boot. Instead of downloading and processing a massive cumulative update alongside everything else, Windows only needed the smaller updates released afterward. The process became faster, more predictable, and less likely to produce errors. But I still had two problems: Unwanted applications were being installed before I removed them. Manufacturer driver packages contained drivers for hardware my laptop did not actually have. Improvement 3: Extract and select the exact drivers Many laptop manufacturers provide one driver package that supports several possible hardware configurations. For example, a Wi-Fi driver package may include: Intel drivers Realtek drivers Qualcomm drivers MediaTek drivers My laptop only uses one of them, but the complete package may copy or stage drivers for several supported configurations. That did not feel precise enough. I started extracting the manufacturer’s .exe driver packages and examining the files inside them. I identified the exact hardware installed in my machine and selected only the appropriate drivers. However, I also learned that not every driver should be treated the same way. Some drivers are primarily standard INF-based packages and work well with offline DISM injection. Other packages are more complex and may include: Multiple dependent drivers Services Registry configuration Software components Firmware utilities Control panels Microsoft Store or UWP companion applications Custom installation logic Graphics, audio, and some Intel platform or firmware packages can fall into this category. For those packages, blindly extracting every INF file and injecting everything is not necessarily correct. I therefore inspected each driver package and divided them into two groups: Safe standard drivers → Inject offline with DISM Complex software-assisted drivers → Install after the first desktop boot using the official installer This gave me control without breaking the functionality supplied by the manufacturer. Improvement 4: Inject drivers before Windows boots Even when the correct driver was installed, installing it after reaching the desktop could temporarily restart or reinitialize the related device. For example, installing a network driver can cause the adapter to disappear and reappear. That is completely normal, but I wanted the hardware to be ready from the first real Windows boot. I therefore started servicing install.wim offline with DISM. My early method was: Copy install.wim from the official Microsoft ISO → Mount the WIM → Inject the safe drivers → Inject the cumulative update → Modify the image → Commit and unmount it → Use the modified image for installation DISM is already part of Windows, so the entire servicing stage could be performed using Microsoft’s own deployment tools. At this point, the installation already had the correct core drivers and the largest Windows update before it ever reached the desktop. Improvement 5: Prevent unwanted Store applications from being provisioned Microsoft Store applications are commonly provisioned in the Windows image. Provisioned applications are prepared so that Windows can register them when a new user account is created. Instead of allowing these applications to register and then uninstalling them afterward, I removed the unwanted provisioned packages from the offline image using DISM. First, I listed the provisioned packages: dism /Image:W:\ /Get-ProvisionedAppxPackages Then, for each package I did not want: dism /Image:W:\ /Remove-ProvisionedAppxPackage /PackageName:<exact-package-name> This meant the applications were removed before my user profile was created. I did not remove essential components such as Microsoft Store or Desktop App Installer. I only removed applications I had already decided I would never use. This felt much cleaner than uninstalling them after the first login. Improvement 6: Prevent OneDrive Setup from starting for the new user OneDrive was a separate case. It was not simply a provisioned Store application in the same way as the other packages. Windows contained a startup entry that launched OneDrive Setup when the user profile was created. I loaded the offline default-user registry hive and removed the OneDrive Setup startup entry. That stopped OneDrive Setup from automatically running when the first user account was created. Again, the objective was not to install something, allow it to initialize, and then remove it. The objective was to prevent the unwanted setup process from starting at all. Improvement 7: Apply my settings before the first login I then realized that many settings could also be applied offline. Instead of entering the desktop and manually changing everything, I loaded the offline registry hives and configured settings such as: Dark application mode Dark Windows interface mode Windows Spotlight policies News and Interests Delivery Optimization Fast Startup OneDrive startup behavior Other system and default-user preferences The settings were therefore present when Windows created the user profile. The system started in the state I wanted instead of starting with default settings and being changed afterward. Everything was now: Official Controlled Repeatable Performed with built-in Windows deployment tools Completed before Windows created its first normal user session But I still was not satisfied. The normal USB installer still hid too much of the process Even with a customized install.wim, the normal Windows Setup interface was still performing many operations automatically. It created partitions, applied the image, configured the boot files, and prepared recovery behind the scenes. That is convenient for normal users. For my perfection-obsessed installation, however, I wanted to know and control exactly what was happening. So I stopped using the normal graphical installation process. I moved the entire deployment into WinRE. The final method: Build Windows manually from WinRE WinRE is a small recovery environment that boots into RAM and provides access to tools such as DiskPart, DISM, BCDBoot, Registry Editor, and ReAgentC. I placed the official Microsoft install.wim, updates, drivers, answer file, and recovery image on a separate drive. Then I booted into WinRE and manually built the complete Windows disk. Step 1: Create the GPT partition structure manually I selected the correct target disk, deleted the existing partition structure, and manually created: EFI System Partition — 300 MB FAT32 Microsoft Reserved Partition — 16 MB Windows partition Windows Recovery partition — 2048 MB This gave me full control over the partition sizes, order, and purpose. The EFI, Windows, and Recovery partitions were assigned temporary drive letters during deployment. Step 2: Apply the official Windows image Instead of running Windows Setup, I applied the Microsoft image directly: dism /Apply-Image /ImageFile:C:\install.wim /Index:1 /ApplyDir:W:\ At this stage, W: contained a fresh Windows installation that had never booted. Step 3: Service the offline installation While Windows was still completely offline, I: Injected the compatible drivers Installed the latest large cumulative update Removed unwanted provisioned applications Modified the default-user and system registry hives Disabled the OneDrive Setup startup entry Applied my preferred Windows settings Added the unattended configuration Cleaned the component store For the final component cleanup, I used: dism /Image:W:\ /Cleanup-Image /StartComponentCleanup /ResetBase I only used /ResetBase after finalizing the update state because it prevents the integrated updates from being uninstalled later. Step 4: Configure OOBE officially through Panther A recent Windows 10 update complicated the local-account path during OOBE, and Windows 11 also strongly encourages online account creation. There are command-line workarounds that restart or interrupt OOBE, but that did not feel clean to me. Instead, I used a Windows answer file in the Panther directory: W:\Windows\Panther\unattend.xml The answer file configured items such as: Language Keyboard layouts Time zone Local user account OOBE behavior Automatic initial login This is part of Windows Setup’s own unattended-deployment system. It did not require third-party bypass tools or interrupting OOBE with an improvised restart. Any plaintext password contained in the answer file should be removed after Setup is complete. Windows 11 builds can behave differently, so an answer file should be validated against the specific build being deployed. Step 5: Create the UEFI boot files manually I generated the boot environment directly from the applied Windows installation: W:\Windows\System32\bcdboot.exe W:\Windows /s S: /f UEFI This created the UEFI boot files on the EFI System Partition. Step 6: Build and register the recovery environment I created the recovery directory, copied winre.wim, and registered it against the offline Windows installation: md R:\Recovery\WindowsRE copy /y C:\winre.wim R:\Recovery\WindowsRE\winre.wim W:\Windows\System32\reagentc.exe /setreimage /path R:\Recovery\WindowsRE /target W:\Windows I then assigned the proper recovery-partition GPT type and attributes and removed its temporary drive letter. The result was a complete disk containing: A fresh UEFI boot partition Windows A properly configured recovery environment No previous user activity No Audit Mode session No Sysprep generalization cycle The controlled first boot The offline deployment was only the first stage. For the first real boot, I still kept the laptop disconnected from the network. My sequence was: Boot Windows without internet → Complete the local OOBE process → Enter the desktop → Install the complex official driver packages → Restart → Pause Windows Update temporarily → Connect to Wi-Fi → Allow required OEM and Store components to install → Run Windows Update → Update Microsoft Store applications → Apply the remaining personal settings → Install required DirectX and Visual C++ runtimes → Restart again The complex driver packages included components that were better installed through their official installers, such as graphics, audio, and certain Intel platform packages. After connecting to the internet, official companion applications such as Dolby or Intel software could install normally. Because the large cumulative update had already been integrated offline, Windows Update only had a relatively small amount of remaining work. Because unnecessary provisioned applications had already been removed, Microsoft Store also had fewer applications to register and update. At this point, I had a complete Windows installation with: Official Microsoft Windows files Official manufacturer drivers Official NVIDIA drivers Official Microsoft updates Official Microsoft Store components My complete configuration No random third-party customization utility No unnecessary driver families No unwanted provisioned applications A working EFI partition A working WinRE partition This was finally the Windows state I wanted. But there was one final problem. Reproducing all of this again would take hours. Preserving the perfect state Once I started using Windows normally, installing random applications, testing software, and modifying files, the installation would no longer be in that carefully prepared state. I wanted to preserve it before normal use. Windows includes the older system-image backup concept, and many third-party disk-cloning tools also exist. However, I had completed the entire deployment using Windows-native tools. I did not want the final backup stage to depend on an unrelated third-party cloning application. So I returned to WinRE and used DISM again. WIM capture First, I captured the Windows partition into a WIM file: dism /Capture-Image /ImageFile:C:\Final-Windows.wim /CaptureDir:W:\ /Name:"Final Ready-to-Use Windows" /Compress:max /CheckIntegrity /Verify Because the capture was performed from WinRE, the Windows installation was offline. The WIM represented the files on the Windows partition at the exact point when I shut the system down. Restoring it later would return the Windows partition to that state. However, a WIM only captures the selected partition. It does not automatically preserve: The EFI partition The Microsoft Reserved partition The recovery partition The complete disk layout To restore a WIM to a completely empty disk, I would still need to recreate the partitions, apply the WIM, rebuild the boot files, and configure recovery again. That was not perfect enough for my objective. FFU: The complete-disk image DISM also supports Full Flash Update images. Instead of capturing only the Windows partition, an FFU captures the physical disk layout. From WinRE, I used: dism /Capture-FFU /ImageFile:C:\Final-Windows.ffu /CaptureDrive:\\.\PhysicalDrive1 /Name:"Final Perfect Windows" The FFU contains the complete disk: EFI partition MSR partition Windows partition Recovery partition Partition order Boot files Windows files Drivers Updates Applications Settings Recovery configuration Now I can boot into WinRE, erase the target disk, and apply the FFU. It recreates the complete disk structure and restores the files to the captured state. Instead of repeating hours of partitioning, servicing, driver selection, updating, and configuration, I can restore the complete prepared Windows environment in a small fraction of the time. It is effectively like returning the machine to the exact day when I finished preparing it. The WIM remains useful as a flexible Windows-partition backup. The FFU is the complete bare-metal recovery image. The final result My complete workflow became: Official Microsoft ISO → Manual GPT partitioning in WinRE → Direct DISM image application → Offline cumulative update integration → Selective offline driver injection → Offline provisioned-application removal → Offline registry customization → Official unattended OOBE configuration → Manual UEFI boot creation → Manual WinRE registration → Component-store cleanup → Controlled offline first boot → Official complex driver installation → Controlled internet connection → Remaining Windows and Store updates → Final runtimes and settings → Offline WIM capture → Complete-disk FFU capture Is this necessary for most people? Absolutely not. The normal Microsoft installer is sufficient for almost everyone. But for someone who is obsessed with understanding, controlling, and perfecting every stage of a Windows installation, this is the closest I have reached to an absolutely clean, official, and reproducible system. The best part is that I can now use Windows freely, install experimental software, and potentially break things without worrying about repeating the entire process. My final FFU image preserves the complete perfect state. I only need to restore it, and I am back where I started. Important notes Always verify the physical-disk number before using DiskPart or FFU commands. Selecting the wrong disk can destroy data. Test the FFU restoration before treating it as your only backup. FFU images are less flexible than WIM images and are best suited to the same machine, disk layout, or compatible target storage. The target disk generally needs enough capacity for the captured layout. Some driver installers should not be replaced with blind INF injection. Windows 10 and Windows 11 do not always use identical package names, updates, or unattended settings. Remove answer files containing passwords after Windows Setup completes. Keep personal files backed up separately. A system image is not a substitute for a separate data backup. I am interested in hearing how deployment specialists would improve this workflow, and whether anyone else has taken the Microsoft-native WinRE, DISM, WIM, and FFU approach this far. submitted by /u/kaidocodm to r/sysadmin [link] [comments]

submitted by /u/heldsteel7 to r/FinOps [link] [comments]

Renewal season is hitting a lot of people and I keep seeing the same pattern: the quote gets escalated before anyone has actually measured what they run. RVTools is free, read-only and takes about twenty minutes with a service account. Here is the checklist I would work through before replying to anyone. Count billed cores, not sockets. The metric moved from per-socket to per physical core. vHost gives you "# CPU" (sockets) and "Cores per CPU". Multiply, sum per site. Then apply two floors, in this order: The historical 16-core-per-socket minimum. An 8-core CPU bills as 16. The 72-core-per-product-per-order-line minimum, which went up from 16 in April 2025. The second one is the one people miss, and it lands on small sites rather than big ones. 16-host cluster, dual 32-core CPUs = 1,024 cores. Neither floor touches it. 3-host edge site, one 16-core CPU per host = 48 real cores, bills at 72. A 50% overpay. 2-host site, dual 8-core CPUs = 32 real cores, floored to 64 by the socket rule, then to 72 by the order-line rule. A 125% overpay on a box in a cupboard. Worth confirming with your reseller whether they can consolidate sites onto one order line, because that changes the answer a lot. Get it in writing. Find what you are licensing for no reason. vInfo, filter Powerstate = poweredOff, sum "In Use MiB". Powered-off VMs still occupy storage and still sit in your capacity planning. vSnapshot, anything with a date older than about 30 days. Those are a production risk as well as reclaimable space. vHealth has a built-in check for possible orphaned VMDKs and zombie files. Provisioned is not consumed, and that is the number that decides your business case. Sum CPUs in vInfo for powered-on VMs, divide by total physical cores from vHost. That is your real vCPU:pCore ratio. Do it against physical cores, not hyperthreaded logical CPUs, because licensing is physical. Then compare three storage numbers that usually get treated as one: provisioned VMDK capacity (vDisk), datastore in-use (vInfo), and guest filesystem consumed (vPartition). The gap between the first and the third is often most of your "capacity". This matters beyond the renewal. Cloud block storage bills on allocated volume size, not what the guest is using, so a thin 2TB VMDK holding 200GB becomes a 2TB bill on day one unless you shrink it first. Sizing any target on provisioned figures will make a migration look far more expensive than it actually is. Gotchas worth knowing before you start: Column names drift between RVTools versions, and older exports say MB where newer ones say MiB. Print your columns before writing any filters. RVTools is a configuration snapshot, not performance history. It cannot tell you utilisation over time. You still want around 30 days of vCenter stats and a P95 per VM before you size anything. Check vDisk for independent/persistent disk mode and RDMs. Both break most snapshot-based migration tooling. Check vMemory for ballooned and swapped. That tells you where you are already past comfortable overcommit. RVTools cannot see inside the guest, so it will not tell you where SQL Server is installed. On some estates the Windows and SQL per-core licensing delta is bigger than the hypervisor saving, and it follows you to whatever you migrate to. Use a dedicated read-only account, not an admin one, and treat the export as sensitive. It is a complete map of your estate. One framing thing. Moving to a managed vSphere offering on a hyperscaler is not an exit, it is a change of landlord. It may still be the right call if you are up against a datacentre lease deadline, but it is worth saying out loud in the writeup before someone else does. Also worth pricing honestly: "renew a smaller, cleaned-up footprint" is a legitimate option, and doing the cleanup makes every other option cheaper too. Curious what ratios other people are finding when they actually pull the numbers. The provisioned-to-consumed gap seems to be the one that surprises people most. submitted by /u/RulezZzOr to r/sysadmin [link] [comments]

submitted by /u/RnadmolyGneeraedt to r/FinOps [link] [comments]

For a small team with a few services, an enterprise checklist can become ceremony without reducing the main risks. My minimum gate would cover a tested rollback, backups with a restore exercise, health and readiness checks, bounded timeouts and retries, an alert owner, log correlation, secret ownership, and a short incident runbook. I would add load testing or multi-region recovery only when the service’s traffic and recovery target justify them. Which item has prevented a real incident for a small team, and which common checklist item has mostly created busywork? submitted by /u/UkrMalt to r/devops [link] [comments]

submitted by /u/Spiritual-Kitchen-79 to r/FinOps [link] [comments]

tldr; my coding agent refused to leak a secret after setting up the toolkit and running it through the wringer. Secrets Manager shipped a "secret safety" skill in the aws-core plugin of Agent Toolkit for AWS . The idea is that an agent can use a secret without ever seeing the plaintext. I ran it against a throwaway secret in a real account with Claude Code, then spent a while trying to get around it. Posting the findings in case it saves someone else the same trial and error. How it actually works, which is two layers not one: A PreToolUse hook that denies the tool call before it executes and hands the agent a message pointing at the safe path. A wrapper called asm-exec plus {{resolve:secretsmanager:...}} dynamic references. The agent's command holds a placeholder, asm-exec resolves it in its own process, and the plaintext never lands in the model's context. I tested ten fetch shapes against the hook. Six denied, four correctly allowed. It catches the CLI fetch, the batch fetch, structured API calls, a boto3 call buried in a script, a curl straight at the local daemon on port 2773, and an inline python3 -c one-liner. It leaves writes, unrelated calls and a plain grep alone. A few things that tripped me up: The skill usually refuses before the hook ever fires. When I just asked for the value in plain language, the agent declined on its own, cited the skill and pointed me at asm-exec . The deny message never appeared because no tool call was attempted. I only saw the hook fire when I insisted it actually run the command. The skill is what changes the agent's mind, the hook is the backstop for when it tries anyway. Hooks load at session start. Install the plugin mid-session, retry, and the secret comes back exactly as before. You have to restart the agent session. This is in the docs but it is easy to miss and it looks like the feature is broken. aws configure agent-toolkit does not install this one. That's the one-command setup for all agents, and it pulls from the skills catalog. The secret-safety skill and the hook only ship with the aws-core plugin, so if you set up via the CLI you don't get the block. I have the steps I took to get this setup in the full blog linked below. The safe path still calls GetSecretValue . It is not read-free. Your identity still needs secretsmanager:GetSecretValue , and the read still lands in CloudTrail. What changes is where the plaintext ends up, not whether the API is called. CloudTrail attribution is nicer than I expected, but not how I first assumed. Reads through the MCP endpoint show invokedBy , sourceIPAddress and userAgent all as aws-mcp.amazonaws.com , so agent reads are trivially separable from your own. The aws:CalledViaAWSMCP context key is a related but separate thing, it is what you write IAM and SCP conditions against rather than a field in the event record. The hook is shape-aware, and the boundary is sharper than the docs suggest. grep get-secret-value ./src is allowed. grep 'aws secretsmanager get-secret-value' ./src is denied, because the CLI pattern is checked before the read-only allowlist applies. Same for rg and echo . I tripped it grepping my own notes for this writeup. Stack: Claude Code on macOS, one throwaway secret with fake values in us-east-1, deleted afterward. See the full walkthrough using Claude Code here Happy to answer questions. If you find a fetch shape it misses, post it. For folks already using the toolkit, if there is something in the developer experience that could be better, tell me and I'll pass it to the team. submitted by /u/j-vogel to r/aws [link] [comments]

[ Removed by Reddit on account of violating the content policy . ] submitted by /u/hadez1999 to r/FinOps [link] [comments]

I currently manage 2 different environments: a dev server running in ec2 and an EKS environment for production server. Problem is that their setup is different, which adds extra management and makes it harder to test prod changes before deployment. I can spawn a UAT EKS for load testing and preparing for prod but it would be just too expensive. I already raised the cost concerns with EKS that this would be an expensive and unnecessary setup but the clients wanted it so I did it. Now they're complaining with cost. I'm just trying to find the best way to manage the current architecture without increasing costs too much. How would you handle this? submitted by /u/RoundCircle12 to r/devops [link] [comments]

Probably been answered else where but even AI gets it wrong (surprise surprise). Have a client with a few MS365 business licences. He wants an estimate of costs. Can find previous invoices easy enough but renewal costs has me stumped. AI says to switch off auto renew to get an estimate but no go. Can't believe giving MS a blank cheque is good biz for anyone bar MS or even legal. So how do I get an estimate from the portal? submitted by /u/mujikcom to r/sysadmin [link] [comments]

I’ve been thinking about this while working with observability systems and I’m curious how other people handle it. We have metrics, logs, traces, alerts, deployment information, etc. In theory, there should be enough information to understand what happened during an incident. But in practice, it often seems like the hard part is connecting everything. Something like: latency spike → database saturation → retries → downstream failures The individual signals are there, but figuring out that they’re all part of the same failure — and determining which event was actually the cause — still seems to require a lot of manual investigation. For people who actually operate production systems: what does your RCA process look like when there’s a serious incident? Do your current observability tools actually help you establish the causal chain, or are they primarily helping you find the relevant data? I’m particularly interested in what happens when the information is spread across multiple systems. submitted by /u/Acceptable_Duty4044 to r/devops [link] [comments]

Case ID: 178633616200405 AWS charged my debit card $600 for a transaction that does not belong to my AWS account. My normal AWS bill is about $3.40/month, and this $600 charge appears nowhere in my billing history. I opened a support case with all the transaction details, and AWS still has not meaningfully investigated it. After multiple calls, one Amazon/AWS support agent told me they could see that the charge came from another AWS account that had already been suspended. Despite that, AWS's fraud department later emailed me saying they found nothing wrong with my account, completely missing the issue. Another agent told me the $600 had already been refunded, while another told me the refund was rejected. Wise is refusing to treat the charge as unauthorized because I have legitimately used AWS before and says AWS needs to provide information about the transaction. AWS keeps claiming another department will investigate, but nothing actually happens. At this point, AWS has acknowledged that the charge came from another account, has apparently suspended that account, and still will not properly resolve or document the fraudulent $600 charge they processed against my card. The complete lack of ownership, contradictory information, and failure to investigate is unacceptable. submitted by /u/polarmass to r/aws [link] [comments]

I'm working to try and change the primary domain inside of a Google Workspace. The workspace had chromeOS devices provisioned. I opened up a support ticket with Google and they stated that I just needed to de-provision those devices, which I have now done, and that the licensing needed to be removed which they have done. The error I'm getting says: Changing your primary domain is not available for: Accounts that included the purchase of your domain when you signed up Accounts in a free trial period Accounts purchased from Google Domains G Suite legacy free edition Google Workspace for Education Google Workspace Resellers Chrome Enterprise Upgrade (Standalone, Offline) Chrome Education Upgrade (Standalone, Offline) Kiosk and Signage Upgrade (Standalone, Offline) Chrome Management Hangouts Software The issue is, I don't know that that is the *ONLY* thing that is erroring out. Support is just useless in the matter and keeps linking me the same support docs that do not answer the question. My question: How do I know that deprovisioning these devices is the 1 out of 11 things that it's erroring out about? They are saying I have to wait 24 hours, then try again, and if I get another error, to wait another 24 hours and open up a new ticket. One of the support guys responses was "All the chrome upgrades is the reason for the errors that you are receiving, It falls to this; - Chrome Enterprise Upgrade or Chrome Education Upgrade licenses purchased through an authorized partner - Standalone Chrome Enterprise Upgrade purchased through an authorized partner, Chrome Enterprise trials, and standalone Chrome Education Upgrade" Which I was pointing out, well, if it's failing for multiple reasons, why would you not be able to address those other issues now, rather than having to wait 24 hours between issue? Anyone by chance have any advice? submitted by /u/nme_ to r/sysadmin [link] [comments]

After over a decade working in software sales, along with dealing with a recent layoff, I'm seriously considering making a career switch into IT. It's something I've wanted to do for several years, but I never really had a clear idea of what the path into the industry would look like. I have some limited technical experience and have been learning Python and SQL on my own, but I wouldn't consider myself an experienced programmer. Right now, I'm particularly interested in Linux System Administration and potentially working my way toward DevOps, SRE, or Cloud Engineering down the road. I've been looking closely at Yellow Tail Tech's Linux System Administrator & DevOps Training Program. A friend of mine made a similar career switch and completed the program in 2024. He was eventually able to land a Site Reliability Operations Engineer role, so seeing someone I personally know make the transition has made me more interested in the program. I'm normally pretty skeptical of bootcamps and career-training programs, so I'm not taking the decision lightly. One thing that interests me about this program is that it's around 10 months and includes an unpaid apprenticeship, which would give me an opportunity to get some hands-on experience and potentially have something relevant to put on my resume. I actually considered joining their September cohort but decided to hold off until January so I could spend the next few months doing as much research as possible before committing. The biggest thing giving me pause is the cost. I would need to take out a loan to pay for the program, so I want to be very confident that I'm making a smart investment rather than making an impulse decision because I'm currently unemployed. I'm fully aware that completing a program doesn't guarantee a job, and I'm not expecting to go from zero experience to a six-figure DevOps job immediately. I'm prepared for the possibility that I'll need to start in an entry-level IT/Linux role and work my way up. For those who currently work in Linux, System Administration, DevOps, SRE, or related fields: Is a program like this actually worth paying for, or would you recommend going the self-study/certification route? Has anyone here completed Yellow Tail Tech's program? What was your experience? How valuable is the apprenticeship portion when trying to land that first IT job? Given my background in software sales, would you see that as an advantage, disadvantage, or mostly irrelevant when applying for technical roles? If you were in my position, what would you do over the next 6–12 months to make yourself employable? Are there specific certifications, projects, or skills you'd prioritize before spending money on a program like this? I'm not necessarily looking for someone to tell me whether I should or shouldn't do the program. I'm more interested in hearing from people who have actually made a similar career transition and what you would do differently if you were starting over. Any honest feedback, including criticism of the plan, would be greatly appreciated. submitted by /u/Cheem1014 to r/sysadmin [link] [comments]

Hello I’m 28 years old. I’m not married, I don’t have a partner. I don’t have children. I don’t have pets. I’m on my own for everything at the moment. I’m currently enrolled in an apprenticeship in Networks & Systems Administration (Sysadmin). I recently got an internship offer at Google. I’m in Belgium, so this type of opportunity, especially as a student, is very rare and hard to get here. I’m very excited about this opportunity, but there are some elements I need to seriously take into account before jumping on it: - Commute (from Monday to Friday): 245km (150 miles) per day. Leave home at 7:00AM and drive for 100 minutes, leave work at 6:00PM and drive back home for 100 minutes. That’s best case scenario, without traffic jams. Highways here often have heavy traffic jams, so honestly I’m probably looking at a 120-minute/2-hour commute for a single trip on most days. Which means I’d get home at around 8:00PM. Here, shops close at 6:00PM and supermarkets at 8:00PM. Working from home isn’t possible during the internship. - School obligations: I have class on every Saturday from 09:00AM until 4:00PM. - Transportation: No public transport reaches the workplace. I’d have to use my personal car and pay for the fuel costs. My car is from 2023 and has 7000km (4500 miles). From my calculations, I’d have to spend about 600€ ($700) per month on fuel alone. The increased wear and tear on my car means that I’ll have to get car maintenance twice per year, so I’d be spending about 400€ ($460) for car maintenance each year, instead of the usual 150-180€. The workplace is located in an area where it snows a lot during winter, so I’d have to spend about 500€ ($580) on new winter tyres the first year. - Income: The internship pays 1000€ ($1200) per month, or 12K€ ($14.4K) per year, which isn’t enough to cover all of my monthly expenses. No possible help from my family. I’d have to take about 500€ ($580) out of my savings each month to cover all of my expenses for 2 years. By my calculations, my savings can juuusssttt cover my expenses for the 2 years. I won’t have much left after that. If something happens to my car, I won’t have enough money to replace it. - Long-term and after the internship: The recruiter told me that because of my profile, and if the internship goes great, it’s highly likely that I will be offered a permanent contract after the internship. But a lot can happen in 2 years, so who really knows… Worst case, I have the experience of working for Google and it looks great on my CV. For 2 years, and maybe more, my professional life will be great, but my personal and social life will be non-existent. Is an internship at Google worth that? I value my time with my friends and my time doing sports activities a lot, I really need that to change my mind and decompress, but I also want to build a good career. I also received other internship offers from 2 other companies. These companies are a lot closer to me. I’d have to drive 15 minutes to get there. But they’re both small MSP companies and my role would be Helpdesk in a 3-people team and no access to infrastructure at all, basically just answering the phone and solving problems from a distance. But at Google, I would be part of a big team, I would be mentored by a senior employee and I would work with infrastructure every day. Google checks all of the boxes for me. Except for the fact that it’s really far away. What would you do if you were in my place? Thanks! submitted by /u/bluedorar to r/sysadmin [link] [comments]

I have been working on something around AI efficiency metrics and what a scoring system could look like to make users within our company pick a model better. The scoring is based on our own data. Not sure if its right or wrong but it gives me a starting point. https://www.linkedin.com/pulse/thought-efficiency-index-tei-experiment-measuring-ai-jason-ward-mba-gibxc?lipi=urn%3Ali%3Apage%3Ad_flagship3_messaging_conversation_detail%3BkD2D4%2FRjRSaaa%2FVNaLwE9g%3D%3D submitted by /u/DifficultyIcy454 to r/FinOps [link] [comments]