Resource Tagging
How Encore identifies and groups your cloud resources
Encore adds identifying metadata to supported infrastructure resources as it provisions them: tags on AWS and labels on GCP. These connect a cloud resource to the application, environment, and resource it represents in Encore's infrastructure graph. Some GCP resources also carry the names of the Encore services they host or support.
This metadata is useful for several common tasks:
- Finding resources: filter your cloud inventory to see the infrastructure associated with an application or environment.
- Investigating issues: identify which Encore environment a database, compute service, or network resource belongs to when inspecting it in the cloud console.
- Organizing infrastructure: group related resources and connect their application and environment IDs to your own ownership, team, or cost-center records.
- Analyzing costs: group supported billing data by application, environment, or individual resource, and identify infrastructure shared by multiple services.
Common identifiers
AWS and GCP use the same five core keys and value formats on the supported resources described below. Example IDs are abbreviated; actual values contain the full ID.
| Key | Meaning | Example |
|---|---|---|
encore-app | Your application's slug, lowercased | my-app |
encore-app-id | Encore's unique application ID | app_… |
encore-env | Your environment's name, converted to lowercase kebab-case | preview-checkout |
encore-env-id | Encore's unique environment ID | env_… |
encore-id | The resource's ID in Encore's infrastructure graph | res_… |
Use names for readable filters and IDs for durable references. Application and environment IDs remain useful across name changes; recreating an environment produces a different identity even if you reuse its name. encore-env is the environment's name, not a classification such as production or development. For those classifications or business ownership, you can maintain a lookup keyed by application and environment IDs.
These IDs identify Encore entities and are separate from AWS ARNs, GCP project IDs, and cloud resource names. An infrastructure resource can host several logical resources: for example, one database server can contain several application databases. Its encore-id identifies that server in Encore's graph.
Tagging is implemented per resource type. Membership in the infrastructure graph does not automatically mean a cloud resource receives tags, and tags on a parent should not be assumed to appear on every child. The sections below describe the current coverage and provider-specific behavior.
AWS
Encore applies the five core identifiers as AWS resource tags. The AWS implementation currently does not add the encore-services tag described in the GCP section.
Resource coverage
| AWS resources | Encore tags applied |
|---|---|
| ECS clusters, services, and task definitions used for Fargate | Core tags and Name |
| EKS clusters and Fargate profiles | Core tags |
| RDS instances, DB subnet groups, and parameter groups | Core tags |
| ElastiCache Redis replication groups, subnet groups, parameter groups, users, and user groups | Core tags |
| SNS topics and SQS queues | Core tags |
| ECR repositories | Core tags |
| Application Load Balancers, target groups, and listeners | Core tags |
| CloudFront distributions | Core tags |
| ACM certificates | Core tags and Name |
| Secrets Manager secrets and KMS keys | Core tags |
| IAM roles, customer-managed policies created by Encore, and OIDC providers | Core tags |
| VPCs, subnets, internet gateways, NAT gateways, Elastic IPs, VPC peering connections, route tables, network ACLs, security groups, and ingress/egress security-group rules | Core tags and Name; selected EKS resources also receive integration tags |
| AWS Resource Groups created by Encore | Core tags and Name |
This lists directly tagged resource types. It does not imply that every object within those services receives tags. For example, the current S3 bucket and object implementations do not apply Encore's core tags. Logical databases inside RDS are represented by the database instance's tags.
Names and environment resource groups
On selected resources, Encore adds the AWS Name tag to make them easier to recognize in cloud tools. It normally contains the generated resource name; for ACM certificates it contains the domain name, and for security-group rules it contains the rule description.
Encore also creates an AWS Resource Group for each environment's region. The group's query selects resources whose encore-env-id matches that environment, across the resource types supported by AWS Resource Groups. This gives you an environment-oriented inventory in the AWS console. Its membership depends on both the tags present and AWS Resource Groups' supported resource types.
ECS task propagation
Encore configures ECS services to propagate task-definition tags to their tasks and enables ECS-managed tags. Consequently, a task's propagated encore-id identifies the Encore task-definition resource; it is not a unique Encore ID for each running task. Use the ECS task ARN to distinguish individual executions.
EKS integration tags and workload labels
Encore adds tags needed by the AWS Load Balancer Controller on selected EKS networking resources:
| Tag | Value and purpose |
|---|---|
kubernetes.io/role/elb | 1 on public subnets used for external load balancers |
kubernetes.io/role/internal-elb | 1 on cluster subnets used for internal load balancers |
kubernetes.io/cluster/<cluster-name> | shared on participating subnets and owned on the cluster security group |
These tags support the Kubernetes integration in addition to the core Encore identifiers.
Inside EKS, Encore uses Kubernetes labels on Deployments and their Pods. The core keys become encore.app/app, encore.app/app-id, encore.app/env, encore.app/env-id, and encore.app/id. An additional encore.app/deployment label contains the Kubernetes Deployment name. Here, encore.app/id identifies the Encore Deployment resource. These are Kubernetes object labels, separate from AWS resource tags; the deployment labeling path does not generate an encore-services equivalent.
For workloads using an EKS Fargate profile, Encore also adds encore.app/eks-fargate-profile with the profile's name.
Using AWS tags for costs
To use Encore tags in AWS cost reporting, activate the relevant keys as user-defined cost allocation tags in AWS Billing and Cost Management. Tagging a resource and activating a key for billing are separate steps. Start with encore-app-id and encore-env-id for application and environment breakdowns. See AWS's cost allocation tag documentation.
GCP
Encore applies the five core identifiers as GCP labels, including Cloud SQL's user labels. These are distinct from Resource Manager tag bindings and network tags. GCP labels are not inherited through the resource hierarchy: labeling a project does not automatically label its resources. See Google's comparison of tags and labels.
Resource coverage
| GCP resources | Encore labels applied |
|---|---|
| Cloud Run services and their revision templates | Core labels; encore-services for hosted Encore services |
| Cloud SQL instances | Core labels and associated services, when available |
| Memorystore Redis instances | Core labels and associated services, when available |
| Cloud Storage buckets | Core labels and associated services, when available |
| Pub/Sub topics and subscriptions | Core labels and associated services, when available |
| Secret Manager secrets | Core labels |
| Projects created by Encore | Core labels |
| GKE clusters | Core labels |
| Global load-balancer forwarding rules | Core labels |
| Certificate Manager certificates, certificate maps, map entries, and DNS authorizations | Core labels |
The current implementation does not directly apply these GCP labels to:
- VPC networks, subnets, VPC peerings, and peering ranges.
- Reserved external and internal IP addresses and Serverless VPC Access connectors.
- Private Service Connect endpoints and forwarding rules.
- Load-balancer URL maps, target HTTP(S) proxies, and backend buckets.
- Artifact Registry repositories and container images.
- IAM service accounts, roles, and bindings.
- GKE node pools and Kubernetes namespaces.
- Cloud SQL databases and users inside an instance.
Logical databases within Cloud SQL and keyspaces within Redis are represented by their parent instance's labels.
Projects and environment organization
With a GCP organization connection, Encore's default is to create a project for the environment. Its generated name includes application and environment information, and the project carries the core labels. You can use that project to find the environment's resources, including those without individual labels.
Encore does not automatically label imported GCP projects. For other imported resources, label coverage depends on how Encore manages them.
Existing projects and infrastructure configuration can change this arrangement. An imported project may contain resources from other environments or workloads managed outside Encore. Before treating a project's inventory or costs as belonging to one environment, verify that the project is dedicated to it. Project labels describe the project; they do not establish ownership of every resource inside it.
Adding your own labels
You can add metadata such as team or cost-center, but whether Encore preserves it depends on the resource's update behavior:
| Resource | Behavior for additional labels |
|---|---|
| GCP projects | Encore preserves customer-added labels. |
| Cloud Run services and revision templates | Encore merges its labels into the existing labels. |
| Cloud Storage buckets | Encore preserves additional labels. |
| Cloud SQL instances | Encore preserves additional user labels. |
| Memorystore Redis instances, Pub/Sub topics and subscriptions, and GKE clusters | Encore replaces the label set during label updates, so additional labels can be removed. |
For provider details, see Google's Cloud Storage label documentation and Cloud SQL label documentation. Encore still supplies its own values for the core keys, so use separate keys for your metadata. To maintain business categories consistently across resource types, keep a lookup keyed by encore-app-id and encore-env-id in your inventory or analytics system.
Associated services: encore-services
On selected resources, Encore adds encore-services to describe the services they host or support. The value comes from the application's infrastructure graph:
| Resource | Services included |
|---|---|
| Cloud Run application service | Encore services hosted together in that Cloud Run service |
| Cloud SQL instance | Services linked to any of the Encore databases hosted on the instance |
| Memorystore Redis instance | Services linked to any of the Encore cache keyspaces hosted on the instance |
| Cloud Storage bucket | Services linked to the bucket, regardless of public access or CDN settings |
| Pub/Sub topic | Services linked as publishers of the topic |
| Pub/Sub subscription | Services linked to that subscription |
Encore joins the names with underscores and lowercases the result. For data resources, it first deduplicates and sorts the linked service names. For example, a Cloud SQL instance used by orders and payments receives encore-services=orders_payments.
If the joined value exceeds 63 bytes, Encore uses many-services. If no associated services are available, it does not generate this label. Examples include dead-letter topics created for subscriptions and Cloud Run services used only for supporting infrastructure. These resources can be in use even without a direct association to an Encore service.
The label describes structural relationships, not every service that might indirectly cause work through another service. Topic and subscription labels can differ because publishers and subscribers are represented separately. Associations can also change when you change your application's architecture or which services share compute or storage.
Treat the value as a grouping key rather than a lossless inventory: names are lowercased, underscores separate them, and long values collapse to many-services. For cost analytics, a shared label identifies a shared resource's cost; it does not measure each service's share. Count the resource once or apply an explicit allocation rule.
GKE workload labels
For Kubernetes Deployments and their Pods, Encore uses the same Kubernetes labels as on EKS:
| Kubernetes label | Meaning |
|---|---|
encore.app/app | Application slug |
encore.app/app-id | Application ID |
encore.app/env | Environment name |
encore.app/env-id | Environment ID |
encore.app/id | Encore infrastructure resource ID for the Deployment |
encore.app/deployment | Kubernetes Deployment name |
These labels identify workloads within the cluster. The deployment labeling path does not generate an encore-services equivalent; use the deployment name or resource ID for workload grouping.
Encore defaults GKE cost allocation to enabled for newly configured clusters, although cluster configuration can override it. With GKE cost allocation and the detailed Cloud Billing export enabled, Google exposes Pod labels under k8s-label/ in the export's labels field. For example, encore.app/id becomes k8s-label/encore.app/id. For workload attribution, prefer that key over encore-id if both exist, since the latter may identify the cluster. Allocation covers supported SKUs and can leave overhead and unallocated capacity outside your workloads. See Google's GKE cost allocation guide.
Using GCP labels for costs
In Cloud Billing Reports, group by an available label such as encore-app-id or encore-env-id. In the billing export, resource labels appear in labels, while project labels appear separately in project.labels. See the Cloud Billing export schema.
A label on a resource does not guarantee that every related charge carries it. Keep unattributed costs visible alongside labeled costs. Label changes affect future exported usage data; previously exported records retain their historical values. See Cloud Billing export behavior.