aws 试用 限制
This section in the series on Enterprise Serverless specifically covers some of the limits and limitations that you are bound to hit when working on large scale serverless projects, and how to solve or work around them. It’s a list that I will continue to update as things come to mind. You can read the ideas behind the series by clicking on the ‘Series Introduction’ link below.
关于Enterprise Serverless的系列中的这一部分专门介绍了在进行大型无服务器项目时必将遇到的一些限制和局限，以及如何解决或解决这些问题。 这是一个清单，我会在想到时继续更新。 您可以通过点击下面的“ 系列介绍 ”链接来阅读系列背后的想法。
The series is split over the following sections:
该系列分为以下几节：
AWS限制和限制 (AWS Limits and Limitations)
The following are some of the typical issues you may face in large serverless projects and how to work around them or factor them into your overall architecture and designs:
以下是大型无服务器项目中可能遇到的一些典型问题，以及如何解决这些问题或将它们纳入您的总体体系结构和设计中的方法：
AppSync中的最大foreach循环迭代 (Max foreach loop iterations in AppSync)
When using AWS AppSync with VTL there is a limit with loops that you should be aware of otherwise it can result in rework. As detailed on the AppSync limits page, the max number of iterations in a foreach loop is 1000, which is hugely annoying when projecting values in a DTO for example.
当使用带有VTL的AWS AppSync时，应注意循环的限制，否则可能导致返工。 如AppSync限制页面中所述，foreach循环中的最大迭代数为1000，这在DTO中投影值时非常烦人。
The easy workaround in this scenario is to use a lambda resolver, as although possible in VTL, batching is a lot of work and you are unable to share code easily i.e. no functions.
在这种情况下，简单的解决方法是使用lambda解析器，就像在VTL中可能的那样，批处理是很多工作，并且您无法轻松共享代码，即没有功能。
Lambda资源名称的最大长度 (Lambda Resource Names Max Length)
An issue you can hit quite often in serverless is hitting the maximum 64 character resource name for a lambda. The easy way to get around this is to obviously just shorten the name, however when auto generating code for example this is one to think about up front!
您可能会在无服务器环境中经常遇到的一个问题是lambda的最大64个字符资源名称 。 解决这个问题的简单方法是明显地只是缩短名称，但是例如在自动生成代码时，这是一个预先考虑的方法！
CloudFront部署时间 (CloudFront deploy time)
As discussed earlier in the series AWS CloudFront deploy times can take some time to deploy and slow down pipelines — so it may be worth looking at CloudFlare workers.
如本系列前面所述， AWS CloudFront的部署时间可能会花费一些时间来部署和减慢管道的速度，因此值得研究CloudFlare工作者。
每个堆栈的最大资源 (Max resources per stack)
Discussed in the tooling section, serverless-plugin-split-stacks is a fantastic plugin to adopt into your serverless projects from inception as you will no doubt hit the maximum resource limit of 200 when working on large serverless projects, and this plugin splits the stacks into further stacks of 200 resources.
在工具部分讨论过， serverless-plugin-split-stacks是一个很棒的插件，从一开始就可以应用到您的无服务器项目中，因为在处理大型无服务器项目时，您无疑会达到200的最大资源限制，并且此插件可以拆分堆栈进一步堆叠200种资源。
参数存储中的CloudFormation安全字符串 (CloudFormation secure strings in Parameter Store)
An annoying limitation with AWS Parameter Store with CloudFormation is being unable to create secure strings, which I assume would be required in production environments in a lot of projects. The way around this in past projects is to use non secure strings in QA or ephemeral environments, and PP and Production to have the parameters added via the pipeline.
带有CloudFormation的AWS Parameter Store的一个令人讨厌的限制是无法创建安全字符串 ，我认为很多项目在生产环境中都需要使用该字符串 。 在过去的项目中，解决此问题的方法是在QA或临时环境中使用非安全字符串，并在PP和Production中通过管道添加参数。
CloudFormation参数存储值更改 (CloudFormation Parameter Store value changes)
If you expect the parameter store values to be updated when changing them in your CloudFormation then you would be wrong! This is an issue that I hit earlier on in a recent project, and one workaround is to simply use the AWS CLI instead; although I have seen some interesting ways suggested to get around this issue such as adding a tag with a UUID generated dynamically to force the change.
如果您希望在CloudFormation中更改参数存储值时将对其进行更新，那么您将错了！ 这是我在最近的项目中前面提到的一个问题，一种解决方法是直接使用AWS CLI。 尽管我看到了一些解决此问题的有趣方法，例如添加带有动态生成的UUID的标记来强制进行更改。
AWS IAM的最大角色 (Max AWS IAM Roles)
When working with ephemeral environments with least privilege in mind when it comes to AWS IAM roles and security, and with a couple of scrum teams, you can quite quickly hit the maximum amount of IAM roles for the account on large serverless projects.
当在短暂的环境中使用AWS IAM角色和安全性并考虑到最少特权时，并且使用几个Scrum团队，您可以在大型无服务器项目中Swift达到该帐户的最大IAM角色数量。
One suggested way around this is to have an AWS account per developer, which is something I have never tried personally on a project. For recent projects this is something that has been worked around, but good to keep in mind.
建议的解决方法是为每个开发人员拥有一个AWS账户，这是我从未亲自在项目上尝试过的。 对于最近的项目，已经解决了这一问题，但是请牢记。
AppSync共享正则表达式，消息和资源 (AppSync shared regexes, messages & resources)
When working with AWS AppSync and VTL one of the more annoying issues when working on large scale serverless projects is the lack of reusability when it comes to shared regexes, info/error messages and custom resources such as i18n translations, as for the most part your VTLs are static code i.e. no imports of modules.
使用AWS AppSync和VTL进行大型无服务器项目时，更烦人的问题之一是共享正则表达式，信息/错误消息和自定义资源(例如i18n转换)缺乏可重用性，而在大多数情况下， VTL是静态代码，即不导入任何模块。
One way to mitigate this on projects using serverless is to use the substitutions property in the serverless YAML/JSON which then allows you to use injected values (key value pairs) and then replace in VTL code to reuse resources such as regexes or config values. An example of using a substitution value for a person name regex in VTL is below:
在使用无服务器的项目上减轻这种情况的一种方法是使用无服务器的YAML / JSON中的替代属性，然后允许您使用注入的值( 键值对 )，然后替换为VTL代码以重用正则表达式或配置值等资源。 下面是在VTL中为人名正则表达式使用替换值的示例：
#set($valid = $util.matches(“${personName}”, $ctx.args.person.name))AppSync最大响应大小(1MB) (AppSync max response size (1MB))
A previously undocumented issue which I hit on one serverless project was hitting the maximum response size in AppSync which was around 1MB. The particular scenario was returning base64 data from a legacy system which in a lot of instances was over the limit. The workaround in this scenario was to store the images in S3 and return the S3 path rather than the base64 data, but this is something to think about up front when designing your APIs.
我在一个无服务器项目中遇到的一个先前未记录的问题是AppSync中的最大响应大小约为1MB。 特定的情况是从旧系统返回base64数据，在很多情况下，这些数据超出了限制。 在这种情况下，解决方法是将图像存储在S3中并返回S3路径而不是base64数据，但这是在设计API时需要考虑的事情。
Lambda的75GB硬限制 (75GB hard limit on Lambda)
For a given AWS account the maximum overall lambda function and layer storage is 75GB which is sizeable in all fairness, but one to keep in mind when working with large numbers of deployed lambdas per ephemeral environments.
对于给定的AWS账户，最大的整体lambda功能和层存储为75GB ，这在所有公平性上都是可观的，但是在每个临时环境中使用大量已部署的lambda时要牢记这一点。
This is where building the lambdas using plugins such as serverless webpack come in to their own, where tree shaking and optimising builds means your lambda size is greatly reduced, as well as ensuring that versioning your lambdas is turned off in serverless by setting versionFunctions to false.
这是使用无服务器Webpack之类的插件构建Lambda的地方，树状摇动和优化构建意味着您的Lambda大小大大减小，并且通过将versionFunctions设置为false来确保在无服务器中关闭Lambda的版本控制。 。
步骤功能任务之间的最大有效负载 (Max payloads between step function tasks)
AWS Step Functions have a limitation of 32KB of data being the maximum size of payloads between tasks (inputs and outputs), which should be thought about when designing your workflows. The best practice to mitigate this issue is using AWS S3 to store data between steps which in experience works very well on most projects.
AWS Step Functions的任务( 输入和输出 )之间的有效负载的最大大小限制为32KB数据，在设计工作流程时应考虑这一点。 缓解此问题的最佳实践是使用AWS S3在步骤之间存储数据，根据经验，这些步骤在大多数项目中都非常有效。
DynamoDB TTL的寿命可能比预期的更长！ (DynamoDB TTL may live longer than expected!)
When working with DynamoDB and using TTL you would be forgiven to assume that your records will be removed instantly when hitting the TTL time — however in my experience you would be wrong. On average I have seen this take up to 15 minutes so it is worth keeping this in mind when working on a feature.
当与DynamoDB一起使用并使用TTL时，您可以假设在达到TTL时间时会立即删除您的记录-但是以我的经验，这是错误的。 平均而言，我看到这最多需要15分钟的时间，因此在使用功能时应牢记这一点。
When using AppSync with DynamoDB for example, I have gotten around this issue in projects by including the TTL in the query expression to ensure the record does not come back if it has not been cleaned up by AWS yet.
例如，在将AppSync与DynamoDB结合使用时，我在项目中解决了此问题，方法是在查询表达式中包括TTL，以确保如果尚未由AWS清除记录，则记录不会返回。
Next section: Security 🚀Previous section: Hints & Tips
结语 (Wrapping up)
Feel free to also connect with me on:
请随时与我联系：
https://www.linkedin.com/in/lee-james-gilmore/https://twitter.com/LeeJamesGilmore
https://www.linkedin.com/in/lee-james-gilmore/ https://twitter.com/LeeJamesGilmore
If you enjoyed the posts please follow my profile Lee James Gilmore for further posts/series, and don’t forget to connect and say Hi 👋
如果您喜欢这些帖子，请关注我的个人资料Lee James Gilmore，以获取更多帖子/系列，并且别忘了联系并说声嗨 👋
关于我 (About me)
“Hi, I’m Lee, an AWS certified technical architect and polyglot software engineer based in the UK, working for a FTSE 100 multinational enterprise software company, working primarily in full-stack JavaScript on AWS for the past 5 years.
“ 嗨，我是Lee，他是英国AWS认证的技术架构师和多语种软件工程师，在FTSE 100跨国企业软件公司工作，过去5年主要在AWS上使用全栈JavaScript。
I consider myself a serverless evangelist with a love of all things AWS, innovation, software architecture and technology.”
我认为自己是一位无服务器的传播者，热爱AWS，创新，软件架构和技术。 ”
** The information provided are my own personal views and I accept no responsibility on the use of the information.
**所提供的信息是我个人的观点，我对信息的使用不承担任何责任。
翻译自: https://medium.com/swlh/enterprise-serverless-aws-limits-limitations-ce99e20432be
aws 试用 限制
1834
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
