Make Dynamo Table billing mode required or PAY_PER_REQUEST by default
See original GitHub issue🚀 Feature Request
General Information
- 👋 I may be able to implement this feature request
- ⚠️ This feature might incur a breaking change
Description
Make Dynamo tables with the billing mode required or PAY_PER_REQUEST by default
The idea behind this is to avoid costs while deploying a Table with only the required attributes using the Table construct.
I think this is a better option than PROVISIONED, because when we want a provisioned table we’ve to make calculations in order to determine the capacity I need for my table, hence, make further configuration on the table. So when creating a Table, I’m more aware I’ve to make further configuration in order to have the capacity plan of my table right.
Making the billing mode required, or PAY_PER_REQUEST by default. I’m sure I’m not being charged from having tables just sitting there.
Proposed Solution
For example: By making this:
dynamo.Table(
scope=self,
id="Connections",
partition_key=dynamo.Attribute(name="connectionId",
type=dynamo.AttributeType.STRING)
)
I already should’ve made some calculations: ¿What should be my provisioned capacity? ¿What should be my auto scaling) And if I don’t dig into the documentation of the method, I don’t know I’ve to do that, so by leaving the defaults, a run into 2 risks, being charged without noticing and under/over serving my requirements.
While if its required:
dynamo.Table(
scope=self,
id="Connections",
partition_key=dynamo.Attribute(name="connectionId",
type=dynamo.AttributeType.STRING),
billing_mode=dynamo.BillingMode.PAY_PER_REQUEST # PROVISIONED
)
I’ve to ask myself “hmmm, what’s this and what implications have in my pocket.” or leaving the PAY_PER_REQUEST as default, wouldn’t penalize us with a bill of tables we’re not currently using.
Environment
- CDK CLI Version: 1.5.0 (build c020efa) (migrating to 1.6.1)
- Module Version:
- OS: Ubuntu
- Language: Python
Other information
The reason behind this is because we got a bill while making test and learning the cdk and it feels like we got penalized by using the defaults, which they should be secure and “free” in most cases -I think that’s the reason behind the free tiers: not penalizing the learning curve-. And because with PAY_PER_REQUEST doesn’t need the configuration I need to do to make it provisioned.
That would be all.
Thx and best regards!
Issue Analytics
- State:
- Created 4 years ago
- Reactions:3
- Comments:5 (3 by maintainers)
Top GitHub Comments
I disagree. The provisioned throughput is well under the free-tier for DynamoDB and even if I leave it running some kind of traffic spike happens, the traffic will get throttled and I won’t get a surprise bill from the pay_per_request charges.
Hey @jindriago-scf ,
thanks for opening the issue. However, the DynamoDB module is marked “stable”, which means we cannot either change the default, or make an optional property required.
If you feel passionately about this topic, feel free to add it to the list of potential changes we can make in 2.0.
I’m going to close this now, feel free to comment if you don’t agree.
Thanks, Adam