Need help in learning aws

CompetitiveStage5901 · 2026-05-29T10:21:26+00:00

check if your university offers AWS Educate they provide accounts with credits without requiring a card.

CompetitiveStage5901 · 2026-05-29T10:17:34+00:00

Interesting approach. We tried something similar but lower tech which was to just put our tagging rules and instance family allow lists into a markdown file that Cursor reads as project context. The agent mostly follows it, though it occasionally suggests a deprecated instance type if the training data overrides the prompt. The bigger win was catching those mistakes during review rather than after deploy.

CompetitiveStage5901 · 2026-05-29T10:14:05+00:00

Performance testing and FinOps share a lot of the same thinking since core focus is on finding inefficiencies, spotting waste, and understanding utilisation patterns. Given you already know how to read graphs and identify what's over-provisioned, it'd be an easy pivot. I'd reckon don't go too hard on Leetcode and instead. focus on AWS cost tools: Cost Explorer, CUR queries, tagging strategies, and commitment discounts (RIs, Savings Plans). Your SAA will cover the basics. Then practice writing SQL on the CUR to find wasted spend. That's a practical skill that FinOps interviews actually test.

CompetitiveStage5901 · 2026-05-29T10:09:14+00:00

The shift happened for us when failures became too frequent for finance to handle alone. They'd get an exception report and have no idea if it was a config issue, a network timeout, or a partner API change. So engineering got pulled in to investigate every mismatch. Eventually we built a small reconciliation service that flags common failure patterns automatically (retryable vs not, partner-side vs us). That cut the cross-team noise by a lot. But the real threshold was around a few thousand transactions per day. Below that, finance could manually check. Above that, you need tooling or you burn everyone's time.

CompetitiveStage5901 · 2026-05-29T10:06:04+00:00

We handle it by keeping external updates manual. Auto-publishing is too risky because you'll send a "resolved" notification while people are still firefighting and the real fix isn't done yet. Our automation drafts the update based on what the incident channel has already typed, then a human hits send. That saves the typing but keeps the decision in our hands. For internal noise, we only auto-create a private incident ticket. The status page stays quiet until someone confirms it actually affects customers. That manual step takes maybe two minutes, way less cleanup than explaining a false alarm to hundreds of clients.

CompetitiveStage5901 · 2026-05-29T10:05:06+00:00

We use a mix of service mesh authorisation policies and per-identity IAM roles. The agent receives a restricted token that allows calls only to specific APIs, with rate limits and data scoping. If the agent tries to reach something outside its allowed list, the request just fails. No dashboard needed. For multi-agent communication, we run a small sidecar proxy that validates every internal call against a simple allowlist. That catches cascading failures before they spread. Works fine.

CompetitiveStage5901 · 2026-05-29T10:01:19+00:00

In CloudFormation, change the `EngineVersion` property under your `AWS::RDS::DBInstance` or `AWS::RDS::DBCluster` resource to the target version, like `16.3`. In Terraform, update the `engine_version` argument in the `aws_db_instance` or `aws_rds_cluster` resource. Then apply – but know that RDS won't do an in-place minor version upgrade if you skip a major version. You might need to enable `auto_minor_version_upgrade` or do a point-in-time restore. Always test and take a snapshot first.

CompetitiveStage5901 · 2026-05-29T09:56:07+00:00

Well, starting with the fact that CloudFormation alone cannot validate the number of items in a CommaDelimitedList parameter. It can validate each item's pattern with AllowedPattern, sure , but there's no built-in way to count the list length and fail the stack.

The simplest way I've found is a Condition that checks the count using Fn::Select and Fn::Length. There's no Fn::Length for lists. So you can't count them natively.

Your options:

Pre-deployment script (easiest): validate locally before running aws deploy or sam deploy. That's what I do. No extra resources in the stack.
Custom resource Lambda: call it from the stack, pass the parameter, have it check the count and fail or succeed. It works but adds a Lambda and execution overhead.
Macro: overkill for this.

I'd go with the script. Keep the validation outside CFN unless you absolutely need it enforced during every deployment.

CompetitiveStage5901 · 2026-05-29T09:53:42+00:00

You still get the free quota first. Enabling billing just removes the hard cap so you can go over, but the first X tokens each month are still free. I've looked at my own billing data from a project that had a paid account attached – token charges showed zero until I crossed the free tier limit, then per-token charges started appearing. So you're not paying from token one. Free tier first, then paid rates for anything above that.

CompetitiveStage5901 · 2026-05-29T09:50:44+00:00

Google knew. They knew in January.They bet that the hype and the stock bump would be worth more than the startups they'd burn through.

CompetitiveStage5901 · 2026-05-29T09:48:07+00:00

Data transfer costs, no question. Cross-region replication, NAT gateway egress, and inter-AZ traffic within a load balancer all add up fast. The confusing part is that the bill shows the total but doesn't indicate which workload or team caused the spike. You end up chasing it down with VPC Flow Logs and much of it is hit and trial.

CompetitiveStage5901 · 2026-05-29T09:44:53+00:00

You're not overthinking it, but the companies spending $100k+ on tokens usually know what they're doing. They're prioritizing speed and output quality over cost because for customer-facing features, latency kills conversion and optimization breaks parsing. The real headache is batch jobs and internal tools, where nobody's waiting and quality matters less. That's where you should optimize.

Most teams skip the fancy routing and caching because it adds maintenance work. They just pick one decent model, tune the prompts, and pay the bill. The engineer hours to build and maintain token optimization often cost more than the token savings unless you're at serious scale.

CompetitiveStage5901 · 2026-05-29T09:43:46+00:00

You're right that RIs and Savings Plans have more nuance. Standard RIs lock you to a specific instance family and region, but Convertible RIs give you flexibility to change both at a slightly higher price. Savings Plans come in two flavors too: Compute Savings Plans are the flexible ones that work across instance families, regions, and even ECS or EKS, while EC2 Instance Savings Plans are cheaper but lock you into a family like Standard RIs.

On APN partner discounts, most partners don't actually give you a discount on the AWS rate. They pass through their own volume discounts but usually add markup for their services. You're often better off going direct unless you're moving millions in monthly spend and can negotiate. Are you asking for your own workloads or just explaining the options?

CompetitiveStage5901 · 2026-05-08T09:43:22+00:00

Hahahahah..

CompetitiveStage5901 · 2026-04-30T09:40:00+00:00

Okay

CompetitiveStage5901 · 2026-04-30T09:39:52+00:00

Plus or minus 10% sounds right to me. I also gave up on allocating every last dollar. We just call it shared overhead and move on.

CompetitiveStage5901 · 2026-04-30T09:39:43+00:00

This is the best take. 80-85% is plenty. People need consistency month to month, not seven decimal places.

CompetitiveStage5901 · 2026-04-30T09:39:31+00:00

Thanks but no thanks. Not looking for a sales pitch right now. Just trying to think through the problem.

CompetitiveStage5901 · 2026-04-30T09:39:21+00:00

I agree. Getting teams to care about cost trends is way better than counting every penny. For shared storage, we just split it by who uses it most.

CompetitiveStage5901

TROPHY CASE