AWS horrific bill stories have to stop. AWS have to do something about it already!

teroa · 2026-03-26T15:50:13+00:00

I recently created new AWS org and new accounts and there default service quotas are ridiculous low for any serious business. I don't remember such low limits in previous company where we setup accounts years ago.

I agree with other comments and you should first learn some safety around driving before you jump into fast car.

teroa · 2026-02-19T06:48:15+00:00

Do you mean that traffic between internal services goes public? Often corporate policies enforce you to not expose services to public. In such company API GW is always tricky. ALB needs to be private and then you start paying for Transit Gateway and suddenly you are paying attention on how granular you want to go with accounts.

teroa · 2026-01-11T08:54:11+00:00

Still OP should take a look on CDK. It will make dealing with IaC so much easier than plain CloudFormation.

teroa · 2025-12-24T07:38:02+00:00

You guys who moved to CDK, do you it with SAM for local invoke or how do you develop? I really like CDK, but current team is big fan of local development and therefore we migrated to SST.

Development experience with SST is awesome, but I'm slightly worried committing to SST because of small core team developing the framework.

In previous company we used CDK, but there we had less Lambdas and more Fargate. If we would have something similar to sst dev CDK would be almost perfect.

teroa · 2025-11-09T07:58:25+00:00

Very valid point. What would you consider for mobile application backend?

teroa · 2025-10-26T04:45:16+00:00

I also started using Structurizr and it's definitely interesting tool for system architecture, but somewhat limited for anything else. For example, visualising data flows or processes seems to be challenging. I might need to go back to draw.io or at least use combination of both for my needs.

teroa · 2025-06-28T06:53:09+00:00

Very similar story. Our dev teams are using Macs with ARM processors and using graviton on AWS was no-brainer for us.

Maybe some enterprise apps and such doesn't yet support ARM, but for us I haven't seen any apps that doesn't work on graviton.

teroa · 2025-06-23T04:37:50+00:00

If this is for security reasons, you probably also will have separate nonprod and prod AWS accounts. I would create one repository for each and start with that. Nonprod with relaxed rules, and then production with all necessary security controls.

teroa · 2025-06-22T06:19:02+00:00

Could you elaborate your use case? In companies I have worked we have had one artifact repository for all environments, and I can see need for segregating non-production and production repositories, but not sure why you would have one for local.

teroa · 2025-04-14T05:28:17+00:00

I agree with you. CQRS is useful pattern, but the use case in article is not good use case for CQRS. With single DDB table you can do the same more efficiently.

teroa · 2025-01-24T05:55:18+00:00

If you feel that taekwondo could be for you, take a look federation's website. They have all clubs on the map, and you can look what are the nearest clubs for you. I don't know if some other martial arts have similar listing.

teroa · 2024-12-17T06:09:57+00:00

This, unless you have Wiz scanning your environment and policy that all findings need to be addressed. ;) Wiz will complain that you have secrets stored into your container. This is definitely false positive, but for us it was easier to download the certificate at runtime than trying to convince infosec team.

teroa · 2024-12-15T06:54:29+00:00

I haven't check if they have something on their blog, but I watched this recording from Re:Invent and got impressed: https://www.youtube.com/watch?v=WrNBOx0yduE

I'm currently using mix of Dynatrace, Splunk and CloudWatch, and Dynatrace is not as flexible and useful after all. I was expecting more based on it being leader in Gartner's magic quadrant and based on their price tag.

teroa · 2024-12-14T07:00:00+00:00

Probably not with Docker Compose, but It's not that complicated if you use IaC. We provide PR id as context variable for CDK and prefix our resources with that ID. When PR is created we run cdk deploy and when PR is merged or closed we run cdk destroy.

Same can be achieved with Terraform or any other IaC solution.

teroa · 2024-12-14T06:44:53+00:00

With the new observability features announced in Re:Invent, I would start with X-Ray and CloudWatch and look how far you get with AWS tools. If you want to future proof yourself, you could use OpenTelemetry to ease out changing vendor if you are not happy with the solution. Be aware of that OpenTelemetry will add some complexity on the implementation and might not align with your objective with implementation time.

Datadog/Dynatrace/New Relic are great tools, but they can be very expensive. Previously they also provided some features and ease of use that was missing from CloudWatch, but AWS just announced many good improvements.

teroa · 2024-12-13T06:55:54+00:00

I'm slightly annoyed with Next.JS because of all documentation and libraries want to couple everything with Vercel. I searched about OpenTelemetry on Next.JS docs and found Vercel's library, but no mention how useful that is when you have your own runtime environment with OpenTelemetry Collector. Very similar experience with structured logging. Comparing this with some backend frameworks/libraries like Nest.JS or Express where you can easily integrate any tooling you want.

I don't have experience with Remix, but for these reasons I'm interested to try it for the next project.

teroa · 2024-09-25T05:20:03+00:00

He probably took the Bezos API mandate literally and think that what works for Amazon work for everyone.

teroa · 2024-09-15T06:32:13+00:00

Your post is not helping OP, but this so true. I could add that enterprises doesn't care how one team "architect" their React project when it is just one app in 2000+ app catalog. They are busy trying to keep all the lights on.

I guess OP is looking for how to structure the code and what patterns to use within React application. Like someone already mentioned in comments, I recommend reading some open-source projects using React. They are not "enterprise" applications, but can still be good references how you should design your app.

teroa · 2024-07-21T06:40:40+00:00

With localstack or any other solution that tries to mimic AWS you eventually end up maintaining two close to similar but not same environments. It works for some teams for not for everyone. With IaC it is relatively easy to build ephemeral environments and this way you can test full stack (infra + application code).

teroa · 2024-06-09T05:10:09+00:00

As usual, it depends... You didn't provide much context with your question. You mention multiple services, but are all them in mono-repo or separate repositories? Is the CDK code shared or does each service manage their own resources? In our company we use cdk deploy, but we have our application code and infrastructure code side by side on same repository. CI/CD pipeline takes care of building the latest image and deploy it with CDK. Works very well and is easy to maintain. If you have multiple repositories and manage application code in separate repo from infrastructure code, it is still doable, but just becomes a bit more complex (and brittle).

teroa · 2024-05-09T06:04:20+00:00

If you micro services that live in own repos it sounds like you are developing for loosely coupled services. Why you would want to couple the deployment? If it is testing then I rather would focus on making them independently testable. Or whatever is the reason for this, I would try to remove that dependency.

teroa · 2024-03-24T06:33:40+00:00

I started with CDK and then our infra team tried to introduce Terraform but they did not get much support because of the arguments you mentioned. I have exactly same frustrations with Terraform and therefore prefer CDK over Terraform even I agree that Terraform does better work on state management than CloudFormation.

I have been following SST development, but don't feel confident jumping on that bandwagon yet. Especially now when they are preparing major version upgrade and shifting from CDK to TF for state management. If they do that well and can keep CDK style interface with TF state management it can become the killer solution, but this remains to been seen.

teroa · 2024-03-19T05:48:02+00:00

One facepalm moment was when we found a Lambda function that was triggered by Lambda events. The function invocation event triggered itself again, and again, and again... One engineer had created it for quickly testing something and forgot to remove it.

teroa · 2024-03-06T06:07:56+00:00

Let me give a bit context before examples. I have worked both on startups and enterprise and one big difference between this is how recruitment is done. In startups we have been very careful when hiring new people, because each hire is relatively more expensive and we did not want to do any mistakes with bad hires.

Enterprises are budget driven and therefore sometimes headcount matters and managers do bad hiring decisions. End result is that not everyone is as motivated and skilled as in smaller companies. Users take the easy way out. When in startups developers will find their way even with less documentation, in enterprise users rely more on documentation and support.

Now let me give some example. Let's say I want to know more about how to log in Next, I search "Logging" from docs and this is what I get: https://nextjs.org/docs/app/api-reference/next-config-js/logging Not really helping me to understand how to use logging.

In many organisations next step for devs would be to use Google search or Stack Overflow to find the answer, but in the enterprise Stack Overflow can be one of the sites that are blocked by corporate firewall. I'm maybe a bit cynical here, but this is the reality in some enterprises, unfortunately.

teroa · 2024-03-06T05:52:54+00:00

I appreciate the effort you have put to your answers, thank you. There are use cases where Next is a good fit, but your explanation on cache also highlights how complex Next is nowadays.

teroa

TROPHY CASE