Overcast releases

Breaking changes

• Changed

  Ref on an AWS::IAM::InstanceProfile is the profile name, as AWS documents it; the ARN is Fn::GetAtt "Arn"

  Migration

  a template passing the Ref somewhere an ARN was wanted needs Fn::GetAtt instead — the reverse of what it needed before

  cloudformation iam
• Fixed

  an AWS::IAM::Policy naming no Groups, Roles or Users fails the stack instead of writing its document to nobody

  • AWS requires at least one of the three, and the resource does nothing at all without one

  Migration

  name the principal the policy is for; a stack that reported CREATE_COMPLETE without one was granting nothing

  cloudformation iam
• Fixed

  an instance profile holds one role, AWS’s quota, and one still holding a role refuses to delete

  • AddRoleToInstanceProfile answers LimitExceeded for a second, different role; DeleteInstanceProfile answers DeleteConflict

  Migration

  RemoveRoleFromInstanceProfile before replacing a profile’s role or deleting the profile, as against real AWS

  iam
• Fixed

  a Parallel or Map failure keeps the branch’s own error name instead of States.BranchFailed/States.TaskFailed.

  Migration

  a Catch or Retry naming States.BranchFailed should name the branch’s error, or use States.ALL

  stepfunctions
• Fixed

  CreateStateMachine rejects duplicate state names across branches and States.ALL outside the last Retry/Catch.

  • it also rejects fields of the other query language (a JSONPath Output, a JSONata InputPath), matching AWS

  • and, for EXPRESS, .sync, .waitForTaskToken, activities and distributed Map, which AWS also refuses there

  Migration

  rename nested states so every name is unique, and move States.ALL into its own final entry

  stepfunctions

Breaking changes

• Fixed

  CreateCacheCluster and CreateReplicationGroup refuse an unknown CacheSubnetGroupName with CacheSubnetGroupNotFoundFault.

  • the name used to be accepted and ignored, which placed the cache on the default plane with nothing said, and the first symptom was a consumer in the intended VPC that could not resolve the endpoint.

  • an empty name is still fine — that is the default VPC, on AWS and here.

  Migration

  create the cache subnet group before the cluster or replication group that names it, or correct the name; a create that names a group Overcast has no record of now fails instead of silently landing outside its VPC.

  elasticache

Breaking changes

• Changed

  UpdateTimeToLive is asynchronous, as on AWS: TTL changes pass through ENABLING/DISABLING before they settle.

  3 details

  • DescribeTimeToLive reports all four TimeToLiveStatus values, and the sweeper expires items only once the status is ENABLED.

  • a second UpdateTimeToLive inside the window, re-enabling an ENABLED table, or disabling a DISABLED one is now a ValidationException, matching AWS.

  • both TimeToLiveSpecification members are required (AttributeName 1..255), and AWS::DynamoDB::Table refuses an attribute rename while TTL is enabled.

  Migration

  change a TTL attribute name by disabling TTL, waiting for DISABLED, then enabling it again — the same two-step AWS requires.

  dynamodb
• Changed

  OVERCAST_ACCOUNT_ID now rejects a value that is not exactly 12 ASCII digits at startup.

  Migration

  set OVERCAST_ACCOUNT_ID to a 12-digit value or unset it.

  config
• Fixed

  Describe* resolves an explicit resource ID; a miss is Invalid<Resource>ID.NotFound or .Malformed, not an empty 200.

  3 details

  • twelve operations: Vpcs, Subnets, SecurityGroups, RouteTables, InternetGateways, NetworkInterfaces, Instances, Addresses, NatGateways, VpnGateways, VpcEndpoints and VpcPeeringConnections.

  • a filter matching nothing is unchanged, still 200 with an empty list; AWS’s per-resource casing is exact, and where AWS documents no Malformed code a wrongly shaped ID is .NotFound.

  • DeleteVpc, DeleteSecurityGroup, StopInstances, ReleaseAddress and every other single-ID lookup answer AWS’s per-resource code too, not InvalidId.NotFound.

  Migration

  code that read an empty list for a named ID as “it is gone” must catch the error, and code matching InvalidId.NotFound must match the per-resource code — as it already must against AWS.

  ec2
• Fixed

  Describe* raises the documented not-found error for an ARN or name it cannot resolve, instead of an empty 200.

  3 details

  • DescribeLoadBalancers, DescribeTargetGroups and DescribeListeners, by ARN and by name; a value that is not an ARN for the resource raises ValidationError.

  • a Describe* naming no identifier still lists the region, and DeleteListener now names ListenerNotFound rather than LoadBalancerNotFound.

  • CreateLoadBalancer requires at least one subnet, CreateTargetGroup validates Protocol and Port, and new ARNs end in AWS’s sixteen hex characters.

  Migration

  code that named a load balancer or target group and read the empty list as “it is gone” must catch the error, as it already has to against AWS.

  elbv2
• Fixed

  a group must name AvailabilityZones or VPCZoneIdentifier, and if both, they must agree — otherwise AWS’s ValidationError.

  3 details

  • a group with neither used to be stored and launched nowhere in particular, falling back to <region>a; UpdateAutoScalingGroup applies the same rule to the group the update would leave.

  • a subnet outside the listed zones used to be stored unchecked and round-robinned independently, so a launch could land in a zone its own subnet contradicted.

  • given only VPCZoneIdentifier, the group takes its zones from the subnets, as AWS does; each launch goes to a subnet and lets EC2 place it in that subnet’s zone.

  Migration

  give every group --availability-zones or --vpc-zone-identifier; when both, list exactly the zones the subnets are in, or drop AvailabilityZones and let the subnets set them.

  autoscaling
• Fixed

  a DynamoDB reserved word used as a bare attribute name in an expression is rejected, as AWS rejects it (#1638).

  • covers UpdateExpression, ConditionExpression, FilterExpression, KeyConditionExpression and ProjectionExpression, with AWS’s message naming the parameter and the keyword.

  • size(...) and the other function names are not attribute names and keep parsing; the 573-word list is generated from the AWS Developer Guide.

  Migration

  reach a reserved word through an ExpressionAttributeNames alias (#s mapped to size), which is what the same expression already needs on AWS.

  dynamodb
• Fixed

  key attributes are validated against KeySchema/AttributeDefinitions on every item and key operation (#1637).

  • a key whose type disagreed with the declared one used to be stored under an encoding a correctly typed GetItem never looked under.

  • covers PutItem, GetItem, UpdateItem, DeleteItem, the batch and transact operations, and Query key conditions; non-key attributes stay schemaless.

  Migration

  send key attributes with the type AttributeDefinitions declares, or declare the type your code sends — real AWS rejects the mismatch either way.

  dynamodb
• Fixed

  Decrypt and ReEncrypt refuse a KeyId/SourceKeyId that did not produce the ciphertext with IncorrectKeyException, as AWS does.

  • both decrypted anyway before, so multi-key rotation and key-hierarchy mistakes all looked like successes.

  Migration

  name the key that produced the ciphertext, or omit KeyId/SourceKeyId and let the symmetric ciphertext blob resolve it.

  kms
• Fixed

  GenerateDataKey*, Encrypt, ScheduleKeyDeletion and CreateAlias enforce AWS’s parameter rules instead of accepting what AWS refuses.

  3 details

  • GenerateDataKey and GenerateDataKeyWithoutPlaintext require exactly one of KeySpec (AES_256/AES_128) or NumberOfBytes (1-1024); both, neither or out of range is ValidationException.

  • Encrypt enforces the 4096-byte Plaintext limit and ScheduleKeyDeletion the 7-30 day PendingWindowInDays range, both as ValidationException.

  • CreateAlias requires the alias/ prefix (alias/aws/ reserved) — InvalidAliasNameException — and refuses a name in use with AlreadyExistsException; UpdateAlias still re-points.

  Migration

  pass exactly one length parameter (KeySpec=AES_256 for the old 32-byte default), envelope-encrypt over 4096 bytes, clamp windows into 7-30, re-point an alias with UpdateAlias.

  kms
• Fixed

  a malformed policy document is refused with MalformedPolicyDocument, as AWS does, instead of being stored unparsed.

  • covers CreatePolicy, CreatePolicyVersion, CreateRole, UpdateAssumeRolePolicy and the three Put*Policy writers, through the parser the simulator already evaluates with.

  • structural only: valid JSON, a Statement that is an object or a non-empty array, each statement an exact Allow/Deny Effect and an Action or NotAction. ARN syntax stays unchecked.

  Migration

  give any placeholder document a real statement — {} and an empty Statement list were never accepted by AWS either.

  iam
• Fixed

  runtime_iam_create_role defaults to a real sts:AssumeRole trust policy, and both IAM create tools refuse a malformed document.

  • the placeholder default carried an empty Statement list, which grants nothing and which the IAM API itself will not store, so a role created through MCP could not be assumed.

  • the check is iampolicy.ValidateDocument, the same one CreateRole and CreatePolicy apply, so the two write paths agree on what a well-formed document is.

  Migration

  pass a document with at least one statement to runtime_iam_create_role and runtime_iam_create_policy, or leave the trust policy out and take the default.

  mcp
• Fixed

  ListObjectsV2 and ListObjects validate max-keys instead of returning a 500 or ignoring it.

  3 details

  • max-keys=0 returns an empty untruncated page rather than crashing the request; a negative value crashed it too.

  • a non-numeric or out-of-int32 value is rejected with InvalidArgument where it used to be replaced by the 1000 default.

  • a value above 1000 is clamped, and MaxKeys reports the clamped page size; ListObjectVersions shares the validation.

  Migration

  clients sending a malformed or negative max-keys now get a 400 and must send a value between 0 and 2147483647.

  s3
• Fixed

  PutBucketTagging and PutObjectTagging enforce the documented tag-set limits.

  • a tag set repeating a key, or carrying a key outside 1-128 characters or a value over 256, is rejected with InvalidTag instead of silently collapsing to the last value.

  • more than 50 bucket tags or 10 object tags is rejected with BadRequest.

  Migration

  a client sending duplicate tag keys or an over-long key/value now gets a 400 and must deduplicate or shorten the tag set.

  s3
• Fixed

  CreateBucket rejects an invalid bucket name with S3’s documented InvalidBucketName code instead of InvalidArgument.

  • the reserved -an suffix follows it; an unrecognised x-amz-bucket-namespace value stays InvalidArgument, which is what S3 documents for a bad request argument.

  Migration

  a test asserting InvalidArgument from CreateBucket on a malformed name should expect InvalidBucketName — the code real S3 returns.

  s3
• Fixed

  the three batch operations enforce AWS’s entry limits, rejecting a whole batch rather than half-applying it.

  • an empty batch, more than 10 entries, or duplicate entry Ids are refused with EmptyBatchRequest, TooManyEntriesInBatchRequest and BatchEntryIdsNotDistinct.

  Migration

  a client sending oversized or duplicate-id batches was silently succeeding locally and failing on AWS; chunk to 10 distinct-id entries per call.

  sqs
• Fixed

  GetQueueAttributes rejects an unmodelled attribute name with InvalidAttributeName.

  • it used to answer with whatever else matched, so a typo read as “that attribute is empty”.

  Migration

  a typo in an AttributeNames entry now fails the call; correct the name.

  sqs
• Fixed

  PutLogEvents enforces AWS’s ingestion window and batch ordering.

  • an event more than 2 hours ahead, older than 14 days, or older than the log group’s retention is discarded behind a 200 and reported in rejectedLogEventsInfo, as on AWS.

  • a batch whose events are not in chronological order is refused whole with InvalidParameterException.

  Migration

  send current timestamps and sort each batch by timestamp — events outside the window are no longer stored, and the field is the only signal they were dropped.

  cloudwatch-logs
• Fixed

  {{resolve:ssm-secure:...}} resolves only in the properties AWS allows secure strings in (#605).

  • a reference anywhere else fails the resource and rolls the stack back, naming the reference and the property path; the parameter is never decrypted.

  • secretsmanager and plain ssm references stay usable in any property.

  Migration

  move an ssm-secure reference outside AWS’s enumerated properties to secretsmanager, or to a stack parameter.

  cloudformation
• Fixed

  CreateAddon and AWS::EKS::Addon refuse an addonName that DescribeAddonVersions does not publish.

  • Ref on AWS::EKS::Addon now returns <cluster>|<addon>, as on AWS.

  Migration

  use a published add-on name (vpc-cni, coredns, kube-proxy, aws-ebs-csi-driver, eks-pod-identity-agent) or add the add-on to the emulated catalog.

  eks cloudformation
• Fixed

  a GraphQL authorization failure now returns AppSync’s GraphQL error envelope instead of the AWS JSON envelope.

  • status code and errorType/message are unchanged; only errors[0].errorType replaces the top-level __type.

  Migration

  read errors[0].errorType instead of __type when detecting an auth failure on POST …/graphql.

  appsync
• Fixed

  ResourceNotFoundException now answers HTTP 400, matching AWS docs, instead of 404.

  Migration

  raw-HTTP or status-code-based ACM error handling should branch on 400, not 404.

  acm
• Fixed

  BlockPublicPolicy refuses a * principal whose Condition is an empty object, as it already did for an omitted one.

  • AWS defines a public statement as one with no condition keys, so Condition: {} narrows nothing; the check is now shared with Lambda through serviceutil.

  Migration

  give a policy that relied on Condition: {} a real condition key or a specific principal, or send BlockPublicPolicy: false.

  secretsmanager

Breaking changes

• Changed

  OVERCAST_VPC_EGRESS=open|routed|none decides container egress; open is the default, so every container reaches the internet.

  3 details

  • none makes every network Overcast creates --internal — both planes and every per-VPC network — for deterministic CI and air-gapped hosts. Overcast’s APIs and the Runtime API keep working

  • routed decides egress per subnet, from that subnet’s route table — see the Added entry above. An invalid value fails startup rather than falling back

  • a VPC network still follows its internet gateway under open, and that now costs nothing; the gateway no longer decides egress alone, which made a private-with-NAT subnet look isolated

  Migration

  nothing to do on Docker Desktop, which already behaved this way. A containerised or native-Linux host with an --internal control plane now gets egress: set OVERCAST_VPC_EGRESS=none

  networking
• Changed

  the GitHub org and Go module path moved to overcast-sh.

  • repo github.com/Neaox/overcast -> github.com/overcast-sh/overcast; images now publish as ghcr.io/overcast-sh/overcast[:tag]

  Migration

  update imports to github.com/overcast-sh/overcast and pull ghcr.io/overcast-sh/overcast[:tag], not ghcr.io/neaox/overcast. Old module versions and Neaox URLs still resolve

  release
• Changed

  POST /_overcast/debug/reset moved to POST /_overcast/reset and no longer needs OVERCAST_DEBUG.

  Migration

  call /_overcast/reset (and /_overcast/reset/{service}); the debug-gated path is gone

  router cli

Breaking changes

• Changed

  HTTP (v2) API error metrics are recorded under AWS’s real metric names, 4xx and 5xx

  Migration

  CloudWatch queries or alarms watching 4XXError/5XXError on an HTTP API must switch to 4xx/5xx; REST API metric names are unchanged

  apigateway
• Changed

  CreateBucket now rejects a global-namespace bucket name ending in the reserved -an suffix

  Migration

  rename a bucket ending in -an, or create it with x-amz-bucket-namespace: account-regional instead

  s3
• Fixed

  Usage plan responses (CreateUsagePlan, GetUsagePlan, GetUsagePlans) no longer return a keyIds member — the API Gateway UsagePlan shape has no such member; the underlying key associations are unaffected and remain fully readable

  Migration

  stop reading keyIds from usage plan responses; the AWS SDKs never surfaced the member there, so SDK-based clients are unaffected — use GetUsagePlanKeys (the modeled channel) to read a plan’s attached API key IDs

  apigateway
• Fixed

  RestApi responses (CreateRestApi, GetRestApi, GetRestApis, UpdateRestApi) no longer return an arn member, and HTTP Api responses (CreateApi, GetApi, GetApis) no longer return one either — neither the REST (v1) RestApi model nor the v2 Api model has an arn member anywhere

  Migration

  stop reading arn from REST API or HTTP API responses; the AWS SDKs never surfaced the member on either shape, so SDK-based clients are unaffected

  apigateway
• Fixed

  ListApplications and DeleteApplication no longer leak tags/applicationTag, CreateAttributeGroup/UpdateAttributeGroup no longer leak attributes, ListAttributeGroups/DeleteAttributeGroup no longer leak tags/attributes, and associated-resource entries no longer carry a creationTime — the AppRegistry model binds these operations to ApplicationSummary, AttributeGroup, AttributeGroupSummary and ResourceInfo respectively, narrower shapes than the ones the emulator was reusing verbatim from Create/Get/Update

  Migration

  stop reading tags, applicationTag, or attributes off list/delete responses and creationTime off associated-resource entries — real AWS never sent them there either; the fields remain on Create/Get/UpdateApplication and Create/Get/UpdateAttributeGroup, where the model defines them

  appregistry
• Fixed

  ApiCache, DataSource, FunctionConfiguration and Resolver no longer echo an apiId member, and DisassociateSourceGraphqlApi/DisassociateMergedGraphqlApi now return only sourceApiAssociationStatus instead of the full sourceApiAssociation — matching the AppSync model, which never declares apiId on those four shapes and only sourceApiAssociationStatus on either Disassociate response

  Migration

  a raw-JSON consumer should stop reading apiId off cache/data-source/function/resolver response objects (the caller already supplied it as the request path parameter) and read sourceApiAssociationStatus directly instead of sourceApiAssociation.sourceApiAssociationStatus on the two Disassociate responses

  appsync
• Fixed

  The Events API management operations (CreateApi/GetApi/ListApis/UpdateApi and the ChannelNamespace equivalents) emitted created and lastModified as ISO-8601 strings.

  • The AppSync model declares these members as plain restJson1 timestamps — epoch seconds on the wire — and strict deserializers such as the AWS SDK for Go v2 fail on the string form (“expected Timestamp to be a JSON Number”), while boto3 and the CLI happened to tolerate it. The fields are now JSON numbers carrying epoch seconds with millisecond precision, verified end-to-end against the Go SDK v2 appsync client.

  Migration

  Event APIs and channel namespaces persisted by earlier versions store the old string timestamps and fail to load after upgrading; delete and recreate them, or start from fresh state.

  appsync
• Fixed

  GetWorkGroup no longer echoes a Tags member on WorkGroup — the Athena model’s WorkGroup shape has no Tags member; it was leaking straight out of the persisted record

  Migration

  read tags via ListTagsForResource instead of WorkGroup.Tags

  athena
• Fixed

  DescribeChangeSet no longer returns a ChangeSetType member — ChangeSetType is an input-only member of CreateChangeSet;

  • DescribeChangeSetOutput does not have it. The value is still recorded internally and used to drive change-set behavior

  Migration

  stop reading ChangeSetType from DescribeChangeSet responses; the AWS SDKs never surfaced the member there, so SDK-based clients are unaffected — the value you set on CreateChangeSet is already known to the caller

  cloudformation
• Fixed

  OriginRequestPolicyConfig’s CookiesConfig, HeadersConfig, and QueryStringsConfig now round-trip the modeled CookieBehavior/HeaderBehavior/QueryStringBehavior member alongside their lists, instead of a bare Quantity/Items list that silently dropped the behavior

  Migration

  stored origin request policies created before this change lose their persisted cookie/header/query-string lists on next read, because the old JSON shape ({"quantity":N,"items":[...]}) does not populate the new {"cookie_behavior":...,"cookies":{...}} shape; recreate any pre-existing OriginRequestPolicy records after upgrading. SDK clients are unaffected going forward, since they already send the modeled, required *Behavior member and now get it back on Get/List responses instead of a bare list.

  cloudfront
• Fixed

  RealtimeLogConfig’s Fields list now uses <Field> child elements, matching the FieldList shape’s xmlName trait, instead of the generic <member> element used by other lists

  Migration

  SDK and CLI clients are unaffected, since they already send and expect <Field>. Anything hand-parsing the previous, incorrect <member> wire shape needs to switch to <Field>.

  cloudfront
• Fixed

  GetTrailStatus emitted a fabricated LatestCloudWatchLogsError member, always empty.

  • The real optional member is LatestCloudWatchLogsDeliveryError, which real AWS omits from the response while empty; overcast never populates it, so the field is dropped entirely rather than emitted empty.

  Migration

  LatestCloudWatchLogsError is gone; the real member is LatestCloudWatchLogsDeliveryError, omitted from the response while empty.

  cloudtrail
• Fixed

  self-service GetUser no longer fabricates UserCreateDate/UserLastModifiedDate. AWS’s GetUserResponse shape carries only Username, UserAttributes, MFAOptions, PreferredMfaSetting and UserMFASettingList — the two timestamp members belong to AdminGetUserResponse/UserType, which AdminGetUser and ListUsers keep returning unchanged.

  Migration

  read a user’s creation/modification timestamps from AdminGetUser instead of self-service GetUser, as on real AWS.

  cognito
• Fixed

  table descriptions no longer carry fabricated top-level BillingMode, TTL or Tags members on CreateTable/DescribeTable/UpdateTable/DeleteTable responses

  Migration

  raw-JSON consumers must read BillingModeSummary.BillingMode (absent for a table left on the default PROVISIONED mode, matching AWS), DescribeTimeToLive and ListTagsOfResource — the modeled channels, already supported — instead of the table description; SDK clients are unaffected

  dynamodb
• Fixed

  CreateSecurityGroup, AssociateAddress and DeleteVpcEndpoints stopped emitting a <return> element the AWS model never defines for their results (CreateSecurityGroupResult, AssociateAddressResult and DeleteVpcEndpointsResult declare no such member — verified against the Smithy EC2 model), and AssociateRouteTable now names its association ID <associationId>, matching AssociateRouteTableResult’s xmlName/ec2QueryName trait, instead of <newAssociationId>, which belongs to a different pair of operations (ReplaceRouteTableAssociation/ReplaceNetworkAclAssociation).

  • Strict deserializers such as the AWS SDK for Go v2 decode by the modeled name, so AssociateRouteTable previously handed every SDK caller back an empty AssociationId; it now comes back populated.

  Migration

  raw-XML or regex-based consumers of AssociateRouteTableResponse must read associationId, not newAssociationId. Callers going through an AWS SDK are unaffected by the removed return fields (SDK output types never exposed them) and gain a correctly populated AssociateRouteTable AssociationId.

  ec2
• Fixed

  SetRepositoryPolicy no longer returns a repositoryArn member — the AWS ECR API models that response as [registryId, repositoryName, policyText] only, matching its sibling GetRepositoryPolicy/DeleteRepositoryPolicy operations

  Migration

  stop reading repositoryArn from SetRepositoryPolicy responses; the AWS SDKs never surfaced the member, so SDK-based clients are unaffected — use DescribeRepositories to read a repository’s ARN

  ecr
• Fixed

  RegisterContainerInstance/DeregisterContainerInstance/DescribeContainerInstances, RunTask/StopTask/DescribeTasks and CreateService/UpdateService/DeleteService/DescribeServices no longer emit clusterName on a container instance, networkConfiguration/networkNamespaceId on a task, dockerId on a task’s containers, or taskSets on a service — none of these are members of AWS’s ContainerInstance, Task or Service shapes.

  • A task’s awsvpc details were always available on attachments as well, which is where AWS puts them; networkConfiguration only really exists on Service, Deployment and TaskSet, and Overcast keeps emitting it there

  Migration

  raw-JSON callers reading these fields directly lose them; the AWS SDKs never modeled them, so SDK-based clients are unaffected

  ecs
• Fixed

  Serverless cache responses (CreateServerlessCache/DescribeServerlessCaches/ModifyServerlessCache/DeleteServerlessCache) echoed a SnapshotArnsToRestore member on the ServerlessCache shape.

  • The ElastiCache model declares SnapshotArnsToRestore only on CreateServerlessCacheRequest; the ServerlessCache output shape has no such member. The field is no longer emitted on the wire, matching real AWS; the create call still accepts it as input.

  Migration

  SDK clients are unaffected — they never modeled a SnapshotArnsToRestore field on the ServerlessCache response shape, so nothing to change there. Callers that were parsing it off raw XML/JSON responses should stop relying on it.

  elasticache
• Fixed

  GetDatabase/GetDatabases/GetTable/GetTables no longer echo a Tags member on Database/Table — the Glue model’s Database and Table shapes have no Tags member; it was leaking straight out of the persisted record

  Migration

  read tags via GetTags instead of Database.Tags/Table.Tags

  glue
• Fixed

  CreateFunction and UpdateFunctionConfiguration reject function environment variables that use Lambda’s reserved runtime keys (AWS_REGION, AWS_LAMBDA_FUNCTION_NAME, _HANDLER, AWS_ACCESS_KEY_ID, AWS_LAMBDA_RUNTIME_API, LAMBDA_TASK_ROOT, …) with real Lambda’s InvalidParameterValueException (”… contains reserved keys that are currently not supported for modification”), instead of accepting them and silently overriding the values at container start.

  • The list is AWS’s documented reserved set; the unreserved runtime keys (PATH, LANG, LD_LIBRARY_PATH, NODE_PATH, NODE_OPTIONS, PYTHONPATH, GEM_PATH, TZ, …) stay settable, as on AWS

  Migration

  remove reserved keys from a function’s Environment.Variables — real AWS never accepted them, and the runtime always provided its own values for them inside the container, so deleting them changes nothing the function observes

  lambda
• Fixed

  DescribeOrganization emitted a fabricated MasterUserEmail member on the Organization shape;

  • the real API has no such member. It now emits the modeled trio MasterAccountId, MasterAccountArn, and MasterAccountEmail, verified against the Organizations Smithy model.

  Migration

  Callers reading MasterUserEmail from DescribeOrganization must switch to MasterAccountEmail for the email address, and can now also read MasterAccountId and MasterAccountArn; MasterUserEmail is gone — it never existed in the AWS API.

  organizations
• Fixed

  V2 GetEmailIdentity no longer returns an IdentityName member — the SESv2 API models that response without one; IdentityName belongs only to ListEmailIdentities’ IdentityInfo items, which are unaffected

  Migration

  stop reading IdentityName from GetEmailIdentity responses; the AWS SDKs never surfaced the member there, so SDK-based clients are unaffected — the identity name is already known to the caller (it’s the request’s EmailIdentity) or is available from ListEmailIdentities

  ses
• Fixed

  ListProtections/DescribeProtection no longer echo a Tags member on Protection — the Shield model’s Protection shape has no Tags member; it was leaking straight out of the persisted record

  Migration

  read tags via ListTagsForResource instead of Protection.Tags

  shield
• Fixed

  DescribeSubscription drops the hardcoded SubscriptionState member — that field belongs only to GetSubscriptionStateResponse, a separate operation Overcast does not implement, and was never part of Subscription

  Migration

  none available; GetSubscriptionState is not implemented

  shield
• Fixed

  DescribeServer no longer returns a CreatedAt member on the described server — the AWS Transfer Family API has no server creation timestamp anywhere in its model, so the emulator was inventing wire data

  Migration

  stop reading Server.CreatedAt from raw DescribeServer responses; the AWS SDKs never surfaced the member, so SDK-based clients are unaffected

  transfer

Breaking changes

• Changed

  LAMBDA_PROACTIVE_INIT now defaults to true:

  • after a settled function has trigger evidence (an invocation this process, a function URL, or an event source mapping), one execution environment is created in the background ~10 s after its last identity-changing write, so the next request lands warm instead of paying a cold start. This is the flip deferred from the cold-start plan after a release of opt-in soak surfaced no regressions. Proactive creation reserves capacity through the same admission budgets (instance count, memory including the high-water margin) a real invocation would, non-blockingly, so it can never queue ahead of real traffic; it never runs for functions with provisioned concurrency, an existing environment, or reserved concurrency of zero

  Migration

  set LAMBDA_PROACTIVE_INIT=false to opt back out and restore the previous on-demand-only behaviour

  lambda
• Changed

  the control plane is now created --internal whenever Overcast can tell it is safe — Overcast is itself containerised, or is running on a native Linux Docker daemon — closing the one documented egress path a gateway-less VPC’s containers had:

  • every VPC-placed resource without an internet gateway now genuinely has no route out, matching a private subnet with no NAT gateway. A native Overcast on a Docker Desktop host is unaffected — the probe declines there and the control plane stays an ordinary bridge; a containerised Overcast qualifies wherever it runs, Docker Desktop included

  Migration

  a Lambda function or ECS task in a VPC with no internet gateway that reached the real internet through this leak (a package fetch, an external HTTP call at cold start) now times out the way it would on AWS — attach an internet gateway, or set PubliclyAccessible (RDS) / assignPublicIp: ENABLED (ECS) per docs/networking.md, to restore reach

  networking ec2
• Changed

  the Aurora writer endpoint is now {cluster}.cluster.{region}.rds.{base}, not {cluster}.cluster-rw.….

  • cluster-rw was a label AWS has never used; dropping the account-specific hash from AWS’s own {cluster}.cluster-{hash}.…, as every Overcast endpoint name does, leaves a bare cluster. The reader endpoint is unchanged

  Migration

  nothing to do if you read the endpoint from DescribeDBClusters or CloudFormation — the new name arrives on the next deploy. If you hard-coded or reconstructed …cluster-rw.… anywhere (task definition, secret, .env), replace it with the value the API returns; the old spelling keeps resolving for an existing cluster and stops once that cluster is recreated

  rds
• Fixed

  every one of the seventeen services that had a tag-accepting operation reaching AWS’s own tag constraints in name only now routes it through the shared serviceutil.ValidateTags — a reserved aws: key prefix, an over-length key or value, or more than 50 tags on one resource is refused instead of silently stored, on every TagResource-style operation and every Create*’s inline Tags member these services carry. Three of the seventeen (Cognito, Glue, Step Functions) were already fixed and needed no change

  Migration

  fix any tags on these services that use a reserved aws: key prefix, exceed the 128/256-character key/value length limit, or exceed 50 tags on one resource — Overcast previously accepted and silently stored these; AWS itself has always rejected them

  acm apigateway appregistry appsync cloudformation cloudfront cognito dynamodb ecr efs glue iam kinesis kms msk secretsmanager stepfunctions
• Fixed

  BackupVaultTags/CreateBackupVault and BackupPlanTags/CreateBackupPlan are now validated and stored instead of being silently accepted and dropped, so a vault or plan tagged with a reserved aws: key prefix, an over-length key or value, or more than 50 tags is refused instead of succeeding with the tags discarded

  Migration

  fix any BackupVaultTags/BackupPlanTags that use a reserved aws: key prefix, exceed the 128/256-character key/value length limit, or exceed 50 tags on one resource — Overcast previously accepted and silently dropped these; AWS itself has always rejected them

  backup
• Fixed

  ECR repository templates now get their ImageTagMutability, ImageScanningConfiguration, EncryptionConfiguration and Tags.

  • The repository handler’s create sent only repositoryName and applied RepositoryPolicyText/LifecyclePolicy as follow-ups, dropping the rest even though the ECR service already stored and echoed ImageTagMutability on both wire paths — a CDK repository with imageTagMutability: TagMutability.IMMUTABLE provisioned as mutable. ImageTagMutability and ImageScanningConfiguration now reach CreateRepository on create and are reconciled through two new operations, PutImageTagMutability and PutImageScanningConfiguration, on update; Tags reaches CreateRepository and is reconciled through TagResource/UntagResource, the same as the Lambda, LogGroup, Secrets Manager and SQS handlers. EncryptionConfiguration is forwarded on create and, since real ECR has no API to change it later, a template that changes it now replaces the repository instead of an update silently keeping the old encryption. EmptyOnDelete is honoured on delete: force is only passed to DeleteRepository when the template says EmptyOnDelete: true, matching real CloudFormation’s default of failing to delete a repository that still holds images

  Migration

  a stack relying on the old always-force delete must set EmptyOnDelete: true on the repository to keep deleting it while it still holds images

  cloudformation ecr
• Fixed

  AWS::ElastiCache::CacheCluster takes its cluster name from ClusterName, the resource’s own property.

  • It read CacheClusterId — what the API calls the parameter, and not a property the resource has at all — so a template that named its cluster got one named after the stack instead, and every endpoint the stack advertised belonged to a cluster nobody had asked for. An unnamed cluster now gets CloudFormation’s generated name rather than <stack>-cache, which carried neither the logical ID nor the random suffix: two unnamed clusters in one stack were handed the same ID, and the second create failed on a name the template never mentions. The generated name is lowercased and capped at 50 characters, which is what ElastiCache accepts in a cluster ID

  Migration

  CacheClusterId on this resource was never valid CloudFormation and is now ignored. Spell it ClusterName to keep the cluster’s name; leave it and the next change to that resource replaces the cluster with the generated one. Stacks already deployed keep the physical ID they were given until something replaces the resource

  cloudformation elasticache
• Fixed

  Fn::GetAtt on a cache cluster resolves the endpoint pair the engine has — RedisEndpoint.Address/.Port for Redis and Valkey, ConfigurationEndpoint.Address/.Port for Memcached, as AWS populates them.

  • Only the ConfigurationEndpoint pair was exported, whatever the engine, and a GetAtt on an attribute a handler does not export does not fail: it falls back to the physical ID. CDK’s attrRedisEndpointAddress therefore handed out a bare cluster ID as a hostname, which no container advertises and nothing can resolve, so an ECS task with REDIS_HOST baked in at deploy time died on getaddrinfo rather than reaching the cache. The pair the engine does not have resolves empty, so a template reading the wrong one gets the same nothing it would get on AWS

  Migration

  a Redis or Valkey cluster’s ConfigurationEndpoint.Address is now empty rather than carrying the endpoint, which is what AWS answers for it. Read RedisEndpoint.Address — CDK’s attrRedisEndpointAddress — as code written against AWS already does

  cloudformation elasticache
• Fixed

  a DELETE_COMPLETE stack is no longer resolvable by name on DescribeStacks, DescribeStackEvents, ListStackResources, DescribeStackResources, GetTemplate and GetTemplateSummary — each now answers ValidationError: Stack with id <name> does not exist, matching AWS’s rule that a deleted stack is addressable only by its unique stack ID once its name is free to reuse.

  • The stack ID (ARN) captured at create still resolves the deleted stack’s final state and events, as does a stack mid-DELETE_IN_PROGRESS looked up by name; only the terminal record excludes the name path. Mutations already treated DELETE_COMPLETE as nonexistent; this closes the one read-side divergence that was deliberately left open

  Migration

  a client that polled DescribeStacks by name to observe a delete finishing (rather than by the stack ID CreateStack returned) now gets a ValidationError instead of a DELETE_COMPLETE body once the delete completes — the same as the AWS SDK’s stack-delete-complete waiter, which already treats that error as the terminal success case. Poll by the stack’s ID, or treat the does-not-exist error as “deleted” the way the waiter does

  cloudformation
• Fixed

  AWS::CloudTrail::Trail now reads the trail name from TrailName, the real resource schema’s property, instead of Name

  Migration

  rename Name to TrailName in any template using this resource; a template still setting Name gets an auto-generated trail name instead of a validation error, since Overcast has no per-property unrecognised-property diagnostic

  cloudformation cloudtrail
• Fixed

  AWS::KMS::Key used to provision successfully and quietly keep the AWS default whenever a template set Origin to anything other than AWS_KMS, MultiRegion: true, or EnableKeyRotation: true — the emulator models none of import/CloudHSM origins, the replica-key relationship multi-Region implies, or rotation state.

  • CreateKey now answers ValidationException for the first two (and both are replacement-required on update); EnableKeyRotation: true (CDK’s enableKeyRotation, a common setting) is now dispatched to the KMS service’s EnableKeyRotation operation, which does not exist, so the resource fails loudly instead of silently reporting rotation off forever — the same “dispatch to the gap” treatment AWS::IAM::User’s LoginProfile gets

  Migration

  drop Origin/MultiRegion from any AWS::KMS::Key template that relied on them being ignored, and drop EnableKeyRotation: true (enableKeyRotation: true in CDK) until key rotation is emulated

  cloudformation kms
• Fixed

  AWS::Athena::WorkGroup now reads the workgroup configuration from WorkGroupConfiguration, the real resource schema’s property, instead of Configuration (the CreateWorkGroup API member it maps onto); a template’s result location, bytes cutoff and the rest were silently dropped before

  Migration

  rename Configuration to WorkGroupConfiguration in any template using this resource; a template still setting Configuration gets a workgroup with no configuration instead of a validation error, since Overcast has no per-property unrecognised-property diagnostic

  cloudformation athena
• Fixed

  native overcast serve now defaults to binding 127.0.0.1 instead of 0.0.0.0;

  • the containerised default (Docker image, OVERCAST_DATA_DIR_SOURCE=image) is unchanged at 0.0.0.0. An explicit OVERCAST_LISTEN always wins over either default

  Migration

  native users reaching Overcast from another machine, a VM, or a phone on the same network must set OVERCAST_LISTEN=0.0.0.0 to restore the old reach

  config
• Fixed

  OVERCAST_HOST is renamed to OVERCAST_LISTEN (LocalStack’s GATEWAY_LISTEN idiom) and removed rather than kept as an alias — a leftover OVERCAST_HOST now fails at startup naming OVERCAST_LISTEN as the replacement, instead of being silently ignored

  Migration

  rename OVERCAST_HOST to OVERCAST_LISTEN wherever it is set (env, .env files, docker-compose.yml, CI config) — the value format is unchanged, the same comma-separated address list

  config
• Fixed

  DeleteSecurityGroup, DeleteSubnet and DeleteVpc now answer DependencyViolation while a dependent (instance, ENI, subnet, gateway, endpoint, peering connection) remains, matching AWS instead of deleting unconditionally; the VPC default security group answers CannotDelete

  Migration

  clear dependents before deleting a security group, subnet or VPC — a template or script that relied on the unconditional delete now sees the same refusal real AWS gives, surfaced by CloudFormation teardown as DELETE_FAILED instead of a silent dangling reference

  ec2
• Fixed

  CreatePipe/UpdatePipe now refuses a stream source’s DeadLetterConfig naming a destination that is not an SQS queue or an SNS topic, instead of storing it and only failing once a batch exhausts its retries

  Migration

  point DeadLetterConfig.Arn at an SQS queue or SNS topic, or remove it

  pipes
• Fixed

  CreateDBCluster and CreateDBInstance enforce the identifier shape AWS documents — 1 to 63 letters, numbers or hyphens, starting with a letter, no trailing or doubled hyphen — and store identifiers lowercase, so a describe finds what a create made whatever case it was sent in

  Migration

  an identifier real RDS would have refused is now refused here too; rename it to match the documented shape. A mixed-case identifier keeps working and comes back lowercased, as it does on AWS

  rds
• Fixed

  a DBSubnetGroupName naming no existing subnet group is refused by CreateDBCluster and CreateDBInstance, and DBSubnetGroupNotFoundFault carries AWS’s documented 404 rather than a 400

  Migration

  create the subnet group before the database that references it, as AWS requires. Code branching on the 400 status rather than the error code should read the code, which has not changed

  rds
• Fixed

  cluster BackupRetentionPeriod defaults to 1 and is held to AWS’s documented 1–35 on create and modify; Port is held to 1150–65535 on both

  Migration

  a cluster created without BackupRetentionPeriod now reports 1 rather than 0. BackupRetentionPeriod=0 was never a value AWS accepts for a cluster and is now refused; send 1 to mean the minimum

  rds
• Fixed

  AppRegistry, EFS, EKS and Scheduler no longer answer POST / for an X-Amz-Target header (AppRegistry., EFS., EKS., Scheduler.) or a Smithy RPC v2 label (/service/<name>/operation/<op>) — a wire the pinned models never gave these restJson1 services and no real SDK ever sends. Both doors now answer the same honest “unknown operation”/“unsupported protocol” error any nonsense request gets, never a 200

  Migration

  address these four services only at their modeled REST bindings, the paths already documented under docs/services/, the same way any AWS SDK or the aws CLI reaches them today

  router appregistry efs eks scheduler