We are proud to announce that Peritos has achieved the highly esteemed AWS Advanced Tier Partner status, a significant milestone in our pursuit of innovation and excellence. This strategic achievement showcases our ongoing dedication to providing state-of-the-art cloud computing solutions and expertise through AWS.

 

The AWS Advanced Tier Partner designation is a testament to our unwavering dedication to offering top-notch services and solutions that empower businesses to harness the full potential of cloud technology. This accolade recognizes our technical proficiency and acknowledges their extensive experience in architecting, deploying, and managing scalable applications on the AWS platform.

 

As we attain this higher level, we can now utilize an extensive selection of resources and tools offered by AWS. It allows us to enhance our services and cater to clients from diverse fields. Our clients can now use various advanced AWS solutions, improving performance, security, and scalability.

 

This achievement underscores Peritos’ continuous pursuit of excellence and unwavering dedication to staying ahead of the curve in a rapidly evolving technological landscape. It also reinforces our commitment to helping businesses of all sizes drive innovation, streamline operations, and achieve digital transformation goals through the power of cloud computing.

The Think Big for Small Business Program from AWS consulting services offers exclusive access to business, technical, and marketing support for small and/or minority-owned public entities. This program provides access to cloud-based services and the opportunity to gain experience with international agencies, governments, and the space industry. There are three main reasons to like this globally available program:

 

Firstly, it celebrates and promotes diversity by focusing on small and diverse business partners, which helps to elevate small and medium-sized enterprises (SMEs) and minority-owned businesses (MOBs). This program supports governments, countries, cities, and agencies in achieving this goal.

Secondly, the program offers global coverage, which includes geographic diversity. The program was the brainchild of Linh Le, the AWS Public Sector Partner leader from Singapore. He worked with team members worldwide to create an exceptional partner experience.

Lastly, the program supports small businesses, which aligns with AWS’s founding principle that the cloud is an empowering technology for companies of all sizes. The Think Big for Small Business Program aligns with the government’s focus on supporting small businesses.

AWS equips tiers (Select, Advanced & Premier) to name organizations that have proven specialized technical ability and shown customer experience. AWS Select Tier Services Partners are the partners with proficient and certified individuals with customer experience. The AWS Select Tier Services offers the benefits of the AWS Distribution Program for Resellers, ISV Workload Migration Program, AWS Public Sector Partner Program, AWS Service Delivery Program, and AWS Solution Provider Program.  

 

Millions of consumers—including the fastest-growing startups, largest enterprises, and leading governance agencies—are using AWS to lower costs, become more agile, and innovate faster. However, at the same time, certain requirements need to be fulfilled to qualify for being upgraded to the AWS Select Tier Services. Peritos Solutions proudly claims that our persistent efforts and challenging work catalyzed the process of being upgraded to Select Tier services. We fulfilled all the requirements demanded for this upgradation such as APN Fee, Knowledge requirements, Experience requirements & Customer Success requirements. More benefits and resources can be unlocked as you progress through the tires and grow with AWS. You can acquire credibility by leveraging the AWS brand, known for innovation, client centricity, and the pace of innovation. Deliver more innovation with the continuously unwinding portfolio of ground-breaking AWS technologies and services. 

Introduction- AWS Tagging Rules

There are certain requirements to define the AWS tagging rules and one must follow them.

This topic describes commonly used  tagging, categories and strategies to help you implement a consistent and effective tagging strategy. The following sections assume basic knowledge of AWS resources, tagging, detailed billing, and AWS Identity and Access Management (IAM).

Each tag has two parts:

• A tag key (for example, CostCenter, Environment, or Project). Remember that tag keys are case sensitive.
• A tag value (for example, 111122223333 or Production). Like tag keys, tag values are also case sensitive.

Tags would be used to categorize resources by purpose, owner, environment, or other criteria. Please add, change, or remove tags one resource at a time from each resource’s service console, service API, or the AWS CLI.

• Each resource can have a maximum of 50 tags.
• For each resource, each tag key must be unique, and each tag key can have only one value.
• The maximum tag key length is 128 Unicode characters in UTF-8.
• The maximum tag value length is 256 Unicode characters in UTF-8.
• Allowed characters are letters, numbers, spaces representable in UTF-8, and the following characters: . : + = @ _ / – (hyphen). Amazon EC2 resources allow any characters.
• Tag keys and values are case sensitive. As a best practice, decide on a strategy for capitalizing tags, and consistently implement that strategy across all resource types. For example, decide whether to use Costcenter, costcenter, or CostCenter, and use the same convention for all tags. Avoid using similar tags with inconsistent case treatment.
• The aws prefix is prohibited for tags; it’s reserved for AWS use. You can’t edit or delete tag keys or values with this prefix. Tags with this prefix do not count against your tags per resource quota.

This article summarizes AWS Tagging Rules and that includes:

• Types of tags
• Best practices
• Naming Constructs
• Mandatory Type of tags

Types of Tags

Below is the account structure we are planning to adopt

• Tags for AWS console organization and Resource groups
• Tags for cost allocation example cost center, business unit or project
• Tags for automation
• Tags for operational support – Backup, Restore, Patching, Ticket creation in ITSM
• Tags for access control
• Tags for security risk Management

AWS Tagging Rules- Best Practices

You should follow the below practices in using the tags

• Inform each team and stakeholders about the right tags so that they can use them and check periodically for the same in reports.
• Use tags consistently
• Tag owners should be identified to enable use and tracking of tags
• Tags for cost
  1. Tagging decisions are reversible, giving you the flexibility to edit or change as needed in the future. However, there is one exception—cost allocation tags—which are included in AWS monthly cost allocation reports. The data for these reports is based on AWS services utilization and captured monthly. As a result, when you introduce a new cost allocation tag it takes effect starting from that point in time. The new tag will not apply to past cost allocation reports
  2. Adopt a standardized approach uses the naming convention as listed in the document below for resource specific tags
• Tag everything
• Constrain tag values: Tags are not useful if they contain missing or invalid data values. If tag values are set by automation, then automation code can be reviewed, tested, and enhanced to ensure that valid tag values are used. When tags are entered manually, there is the opportunity for human error. Reduce this by using AWS Service Catalog
• Propagate tags and then tag values across related resources
• If tags are used in access control limit, users have the ability to modify tag values in order to gain access
• Use AWS Configuration to create rules to check resources for required tags as it will continuously monitor your resources against those rules 
• Impact analysis, approval, and implementation for requests to add, change, or deprecate tags application of existing tagging requirements as new AWS services are adopted by monitoring and remediation of missing or incorrect tags

• Use each key only once for each resource. If you attempt to use the same key twice on the same resource, then your request will be rejected.
• You cannot tag a resource at the same time you create it. Tagging requires a separate action after the resource is created.
• You cannot backdate the application of a tag.
• Maximum number of tags per resource: 10
• The more tags you have, the better your AWS visibility.
• Standardize your tagging format to prevent duplications, mix-ups, and inconsistencies.
• Don’t use tags to store confidential data such as your personal information. Because tags are used across many services on AWS, the information could be accidentally shared
• Automation tools, such as CloudFormation templates can help you tag resources proactively, especially as you scale.
• Get notified automatically when tags are incorrect or missing.
• Designate a tag owner – the individual who owns a specific tag and can demonstrate its value to the organization.

AWS Tagging Rules- Naming Constructs

The following basic restrictions apply to tags.

Restriction	Description
Maximum number of tags per resource	50
Maximum key length	128 Unicode characters in UTF-8
Maximum value length	256 Unicode characters in UTF-8
Prefix restriction	Do not use the aws: prefix in your tag names or values because it is reserved for AWS use. You can’t edit or delete tag names or values with this prefix. Then tags with this prefix do not count against your tags per resource limit.
Character restrictions	Tags may only contain Unicode letters, digits, whitespace, or these symbols: _ . : / = + – @

Mandatory Types of Tags

“Environment” Tag

The “environment” tag refers to the hierarchical stages an application deployment migrates through.

Tag Name

The tag name MUST be written as “environment”.

Possible Value

• The tag value for environment MUST be one of [“Production”, “UAT”, “Test” or “Development”].
• If you have an environment that is not one of the values listed, you MUST select a value that most closely relates.  Note: the “Name” tag convention MAY allow more flexibility for this.
• The tag value SHOULD be in agreement with the scope of the account you are in.

Rationale

•  Useful for Business Owner to understand their spending by environment and possibly see opportunities for cost savings.
• Operations – Monitoring (among other things) is driven directly by the environment.

“Application” Tag

• The “application” tag refers to the application context of the resource.

 Tag Name

• The tag name MUST be “application”.

Possible Values

• The tag value for the application must be the same name as the application name in AWS

Rationale

• Billing – Since most groups manage more than one application, it is useful to be able to differentiate and spend on a per-application basis.
• Operations – By matching the nomenclature in this tag to the list of Applications then this tag can be used for Incident Management purposes and routing any requests to the specific application owner
• Security – As with Operations, this tag could be used to escalate Security incidents to the appropriate party.

“Costcenter” Tag

• The “costcenter” tag refers to the identifier used to manage billing for a resource.

Tag Name

• The tag name MUST be “cost center”.

Possible Values

• Different cost center code values then which can be defined specific to each client

Rationale

• Billing – Enables AWS Billing to divide up a single account among multiple costcenter codes.

“Name” Tag

• The “Name” tag is used by Amazon to display a default name in the AWS console for many resource types.

Tag Name

• The tag name MUST be “Name”. Note the uppercase “N”, as distinct from other Tag Names in this document.

Possible Values

• The Name value is arbitrary but SHOULD be standardized across organizations.
• Refer to AWS Naming conventions and then name should be same or similar specific to the AWS Account, Application or env name
• See the Appendix section for naming restrictions specific to your cloud vendor.

Rationale

• Operations – If this tag is not populated, then AWS consoles will not display a name for assets, making them difficult to manage at a glance.

“Platform” Tag

The “platform” tag is then primarily used for operational purposes to distinguish between the major operating system types (Linux and Windows) for better visibility within configuration management.

Tag Name

• The tag name MUST be “platform” (lowercase).

Possible Values

• Tag values must be lowercase.
• “linux” for Linux based instances (Amazon Linux, CentOS, RHEL, Ubuntu, etc…).
• “windows” for Windows based instances.

Rationale

• To allow greater visibility to the configuration management system for inventory grouping purposes.
• Allow better filtering of operating system types within other data gathering tools.

Optional Tags: AWS tagging rules

Assume that all tags and values are case sensitive, particularly for arbitrary values.

“Subproduct” Tag

• The “subproduct” is OPTIONAL and refers to specify a sub classification of your product.

Tag Name

• The tag name MUST be “subproduct”.

Possible Values

• Component of product or application (implied hierarchical relationship with product).
• Then see the Appendix section for naming restrictions specific to your cloud vendor.

Rationale

• Billing – If the “product” tag is insufficiently granular for managing IT spend inside a single group, then  this tag can also be used.

Authorization to Create/Edit Tags

• Tags are sensitive and should only be created/updated by those with the appropriate level of permission. Then this can be accomplished with an execution model which is not yet standardized at the time of this writing.
• Incorrectly tagged assets can impact both billing and uptime of your application.

Security Awareness

• Tags will help identify the appropriate owner and then to take corrective action in ongoing compliance testing.
• Tags provide the context to determine if an application has the appropriate level of security applied for its data classification.
• Without tags, a compromised asset with no ownership data may need to be forcefully locked down and then  potentially causing interruption to your business.

Conclusion: AWS tagging rules

In conclusion, Managing assets in the cloud effectively requires coordination across stakeholder interests.  A consistent tagging standard enables you to audit, authorize, bill, communicate and secure resources in the cloud more quickly. Then  Additional tags can be used in many more useful ways that are more application or department specific.

Reference

1. https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html
2. https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pd

The AWS Public Sector Partner (PSP) Program validates AWS consulting service partners with cloud-based solutions and an understanding of supporting the government, space, education, and nonprofit organizations globally. AWS partners are delivering critical solutions and services to public sector organizations from Universities in Africa to Law enforcement agencies in Europe to nonprofits in Asia. The partners are helping their customers overcome technological challenges. The AWS public sector partner program, also known as PSP, helps partners accelerate engagement with public sector organizations.   

 Peritos was confirmed for AWS public Sector Competency and we underwent a technical validation to receive the AWS Competency designation, which highlights top AWS Partner Network (APN) Partners to customers, and organizations, for getting selected. We were also assessed on the previous work done, security, performance, and dependability of our Amazon Web Services (AWS) solutions and we fulfilled all the mentioned criteria.     

The Think Big for Small Business Program of AWS consulting services supplies unique access to business, technical, and marketing enablement support for small and/or minority-owned public entities. This program allows you access to cloud-based services and gain experience with international agencies, government, and the space industry. The 3 things to like about the now globally available Think Big for Small Business Program: 

Celebrating and promoting diversity- With a focus on partners who are small and diverse businesses the Think Big for Small Business Program helps elevate small and medium enterprises (SMEs) and MOBs as well as helps governments, countries, cities, and agencies.  

Global coverage- Diversity also means geographic diversity. This program was the idea of Linh Le, the AWS Public Sector Partner leader from Singapore, who worked with the team members globally to figure out how to help make this program a great partner experience.  

Supporting small businesses-AWS was built on the concept that the cloud is an empowering technology for all sizes of companies. The Think Big for Small Business Program aids the government’s focus on supporting small businesses.