terraform-provider-aws
aws-sdk-go
Our great sponsors
terraform-provider-aws | aws-sdk-go | |
---|---|---|
99 | 34 | |
9,443 | 8,548 | |
1.0% | 0.3% | |
10.0 | 9.4 | |
1 day ago | 1 day ago | |
Go | Go | |
Mozilla Public License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
terraform-provider-aws
-
AWS EKS: From IRSA to Pod Identity With Terraform
For Terraform, instead, a new version of the AWS module supports a dedicated resource.
-
Authorization and Amazon Verified Permissions - A New Way to Manage Permissions Part XII: Terraform
If we check the support for the Terraform AWS Provider here (state for the date of publishing this article), we will see that the service is not yet fully supported. Last week, after more than half a year, support for creating a policy store was added. Additionally, we have the configuration to add template policies. However, the identity source is in the form of a PR draft, and there is no PR yet for the ability to create policies.
- 10 Ways for Kubernetes Declarative Configuration Management
- obsidian terraform code support (hcl)
-
HashiCorp silently amend Terraform Registry TOS
https://github.com/hashicorp/terraform-provider-aws/issues/3...
The size is what you get when you add every single AWS Go client into one binary.
Each service client like 1-2MB. But when you have 200 services....
-
Unveiling the Speed Mystery: Investigating Slow S3 Uploads from AWS EKS Pods
Issue with EC2 Instance Metadata running inside Container
-
A Cloud Development Troubleshooting Treasure Hunt
Well, at least we now have a promising lead. Some diligent googling and browsing through Github issues in the AWS provider project yielded no directly related findings. However, I did come across a few recent bug reports about the recent change AWS made regarding the treatment of public buckets. And interestingly, they described precisely the behavior I was encountering.
-
Changing VPC flow Log parameters plan also shows VPC nacls changing multiple values to null
Latest version of TF but seems to be same Issue as this which has already been submitted : https://github.com/hashicorp/terraform-provider-aws/issues/10611
-
aws_wafv2_web_acl: How do I do dynamic rule and rule overrides?
Look at this; I think the provider is just screwed up: https://github.com/hashicorp/terraform-provider-aws/issues/28672
-
Converting Full Terraform Programs to Pulumi
> We're coming up on 10000 resources in our main Terraform repository and while there is definitely some friction, it's overall much better than having to hit the cloud API's to gather each of those states which would probably take at least an order of magnitude longer.
I don't think that's necessary true. Most cloud API's actually can return hundreds of records with 1 API calls, e.g. https://docs.aws.amazon.com/elasticloadbalancing/latest/APIR... has a maximum page size of 400.
If I manage the cloud resources via some custom tools and/or with some ansible-fu, I can decide to batch the API calls when it makes sense.
With terraform, it is not possible to do so (https://github.com/hashicorp/terraform-plugin-sdk/issues/66, https://github.com/hashicorp/terraform-provider-aws/issues/2...).
aws-sdk-go
- my first go project, a CLI application to store IP addresses
-
Go 1.21 will (probably) download newer toolchains on demand by default
I'm... really not sure I agree with this, from a philosophical point of view. It feels like this is making "eh, we'll just upgrade our Go version next quarter" too easy; ultimately some responsibility toward updating your application's Go version to work with what new dependencies require should fall on Us, the application developers. Sure, we're bad at it. Everyone's lived through running years-old versions of some toolchain. But I think this just makes the problem worse, not better.
Its compounded by the problem that, when you're setting up a new library, the `go` directive in the mod file defaults to your current toolchain; most likely a very current one. It would take a not-insignificant effort on the library author's part to change that to assert the true-minimum version of Go required, based on libraries and language features and such. That's an effort most devs won't take on.
I'd also guess that many developers, up-to this point if not indefinitely because education is hard, interpreted that `go` directive to mean more-of "the version of go this was built with"; not necessarily "the version of go minimally required". There are really major libraries (kubernetes/client-go [1]) which assert a minimum go version of 1.20; the latest version (see, for comparison, the aws-sdk, which specifies a more reasonable go1.11 [2]). I haven't, you know, fully audited these libraries, but 1.20 wasn't exactly a major release with huge language and library changes; do they really need 1.20? If devs haven't traditionally operated in this world where keeping this value super-current results in actually significant downstream costs in network bandwidth (go1.20 is 100mb!) and CI runtime, do we have confidence that the community will adapt? There's millions of Go packages out there.
Or, will a future version of Go patch a security update, not backport it more than one version or so, and libraries have to specify the newest `go` directive version, because manifest security scanning and policy and whatever? Like, yeah, I get the rosy worldview of "your minimum version encodes required language and library features", but its not obvious to me that this is how this field is, or even will be, used.
Just a LOT of tertiary costs to this change which I hope the team has thought through.
[1] https://github.com/kubernetes/client-go/blob/master/go.mod#L...
- How to get better on golang
-
Send an Email through AWS SES with GoLang
This email was sent with " + "Amazon SES using the " + "AWS SDK for Go.
-
Looking for library recommendations: Django -> Golang port
I figured I'd ask the community for some recommendations for the following capabilities that Django + python stack is giving me at the moment: 1. Amazon SES Mailing (considering - aws-sdk-go) 2. Django Admin (considering go-admin 3. Django Signals (considering syncsignals 4. Celery (No contenders here)
-
S3 upload with progress
I've been trying to implement some logging of progress when uploading objects to S3. My code is building on this example and can be found here.
-
Background process in Lambda using SQS
Now that you have everything you need, let’s install the AWS SDK for Go library.
- Node.js 18 support in Lambda added to Go SDK
- Node.js 18 Runtime support added to Golang SDK
-
AWS and its complicated shit needs to die
Counterpoint 2: Amazon is bad and should feel bad for making this an internal and embedding it in the Credentials struct.
What are some alternatives?
crossplane - The Cloud Native Control Plane
minio-go - MinIO Go client SDK for S3 compatible object storage
terraform-provider-lastpass - Terraform Lastpass provider
Moto - A library that allows you to easily mock out tests based on AWS infrastructure.
cognito-custom-email-sender-lambda - AWS Cognito custom email sender Lambda trigger
botocore - The low-level, core functionality of boto3 and the AWS CLI.
rover - Interactive Terraform visualization. State and configuration explorer.
twitter-scraper - Scrape the Twitter frontend API without authentication with Golang.
terraform-provider-opsgenie - Terraform OpsGenie provider
cachet - Go(lang) client library for Cachet (open source status page system).
terraform-provider-snowflake - Terraform provider for managing Snowflake accounts
paypal - Golang client for PayPal REST API