AWS Cloud Control API, a Uniform API to Access AWS and Third-Party Services

I&#x27;m really excited that Pulumi supports this from day one: <a href="https:&#x2F;&#x2F;www.pulumi.com&#x2F;blog&#x2F;announcing-aws-native" rel="nofollow">https:&#x2F;&#x2F;www.pulumi.com&#x2F;blog&#x2F;announcing-aws-native</a>.

Since this is from CloudFormation team, what can we expect about the performance vs calling the APIs directly? CloudFormation is not known for its speed.

Luc van Donkersgoed wrote a blog post about inconsistent AWS APIs just a week ago [1]. Funny coincidence.<p>[1]: <a href="https:&#x2F;&#x2F;www.lastweekinaws.com&#x2F;blog&#x2F;how-aws-dumps-the-mental-burden-of-inconsistent-apis-on-developers&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.lastweekinaws.com&#x2F;blog&#x2F;how-aws-dumps-the-mental-...</a>

Each API still needs to have its own custom body, with specific mandatory keys and values. The name of the verb is just another key and value ... so how is this different from existing APIs? Not different much.<p>The only addition introduced here is the support for third-party CloudFormation resources. So the same AWS APIs can now be used to directly manipulate third party resources without using CloudFormation at all.

I don&#x27;t know why hashicorp and pulumi are all smug about this. In one go it&#x27;s destroyed half their moats.

Pretty awesome. Now IaC tools like Pulumi will be always up-to-date.

They only released support for it for the legacy AWS CLI v1, but not for AWS CLI v2.

I wonder how long before this becomes a standard like swagger. People will create a spec for a well-known endpoint and probably call it CURDL that allows APIs to be self documenting and automatically compatible with a general universal API client. No one will have to maintain their own clients any more and everyone will wonder why it took so long to think of this...

I don’t understand how this changes something? Now the type of resource you want to create and many different bodies depending on that will be inside the CreateResource instead of whatever function the specific AWS API had.

I feel like the more complex corners of the AWS resource model (e.g. offer-accept stuff between accounts, in TGW for example) are going to get over simplified behind this CRUDL API.

My use case is for mostly read-calls. I just tried it for DynamoDB Table, SQS Queue, SNS Topic, and EC2 Instance, Kinesis Stream. With these resources, only Kinesis supports List call. SQS Queue &amp; SNS Topic does not even support READ. It might be useful for resource creation, but I would go nuts to discover what resource and what APIs are supported.

It is super interesting to me that they now have essentially a declarative API in CloudFormation and now this corresponding imperative version with the same format. I&#x27;m not quite sure why you would need the imperative version. Anyone have any ideas? Couldn&#x27;t Pulumi have just compiled their code into CloudFormation and deployed it?

Yo more complexity ! They(AWS) should hire the UX team from &quot;Hetzner Cloud Services&quot; - sure it doesn&#x27;t have the same features, but dammit it&#x27;s super easy to navigate.

What does this change compared to the current status ? Terraform&#x2F;Pulumi&#x2F;AWS CDK already use AWS API. Is it just about having consistent API calls naming ?

Hmm this would also be nice for ansible.

Interesting. One could see this being a way to operate cloud resources through a Kube API.

Just buy Pulumi already and have them do it the way it&#x27;s supposed to be. It&#x27;s ridiculous that AWS documentation usually contains dozens of error prone manual steps.

There&#x27;s an xkcd for that: <a href="https:&#x2F;&#x2F;xkcd.com&#x2F;927&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;927&#x2F;</a>

Where is the sdk?

Why:<p><pre><code> aws cloudcontrol delete-resource \ --type-name AWS::Lambda::Function \ --identifier ukjfq7sqG15LvfC30hwbRAMfR-96K3UNUCxNd9 </code></pre> and not:<p><pre><code> aws cloudcontrol delete-resource \ AWS::Lambda::Function \ ukjfq7sqG15LvfC30hwbRAMfR-96K3UNUCxNd9 </code></pre> (and why &#x27;cloudcontrol&#x27; for that matter, not top-level CRUD)<p>Awscli loves its arguments. Several people are going to point me at autocompletions, tell me zsh has this really great feature where .. all fine. But why have this &#x27;problem&#x27; to solve in the first place? I don&#x27;t get it.<p>For non-interactive use, sure, I don&#x27;t care how verbose it is, it&#x27;s even a sort of self-documenting feature. Is that it? They just really want all interaction via the web console?