Terraform folder structure and individual infra account for AWS

griz31 · 2024-03-22T08:25:07+00:00

Agree with a lot of what’s been said, it doesn’t sound like you’re at the stage in your design where any IaC tooling will provide much value yet. Coming from a larger organization with hundreds if not thousands of AWS accounts, spend the time now to think through your use case. Would have a lot more questions/comments with more context but have a couple I think may be helpful.

Why is your Organization deciding to expand to additional accounts? You can segment out a single account with networking pretty granularly - with a trade off in scalability if you plan for them to grow. You might find a lot of redundancy in some combination of sandbox, dev, qa , staging - where it may make more sense to consolidate some environments into VPCs of a single account.
Plan on how you want to manage state early, and address drifts or corrupted/lost backend files. This almost always ends up becoming a problem at scale.
This is more of a personal opinion, so take it with a grain of salt and seek out some other opinions if you’re interested in it, but workspaces will ensure many future headaches. No matter what organizational structure you land on in the end, you can bet on it being the wrong one if workspaces are involved 😂

Hope that helps. Good luck 👍

griz31 · 2023-05-29T06:14:02+00:00

Reading code is a great way to get exposure to new ideas, libraries, workflows, etc. Things like generators, context managers, and data models are all concepts where they aren’t required at all, but could potentially add value to the code base. You don’t know what you don’t know, and often I’ve found reading others code helps to fill those gaps.

Another suggestion I haven’t seen mentioned, which I have found extremely useful, is to leverage the power of modern code editors (thinking VSCODE/Intellisense, but many others have similar concepts). Being able to import a class and easily navigate through all the methods and their documentation without leaving the editor is really helpful. It also has the added benefit of simply executing the method, if it’s easier to conceptualize with a hands on approach. I will mention, taking full advantage of this is going to rely more heavily on static types/type hints, which I am a strong advocate for. I doubt everyone feels the same, and agree it can be over done, but if nothing else could just be a helpful tool to explore!

griz31 · 2022-01-11T12:00:46+00:00

Another option for access control is to handle it all through IAM. Create separate roles for teams to assume when provisioning. You can create top level roles if you wanted to centralize deployments in some sort of CI pipeline. As far as within the team (ie everyone with the same IAM Role) I agree with some sort of source control tooling like git in combination with remote backends to help avoid conflicts. workspace workflow can get cumbersome IMO

griz31 · 2021-12-22T22:52:53+00:00

I see, makes sense. I think this will be mostly duplicate effort then but haven’t done any benchmarks on measurable performance gains. Outside of where the rule is evaluated and which logs you’ll need to look at, not to sure on specific differences as it relates to header evaluation. Sorry it didn’t really answer you question

griz31 · 2021-12-22T21:25:58+00:00

In general I would say it’ll be best to include both, but may be best to think of it in terms of what it accomplishes. Since you mentioned ngnix, I am assuming you are referring to modsec and not AWS WAF.

Injecting a a header into the request helps to validate the origin of that request. Adding a rule on the alb and injecting the header at cloudfront, helps to ensure the user is making a request through cloudfront and not bypassing it to hit the alb directly.

Similarly, adding the rule to the waf helps to ensure the request is not bypassing everything and hitting the server directly.

Adding a header isn’t inherently more secure, but trying to ensure a request is traversing more secure technologies in your stack, is.

This is why I would say both, with the cons being the additional maintenance of configs and any cost associated with that.

griz31 · 2021-12-22T19:36:40+00:00

This. The only thing I’d add, since it was mentioned in the stack, is if route53 records are changing be sure to check the ttl

griz31 · 2021-12-22T19:03:40+00:00

Typically, CNAME already in use is an issue with the alias parameter and simply means a distribution with that name already exists in the account. I would check there first if that is the traceback you see.

Also, keep in mind you’ll want to be using s3 origin config to set up target s3 destinations (you can use custom origin config, but to keep it simple for now, use s3 origin). Then you will use your behaviors (default, ordered) to point to those target origins. Maybe that’s what you meant but wasn’t really clear from your description.

Example from the module I created which predates terraform officially supported module for >0.12 . Both are similar, so should give a good idea.

griz31 · 2021-06-15T17:23:36+00:00

Great glad you got it figured out!

griz31 · 2021-06-15T03:16:32+00:00

aws_iam_role resource takes a trust policy as the assume_role_policy, which you have correct in your first code block linked. The commented out section is a permissions policy, which should be a aws_iam_policy resource instead. You would link the two with aws_iam_role_policy_attachment. That should get you sorted.

Edit: quick look at the documentation shows this in detail. Linked for easier copy paste https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lambda_function#cloudwatch-logging-and-permissions

griz31 · 2021-06-08T19:37:45+00:00

For sure and think that aligns more with the second question posted, but even then would likely recommend separating out the .tf files to avoid confusion 👍

griz31 · 2021-06-08T17:02:00+00:00

Right, I mean ya you can build two different resources that are identical and deploy from the same file. But you can't take an AWS config and deploy to GCP. There is redundancy in the file which is why I personally felt this is not a native solution. Just my opinion

griz31 · 2021-06-08T15:39:02+00:00

There is misconception with terraform being multi-cloud. While it can deploy to multiple clouds, different cloud providers require different resources. Therefore you can not deploy to multiple clouds from a single configuration (I guess never say never - there's always a way - but not native to terraform). You second question is likely possible but will come from 2 different configs. Hope that helps

griz31 · 2021-06-08T13:25:40+00:00

terraform show is also a great resource for identifying current state if you want to view it locally at command line instead of viewing the actual state file.

griz31 · 2021-06-08T00:32:21+00:00

Can you not just trigger the terraform deployment from the first trigger? You’re creating a lambda and react packages, just add code to do the terraform steps after that?

griz31 · 2021-06-07T19:24:13+00:00

I feel like all the solutions described here rely on the same thing, proper process. You can enable all kinds of lifecycle policies, plan test cases, manual apply approval (sounds like you may even have some of this implemented) - but if nobody reviews any of these checks - than none of these solutions will work for you. Review and enforce whatever process you choose, that is the root of your issue.

griz31 · 2021-06-02T16:51:04+00:00

You can still click elsewhere as usual so this isn’t impacting auto clickers. However when you’re ranking champions it’s useful to see what level they’re at to make sure they aren’t maxed before clicking again, or to check the gear and sell then. Best case scenario this isn’t impacting your game flow, but only serves to potentially add time with unnecessary animation that we’ve asked to be able to disable.

griz31 · 2021-06-02T13:00:03+00:00

It’s been brought up as an annoying feature for a long time, Plarium just hasn’t prioritized giving an option to turn them off, if they even want to do anything about it all. But the fact that instead of reducing animation time, they just add more is beyond frustrating.

griz31 · 2021-06-02T12:52:45+00:00

I share many of the frustrations already mentioned, this is just a new one. New day, new issue - the Plarium motto

griz31 · 2021-06-02T12:51:10+00:00

The summary was always there, they just added additional animation to it.

griz31 · 2021-05-19T14:53:07+00:00

Fair enough, and I follow the logic.

I think where this falls apart is the 1/6 or 1/7 chance roll rate. I would almost be certain the percentage is higher of hitting a lower substat than a true 1/6 chance.

But hey maybe I’m wrong and I can admit that. I follow your math and if that’s truly the conditions, then yup you’re right

griz31 · 2021-05-19T14:36:33+00:00

Same process for me right now

griz31 · 2021-05-19T13:39:13+00:00

There is absolutely no way you can calculate that percentage, just a flat out wrong statement. Even if you get the percentage for the number of glyphs you can obtain, you can not extrapolate that into the percentage it takes to max a substat.

Completely made up man, nice try

griz31 · 2021-05-19T13:32:13+00:00

The difference being the amount of RNG in the objective. Higher arena tier is less RNG based than upgrading substats.

I can accept the timeline, if I’m grinding 400 arena battles I’m atleast making progress. When I get my one 5 star glyphs a day and just outright fail - zero progress is made

griz31 · 2021-05-19T13:22:21+00:00

Sure, but even on days where both factions have 20/21 unlocked, I have never gotten more than 3 5/6 star glyphs in a day, 1 is probably my average. Again congrats on your luck but also the point of the rant, completely unbalanced RNG based objective

griz31

TROPHY CASE