#aws (2024-10)

But what is the question. You can use ECS in that way. If your process doesn’t need to be awake and polling or some such all the time and you don’t need to manipulate the environment much, Lambda is great for scheduled workers. You can use a scheduled event to trigger the Lambda, do the work and then stop. But you definitely can use ECS / Fargate similarly. For example, you don’t have to run a service. You can just call the ECS API to schedule a task, and that task just does its work then halts.

cross post from refarch - let’s use that one instead

https://sweetops.slack.com/archives/C04NBF4JYJV/p1728659490005569

Yes it’s that easy

See this blog post

https://aws.amazon.com/blogs/security/build-an-end-to-end-attribute-based-access-control-strategy-with-aws-sso-and-okta/

gotcha, given that SCIM is being used

are updates real time?

for example, if the user gets pushed over a tag because they were temporarily added to a group with a custom attribute…

when they get removed from the group, will aws remove the tag from the user?

in theory, it SHOULD, but given that SAML assertions are evald at logon, im a bit unsure if that tag would remain on the user until they re auth

also I looked at that blog post a while back, and something that makes me skeptical is no mention of custom tags

but I’ll give it a shot

im pretty sure it works for user profile attributes, but looks like it doesn’t for group attributes :(

https://support.okta.com/help/s/article/okta-push-group-does-it-support-custom-group-attribute-for-group-push-mapping?language=en_US

Oh yes i don’t believe it works for group attributes, only user attributes. At least, that’s as far as i tested

You could probably add some automation. If user is in group x, grab group attributes and add to user

Reverse automation if the user is removed or not in the group, the group attributes should then be removed from the user

yeah I was trying to avoid any custom automation :(

in this case with okta workflows

the switch from Redis to Valkey took about an hour (just waiting for the status to update from Modifying to Available) for a 2 node cluster. Everything seems to work out of the box with no other changes necessary.

I will update on costs once I have some better numbers

I changed redis instance to valkey and everything works like a charm

after running Valkey for a week, we are seeing slightly more than 20% reduction in costs, and no issues

if everything is running in a single VPC, then transit gateway doesn’t have any value for you

transit gateway would be useful if you split network into VPCs/accounts

As others have indicated based on solely the description above, it’s hard to identify how a transit gateway would help. However, let me describe how we use them in the event that it is also what you were maybe contemplating. In reference architecture, we have the concept of a platform organizational unit or OU. In this OU, we have dev, staging and production accounts. Each of those accounts has a VPC. None of those accounts need to talk with each other. Separately, we have another OU. We call that core. In this OU, we have a number of accounts that we call singletons that form the core organizational accounts for our organization. One of those is an automation account used for hosting runners for CICD. And another is a network account. The automation account to be able to connect to clusters inside of each of the platform accounts we need network connectivity. This is used to provision things, for example, on kubernetes or to manage users on databases, using something like the postgres terraform provider. To make all of that possible we use a transit gateway with a hub deployed in the network account. Then each of the accounts are connected as spokes hub. we can set up routing to permit certain accounts to talk to others. For example, the automation can talk to everything but individual SDLC account cannot.

The main reason to have an architecture like this so that you can have account level IAM boundaries. This is necessary as an organization grows because you’ll have multiple owners. Somebody might need to be an administrative network admin, but doesn’t have any access to do non-networking things in other accounts. Restricting I am by tags or other dimensions is complicated and it’s much much easier when you start breaking your infrastructure into accounts this way.

@Erik Osterman (Cloud Posse) @andrey.a.devyatkin @loren Thank you for the response!

I tried to get this going, but couldn’t figure it out. It also hasn’t been updated in a while https://github.com/edmunds/shadowreader

If there is no cloud-native way to achieve this on the ALB level then probably I would go with Envoy Proxy, so then you need the proxy itself without any Lambdas

AWS VPCs supports traffic mirroring on the network level, AWS published a blogpost and tool to decode HTTP requests and replay them to another backend: https://aws.amazon.com/blogs/aws/amazon-aurora-postgresql-limitless-database-is-now-generally-available/

(it doesn’t support h2 and I wouldn’t expect it to perform very well under significant load)