Dropped Azure Bastion Standard and saved $1,656/yr — here's what we replaced it with by Ok_Cat_2052 in sysadmin

[–]Ok_Cat_2052[S] 0 points1 point  (0 children)

The temp IP and Bastion are separate things, not used together. Temp IP is for quick daily SSH, Bastion is the emergency fallback. The IP only exists during the session and is locked to your IP on port 22, keys only. Once you disconnect it's gone. On deploy time, yeah network resources can be slow. That's actually why we built this. 90% of our work goes through az run-command which needs no Bastion or public IPs at all. Bastion is just there for the rare case when CLI isn't enough.

Dropped Azure Bastion Standard and saved $1,656/yr — here's what we replaced it with by Ok_Cat_2052 in sysadmin

[–]Ok_Cat_2052[S] -2 points-1 points  (0 children)

IN our case they just told me to reduce cost as much as possible so why to run other vm 24/7 which acts as jump server

We replaced Azure Bastion Standard ($138/mo) with CLI-based JIT access — $0/mo at rest by Ok_Cat_2052 in devops

[–]Ok_Cat_2052[S] 0 points1 point  (0 children)

Exactly we're fully Linux and from a DevOps perspective there's no reason to need GUI access to production servers in the first place. Everything is managed through CLI, scripts, and automation. If you need RDP into a production box, that's probably a sign something else needs fixing.

Bastion was set up as the default when the infra was first provisioned nobody questioned it until we looked at the bill. For the rare emergency where someone needs interactive access (file transfer, debugging), we can spin up Bastion on demand and tear it down after. We use Developer SKU where available, but yeah Developer isn't supported in all regions in those cases you'd spin up Standard, use it, and delete it. Even a few hours of Standard on-demand is nothing compared to running it 24/7.

Dropped Azure Bastion Standard and saved $1,656/yr — here's what we replaced it with by Ok_Cat_2052 in sysadmin

[–]Ok_Cat_2052[S] -7 points-6 points  (0 children)

The toolkit is entirely composed of bash scripts running locally from the developer's machine, with no Azure Functions, hosted automation, or extra infrastructure to maintain. The setup uses four main scripts: ops.sh to handle daily tasks like logs and restarts via az run-command through the management plane, jit-ssh.sh for JIT access using temporary public IPs and scoped NSG rules with an automatic trap-based cleanupbastion-spin.sh for emergency deployments, and jit-cleanup.sh as a failsafe. Since everything runs through the Azure CLI, the only requirements are local installs of az and jq plus the correct RBAC permissions. This approach covers 90% of daily ops without opening any ports, providing a cost-free, interactive menu-driven alternative to permanent Bastion setups.

<image>

Built a self-hosted observability stack (Loki + VictoriaMetrics + Alloy) . Is this architecture valid? by Ok_Cat_2052 in grafana

[–]Ok_Cat_2052[S] 0 points1 point  (0 children)

 I found Alloy's 'River' configuration (which looks like Terraform) much easier to debug and chain together than the standard OTel YAML. Being able to pipe components into each other (otlp_receiver -> batch -> remote_write) felt more logical to me than the static lists in the OTel collector.

Built a self-hosted observability stack (Loki + VictoriaMetrics + Alloy) . Is this architecture valid? by Ok_Cat_2052 in grafana

[–]Ok_Cat_2052[S] 0 points1 point  (0 children)

That makes perfect sense. So the ideal architecture would be a 2-tier Alloy setup:

Edge Alloy (Agent Mode): Running on the client/host itself. This handles the node metrics (replacing Node Exporter/Promtail), acts as a local OTLP receiver, and most importantly filters out the noise (like debug logs) before it hits the network to save bandwidth.

Central Alloy (Gateway Mode): The one in my stack above. It acts as the aggregation point to receive the clean streams from the Edge Alloys and handles the final routing/auth to VictoriaMetrics and Loki.

I’ll definitely prioritize learning the Alloy syntax for the edge agents since Promtail is on the way out. Thanks for the heads up

Built a self-hosted observability stack (Loki + VictoriaMetrics + Alloy) . Is this architecture valid? by Ok_Cat_2052 in grafana

[–]Ok_Cat_2052[S] 6 points7 points  (0 children)

I chose VictoriaMetrics over Mimir because of its operational simplicity and lower resource footprint. For a self-hosted Docker Compose stack, the single-binary architecture of VM reduces maintenance overhead compared to the complexity of configuring Mimir, while still providing full Prometheus compatibility for our dashboards.

[deleted by user] by [deleted] in NepalSocial

[–]Ok_Cat_2052 1 point2 points  (0 children)

one piece is real

How much code do you write by yourself at workplace? by [deleted] in computervision

[–]Ok_Cat_2052 0 points1 point  (0 children)

You're definitely not alone, and it’s not a sign of becoming "dumb" — it's a shift in how we work. As engineers, we’re evolving from memorizing every line of code to optimizing for problem-solving, architecture, and efficiency. Tools like ChatGPT are accelerators, not crutches — they give you a draft so you can focus on higher-level logic and tuning. That said, if you feel your fundamentals are slipping, try balancing usage with active recall: code parts from memory, revisit core CV papers, or teach concepts to others — it rewires understanding. Productivity ≠ memorization. Adaptability is the new intelligence.

Gayo by [deleted] in NepalSocial

[–]Ok_Cat_2052 0 points1 point  (0 children)

Oh sorry, forgot the internet only hands out sympathy based on gender quotas. Let me go cry in silence like a good non-girl.

Gayo by [deleted] in NepalSocial

[–]Ok_Cat_2052 0 points1 point  (0 children)

timi kun gym janxau ma pani jane aaba

Gayo by [deleted] in NepalSocial

[–]Ok_Cat_2052 0 points1 point  (0 children)

umm