3 messages
Discussion related to Amazon Web Services (AWS)
Archive: https://archive.sweetops.com/aws/
Michael17 days ago
Curious how everyone is handling deprecated Lambda runtime upgrades at scale? We have a few hundred functions running across multiple AWS accounts and looking for some creative approaches
Yota12 days ago(edited)
Hello,
Here’s a quick overview on my experiments with infra-as-code here. I’ve started using ACK/KRO/FluxCD/Helm to deploy Kube applications that need AWS resources:
• KRO (https://kro.run) allows you to define a resource graph.
• ACK (https://github.com/aws-controllers-k8s/community) lets you manage AWS resources from Kube.
Advantages:
• It's a natural integration with ArgoCD/Flux.
• Declared as YAML (no more yaml/json/hcl mix) in Git and applied directly to the cluster.
• Developers only need to interact with the Kubernetes (already the case). They do not need to learn Terraform or manage Terraform state files.
• With KRO, I can define custom, simplified APIs for developers, hiding the underlying complexity of cloud resources and Helm deployments behind a single custom resource.
• No more he "Two-State" problem (tfstate and Kubernetes state).
It’s really promising.
I hesitated to use Helm provider in Atmos, but that would mean granting extensive AWS permissions, and I would then lose Kube’s reconciliation loop and the ability to manipulate objects from Kube.
Here’s a quick overview on my experiments with infra-as-code here. I’ve started using ACK/KRO/FluxCD/Helm to deploy Kube applications that need AWS resources:
• KRO (https://kro.run) allows you to define a resource graph.
• ACK (https://github.com/aws-controllers-k8s/community) lets you manage AWS resources from Kube.
Advantages:
• It's a natural integration with ArgoCD/Flux.
• Declared as YAML (no more yaml/json/hcl mix) in Git and applied directly to the cluster.
• Developers only need to interact with the Kubernetes (already the case). They do not need to learn Terraform or manage Terraform state files.
• With KRO, I can define custom, simplified APIs for developers, hiding the underlying complexity of cloud resources and Helm deployments behind a single custom resource.
• No more he "Two-State" problem (tfstate and Kubernetes state).
It’s really promising.
I hesitated to use Helm provider in Atmos, but that would mean granting extensive AWS permissions, and I would then lose Kube’s reconciliation loop and the ability to manipulate objects from Kube.
Michael6 days ago
Curious if anyone is doing self-service AWS accounts without control tower? Looking into creating a service catalog to make self-service provisioning easier for teams, but curious how others approach this when managing the resources in IaC