troposphere VS aws-cli

Under the IaC category, in July 2023, AWS added loops to CloudFormation, finally ticking a box the community has been asking for since troposphere. I suspect that, in combination with the Terraform licensing changes, it may keep people using CloudFormation for a while longer.

Because ECS Compose-X uses Troposphere, I was able to create a very light and simple python library(https://github.com/JohnPreston/troposphere-awscommunity-applicationautoscaling-scheduledaction) to distribute the resource for other Troposphere users to re-use.

Written in house, but the library troposphere is the primary component of how it is built. Example stacks are here.

I am kind of going off topic here, but isn't the point of being an SA to be created with code services to deliver solutions at scale that are cost-effective? How in the hell can you do that when you can't write a simple Python template that generates code at 50 times the rate you can manually? How can you ever be expected to deploy a serverless solution if you can't write any code yourself? There has to be some level of proficiency there.

Wouldn't using troposphere[1] be easier?

[1] https://github.com/cloudtools/troposphere

You might have seen some tutorials on how to set up S3 buckets using the AWS Console. This works fine, but I'm a firm believer of managing your resources with code. I've chosen the native solution of AWS, called AWS CloudFormation. This makes it easier to reproduce the setup if I ever need to tear it down of move it to another account or region. Below is the full CloudFormation template, I've used a framework called Troposphere, a Python library that creates CloudFormation.

For CF for example I no longer write template in yaml or shudders json, and instead I use troposphere.

refer : https://github.com/cloudtools/troposphere

The AWS CLI is a must-have tool if your team relies on Amazon Web Services. It lets you effortlessly interact with AWS services, orchestrate resource management, and automate tasks from the comfort of your terminal. Once you get used to the tool, you'll notice how convenient and quick it is to fit into your processes – especially compared to going through AWS's web-based user interface.

Just for your consideration, the network effect is very real with package managers, too:

https://search.nixos.org/packages?channel=23.05&show=awscli2 is 2.11.27 (even on the "unstable" channel), versus https://formulae.brew.sh/formula/awscli#default that is 2.12.1, which correctly is the most current (https://github.com/aws/aws-cli/tags)

s3fs allows Linux, macOS, and FreeBSD to mount an S3 bucket via FUSE(Filesystem in Userspace). s3fs makes you operate files and directories in S3 bucket like a local file system. s3fs preserves the native object format for files, allowing use of other tools like AWS CLI.

AFAIK it's still a Python package: https://github.com/aws/aws-cli/tree/2.11.6

Check CLI version, it looks like the earliest version that had DEEP_ARCHIVE support was 1.16.133 (https://github.com/aws/aws-cli/commit/55efab102f774ef17bf51ad32e939e4e03a5ff8a)

And this is the init_localstack.sh file content, a unique thing about localstack its that you can move all strings like an aws-cli tool, also the container deletes all the content and config once the container stops, so the script file must create all the resources that you need from Localstack

It can? I created a pull request for this that hasn't been merged yet: https://github.com/aws/aws-cli/pull/6365