CommPulse

We have a currently CSP providing us licensing with a 10% discount over Microsoft's direct pricing, and thats fine by us. This relationship started out great with having a dedicated person we could ask licensing questions to that was fairly knowledgeable, so that was a nice perk when navigating the licenses available became a bit too much. Unfortunately we've began running into billing issues. These issues are taking far too long to work out. Our contacts have also become fairly unresponsive to our emails taking weeks to get back to us at times. This all prompts us to start looking around at options. Does anyone have any companies they currently have a good experience with? I don't really want to cold call, find a CSP that promises everything, and then puts us right back where we're at right now. We're just looking for licensing with a discount over going direct via Microsoft, this should be purely transactional so we need someone that makes it that easy. We are in the ~150 user range since I know that can make a large difference. Located west coast US. Thanks! submitted by /u/FIRE0118999881999119 to r/sysadmin [link] [comments]

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

I'm sitting here scratching my head trying to figure this one out, I've went through our group policy settings multiple times and I can't find anything I might have configured that would cause this problem. new out of the box lenovo thinkpad laptop with 25H2 preload on it from factory. works great until it is joined to the domain, as soon as it joins the domain and rebooted, subsequent logins for any domain account or local account on the machine are having issues with not being able to run any apps other than edge or file explorer and on login it's giving an error stating that your system administrator has blocked the program. when I check the logs I'm seeing DistributedCOM errors with event id 10001 for Microsoft.AADBrokerPlugin, that appear to be related to windows security core background get token task classid webaccountprovider being unavailable. I'm not sure what the heck is going on here, but I need to get it fixed before it spreads to any of our existing windows 11 machines if it was caused by a malfunctioning windows update or something else. I'm about to blow the machine away and just load a clean install of 24h2 on it, but if anyone knows how to go about fixing this I'd like to try that first before I give up. this one is a replacement laptop for an employee and he can manage for a few days with his current laptop. my google-fu skiils haven't came up with anything that has worked thus far on it. I've reset it and it runs fine again until it is joined to our domain. I did notice when I ran systeminfo from a command prompt it is reporting that App Control for Business policy is enabled and app control for business user mode policy is set to audit. Looking on another machine that is still working fine, those two settings aren't activated. I tried local group policy to turn device guard off to see if that made a difference, but it didn't. submitted by /u/doctorevil30564 to r/sysadmin [link] [comments]

I currently handle SaaS & AI procurement for client orgs and want to add FinOps to my skillset. I'm non-technical, was in sales before procurement, and have a decent grasp on financial concepts having passed CFA level I (from a previous career path I thought I would go down but didn't). I have minimal cloud knowledge, should I start with AWS CCP to understand cloud fundamentals and so better understand the scenarios FOCP questions pose later, or start with the (as I understand it) less technical FOCP for a gentler learning curve? submitted by /u/BLWHpurple to r/FinOps [link] [comments]

https://preview.redd.it/4ceym8fdealh1.png?width=1672&format=png&auto=webp&s=839cc0b352c7b923cacd02b4386bc834f48dc47d A lot of compliance work isn't spent fixing security problems. It's spent finding the evidence . Screenshots. Spreadsheets. Configuration exports. Change logs. Emails between IT, security, risk, and compliance teams. Then the cycle starts again before the next audit. For Saudi enterprises working across frameworks such as NCA ECC, SAMA, PDPL, ISO 27001, PCI DSS, SOC 2, and others, the operational burden can become enormous. We broke down a five-step approach to making compliance more continuous: Map infrastructure to relevant frameworks continuously Generate evidence automatically Detect configuration drift early Unify visibility across multi-vendor environments Use AI for policy and gap analysis—not just reporting The interesting shift is from: "We need to prepare for the audit." to: "We should already be able to prove our compliance posture." That's where AI-driven continuous monitoring could have a significant impact. Full breakdown: How to Cut Compliance Audit Effort by 90%: A Practical Framework for Saudi Enterprises For anyone working in security or compliance: what currently consumes the most time during your audit preparation? #Compliance #Cybersecurity #NCAECC #SaudiArabia #AgenticAI #GRC submitted by /u/WancloudsInc to r/FinOps [link] [comments]

We run an internal self-service platform API. Individual humans wanting CLI/scripted access this is where I'm stuck . Currently we mint a static token, show it once in the UI, and the user keeps it. Two things bother me: Authority is frozen at creation. We store the list of accounts the token may touch. If the user later loses their admin role on one of those accounts, the token keeps working. The credential outlives the entitlement. Distribution is copy-paste. It ends up in .env files, shell history, occasionally a chat message. If you've done per-request authorization lookups, what did it cost you in latency and directory load? How long do you cache, and how do you handle the lookup failing fail open or fail closed? For humans needing programmatic access, has anyone made short-lived tokens work by exchanging an existing SSO session? Feels like the "right" answer but I haven't seen it described much outside cloud provider SDKs. Is there a simpler option I'm missing? Something like mTLS with per-user certs, or just accepting static tokens with a short expiry and good auditing? For anyone who went the secret-manager route: did rotation actually work invisibly, or did you get outages from clients that cached the value? submitted by /u/SmartWeb2711 to r/devops [link] [comments]

For transparency: I run a small UK hosting company, where WHMCS is our current billing/provisioning system. Last week I moved WHMCS 8.13.1 from a CloudLinux OS 9 box running Plesk, to a fresh Debian 13 box. Mostly as we had WHMCS on a shared host during our early days and now it needed its own space. Two things worth sharing if anyone else hits this: Debian 13 ships with PHP 8.4 by default whereas WHMCS wants 8.3 so you need to use the Ondrej Sury repository and not the base repository. ionCube loader has to be placed manually and the ini file renamed to 00-ioncube.ini rather than the default 20-ioncube.ini otherwise if it loads after OPcache, WHMCS breaks very unhelpfully with no clear errors pointing at the fault. Also worth flagging, we had stale absolute paths from the old server that lived in multiple places. We had some in configuration.php, the storage settings gui, and the tblconfiguration SQL table and also in config.php that took a while to track down. Also don't forget to redo the cron! Posting in the hopes it saves someone else an afternoon! submitted by /u/SortingYourHosting to r/sysadmin [link] [comments]

Overview of the GUI I wanted a real OpenShift lab on AWS to practise on, and I specifically wanted UPI — user-provisioned infrastructure — because it's the install method where nothing is hidden. You build the VPC, the load balancers and the DNS records, and the installer only takes over once that's all correctly in place. IPI hides most of that inside the installer binary; ROSA is managed. The problem with UPI is that doing it by hand is slow and easy to get wrong, and I couldn't find anything that automated the whole lifecycle for AWS. So I wrote one. **What it does** `cluster.yaml` is the only file you edit. Everything else — the Terraform variables, the Ansible variables, `install-config.yaml` — is generated from it. ``` ocplab deploy # terraform apply, wait for bootstrap, approve CSRs, finalize ocplab verify # ClusterVersion, node readiness, ClusterOperators ocplab cost # what's deployed right now, priced live ocplab repair # recreate a worker AWS reclaimed, approve its CSRs ocplab power off # graceful shutdown, as an alternative to destroying ocplab destroy # ordered teardown, including what the cluster made itself ``` Some things it handles that took me a while to get right: - **Version pinning.** One field pins the installer, the `oc` client and the RHCOS AMI together, cached locally. - **Spot instances** for compute and bootstrap, with a "minimal" profile that uses them. Not for the control plane — UPI has no ControlPlaneMachineSet, so a reclaimed master isn't replaced automatically. - **Cost visibility.** `ocplab cost` reads live AWS state and prices it, Spot at Spot rates, and it's power-state aware. - **A budget safety net.** AWS Budget with alerts, an automatic lockdown action, and a daily killswitch Lambda — managed outside Terraform so it survives a failed teardown. - **Optional capability trimming**, which cuts the container images pulled per deploy by about a third. - **Teardown that actually completes.** The ingress operator creates a load balancer, a security group and DNS records outside Terraform; the teardown removes them in the right order first. **The web UI** There's also a local browser UI (`ocplab web start`) if you'd rather not watch a 40-minute deploy in a terminal: a status dashboard, a `cluster.yaml` editor that validates before saving, and live output for every operation — including Terraform's resource-by-resource log and the installer's own log. It binds 127.0.0.1 only and runs the same commands as subprocesses, so there's no second implementation to keep in sync. **Scope** It's built for labs and PoCs, not production. Single AZ, single NAT gateway, no HA design beyond etcd's own quorum. It costs roughly $0.83–1.06/hour while it's up, so the intended flow is create, test, destroy the same day. Tested end to end against OpenShift 4.22.6 and 4.22.7. MIT licensed. https://github.com/LuixyToledo97/openshift-upi-aws Happy to answer questions, and issues are welcome if you try it and something doesn't work. submitted by /u/Financial_Spring636 to r/devops [link] [comments]

Cloud migration decisions are often evaluated through the lenses of security, availability, performance and cost. Portability is usually considered much later—sometimes only when an organisation needs to change providers, meet a new regulatory requirement or negotiate a major contract renewal. For KenyaBank, portability cannot be an afterthought. The bank is undertaking an 18-month programme to modernise a legacy core banking environment currently running on Oracle WebLogic and Oracle Database in its Westlands data centre. The target architecture introduces AWS services including Amazon Aurora PostgreSQL, Amazon DynamoDB, Amazon EventBridge, Amazon MSK, AWS IAM Identity Center, AWS Systems Manager and AWS CloudFormation. These services reduce infrastructure-management overhead and accelerate delivery. However, each managed service creates a different degree of dependency on AWS. The real question is therefore not: “Does the architecture contain vendor lock-in?” Almost every cloud architecture does. A more useful question is: “Is the lock-in understood, controlled and justified by the business value it provides?” This article audits five AWS-specific dependencies in KenyaBank’s target architecture, estimates the effort required to replace each one and assigns the overall architecture a portability score. KenyaBank is a Tier-1 Kenyan commercial bank serving approximately 4.2 million customers through 68 branches. Its existing environment includes: A monolithic Java EE core banking application Oracle WebLogic application servers A 3.8 TB Oracle 11g database A legacy internet-banking application Local teller servers in 68 branches An on-premises Microsoft Active Directory environment MPLS connectivity between branches and the Westlands data centre The target architecture uses the Strangler Fig pattern to extract capabilities from the monolith gradually. Internet banking will be containerised, the database will move towards Aurora PostgreSQL, and applications will increasingly communicate through events and managed messaging services. This gives KenyaBank a more scalable and resilient platform, but it also introduces several AWS-specific interfaces, data models and operational processes. //insert diag What is cloud vendor lock-in? Vendor lock-in occurs when moving an application, its data or its operational processes away from a provider would require significant time, cost or redesign. Lock-in is not a single condition. For this assessment, it is divided into three categories. API lock-in API lock-in occurs when application code depends directly on a provider-specific SDK, API, event format or service behaviour. For example, application code written around DynamoDB operations such as PutItem, Query and UpdateItem cannot simply be pointed at PostgreSQL. Data lock-in Data lock-in occurs when data is stored using a proprietary model or format that is difficult to reproduce in another platform. The challenge is not always exporting the raw records. It may involve translating partition keys, indexes, access patterns, relationships, transactions and consistency behaviour. Operational lock-in Operational lock-in occurs when an organisation’s deployment, identity, monitoring, patching or support processes depend on provider-specific tooling. The application may remain technically portable, but the operating model must be rebuilt before it can run elsewhere. The portability-scoring method Each dependency is assessed using five factors: Factor Question Application coupling How much code uses AWS-specific APIs? Data coupling How difficult is it to export and remodel the data? Infrastructure coupling Can the deployment definition run elsewhere? Operational coupling Must procedures and skills be rebuilt? Replacement availability Is there a mature portable alternative? The portability scale is defined as follows: Score Interpretation 1 Highly proprietary; substantial redesign required 2 Significant lock-in; migration would be difficult 3 Moderate lock-in; migration is feasible with planning 4 Mostly portable; limited provider-specific adjustments 5 Highly portable; based mainly on open standards Exit effort is expressed in engineering effort rather than a fixed monetary amount. A defensible financial estimate would require application size, event volume, table count, test coverage, staff rates and recovery requirements that are not provided in the scenario. The estimates assume a multidisciplinary team containing cloud, application, database, security and testing specialists. Dependency 1: Amazon DynamoDB How KenyaBank uses it The proposed architecture uses DynamoDB for session storage. This is attractive because DynamoDB provides managed scaling, high availability and low-latency key-value access without requiring KenyaBank to manage database servers. It is also the strongest source of lock-in in the assessed architecture. Nature of the lock-in Classification: API lock-in and data lock-in Portability score: 2 out of 5 Estimated exit effort: High — approximately 12–20 person-weeks DynamoDB applications are normally designed around: Partition and sort keys DynamoDB-specific query operations Global and local secondary indexes Conditional writes Time-to-live attributes DynamoDB Streams Provisioned or on-demand capacity behaviour AWS SDK request and response models Although DynamoDB tables are flexible, that flexibility does not make them automatically portable. The table design is typically based on application access patterns rather than relational normalisation. AWS supports full and incremental table exports to Amazon S3. These exports do not consume table read capacity, but the supported export formats are DynamoDB JSON and Amazon Ion—not a ready-made PostgreSQL schema. AWS documentation: DynamoDB export to S3 Exporting the records is therefore only the beginning. KenyaBank would still need to: Choose a replacement platform. Design the target schema. Translate DynamoDB-specific data types. Recreate indexes and expiration behaviour. Rewrite the repository or data-access layer. Migrate active sessions. Validate performance and consistency. Run the old and new stores in parallel. Cut over without invalidating customer sessions. Possible alternatives Potential alternatives include: Redis for short-lived customer sessions PostgreSQL for durable relational session records MongoDB for document-oriented access A Kubernetes-compatible Redis deployment A managed Redis service available from multiple providers For temporary session data, Redis would normally provide a more portable model than DynamoDB because its commands and client libraries are available across cloud and self-managed environments. Is the lock-in justified? Partly. DynamoDB is justified when KenyaBank needs very high scale, predictable low latency and minimal database administration. However, using it for ordinary session storage may create more coupling than necessary. The bank should first validate whether the expected session volume genuinely requires DynamoDB. If not, a portable Redis-based implementation may provide enough performance while reducing exit complexity. Recommended control KenyaBank should implement a repository interface between application code and DynamoDB: SessionRepository ├── DynamoDbSessionRepository ├── RedisSessionRepository └── PostgreSqlSessionRepository The business logic should depend on SessionRepository, not directly on the AWS SDK. This will not eliminate data migration, but it will reduce the amount of application code that must be rewritten. Dependency 2: Amazon EventBridge How KenyaBank uses it EventBridge can route business and operational events between loosely coupled application components. Rules match events and deliver them to configured targets. AWS describes an EventBridge event bus as a router that receives events and delivers them to one or more destinations. Rules use AWS-specific event patterns to inspect event metadata and detail fields. AWS documentation: EventBridge event patterns Nature of the lock-in Classification: API and operational lock-in Portability score: 2 out of 5 Estimated exit effort: Medium to high — approximately 8–14 person-weeks Coupling may develop in several places: The EventBridge event envelope PutEvents API calls AWS SDK integrations Event-pattern syntax Event bus policies Rule-to-target configuration Dead-letter queue configuration IAM permissions EventBridge Scheduler AWS-specific target integrations If business applications publish raw EventBridge events directly, a move to Kafka, Google Cloud Pub/Sub or another event platform will require changes to every producer. Consumers may also depend on fields such as source, detail-type, account, region and detail. Exit approach A controlled exit would require KenyaBank to: Inventory event buses, schemas, rules and targets. Define a provider-neutral event contract. Introduce an event-publishing abstraction. Translate existing events into the new format. Recreate routing and filtering rules. Implement retry and dead-letter handling. Run dual publishing during transition. reconcile missed or duplicated events. Retire EventBridge rules after validation. Is the lock-in justified? Yes, but only at the integration boundary. EventBridge is valuable for AWS service integration and operational automation. It can significantly reduce the code required to connect AWS services. For core banking domain events, however, the event itself should not be defined by EventBridge. KenyaBank should use a portable event specification such as CloudEvents and treat EventBridge as one possible transport. A portable business event might look like this: { "specversion": "1.0", "type": "ke.kenyabank.payment.completed.v1", "source": "/core-banking/payments", "id": "a03ac2f8-5e51-4c51-95d5-7714be667350", "time": "2026-07-29T09:30:00Z", "datacontenttype": "application/json", "data": { "paymentReference": "PAY-104582", "status": "COMPLETED" } } The same logical event could be transported through EventBridge, Amazon MSK or another cloud’s event service. Recommended control Standardise domain events using CloudEvents. Publish through an internal event interface. Keep AWS SDK calls inside adapters. Store event schemas in a provider-neutral repository. Avoid placing business rules exclusively in EventBridge rule definitions. Use EventBridge mainly for AWS-native operational events. Dependency 3: AWS CloudFormation How KenyaBank uses it CloudFormation defines AWS infrastructure as YAML or JSON templates. It gives KenyaBank repeatable deployments, change tracking and automated infrastructure management. However, CloudFormation templates use AWS-specific resource identifiers such as AWS::S3::Bucket and AWS::EC2::VPC. AWS documents these service-specific resource and property definitions in its CloudFormation resource reference. AWS documentation: CloudFormation resource syntax. Nature of the lock-in Classification: Operational lock-in Portability score: 2 out of 5 Estimated exit effort: Medium — approximately 8–16 person-weeks The deployed resources may use standard technologies, but the infrastructure definition cannot be applied directly to Azure, Google Cloud or an on-premises platform. Coupling increases when templates use: AWS-specific resource types Intrinsic functions such as Ref and Fn::GetAtt Nested stacks CloudFormation exports StackSets AWS-specific transforms Lambda-backed custom resources CloudFormation deployment pipelines Custom resources create additional coupling because they can invoke Lambda or SNS-based provisioning logic. AWS documentation: CloudFormation custom resources Exit approach Migrating from CloudFormation to Terraform or OpenTofu would involve: Inventorying all stacks and nested stacks. Mapping resources into the target tool. Rewriting parameters, outputs and dependencies. Importing existing infrastructure into the new state. Comparing both infrastructure definitions. Testing changes in a non-production account. Freezing CloudFormation changes during transition. Transferring resource ownership in controlled phases. Retiring stacks without deleting live resources. The main risk is not reproducing the YAML syntax. It is safely transferring control of already-running infrastructure without accidental replacement or deletion. Is the lock-in justified? Not for the long-term target state. CloudFormation is a capable option for AWS-only environments, but KenyaBank’s portability objective favours Terraform. The bank does not need to replace every existing template immediately. A phased six-month migration would be safer: Month 1: inventory and prioritisation Month 2: Terraform/OpenTofu standards and modules Months 3–4: non-production migration Month 5: production resource import Month 6: validation and CloudFormation retirement Recommended control Use Terraform or OpenTofu for new infrastructure. Create modules around architectural capabilities rather than individual resources. Keep environment values separate from reusable modules. Prohibit new CloudFormation custom resources during the transition. Apply deletion protection and lifecycle safeguards before importing production resources. Retain CloudFormation templates until rollback is no longer necessary. Dependency 4: AWS IAM Identity Center How KenyaBank uses it IAM Identity Center provides workforce access to multiple AWS accounts. KenyaBank intends to connect its existing Active Directory environment using SAML 2.0 and SCIM, with permission sets assigned to teams such as Banking Operations, Technology Operations, Development and Audit. This dependency is more nuanced than DynamoDB because its identity-federation interfaces use open standards. AWS IAM Identity Center supports SAML 2.0 for authentication and SCIM for user and group provisioning. An identity provider that implements these standards is expected to interoperate with IAM Identity Center. AWS documentation: SAML and SCIM federation Nature of the lock-in Classification: Primarily operational lock-in Portability score: 3 out of 5 Estimated exit effort: Medium — approximately 6–12 person-weeks The following elements are relatively portable: User identities retained in Active Directory SAML-based authentication SCIM-based provisioning Group membership General role-based access principles The AWS-specific components include: Permission sets AWS account assignments IAM policies AWS Organizations integration AWS account and organisational-unit mappings AWS-specific attributes and session controls Permission sets determine the level of access users and groups receive in AWS accounts. These permissions cannot be transferred directly to another cloud because other providers use different resource and policy models. AWS documentation: IAM Identity Center permission sets Exit approach Moving to another platform would require KenyaBank to: Retain Active Directory or another independent identity provider as the system of record. Integrate the target platform through SAML or OpenID Connect. Recreate user and group provisioning. Translate AWS permission sets into target-cloud roles. Replace IAM policy conditions. test privileged and emergency access. validate separation of duties. update access-review and audit procedures. Is the lock-in justified? Yes. The lock-in is acceptable because the authoritative identities remain outside AWS and federation relies on standard protocols. KenyaBank receives centralised access management across its AWS accounts without making AWS the permanent system of record for workforce identities. Recommended control Keep Active Directory as the authoritative identity store. Group users by business function, not by AWS service. Document every permission-set mapping. Export permission definitions into version control. Maintain a cloud-neutral access matrix. Test emergency access independently of normal federation. Avoid manually creating long-lived IAM users. This approach allows the bank to retain a portable identity-governance model even though cloud permissions remain provider-specific. Dependency 5: AWS Systems Manager How KenyaBank uses it KenyaBank intends to manage EC2 instances and 68 branch servers through AWS Systems Manager. Systems Manager hybrid activations allow on-premises servers, virtual machines and edge devices to register as managed nodes. Those machines then use the SSM Agent to communicate with AWS Systems Manager. AWS documentation: Systems Manager hybrid environments This gives the bank centralised inventory, patching, command execution, automation and audit history without requiring SSH access or bastion hosts. Nature of the lock-in Classification: Operational lock-in Portability score: 2 out of 5 Estimated exit effort: Medium to high — approximately 10–18 person-weeks The servers themselves remain portable, but the management processes become AWS-specific. Coupling includes: SSM Agent registration Hybrid activation codes IAM service roles Patch baselines Maintenance windows State Manager associations Run Command documents Automation runbooks Inventory and compliance reports Parameter Store integration CloudWatch and EventBridge automation The greater the number of SSM documents and automated remediation workflows, the greater the exit effort. Exit approach Potential replacements include: Ansible Automation Platform Red Hat Satellite Canonical Landscape Microsoft Configuration Manager Azure Arc Google Anthos Kubernetes-based management where appropriate Migration would require: Deploying the replacement agent or configuring agentless access. Recreating the server inventory. Translating patch baselines. Rebuilding maintenance schedules. Rewriting automation documents. Replacing IAM-based authorisation. Reconstructing audit and compliance reporting. Operating both platforms during transition. Deregistering the servers from Systems Manager Is the lock-in justified? Yes for the AWS estate; only partly for branch servers. Systems Manager is a strong fit for EC2 because it integrates naturally with IAM, CloudTrail, Patch Manager and AWS automation. Using it for all branch infrastructure provides consistency, but it makes the operational model AWS-dependent even when the servers are physically located outside AWS. For a regulated bank, that trade-off may still be justified if the centralised audit trail and reduced reliance on SSH materially improve security. Recommended control Write automation in scripts or Ansible where practical. Keep SSM documents thin and use them to invoke portable scripts. Store scripts in version control. Maintain an independent configuration-management database. Export compliance results into the bank’s central reporting platform. Document how servers would be managed if Systems Manager were unavailable. Test replacement management tooling on a small branch-server sample. Consolidated portability assessment Dependency Primary lock-in Portability Exit effort Is it justified? DynamoDB session store API and data 2/5 High Partly Amazon EventBridge API and operational 2/5 Medium–high Yes, at AWS integration boundaries AWS CloudFormation Operational 2/5 Medium No for the long-term target IAM Identity Center Operational 3/5 Medium Yes AWS Systems Manager Operational 2/5 Medium–high Yes, with controls [Screenshot placeholder: KenyaBank dependency and exit-effort matrix] Dependencies that improve portability Not every AWS-managed service creates the same level of risk. Two choices in the KenyaBank architecture make the environment more portable. Amazon MSK Amazon MSK runs open-source Apache Kafka and supports existing Kafka clients, tools and plugins. AWS documentation: What is Amazon MSK? If KenyaBank uses standard Kafka APIs, portable schemas and open-source connectors, producers and consumers can move to another Kafka distribution with relatively limited application changes. AWS-specific authentication, monitoring, replication and control-plane automation can still create operational coupling, but the data plane is substantially more portable than EventBridge. Estimated portability: 4 out of 5. Amazon Aurora PostgreSQL Aurora PostgreSQL is PostgreSQL-compatible and supports standard PostgreSQL tools. AWS documents migration options including pg_dump, pg_restore and AWS DMS. AWS documentation: Migrating Aurora PostgreSQL data Portability decreases if KenyaBank depends on Aurora-specific capabilities such as: Aurora Global Database Aurora Serverless scaling behaviour Cluster endpoints Aurora-specific replicas Backtrack or other engine-specific functions AWS-specific monitoring and failover automation If the database schema, SQL and drivers remain PostgreSQL-standard, the exit path is still considerably easier than leaving a proprietary database model. Estimated portability: 4 out of 5. Overall portability score: 3 out of 5 KenyaBank’s proposed architecture receives an overall portability score of: 3/5 — Moderately portable The score is not a simple average of the five dependencies. It considers their architectural importance and the effect of existing mitigation opportunities. The architecture earns a moderate score because: Aurora PostgreSQL provides a PostgreSQL-compatible exit path. Amazon MSK is based on open-source Apache Kafka. SAML and SCIM reduce identity coupling. Containers make the application runtime relatively portable. The Strangler Fig pattern supports incremental change. The score is prevented from reaching 4 or 5 because: Session management depends on DynamoDB’s proprietary data model. Domain events risk becoming coupled to EventBridge. Infrastructure is described using CloudFormation. Branch operations depend heavily on Systems Manager. AWS-specific IAM and automation remain embedded in the operating model. The architecture is therefore portable in principle, but exiting AWS would still require a planned transformation programme rather than a simple redeployment. Recommended portability-improvement plan KenyaBank does not need to avoid managed services. It needs to isolate their use. Introduce application adapters Applications should call internal interfaces rather than AWS SDKs directly. Examples include: SessionRepository EventPublisher SecretProvider ObjectStorageClient IdentityClaimsMapper Each interface can have an AWS implementation today and another implementation in the future. Adopt portable event contracts Core banking events should use: CloudEvents envelopes JSON Schema, Avro or Protobuf contracts Versioned domain-event names Provider-neutral metadata A schema-compatibility policy EventBridge and MSK should transport events without owning their business meaning. Move infrastructure definitions towards Terraform or OpenTofu CloudFormation stacks should be replaced gradually. Production resources should be imported carefully rather than recreated. This change improves infrastructure portability, although the resources defined may still be AWS-specific. Use PostgreSQL-compatible features by default Aurora-specific capabilities should require an architecture decision record explaining: The business benefit The portability impact The alternative considered The exit approach The trigger for reassessment Keep identity outside the cloud provider Active Directory should remain the workforce identity authority. IAM Identity Center should provide AWS access federation rather than become the only identity repository. Keep operational scripts portable Systems Manager runbooks should invoke scripts that can also run through Ansible or another orchestration platform. The bank should avoid encoding every operational procedure entirely inside SSM documents. Test the exit plan A portability strategy is only credible if it is tested. KenyaBank should run an annual portability exercise that: Restores a sample Aurora schema into standard PostgreSQL Consumes an MSK topic using a non-AWS Kafka client Replays EventBridge events into an alternative broker Deploys one Terraform/OpenTofu-managed environment Manages one branch server using an alternative tool Exports a sample DynamoDB table and transforms its data Final assessment KenyaBank should not reject AWS-managed services merely because they introduce lock-in. DynamoDB, EventBridge, IAM Identity Center and Systems Manager can reduce operational effort and improve availability, security and delivery speed. Those benefits may be more valuable than complete portability. The most important finding is that not all lock-in is equally risky. DynamoDB creates the greatest application and data portability concern. CloudFormation and Systems Manager create substantial operational dependence. IAM Identity Center is a more acceptable dependency because it integrates through SAML and SCIM, while Aurora PostgreSQL and Amazon MSK offer stronger portability foundations through PostgreSQL and Apache Kafka compatibility. The recommended decision is therefore to continue with AWS, while introducing architectural boundaries around proprietary services. KenyaBank does not need a platform that can move to another cloud overnight. It needs a platform whose dependencies are visible, whose business benefits are understood and whose exit paths remain technically achievable. That is the difference between unmanaged vendor lock-in and a deliberate cloud strategy.

I keep seeing engineers falling into an AI architecture trap. Some engineers try to solve every problem by prompting to a LLM. Others talk about creating an agent for every usecase. So knowing how to use AI has become a core competency. Otherwise you will waste time, money and DevOps resources. If you want to solve an actual business problem without creating an infrastructure nightmare, 99% of your use cases fall into one of these 5 application architectures. Here is how to know which one to use. 1. Basic Prompting (Stateless API) The Use Case: You need to summarize text, extract sentiment, or reformat data (like turning unstructured text into JSON). The data easily fits into the context window. The Trap: Thinking you need a custom model just because the base model didn't output your exact format on the first try. Before you do anything complex, try giving the model 3 concrete examples in the prompt (few-shot prompting). That solves the problem most of the time. 2. RAG (Retrieval-Augmented Generation) The Use Case: You need the LLM to answer questions about your proprietary data (internal wikis, codebase, customer records). You query a VectorDB for the relevant context, shove that context into the prompt, and let the LLM read it. The Trap: Trying to fine-tune a model on your company wiki. Models hallucinate facts. If you need accurate, source-traceable answers based on your internal data, you need RAG, not a fine-tuned model. 3. Chaining / Workflows The Use Case: The task is too complex for one prompt and requires distinct, predictable steps. For example: Step 1 extracts raw text -> Step 2 categorizes it -> Step 3 writes a summary based on the category. The Trap: Cramming a massive, 15-part instruction into a single mega-prompt and crossing your fingers. Break it down into a predictable pipeline. It’s much easier to debug a chain of small LLM calls than one giant, confused prompt. 4. Routing The Use Case: You are dealing with high volume and need to control costs and latency. You build a router that sends simple tasks (like spelling correction) to a fast, cheap model (like Claude Haiku or GPT-4o-mini), and complex reasoning tasks to the expensive, heavy models. The Trap: Sending every single trivial API request to the most expensive flagship model available and bankrupting your cloud account. 5. Autonomous Agents The Use Case: Open-ended tasks where the exact steps aren't known in advance. The LLM is given a goal and external tools (Python interpreter, web search, internal APIs) and loops continuously, evaluating its own output until it achieves the goal. The Trap: Using agents for deterministic workflows. If you can solve a problem with a standard if/then Python script or an Ansible playbook, do it. Do not introduce probabilistic, infinite-looping agents into a workflow that just needs a standard script. The Takeaway: Don't jump straight to training models. Work your way up this list. Start with prompting. If it lacks context, use RAG. If it lacks reliability, chain it. If it lacks cost-efficiency, route it. Only use agents when absolutely necessary. Curious if anyone else has horror stories of teams trying to fine-tune models to learn internal docs? submitted by /u/SeaworthinessHour233 to r/devops [link] [comments]

I'm an indie dev and honestly exhausted. I've been stuck in a support loop with Google Cloud for nearly a full year over an acknowledged platform-side bug. Here is the short version of what's happening: The Bug: My GCP project was hit with an unexpected $8,367.11 charge surge on the Gemini 2.5 Flash image generation SKU. Product Lead Logan Kilpatrick publicly acknowledged this bug on the official forums and promised affected devs would be taken care of. The "90% Cap": Google Billing gave a 90% adjustment and declared that 90% is the "maximum allowable limit" for this incident—leaving $838.26 on my account for a bug on Google's infrastructure. The "No Logs" Excuse: When I demanded backend logs or proof showing why I owe this remaining balance, support literally replied: "they do not share external-facing documentation, internal case notes, or further detailed explanations regarding their final review process." 1 Year of Support Ping-Pong: Opened a billing ticket $\rightarrow$ immediately closed and bounced back. Tier 1 agents just rotate shifts, paste identical templates, and close tickets without consent. My account currently sits with a red banner warning and an active $838.26 balance for services I never consumed. Screenshots attached: 1.Billing Support confirming the charge was caused by the Gemini 2.5 Flash bug. https://preview.redd.it/x083tf255olh1.png?width=438&format=png&auto=webp&s=f57d82c545e94f41d28eee18802a0243731f2366 Support stating the 90% adjustment is final. https://preview.redd.it/eaq8leu55olh1.png?width=690&format=png&auto=webp&s=36fb40b01c9f27c07cbd0f1d920eacd011b0575d My billing console showing the pending $838.26 balance and account warning. https://preview.redd.it/ahyl62n65olh1.png?width=690&format=png&auto=webp&s=e9403517ca4b0c93b3fbcc102633f78f35cf7f4b Support's latest response admitting they cannot provide any logs or explanation. https://preview.redd.it/ec9uxzv95olh1.png?width=1481&format=png&auto=webp&s=a59b05554a4fd661828dc2d83d32d9a7178ad05a I've documented this on the Google AI Forum and am preparing consumer complaints in Japan (消費者庁 / 消費生活センター). Has anyone ever broken through this Tier 1 "final decision" wall without an Enterprise support plan? Any advice or visibility would be really appreciated. submitted by /u/Character-Candy1120 to r/googlecloud [link] [comments]

This is likely a bit of a niche question, but I am going a tad insane trying to figure out why my old script for purging emails via a compliance search is failing. Previously (around a year ago), this script would create a new compliance search in EXO, start it, poll for progress, and then export the results and ask if you wanted to purge the emails from the relevant mailboxes. Had something come up yesterday while I was unavailable, and my old script didn't work. Messing around with it this morning, I found that while I can create a new compliance search, I cannot preview the results OR export the results. It does however, seem like I can still purge emails. Only you know, I cannot preview the emails, or verify it actually found the right emails beyond hoping that the item count from the search makes sense. Not so cool. From what I found on Microsoft's own documentation pages, it looks like the preview, and export functions will only work for on-prem exchange now, and I really do not see any alternatives. All that being said, is this Microslop making things difficult for the sake of adding some new subscription in the coming months, or is there actually a way to do this and their documentation is woefully out of date? I have a feeling the answer is going to be a resounding "no" based on an hour or so of searching, but you never know 😉 submitted by /u/TheOnlyKirb to r/sysadmin [link] [comments]

Hi guys, I'm needing your guidance here. I work in an automation-focused role that gradually became much more technical than operational. A lot of my job is taking broken/manual processes, improving them, and building automations around them. In practice, that means dealing with business rules, integrations, permissions, data sources, testing, edge cases, etc. However, I still consider myself junior technically. My current challenge is that the company is becoming more restrictive about external/unapproved automation tools, so I’m trying to move everything into approved internal tools and infrastructure. The problem is that access is granted gradually, permissions change, and some features depend on other teams. Stakeholders often just see that “the automation isn’t ready,” while a lot of the delay is actually caused by access, security, infrastructure, or dependencies. I’ve started communicating blockers and development stages more clearly, but I’m curious about how this is normally handled in US/European companies. How much responsibility is usually placed on the developer when delivery is blocked by access or another team? And how do you manage expectations when something sounds simple from the business side but isn’t simple technically? submitted by /u/Kooky-Internet8806 to r/devops [link] [comments]

https://preview.redd.it/tj068f1g1cjh1.png?width=2107&format=png&auto=webp&s=35fb64e37f0fe01bc985df9e0407adee6f055cee https://preview.redd.it/7a3lvq2k1cjh1.png?width=1695&format=png&auto=webp&s=da48778e9b362485b942eb4f05a59f1b7256cb40 My usage this month was around IDR 170.000 but I was charged IDR 3 million. Why is that? The support bot said: Since your July usage ( Rp 863,006 ) was already paid and your August usage is only ( Rp 168,763 ), these charges of IDR 1,000,000 and IDR 2,000,000 processed today are highly likely due to one of the following reasons: Temporary Authorization Holds: When you update payment details, add a new card, or reach certain verification checkpoints, Google or your bank may place temporary authorization holds (often in round numbers like IDR 1,000,000 or 2,000,000) to verify your card's validity. These are not actual charges and will be automatically released back to your account by your bank within a few business days. Multiple Google Billing Accounts: If you use the same credit card for other Google services (such as Google Ads, Google Workspace, or a separate Google Cloud Billing account), these charges may have originated from those services. submitted by /u/rfajr to r/googlecloud [link] [comments]

We got the Azure notice about upgrading our Storage and Blob accounts from GPv1 to GPv2 ahead of the October 13th automatic migration deadline. The Azure portal makes it look incredibly easy with a simple "one-click" in-place upgrade button for the Storage Accounts which have been identified as GPv1 and Blob. Documentation says zero downtime and zero data loss. However, I know GPv2 flips the billing model (cheaper storage, much higher transaction costs). For anyone who has already gone through this migration: Did you just click the upgrade button and wing it? If so, did your bill spike unpredictably? Did you actually pull Azure Monitor metrics first? If you audited transaction volumes, what thresholds made you hesitate or re-architect a workload? Any hidden gotchas? Did you run into issues with default access tiers (Hot vs. Cool) or legacy ZRS replication during the flip? Since Microsoft is going to auto-upgrade us anyway in October, I want to know if it is worth digging into the transaction logs manually or if I am overthinking a routine upgrade. Appreciate any real-world horror stories or "it went fine" reassurances! submitted by /u/nomadicviking024 to r/AZURE [link] [comments]

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

After working with Kubernetes in production, I've noticed that some of the most annoying incidents aren't caused by obvious failures. They're often caused by small configuration decisions that look perfectly reasonable during review. Things like: missing resource requests/limits incorrect probes overly permissive RBAC missing PodDisruptionBudgets unsafe container configuration incorrect readiness behaviour services without appropriate timeouts configuration drift between environments I'm curious what the DevOps community has actually encountered in production. What's one Kubernetes configuration mistake that caused you a real incident? I'd especially like to hear about the less obvious ones that aren't caught by the usual linters. submitted by /u/nerd3n to r/devops [link] [comments]

What happened On Aug 1, an IAM access key belonging to one of our accounts was compromised through a supply chain compromise — the key was exposed via a third party in our toolchain, not by us publishing it. This was a programmatic access key, so MFA (enforced on all human identities from day one) was never in the path. We caught it and reported it to AWS Support within 4 hours , well inside the 48-hour public-contract cancellation window. The case then sat unassigned for 14 days. As of today that's 20 days, still open, still no resolution. Where the bill is now Total USD 477,505.20 Contract creation (0 months) USD 4,800.00 Usage Fee | us-east-1 USD 472,705.20 47,270,520 Units @ USD 0.01 The part I don't understand We never activated the product. Specifically: - The Marketplace console still shows "Set up product" for this agreement - No License ID was ever issued - CloudTrail shows zero Marketplace events in our account after the initial compromise window on Aug 1 - We have never had credentials for, or logged into, anything on the seller's side Yet 47.2 million billable units were metered against us in us-east-1. As I understand the SaaS flow, usage on this kind of product is submitted by t he seller calling `BatchMeterUsage` against the entitlement's `CustomerIdentifier` — from the seller's own infrastructure, not from our account. If that's right, then nothing in our account was ever in the path, and no control we have could have stopped it. Revoking the key, deleting the attacker's IAM user, applying SCPs — none of it touches seller-side metering. The unit count has been static for several days now, so metering appears to have stopped, but the agreement status is the thing I can't get a straight answer on. Support so far Seller support (automated) told us Marketplace transactions are not their department and to contact AWS. AWS support has pointed at the seller for anything usage-related. The payer account has now escalated and asked AWS to investigate the agreement and stop metering. Still waiting. There is no phone line and no chat. The only channel is tickets, and they've been sitting for 20 days. Questions for people who actually know the internals For a SaaS contract-with-consumption product, is metering purely seller-side ? Is there any circumstance where usage gets attributed to a buyer account without the buyer ever completing registration? Does "Set up product" persisting in the console reliably mean the fulfillment/`ResolveCustomer` handshake never happened — or is that just stale console state that doesn't update? Is there any way for a buyer to see the registration record for their own entitlement? Anything in the Agreement APIs, CUR, or elsewhere that shows when/whether `ResolveCustomer` was called? The 48-hour window: AWS Customer Service can process a full refund on a public contract without seller involvement. Does that path survive a case sitting unassigned for 14 days, or is the window enforced strictly on wall-clock time regardless of AWS-side latency? Has anyone here had Marketplace usage fees (not just the contract fee) reversed after a credential compromise? Contract fee reversals I've seen written up. Usage fees at this scale, never. To be blunt about the stakes: we're a small company. We cannot pay $472k for consumption we did not generate, on a product we never activated, after cutting off access in under 4 hours. I'm trying to understand the metering mechanics, and whether there's a path here other than waiting on a ticket queue. submitted by /u/Round_Vegetable3764 to r/aws [link] [comments]

Azure weekly update #33 is here. This week Azure rolled out key networking and SQL platform improvements, new Copilot and healthcare agent offerings, and important service lifecycle updates including Azure VMware Solution retirement planning. Detailed list: * Launched | Generally Available: Summarized advertised gateway prefixes for route advertisement . This feature allows for advertising aggregated prefixes instead of every individual virtual network address space, which is great for large hub-and-spoke deployments. * Announcing: Azure Copilot introduces direct access to agents . Users can now select specific Azure Copilot agents like Troubleshooting or Deployment to move more quickly from questions to action. * Launched | Generally Available: Azure Databricks Lakebase in four additional regions . Lakebase is now available in North Central US, France Central, Germany West Central, and East Asia, expanding regional options for workloads. * Launched | Generally Available: Azure SQL updates for mid-August 2026 . This update brings enhancements to Azure SQL, including customizable keyboard shortcuts within Visual Studio Code. * In preview | Public Preview: SQL Formatter in MSSQL extension . The SQL Formatter is now in public preview, offering more customizable formatting options to help streamline development. * Launched | Generally Available: Azure SQL Database provisioning in MSSQL extension . You can now create and connect to a fully managed cloud database directly from your editor at no cost. * Launched | Generally Available: vCore Customization: Disable Multithreading and Configurable Constrained Cores . This new capability gives users greater control over virtual CPU configurations to optimize performance and reduce licensing costs. * Launched | Generally Available: BYON (Bring Your Own NIC) in Azure Site Recovery . Azure Site Recovery now supports attaching existing, pre-provisioned NICs in the target region for failover scenarios. * Retirement: Azure VMware Solution License-included service will be retired August 30, 2027 . Customers should be aware that the AVS license-included service will be retired on August 30, 2027, requiring transition planning. * Launched | Generally Available: Managed Instance on Azure App Service . Managed Instance is now available, allowing migration of web applications to Azure App Service with minimal configuration. * In preview | Public Preview: Ipv6 support in Azure Firewall . Azure Firewall now supports IPv6 in public preview, enabling dual-stack mode for both IPv4 and IPv6 traffic. * In preview | Public Preview: Zone redundancy for Azure SQL Managed Instance Next-gen General Purpose . Enhanced resilience is available via public preview zone redundancy for Azure SQL Managed Instance Next-gen General Purpose. * Launched | Generally Available: Dragon Copilot Physician Apps and Agents on Microsoft Marketplace . Dragon Copilot Physician Apps and Agents are now available for discovery and purchase through Microsoft Marketplace. * In preview | Public Preview: Azure Linux on WSL . Azure Linux on WSL is now available in Public Preview, allowing teams to use a consistent Linux foundation across development, testing, and production. submitted by /u/groovy-sky to r/AZURE [link] [comments]

Had one of those fun discoveries recently: a nightly backup cron had been failing (or not running) for a stretch, and nobody knew. Host was fine, uptime checks were green, no ticket, nothing. Found it only when we actually needed a restore. Curious how other people handle the "job went quiet" case — not "the server is down", but "the scheduled thing didn't check in". What are you using in practice? - Healthchecks / Cronitor / Dead Man's Snitch / something else SaaS? - Self-hosted (Uptime Kuma push monitors, Prometheus + blackbox/heartbeat, custom scripts)? - Just mail on failure from the job itself (`MAILTO`, wrapper scripts, etc.)? - Or do you mostly not bother unless it's a critical path? Also interested in what actually matters day to day: - Grace periods vs exact schedules - Success-only heartbeat vs explicit fail signal - Email only vs Slack/Teams/PagerDuty - How many jobs you bother monitoring vs "we'll notice eventually" Not looking for a product pitch — just war stories and what you'd recommend to a small team that doesn't want another heavy observability stack for a handful of crons. submitted by /u/georgi_tsenov to r/sysadmin [link] [comments]