rcrowley

7 ms·

31.
by rcrowley 3y ago
That does work well for environments because typically you’d run exactly the same code, maybe with different cluster sizes or instance types, in each environment. But it doesn’t work well for isolating two services where the code is signifi
32.
by rcrowley 3y ago
Glad we cleared up our terminology! I agree that “root module” risks ambiguity, just like you point out. I just realized I never responded to the very last point in your original comment. I don’t have, and I don’t think Terraform has, a com
33.
by rcrowley 3y ago
I stuck with my typical term, root module, synonymous with how folks are using “stack” and “state” in various parts of this thread. A module is any directory with Terraform code in it. A root module is one that has a configuration for how t
34.
by rcrowley 3y ago
(Hi, I’m one of the authors of the article at the root of this thread.) Considering your hypothetical stateless microservice change in the same root module as stateful services, problems arise when _someone else_ has merged changes that con
35.
by rcrowley 3y ago
(Hi, I’m one of the authors of the article at the root of this thread.) I’ve gone back and forth on workspaces versus more root modules. On balance, I like having more root modules because I can orient myself just by my working directory in
36.
by rcrowley 4y ago
It’s set in Computer Modern, the font Donald Knuth designed for TeX and which you most often encounter in academic papers.
37.
by rcrowley 4y ago
All rings true, to me.
38.
by rcrowley 4y ago
We created a second GSuite for GCP at Slack because we didn’t want email and other corp IT assets to be mixed into what could’ve (but didn’t) become production infrastructure.
39.
by rcrowley 4y ago
Honestly, having lived a parallel life to the Windows ecosystem, TIL about “red forest.” I do think, though, that cross-account AWS actions are much more first-class than it sounds like jumping between forests ever was.
40.
by rcrowley 4y ago
The same link’s in the second sentence of the article. But, sure, I forgot.
41.
by rcrowley 4y ago
In the meantime, check out Substrate < https://src-bin.com/substrate/ > and don’t worry about waiting for AWS to improve.
42.
by rcrowley 4y ago
Interesting. Thanks for the detailed response. Another, positive way to look at one aspect of your architecture is that the AWS account boundary prevents most cases of dueling configuration management, with two tools changing the same resou
43.
by rcrowley 4y ago
I’d love to hear more about your experience with shared VPCs. What’s inherently unstable about them?
44.
by rcrowley 4y ago
That UX is atrocious. Substrate [1] instead presents you with a list of all your accounts with a link to assume your role in that account in the AWS Console (and parallel tools for assuming that role in a terminal, too). [1] < https:&#x2
45.
by rcrowley 4y ago
AWS recently added the organizations:CloseAccount API (albeit with some caveats discussed elsewhere in this comment tree).
46.
by rcrowley 4y ago
Actually, as of Friday, that’s no longer true. \o/ < https://aws.amazon.com/about-aws/whats-new/2022/09/aws-updat... >
47.
by rcrowley 4y ago
Curious / product research: Are your 38 accounts all in the same organization? Do you have any human IAM users left or is it all IdP, all the time? Do you use Terraform or anything like it? Also, yes, a pox on the single-player AWS Con
48.
by rcrowley 4y ago
Service limits for regional services like EC2 are regional. Service limits for global services like Organizations appear to only be manageable from us-east-1.
49.
by rcrowley 4y ago
This is a bummer, yes. I haven’t looked but I wonder if that 10% is a soft limit. At any rate, this is a good reason to use accounts for architectural divisions, not teams, and certainly not individual engineers.
50.
by rcrowley 4y ago
Control Tower is cool if the problem is “I need lots of AWS accounts.” Substrate [1] is cool if the problem is “I need to accomplish something and I’m cool with using lots of AWS accounts to do it.” [1] < https://src-bin.com&#x
51.
by rcrowley 4y ago
Actually upgrading your Support plan is one of the very, very few things you still need to break into the root of each account to do. However, if you’re big enough you just sign an EDP contract that forces all your accounts onto Enterprise
52.
by rcrowley 4y ago
You’re absolutely right, I’ve fucked up plenty. That’s why I believe so strongly in making the right thing the easy thing. I think I’m doomed if it’s critical for tags to be perfect because they always drift, doomed if IAM policies must be
53.
by rcrowley 4y ago
As the other commenter notes, no, you still have just one bill. Better, though, that one bill is broken down by account so you can see where the money’s going.
54.
by rcrowley 4y ago
Author here: I have settled on account per service per environment with a couple of exceptions. Sometimes I run multiple services in one account if they’re so tightly coupled as to be useless as a group if any one is down. (This has practic
55.
by rcrowley 4y ago
Substrate [1] is meant to lessen the investment required to use lots of AWS accounts. Would love to know how it looks to you. [1] < https://src-bin.com/substrate/ >
56.
by rcrowley 4y ago
Substrate [1] is meant to help folks not make a mess of lots of AWS accounts. Would love to know if it feels less enormous. [1] < https://src-bin.com/substrate/ >
57.
by rcrowley 4y ago
actual lol
58.
by rcrowley 4y ago
Synchronizing ~/aws/config gets harder and harder as your team grows because there are both more people who need to receive changes and more people making changes. I think the human-readable names for AWS accounts need to be part
59.
by rcrowley 4y ago
I have thought a great deal about whether I also want EKS clusters to officially support nodes in multiple AWS accounts. On the one hand, having the option to create that additional low-level isolation would be lovely, even and maybe even e
60.
by rcrowley 4y ago
I'm not honestly sure how AWS Organizations interacts with the AWS free tier. Rest assured, though, having lots of AWS accounts (and using AWS Organizations, their service designed to _help_ you use lots of AWS accounts) is _not_ again

More ›