New CDK Bootstrap and the EKS Cluster
In the AWS CDK Version v1.25.0, the CDK team added a new bootstrap template that includes new resources like IAM Role and S3 Buckets. From the AWS CDK Documentation: > The AWS CDK supports two…
The first day of re:Invent 2020 contained an absolute torrent of releases. The rest of the week was a bit quieter, so let’s take a look at what was released from Wednesday to Friday.
The Well-Architected tool is an AWS service that lets customers or AWS partners review their workloads. The reviews are based on the Well-Architected Framework and its five pillars: Operational Excellence, Security, Reliability, Performance Efficiency and Cost Optimization.
AWS has released two additional lenses at re:Invent 2020. These lenses add an additional number of questions, which focus on a specific area. The new lenses are the Foundational Technical Review Lens (AWS News) and the SaaS Lens (AWS News - AWS Blog).
The FTR Lens allows Independent Software Vendors (ISVs) to self-assess their workloads before applying for the actual Foundational Technical Review. The twelve questions in this lens include:
SaaS products have specific requirements and properties, which might differ from single-tenant applications. The SaaS Lens helps developers review the architectures and environments for their software-as-a-service products. It includes fourteen questions across all five pillars:
The questions in these lenses are very focused and valuable. They help developers take a critical view of their own products and might highlight potential issues they hadn’t thought of themselves. These review templates are provided free of cost, and can be performed in any AWS account. However, they might require deep knowledge to answer correctly. AWS Well-Architected Partners like Sentia can help to understand the questions and your workloads. These Well-Architected Partners use these tools as well, to provide a framework for improvement plans.
ECS Deployment Circuit Breaker, now in preview, will detect failing deployments and roll back to a previous healthy state when they occur. This helps your cluster maintain a healthy state, and helps your developers to respond to failing builds quickly.
Any developer or engineer working with ECS has run into this issue: you create a new container, and successfully test it locally. Then you roll out to an acceptance environment, and everything is fine. Next, you roll out to production, and that one parameter is missing in the parameter store. The newly launched container fails its health checks, gets terminated, and ECS tries to replace it with a new one. This goes on for an hour, or until you manually reconfigure the ECS cluster to use the old version.
With ECS Deployment Circuit Breaker, this is finally a problem of the past. When a failing deployment is detected, ECS will automatically roll back to its previous healthy state, no longer requiring manual intervention.
AWS Batch is an orchestration tool for large distributed workloads. For example, you can use Batch to spin up hundreds or thousands of EC2 instance to convert an archive of videos. Or you can use it to run millions of variations of a biological simulation.
Previously, Batch could either spin up EC2 instances for your workload (this is called a managed environment because Batch manages the instances), or use an ECS cluster managed by the customer for the workload (this is called an unmanaged environment because Batch doesn’t manage the compute instances). With Fargate support, you can now run containers in a managed environment.
If you have workloads with high compute requirements and high parallelism, AWS Batch is the go-to orchestration layer. However, if your workloads needs, uses or is optimized for containers, there was still a lot of manual work required to create an execution environment for these containers. With Fargate support, this undifferentiated heavy lifting becomes Amazon’s responsibility, allowing you to focus on the business needs.
As the world becomes more and more software driven, application development skills becomes more and more scarce. The big tech companies hire all the talent, and enterprises need to depend on expensive external consultancy firms more than they would like. The no-code movement promises a solution by offering building blocks and easy-to-use glue to companies with low in-house development capacity.
Amazon positions Honeycode as “a fully managed service that allows customers to quickly build powerful mobile and web applications – with no programming required”. These applications will not be as powerful or polished as the Facebook, Pinterest or Among Us apps, but they will get the job done.
Amazon AppFlow is a “fully managed integration service that has pre-built connectivity with 15 source SaaS applications, such as Salesforce, Marketo, Zendesk, Slack, and Google Analytics”. It allows you to send and receive data from these applications, and process them in your AWS environment, without writing any code.
With the new Honeycode integration for Amazon AppFlow, data received by AppFlow can be made available to Honeycode, in addition to existing AWS services like S3.
There is a big unexplored, unexploited future for no-code and low-code solutions. As workflows and implementations gravitate towards standardized solutions and architectures, it becomes easier to define them as reusable building blocks - which is exactly what companies like OutSystems and Mendix are pioneering.
With the earlier release of Honeycode and the release of new integrations, Amazon is showing they take this movement seriously, and want to play a competitive role in it.
CloudTrail can record two types of events: Management events (API calls) and Data events (S3 and Lambda operations). Recording Management events into an S3 bucket for auditing purposes is an essential security measure which should be enabled in every AWS account. AWS supports this view by providing the first recording of every Management event free of charge.
Data events can be configured on specific Lambda functions, after which it will record who and when invoked the function. It can also be enabled on specific S3 buckets, after which it will record events such as Get, Put, Delete and List actions. Recording these events incurs a cost of $0.10 per 100,000 events.
With the more granular controls, you can now include or exclude Data events based on values in fields such as EventSource, EventName, and ResourceARN. This allows you to for example exclude trusted sources, or only include DeleteObject events on sensitive data, instead of all objects in a bucket.
$0.10 per 100,000 events might not seem like much, but in heavy-traffic S3 buckets or Lambda functions, this can easily lead to very high costs. If much of the traffic is trusted, or if you’re only interested in a small subsection of events, you would be paying a lot of overhead just to measure the slice of data important to you. With the new granular controls, you can just measure (and pay for) relevant events, which might lead to large cost savings. Additionally, this lowers the bar for new security event detectors: it has now become easier and cheaper to deploy a very narrowly scoped trail, for example alerting on an unauthorized execution for a specific Lambda function.
It’s a wrap for re:Invent 2020 week 1! Although the first day was by far the busiest, we’ve also seen many significant releases on Wednesday to Friday. In this article we’ve reviewed some of the most important ones. For a complete overview, check out AWS What’s New. We have another two weeks to go, so stay tuned for more updates!
This article is part of a series published around re:Invent 2020. If you would like to read more about re:Invent 2020, check out my other posts:
I share posts like these and smaller news articles on Twitter, follow me there for regular updates! If you have questions or remarks, or would just like to get in touch, you can also find me on LinkedIn.