Service Connect provides an exciting opportunity to take advantage of a service-mesh like approach to logical addressing in Amazon ECS. Before you get started with this new feature, there are a couple of caveats to consider. To handle the routing of requests in this new model, Service Connect injects a container into each Amazon ECS task, much like the sidecar architecture patterns used with Envoy and similar mesh solutions. This sidecar consumes Amazon ECS compute resources and may require some reconfiguration of existing task definitions to ensure desired performance. The addition of this injected container also means that previously existing tasks cannot participate in Amazon ECS Service Connect, those tasks must be administratively upgraded to support the feature, which involves some reconfiguration and a restart of those tasks.
Though the sidecar pattern might give some administrators heartburn to start (given it somewhat magically appears), the ability to reduce dependency on load balancers for routing and the clarity added through friendly service names, brings a lot of value into the Amazon ECS ecosystem without relying on complex third-party mesh systems. It will be exciting to see how this feature continues to grow and what it may one day allow us to further simplify in our Amazon ECS-based applications.
AWS Lambda Vulnerability Scanning
Anyone who has had to sell AWS Lambda as a compute model, be it to customers or internal stakeholders, has eventually heard the same question:
“How do I know if my AWS Lambda functions are vulnerable, dangerous, etc. etc. ”
It is a valid question. After all, as consumers of the AWS Lambda service, we are handing over a piece of code and asking for it to run at potentially massive scales. For many customers, AWS Lambda adoption represents their first venture into serverless and microservice development, which in itself can create anxiety. If that code can conceivably contain vulnerabilities, the management of related risks, and the anxiety of planning mitigation strategy, too can scale in tandem.
As AWS Lambda has matured and its use has become more commonplace, it has been a reasonably addressable question. The industry has stepped up and offered many third-party solutions to statically analyze AWS Lambda function code during the development process. Solutions even exist to run underneath AWS Lambda functions at runtime using layers to ensure that policies like egress filtering are honored. Like any non-native solution, these answers to the question have involved additional processes, more complexity in pipelines, diagnostic burden (in the case of layers), and additional vendor management activities. This year, Amazon Inspector gives us something a little closer to home.
Amazon Inspector, the cloud-native security and scanning service used across AWS, now supports vulnerability scanning for AWS Lambda functions. Once activated, this new Inspector feature can scan all the lambda functions in an AWS organization. Customers can exclude accounts and individual functions from scanning as desired for more granular control of findings. When a vulnerability is found, Amazon Inspector creates and distributes findings to AWS Security Hub and Amazon Event Bridge so that existing policies and procedures can be adapted to include responses to AWS Lambda-specific vulnerabilities.
Inspector initially scans functions when they are deployed or updated, but also reactively scans when a new CVE is added to Amazon’s database. Existing functions will also be discovered periodically (which AWS indicates may take up to an hour). The continued scanning of functions throughout their lifecycle, and as a response to new CVEs, provides confidence to developers and business stakeholders that regular auditing of their code is performed; All without the need for added complexity or reliance on a third-party vendor.
Just as AWS Lambda has eased the adoption of cloud-based computing, their interface with Amazon Inspector is easing the adoption of security best practices. It’s an exciting first step toward a risk-management-influenced approach to cloud-native application development.
AWS Lambda makes cold starting Java functions a snap
SnapStart is a feature years in the making, and it solves a very complex problem, cold starts. For the uninitiated, a cold start refers to the amount of time it takes for an AWS Lambda function, or more specifically, the execution environment upon which it runs, to respond to its first request. Cold starts occur whenever an execution environment supporting a AWS Lambda function must be “warmed up” or otherwise made ready to accept an invocation. This happens when a function is first deployed, after being re-awakened from a period of no requests (commonly referred to as falling asleep), or during scaling events. Each execution environment can handle a finite number of simultaneous invocations, so functions experiencing spikes in demand may scale drastically and introduce several cold starts when additional execution environments must be warmed up to support the load.
Imagine, if you will, serving a dining room filled with thousands of hungry people, but you only had ten microwaves with which to prepare food. Periodically you would be able to serve bursts of requests, but then you would have to reload the microwaves before more food was ready. Wouldn’t it be better to have some pre-warmed food ready to go?
Caylent Team
