AWS Copilot v1.23: App Runner Private Services, Aurora Serverless v2 and more!
Posted On: Nov 1, 2022
The AWS Copilot core team is announcing the Copilot v1.23 release.
Our public сommunity сhat is growing and has over 300 people online and nearly 2.5k stars on GitHub. Thanks to every one of you who shows love and support for AWS Copilot.
Copilot v1.23 brings several new features and improvements:
- App Runner Private Services: App Runner just launched support for private services, and you can create them by adding
http.privateto your Request-Driven Web Service manifest! See detailed section.
- Support Aurora Serverless v2 in
storage init: See detailed section.
- Move misplaced
httpfields in environment manifest (backward-compatible!): See detailed section.
- Restrict container access to root file system to read-only: See manifest field (#4062).
- Configure SSL policy for your ALB’s HTTPS listener: See manifest field (#4099).
- Restrict ingress to your ALB through source IPs: See manifest field (#4103).
What’s AWS Copilot?
The AWS Copilot CLI is a tool for developers to build, release, and operate production ready containerized applications on AWS. From getting started, pushing to staging, and releasing to production, Copilot can help manage the entire lifecycle of your application development. At the foundation of Copilot is AWS CloudFormation, which enables you to provision infrastructure as code. Copilot provides pre-defined CloudFormation templates and user-friendly workflows for different types of micro service architectures, enabling you to focus on developing your application, instead of writing deployment scripts.
See the section Overview for a more detailed introduction to AWS Copilot.
App Runner Private Services
You can now create App Runner private services using Copilot. Simply update your Request-Driven Web Service manifest with:
http: private: true
http: private: endpoint: vpce-12345
network.vpc.placement: 'private'in your manifest.
Support Aurora Serverless v2 in
Aurora Serverless v2 was made generally available earlier this year, and is now supported as a storage option in Copilot.
Previously, you could run
$ copilot storage init --storage-type Aurora
copilot storage init --storage-type Aurora --serverless-version v1to generate a v1 template.
For more, check out the doc for
http fields in environment manifest (backward-compatible!)
In Copilot v1.23.0, we are fixing the hierarchy
http field in the environment manifest.
What is getting fixed, and why?
Back in Copilot v1.20.0, we released the environment manifest,
bringing all the benefits of infrastructure as code to environments. At the time, its
http field hierarchy looked like:
name: test type: Environment http: public: security_groups: ingress: # [Flaw 1] restrict_to: # [Flaw 2] cdn: true private: security_groups: ingress: # [Flaw 1] from_vpc: true # [Flaw 2]
security_groupsis ambiguous. Each security group has its own ingress - it is unclear what the "ingress" of several security groups means. (Here, it was meant to configure the ingress of the default security group that Copilot applies to an Application Load Balancer.)
restrict_tois redundant. It should be clearly implied that the
http.publicis restrictive, and the
http.privateis permissive. The
from_vpcalso suffers from the same redundancy issue.
To illustrate - fixing them would give us an environment manifest that looks like:
name: test type: Environment http: public: ingress: cdn: true private: ingress: vpc: true
What do I need to do?
The short answer: nothing for now.
(Recommended) Adapt your manifest to the corrected hierarchy
While your existing manifest will keep working (we will get to this later), it is recommended that you update your manifest to the corrected hierarchy. Below are snippets detailing how to update each of the fields impacted:
Adapt your environment manifest to the corrected hierarchy
# If you have http: public: security_groups: ingress: restrict_to: cdn: true # Then change it to http: public: ingress: cdn: true
# If you have http: private: security_groups: ingress: from_vpc: true # Then change it to http: private: ingress: vpc: true
Your existing environment manifest will keep working
It's okay if you don't adapt your environment manifest to the corrected hierarchy immediately. It will keep working - unless you modify your manifest so that it contains both
http.public.security_groups.ingress (the flawed version)
http.public.ingress (the corrected version).
For example, say before the release of v1.23.0, your manifest looked like:
# Flawed hierarchy but will keep working. http: public: security_groups: ingress: restrict_to: cdn: true
However, if at some point you modify the manifest to:
# Error! Both flawed hierarchy and corrected hierarchy are present. http: public: security_groups: ingress: restrict_to: cdn: true ingress: source_ips: - 10.0.0.0/24 - 10.0.1.0/24
http.public.security_groups.ingress(the flawed version) and
http.public.ingressexist in the manifest. It will error out, along with a friendly suggestion to update your manifest so that only
http.public.ingress, the corrected version is present:
# Same configuration but written in the corrected hierarchy. http: public: ingress: cdn: true source_ips: - 10.0.0.0/24 - 10.0.1.0/24