AWS Partner Network (APN) Blog

Since the launch of the official AWS Managed Service Program in 2014, more than 50 APN Partners across the world have successfully completed the third-party validation audit established by the MSP team. More and more firms are looking for guidance on what it takes to pass the audit, and become an AWS MSP.

Along with the MSP Validation Checklist we’ve made available on the APN Portal, we want to share some tips and tricks to successfully prepare for (and pass!) your audit from the third-party auditing firm, ISSI. “ISSI is primarily a consulting company, focused on building streamlined, effective management systems that allow our customers to achieve compliance with industry and customer specifications,” says Burjor Mehta, ISSI CEO. “AWS engaged ISSI’s worldwide team to conduct the (AWS) Managed Service Program partner audits because of our dedication to a collaborative, consultative approach; our goal is to ensure not only that APN Partners meet the high standards set by AWS for next generation MSPs but also to encourage APN Partners to look for ongoing opportunities for improvement and alignment with AWS best practices. We’re excited to be part of the transformation of the managed service provider industry as defined by the AWS MSP program!”

Without further ado, let’s jump into the seven steps for successful preparation as outlined by ISSI.

Step One: Prepare

We have seen overwhelmingly that APN Partners who spend more time planning and preparing for the audit have a better experience and a more positive outcome.

• Carefully review the current AWS Managed Service Program Partner Validation Checklist; use the validation checklist to complete the Self-Assessment as a gap analysis of your current compliance compared to the actual program requirements
• Focus on the items that have scores that are more heavily weighted (i.e, +0, -200)
• Highlight any controls in the Checklist that are unclear, or controls that you’re concerned about your ability to provide evidence
• If compliance gaps are significant or if you are early in the development and implementation of your Managed Service practice, consider engaging a consultant to better prepare you for the audit
• After you’ve verified that you can satisfy the highest weighted requirements and a majority of the remaining items, submit your AWS MSP application through the APN Portal

Step Two: Organize and Assign

A common misconception is that one person in the organization must be able to provide all of the answers during the audit; don’t hesitate to identify and engage your internal subject matter experts to collaborate on audit preparation.

• Note which checklist items belong to which groups within your business, and assign to the appropriate stakeholders
• Establish a working timeline, and set deadlines and meetings with key people to address evidence and progress – lean on your Project Management Officer (PMO), if possible, for support
• Get buy-in from management to assist with the delegation of relevant tasks to the appropriate teams
• Create a central repository for audit documents, information, and completed evidence (using Amazon WorkDocs or Amazon S3 can help!)
• Analyze areas of immaturity, and establish timelines to implement short-term and long-term improvements

Step Three: Adopt

Be sure to consider the scalability and repeatability of any new tools or processes that are adopted in order to meet the Checklist requirements. We will be looking for real-time evidence that tools and processes are being effectively implemented.

• Identify tools or processes that must be implemented prior to audit to obtain the full checklist points
• Create a timeline for implementation of new tools or processes
• Prepare documentation for any tools or processes that are on your long-term roadmap, but may not be fully mature prior to the audit
• Implement only those tools or processes that improve your business, and that are scalable as you grow – don’t implement changes to “check the box” for the audit

Step Four: Review/Refine

A common best practice is to link documentary evidence directly to the Checklist sections, so it is easily referenced and accessible when requested by the auditor. While the audit itself will be fluid, being able to quickly reference documents that provide validation of compliance will ensure a better overall audit experience.

• Review evidence to ensure it’s consistent with requirements, and is ready for presentation to an auditor; review and update your completed Self-Assessment to identify where gaps may remain
• Assess weaknesses in prepared evidence and refine as necessary
• Review presentation for ease of use – ensure there are links to evidence, demonstrations, and screenshots in a single, easily accessible document
• Ensure the presentation is organized, and follows progression of the audit checklist with any changes to the order identified (i.e., to ensure appropriate personnel can be present for their portion of the audit)
• Simple is better! Organize evidence so that presenters have documents and demonstrations available at their fingertips
• Remember, the best evidence will always be based in customer examples: hypothetical scenarios or process documents that haven’t been tested will not meet the audit criteria in most cases

Step Five: Practice

Many APN Partners conduct “dry runs” of the audit day, to ensure that documents and tools are readily accessible and that all presenters are prepared. This will also catch any potential technological issues (e.g., databases not accessible from the presenter’s system, etc.) that could slow the progress of the audit. 

• Practice in sections with responsible parties and practice the full audit at least once with all the required attendees
• Present your Customer Capabilities Demonstration to others to gauge effectiveness of your sales pitch
• Ensure that any new processes or tools have been used and are functioning properly; address any concerns or issues at this time and update any documentation as necessary
•  Ensure that the appropriate personnel are prepared to address any areas of concern
• Consider scheduling a pre-assessment with the audit firm to ensure an objective dry run and to help shore up the evidence ahead of the actual audit; this should be completed at least 2-3 weeks prior to the audit date, in order to allow time to implement recommendations for closing any remaining gaps

Step Six: Present

Don’t forget that we are looking to validate compliance. Showcase your strengths relative to your AWS Managed Service practice, and be open and honest about areas where you are still looking to grow and improve. We will in turn share best practices and recommendations for improvement that can be integrated into your current roadmap.

• On the day of the audit, present your evidence to the auditor as if you are selling to a prospective client
• Emphasize the positives that your business brings to AWS customers in a competitive marketplace
• Use language from the Checklist when discussing evidence to avoid any misunderstandings
• Focus on company strengths, accomplishments, and service differentiators
• The auditor’s role is to assist in your success by thoughtful review and validation of your processes and systems; auditors are trained to take a consultative approach and to ensure a positive experience

Step Seven: Relax!

Congratulations. Completing the audit process is a significant accomplishment. The shared goal of AWS and ISSI is to identify and acknowledge APN Partners who are providing end-to-end, next-generation managed services for AWS customers. Your success is our success!

• You will have an opportunity to close any identified gaps after the conclusion of the audit and before a detailed final report is submitted to AWS for review
• Your company will emerge from the process well positioned for growth and success; be sure to put your APN status and AWS MSP Certification to good use by developing a marketing plan that builds on the momentum of your successful audit

Want to learn more? Download the AWS MSP Getting Started Guide on the APN Portal.

We recently published an AWS case study on Dodge Data & Analytics, who worked with Advanced APN Consulting Partner Harman to migrate to AWS. What follows are some details of Dodge Data’s move to AWS.

Who is Dodge Data & Analytics?

Dodge Data & Analytics is a leading provider of data, analytics, news, and intelligence serving the North American construction industry. The company’s information enables building product manufacturers, general contractors and subcontractors, architects, and engineers to assess markets, prioritize prospects, target and build relationships, strengthen market positions, and optimize sales strategies. The company’s brands include Dodge, Dodge MarketShare, Dodge BuildShare, Dodge SpecShare, and Sweets.

Why did Dodge Data engage AWS?

Frequently, large organizations adjust their operational focus and divest divisions and groups that no longer fit their business profile or brand image. This kind of divestment often poses complex operational and technology challenges as systems and processes are “carved out” of the parent company. This was the case for McGraw Hill Financial, which sold its construction media and services division, McGraw Hill Construction, to private equity firm Symphony Technology Group in September 2014. The divested company, which has been renamed Dodge Data & Analytics, provides extensive information on construction projects, including project bidding leads, market forecasts, construction news, and more. In doing so, it helps construction companies and contractors to identify new business opportunities and grow their businesses.

As a key condition of the divestment deal, Dodge Data had just one year to move its IT infrastructure out of the McGraw Hill data center, with monthly fines written into the divestment contract for exceeding the deadline. From the earliest days of the migration project, Dodge Data decided to host its mission-critical IT infrastructure in the cloud, which offers major cost-savings compared to building out infrastructure in traditional data centers.

After evaluating all available cloud providers, Dodge Data decided to host its infrastructure on Amazon Web Services (AWS). “We went with AWS for a number of important reasons,” says Sagar Bhujbal, director of enterprise architecture at Dodge Data & Analytics. “First, it was a leader in the Gartner Magic Quadrant, which gave us a lot of confidence. Second, it supported more of our existing systems out of the box than any other cloud provider, which meant we could migrate our infrastructure more quickly and with fewer issues. And third, we were impressed by the security credentials of AWS, including its PCI-compliant data centers.”

With the decision made to use AWS, Dodge Data looked for a suitable migration partner, and chose to work with APN Partner Harman. “After reviewing different proposals, we entrusted the migration to our sister company Harman, which has experience in handling large migrations from traditional data center infrastructure to the cloud,” says Bhujbal. “The team it put together for us was extremely knowledgeable about AWS, which gave us peace of mind that the migration would be completed successfully, and on time.”

Together, Harman and Dodge Data created a sophisticated, multiphase migration plan involving almost 80 people in six different teams. “Initially, we designed and built shared systems in AWS for things like anti-virus protection, patching, monitoring, and intrusion detection,” says Bhujbal. “We then started thinking about how to migrate our other complex systems to the cloud. The systems Dodge Data needed to migrate included the company’s complex Informatica environment, which incorporates 300 ETL processing workflows to support the company’s innovative, customer-facing apps. Other systems that needed to be moved to the cloud included the company’s Tableau sales reporting and analytics tools, Oracle databases, ERP and CRM apps, data warehouses, batch-job scheduling systems, and BI systems.”

What are the benefits for Dodge Data?

By migrating to AWS, Dodge Data has experienced a number of benefits:

• The team was able to meet its 12-month deadline for moving out of its previous environment, while keeping customer facing-apps available at all times
• Dodge Data has experienced overall IT costs savings of about $5.25 million a year compared to the company’s previous data center infrastructure
• Customer-facing application performance has improved; Dodge Data has seen a 50 percent improvement in the performance of key customer-facing apps

Want to learn more about how Dodge Data uses AWS? Read the full case study. 

To learn more about Harman, visit the company’s website.

Formed in 2011, MongoLab’s goal is to make software developers more productive. An Advanced APN Technology Partner and AWS SaaS Partner, MongoLab offers customers a fully managed cloud database service featuring automated provisioning and scaling of MongoDB databases, backup and recovery, 24/7 monitoring and alerting, web-based management tools, and expert support. Looking forward, the team has a strong drive to build and offer services up the data stack to provide additional value to customers. Yesterday, MongoLab announced new branding, and will be called “mLab” to reflect its expanded focus moving forward.

I sat down with Will Shulman, CEO and co-founder of mLab, to learn more about the company’s journey on AWS, the team’s experience as an APN Partner, and to get a little bit more information about what the brand change signifies for mLab’s customers and partners.

Will, thanks for chatting with me today. Let’s begin with the most important question: day-to-day, what’s mLab’s mission? What do you want to empower your end customers to do?

In a lot of ways, what we’re trying to do, and what we feel is our purpose in life, is similar to AWS: we want to make software developers more productive, via tools and cloud infrastructure. A lot of the folks who started the company worked together at a previous start-up. We shared a common love of data and databases, and the idea of cloud infrastructure. At the time, cloud infrastructure was just starting to take off and was something that a lot of companies didn’t yet know, and didn’t yet use. It was starting to blossom into what we see today.

We quickly identified AWS as a platform we wanted to use, and we built mLab, our database as a service, on top of AWS. It’s one layer up from the infrastructure as a service (IaaS) level. Customers want to use MongoDB, but don’t want to have to deal with the complexities of hands on management of their infrastructure, both the database infrastructure and below – VMs, disks, networking, security, OS patches, maintenance, etc. Customers want to be able to say, “I want a database. I want to have ‘x’ nodes, I want it to have ‘x’ storage, I want it to perform, and I want it to scale. Go.” That simplicity is what we strive to provide our customers through our managed database service for MongoDB.

What value do your customers find in your product?

I think there are two sides to it. One is the automation of cloud elements that go into managing a database deployment, and the automation to provision, monitor, backup, and scale a fault-tolerant, multi-node MongoDB cluster. Our customers don’t have to think about it, and they can focus on what their own solution’s value-add is to the world.

The other part we pride ourselves on is our support. The database tier is a complicated part of the app stack, and we help customers grow and scale their applications. Bundled with their subscription, a customer gets a high-level of support from our team, on anything from troubleshooting, to advice, to emergency support. Having that as a part of the subscription and cloud service, we hear a lot of feedback from customers that they find it to be a great integration of technology and human expertise.

Can you tell me about mLab on AWS? How long have you worked with AWS, and been a member of the APN?

We’ve used AWS since our inception as a company in early 2011, and we’ve been an APN Partner since 2014.

We’ve been working very closely with AWS teams since the beginning, as our platform integrates tightly with the AWS platform. We’ve developed close relationships with the AWS product and sales teams, and have had great opportunities to provide our technical feedback and give talks to internal groups in AWS. Building these relationships has helped us do more with AWS, and reach more customers who are working with MongoDB on AWS. Similarly, we’ve worked closely with our AWS Partner Managers, who’ve been great. They’ve helped us better understand the AWS ecosystem and have been really helpful resources. We’ve really enjoyed working with the APN.

Why did you decide to use AWS, and become an APN Partner?

Some cloud services that application developers might integrate with don’t necessarily need to be hosted particularly closer to their application. That’s not true with databases. It’s really important for your database that it’s physically close to your application servers.

By supporting AWS, we can provision customer databases in the same AWS Region that they run their application. We run on AWS, along with other providers, and from the very beginning we chose AWS as our core platform. AWS is the leader in the space, and most of our customers are also running on AWS.

When we joined the APN, it really helped us grow our presence with AWS, both on the product side in understanding who to work with and collaborate with technically, as well as on the go-to-market (GTM) side. Being able to work more closely with the sales and solutions teams to identify and support MongoDB customers who are looking for a MongoDB solution on AWS has been really helpful for us. We really value our relationship. In the last year, we’ve doubled our paid customer account, and had our fourth quarter of profitability this quarter. We continue to expand our presence on AWS, and we have some great stuff in the pipeline.

How does mLab use the AWS platform?

mLab integrates very tightly with AWS. When a customer provisions a multi-node database deployment with mLab, our automation infrastructure uses the AWS API to provision VMs, disks, and other AWS infrastructure to build the database cluster on demand. All the customer needs to do is specify a plan and an [AWS Region] and mLab takes care of the rest, freeing the developer from the complexities of the underlying infrastructure and allowing them to focus on their application.

mLab hosts databases directly in AWS, and is a software as a service (SaaS) Partner. Have you had a good experience running SaaS on AWS?

We’ve had a great experience. We almost exclusively use the AWS APIs for everything we do. It’s completely automated, and our interface to AWS has been the AWS API, and it works really well.

Frankly, it’s one of the things I really appreciate about AWS: things just work as advertised. It’s really been a great experience.

Since mLab’s inception as a company, to where the company is today, what’s changed in terms of the company’s focus, philosophy, and goals?

Our goal definitely remains to focus on the developer. When we started the company, we envisioned mLab to be the first part of a larger vision that we had around cloud infrastructure and cloud data services. We wanted to allow people to have a single place where they could build the types of data services they need to run their applications. The database simply isn’t the whole story in the data layer, and our original idea was to start with MongoDB, and then start building some other services that are adjacent to the database.

“MongoLab” was a great name for us when our only product was MongoDB-as-a-Service. But now we feel it is time to change our name to one that accommodates our larger vision. There’s always been a plan to start moving up the stack and we’re now looking to build services that will help our existing customers to do even more with their data.

How do you feel your brand change impact your customers and your partners?

We want our customers and our partners to know that we’re still focused on being one of the best places to run MongoDB on the cloud, but that we’ll also be coming out with new solutions that will radically simplify server-side development. We’ve found our channel market to be an incredibly effective way to reach customers, and we hope our new offerings will enable new ways to partner with us.

Has being an APN Partner influenced any cultural shifts at mLab?

One thing we very much admire about AWS, and I think it resonates well with our natural culture, is the straightforward way AWS engages with customers, partners, and the marketplace. The content coming from AWS is always helpful, and our interactions across teams are always sincere. Everyone is focused first-and-foremost on addressing the needs of the customer, in a professional manner. And it’s been very consistent across teams, whether it be the sales, product, or partner team. It seems to be very much a part of the culture. Seeing that at a small company is one thing. But in my opinion, seeing it done at such a large company is quite another thing. It’s been very encouraging see a company so large value and drive that type of culture. It’s refreshing.

What’s next for mLab on AWS?

We’re going to be coming out with solutions that will help our customers to develop higher-level data services with MongoDB. There’ll be more information to come this year. In the near future, we’re going to be doing some cool stuff with our core MongoDB service around Software Defined Networking (SDN) and Virtual Private Cloud (VPC) that our core customers have been asking for.

We are also working to support a lot of new mobile customers as a result of the Parse shutdown. We have been working with the Parse team for some months to help ensure that Parse customers have a great option for where they host the database component of their app. They have published an official migration guide, which recommends that customers use mLab to manage the database piece. AWS also has a guide to help AWS customers on the mobile development blog.

No doubt there will be a number of exciting announcements from mLab in the coming year. If you’re interested in learning more about mLab, don’t hesitate to reach out to their team: support@mLab.com.

For general information about mLab, visit the company’s Partner Directory listing.

Today, we’d like to highlight our newest AWS Partner Success Story featuring Wipro, a Global Systems Integrator, Premier APN Consulting Partner, AWS Managed Service Provider, and AWS Life Sciences Competency Partner.

Headquartered in Bangalore, India, Wipro is a global IT consulting and system integration services firm that develops and implements solutions for enterprises across the globe. Wipro partners with more than 900 of the Fortune 1000 enterprises, and its 160,000-plus employees work in 67 countries. The organization operates more than 55 Centers of Excellence for emerging technologies, through which it takes advantage of the latest technology to deliver business capabilities to customers in financial services, manufacturing, technology, retail, consumer goods, healthcare, and media.

In the mid-2000s, an increasing number of Wipro customers started looking at new, more cost-effective approaches to consuming IT services. The cloud quickly emerged as one of those approaches. “Our customers wanted to move away from up-front capital expenses, and that really drove the trend toward IT as a service,” says Dr. Manish Govil, Global Cloud Alliances Head, Wipro. “Also, our customers wanted to bring services to market faster, and the agility and flexibility of the cloud enable that. We sensed that trend early on.”

Because its customers continued to express interest in the cloud as a business enabler, Wipro knew it needed to create a new strategy based on the development of software as a service (SaaS) solutions. “We had to develop a completely different business model to meet the demand for cloud offerings,” Govil says.

As an APN Partner, Wipro has been able to transform its business model. “By working as an APN Partner, we can be an innovation partner to our customers. We can now offer services we weren’t able to offer before,” says Govil. “We can structure our offerings as a service as a result of working in the cloud. We don’t have to manage our own data center infrastructure, so we have the flexibility and agility to release our services and solutions to market faster.”

Curious to learn more? Read the full case study.

…Training and Labs? Check. 

…Networking? Check.

…In-depth technical sessions? Check.

….APN Partner-specific events? Check.

Hosted around the world, AWS Summits provide you with a wealth of in-person resources to help you learn what’s new with AWS, and how to take advantage of the AWS platform. With the AWS Summit – Chicago fast approaching on April 18 – 19th, we want to highlight some of the benefits you can gain as an APN Partner by attending.

What Can You Expect at the AWS Summit – Chicago?

Training – Get 10 percent off AWS Technical Bootcamps purchased by March 1st!

Getting trained and certified on AWS is one of the most important steps in the APN Partner journey. Better trained APN Partners are generally more equipped to meet the needs of AWS customers, and we encourage all APN Partners to take advantage of opportunities to get trained on AWS.

There are five, full-day training bootcamps happening on April 18th, including:

• AWS Business Essentials (Introductory Level) – This session helps IT business decision makers understand the benefits of cloud computing and how a cloud strategy can help you meet your business objectives.
• AWS Technical Essentials (Introductory Level) – This session introduces you to AWS products, services, and common solutions. It provides IT technical end users with basic fundamentals to become more proficient in identifying AWS solutions so that they can make informed decisions about IT solutions based on their business requirements.
• Serverless Development on AWS: Build a Location-Aware, Search & Recommendations-Enabled Application (Expert Level) – In this session, you will walk through a real-world location-aware social application that displays information generated from a model created with Amazon Machine Learning.
• Securing Cloud Workloads with DevOps Automation (Expert Level) – This bootcamp walks through the design considerations of operating high-assurance workloads on top of the AWS platform and provides hands-on labs on governance, configuration management, trust-decision automation, audit artifact generation, and native integration of these tasks into custom software workloads.
• Taking AWS Operations to the Next Level (Expert Level) – This bootcamp is designed to teach solutions architects, SysOps administrators, and other technical end users how to leverage AWS CloudFormation, Chef, and AWS SDKs to automate provisioning and configuration of AWS infrastructure resources and applications. This bootcamp also covers how to use AWS Service Catalog to create, manage, and distribute portfolios of approved products to end users, who can then access the products they need in a personalized portal.

Sign up for a hands-on training bootcamp by March 1, and receive a 10 percent discount on the regular price of the bootcamp. This will end on March 1st, so don’t delay. Learn more.

Networking

The Chicago Summit provides a great opportunity for you to connect with regional attendees from all across the Midwest. The Partner & Solutions Expo is the center of Summit activity, and is a fantastic place to connect with fellow APN Partners and customers alike. The Expo will be open on Tuesday, April 19th, from 8:00 am – 9:30 am, and 11:30 am – 7:00 pm. Check out all of our Sponsors here.

In addition, there’ll be a networking reception in the Expo from 5:30 pm – 7:00 pm. Don’t miss it!

Sessions

There will be over 50 sessions available across a number of tracks, including deep dive technical sessions on new services. The session tracks are Big Data & Analytics, Enterprise, Security, and Services. Learn more.

Building Your Practice on AWS: An APN Partner Breakfast Session – Tuesday, April 19th 

Join us from 8:30 – 9:30 am on Tuesday and learn how the APN can accelerate and support your cloud business strategy. Our breakfast session will highlight various programs and resources available to APN Partners looking to grow and develop their business on AWS. We will also provide you with insight into the Training and Certification offerings available to APN partners. Learn more.

Have additional questions about the AWS Summit – Chicago? Visit the FAQ page.

Have you joined us at a previous AWS Summit? We want to hear about your experience! Leave us a comment.

Editor’s Note: Each month, we plan on doing an Amazon Aurora digest to highlight pieces from our APN Partners that profile Amazon Aurora.

Have you used Amazon Aurora? Have you helped your customers migrate to Aurora?

More and more, our APN Partners are telling us about the work that they’re doing with Aurora. We want to share with you a note from our Amazon Aurora team, along with links to a number of pieces of informational content developed by a few APN Partners highlighting Amazon Aurora best practices.

Amazon Aurora is a MySQL-compatible relational database engine that combines the speed, availability and security of high-end commercial databases with the simplicity and cost-effectiveness of open source databases. Our customers run mission-critical database workloads across multiple industries and our partners have been an important driver of customer success. We value the expertise that our partners bring to the table and support them through tools and training as customers continue to migrate increasingly complex workloads to Aurora. As we continue to help organizations move to Aurora and AWS, we look forward to strengthening and expanding our relationship with APN Partners.

– The Amazon Aurora team

Case Studies

CorpInfo, a Premier APN Consulting Partner: AWS Case Study – GoGuardian

AppsAssociates, a Premier APN Consulting Partner: PetTrax – Migrating to Amazon Aurora

Webinars & Presentations

AppsAssociates recorded joint webinar: Deploying High Performance Databases in the Cloud

Alfresco, an Advanced APN Technology Partner: Scaling Massive Content Stores with Amazon Aurora

Whitepapers/eBooks

AppsAssociates ebook: Three Reasons to Migrate your Database to the Cloud

AppsAssociates whitepaper: Amazon Aurora, A Fast, Affordable and Powerful RDBMS

Blog Posts

Alfresco: How Alfresco powered a 1.2 Billion document deployment on Amazon Web Services

BluePi, a Standard APN Consulting Partner: Amazon Aurora – Superior Cloud Database

Do you have links to content you’d like to share with us detailing how your firm has used Amazon Aurora to provide additional value to customers? Let us know! Email us: apn-blog@amazon.com

Are you a telecom provider looking to transform your business on the cloud? If yes, then we have an exciting announcement to share with you. Today, APN Consulting Partner Ericsson announced plans to form a global business, technology, and services alliance with AWS to accelerate cloud transformation for telecom service providers. Ericsson is creating a global team of experts focused on AWS, and is opening cloud innovation centers with customers, with AWS support.

Why Ericsson and AWS?

As the Ericsson team explained today in their press release, “New technologies such as mobile broadband and the cloud have transformed the competitive battleground for service providers. Today’s leading telecoms companies seek to capitalize on new opportunities such as Internet of Things (IoT) and big data analytics and at the same time, leverage the latest technologies to improve productivity and efficiency, increase agility, reduce complexity and risk, as well as create unique value for their customers.

Ericsson will leverage AWS’ services and expertise to work closely with service providers to implement a cloud adoption framework to fit their unique business objectives. The Ericsson teams will consist of program directors, solutions architects and system engineers who are trained on AWS and Ericsson technologies and bring together deep service provider industry and cloud domain expertise. AWS is supporting Ericsson in this effort with a broad range of resources that may include solutions architects, professional services and training. The companies’ efforts are designed to accelerate cloud adoption through cloud transformation programs, data center consolidation and application migration.”

To learn more about this alliance and about Telstra, an Australian operator and the first Ericsson customer who is hosting a joint cloud innovation center with Ericsson, read the company’s press release.

We have some exciting news for US veterans working at AWS Partner Network (APN) firms.

To help veterans succeed, we’ve worked with the Department of Veterans Affairs to make AWS Certification exams eligible for VA reimbursement.

Qualifying US veterans covered under a GI Bill can now submit a reimbursement request to the Department of Veterans Affairs for exams taken after December 10, 2015 and purchased from Webassessor. The VA will cover exam fees up to $2000. (Costs connected with preparing for a certification such as training courses or practice exams are not reimbursable.)

Learn more on the AWS Blog, and on our website.

Want to hear about the value of AWS Training & Certification from other APN Partners? Click here.

We recently announced that we’ll be opening an AWS Region in Canada in the coming year. Today, we’d like to share the story of The Globe and Mail, a Canadian customer already taking advantage of the benefits of the AWS platform, with the help of Premier APN Consulting Partner ClearScale. The company is also an AWS Big Data, DevOps, Marketing & Commerce, and Mobile Competency holder. ClearScale helped The Globe build an article recommendation engine on AWS.

“ClearScale was introduced to The Globe and Mail by one of the Amazon Web Services (AWS) representatives. We were more than impressed by a publication with a 170-year history looking to develop a cutting-edge recommendation engine for their mobile application,” explains Pavel Pragin, CEO, ClearScale. “The Globe & Mail was interested in a reliable cloud services partner that could deliver an innovative and reliable solution. ClearScale’s solution helped The Globe & Mail expand their readership and gain additional advertising opportunities while meeting their tight project deadlines.”

Who is The Globe and Mail? 

The Globe and Mail is Canada’s most read newspaper with a national weekly digital readership of 4.7 million. In print for 170 years, the newspaper delivers coverage of national, international, business, technology, arts, entertainment, and lifestyle news.

Why did The Globe and Mail engage AWS? 

The Globe and Mail was planning to launch a new application that enables its growing online readership to access stories and breaking news from mobile devices. And to increase reader engagement, it wanted to serve up targeted articles based on each reader’s individual interests. The Globe team considered building a custom system on premises, but concluded that hosting its article recommendation engine in the cloud would be faster and would provide greater flexibility for testing different algorithms. The Globe team had already been prototyping a number of recommendation algortithms on AWS. Having had a great experience, the team decided to use AWS for its official platform. The Globe uses a number of AWS services, including:

• Amazon Kinesis to collect massive amounts of information (including user clicks, article engagement, and article metadata)
• Amazon DynamoDB for a fast and flexible database to store data
• Amazon Elastic MapReduce (Amazon EMR) for data processing
• Amazon EC2 for compute capacity
• Amazon S3 for secure, durable, highly scalable object storage
• Amazon Simple Queue Service (Amazon SQS) for queuing messages
• Amazon CloudWatch to monitor the performance of the system
• AWS CloudFormation to give developers and systems administrators an easy way to create and manage a collection of AWS resources
• AWS OpsWorks to help users configure and operate applications using Chef automation

What are the benefits for The Globe and Mail? 

By building its personalized recommendation system on AWS, The Globe has experienced a number of benefits:

• The team was able to get the service to market in just three months, less than half the time it would have taken had the newspaper built an on-premises solution
• The Globe has obtained a flexible platform for testing, allowing the company to improve its mobile app over time
• The Globe is dramatically increasing reader engagement; initial results show that parts of the mobile app that promote a personalized selection of articles based on the recommendation engine are seeing a 25% greater click-through than a selection of the current most popular articles that would otherwise be the top performers

Want to learn more? Read the full case study here.

To learn more about ClearScale, visit the company’s website, or check out the company’s AWS Partner Directory page.

As a Partner Solutions Architect, I look at a lot of AWS Partner Network (APN) Partner software and services. I like trying new things and experiencing the exciting solutions that our APN Partners are building. Security is job zero at AWS, so when I work with our APN Partners, there’s one thing I look for above all others, and that’s to understand if the APN Partner is following best practices to protect customer data and any customer AWS account they may access. If it seems like the APN Partner’s product will need to access a customer account, I’ll check to see how the APN Partner is getting credentials from the customer. If a partner is asking customers for AWS Identity and Access Management (IAM) access keys and secret keys, I halt my investigation and focus on helping the partner fix this approach.

It’s not that I have a problem with partners accessing customer accounts—APN Partners can add incredible functionality and value to the resources in an AWS account. For example, they can analyze AWS CloudTrail logs, or help optimize costs by monitoring a customer’s Amazon Elastic Compute Cloud (Amazon EC2) usage. The problem here is how the APN Partner is accessing the AWS account. IAM access keys and secret keys could be used anywhere, by anyone who has them. If a customer gives these keys to an APN Partner, they need to be able to trust that the APN Partner is adhering to best practices to protect those keys. This should really resonate with APN Partners, who need to store and protect their customers’ keys, but lack control over how customers manage those keys. Using IAM access keys and secret keys for cross-account access is not ideal for anyone. Fortunately, there is a better way.

Cross-account IAM roles allow customers to securely grant access to AWS resources in their account to a third party, like an APN Partner, while retaining the ability to control and audit who is accessing their AWS account. Cross-account roles reduce the amount of sensitive information APN Partners need to store for their customers, so that they can focus on their product instead of managing keys. In this blog post, I explain some of the risks of sharing IAM keys, how you can implement cross-account IAM roles, and how cross-account IAM roles mitigate risks for customers and for APN Partners, particularly those who are software as a service (SaaS) providers.

The problem(s) with sharing IAM keys

On AWS, access and secret keys are credentials that allow access to AWS APIs in an account. These can be associated with an IAM user in an account or with the root user of an account. Sharing these keys with external parties can create a lot of headache for everyone involved. The root of the problem with sharing IAM keys is that they can be used until explicitly revoked by a customer, and that the keys can be used from any computer that has Internet access (this includes servers, laptops, mobile phones, etc.). If an APN Partner wants to use IAM access and secret keys in a customer’s product, here are some important questions that both the APN Partner and the customer should be able to confidently answer:

• Are keys being managed securely? Are they encrypted when they are transmitted and stored? Who has access to the keys? What processes protect the keys from being exfiltrated from the partner’s systems?
• Are keys being rotated frequently? If you are a customer, will the APN Partner tell you when to rotate your keys? As an APN Partner, how can you make sure all your customers frequently rotate their keys? How do you coordinate key rotation with your customers to minimize downtime?
• Can you control who has access to the customer’s AWS account? For both customers and APN Partners, how will you know who uses a key, and from where?
• Is the access policy associated with the key too permissive? For APN Partners that have a database of keys, how many of those keys provide too much access, or are root account keys?

APN Partners could build solutions that address these considerations, and customers could take on more work to ensure that their keys are being handled in a secure way. However, this involves a lot of undifferentiated heavy lifting that cross-account IAM roles can handle for both parties.

How cross-account IAM roles work

An IAM role is an AWS identity with an access policy that determines what the role can and can’t do in AWS. They are designed to be assumable by another AWS identity that is already authenticated to AWS. When an identity assumes a role, it receives temporary credentials and the same access policy as the role. You may be familiar with how roles work if you have used EC2 instance profiles, or have set up an AWS Lambda function.

A cross-account IAM role is an IAM role that includes a trust policy that allows AWS identities in another AWS account to assume the role.  Put simply, I can create a role in one AWS account that delegates specific permissions to another AWS account. Let’s take a look at the overall process as it applies to APN Partner software that needs to access a customer account:

1. A customer creates an IAM role in their account with an access policy for accessing the resources that the APN partner requires. They specify that the role can be assumed by the partner’s AWS account by providing the APN Partner’s AWS account ID in the trust policy for that role.
2. The customer gives the Amazon Resource Name (ARN) of the role to the APN partner. The ARN is the fully qualified name of the role.
3. When the APN Partner’s software needs to access the customer’s account, the software calls the AssumeRole API in the AWS Security Token Service (STS) with the ARN of the role in the customer’s account. STS returns a temporary AWS credential that allows the software to do its work.

Customers can include conditional checks on the trust policy associated with an IAM role to limit how third parties can assume the role. An example of this would be the external ID check. The external ID is a string defined in the trust policy that the partner must include when assuming a role.  External IDs are a good way to improve the security of cross-account role handling in a SaaS solution, and should be used by APN Partners who are implementing a SaaS product that uses cross-account roles.

How cross-account roles mitigate risks

Using cross-account roles addresses and mitigates a number of risks, so it’s worth taking a closer look at how cross-account roles help address the security questions we listed earlier.

• Are keys being managed securely? The Role allows the partner to get temporary credentials when they need to use them. Unlike Access and Secret Keys, these don’t need to be stored, so partner doesn’t need to be concerned with managing keys.
• Are keys being rotated frequently? Credentials generated by STS expire after an hour. Many of our software development kits (SDKs) have credential providers that handle this automatically, so neither the APN Partner nor the customer needs to manage credential rotation manually.
• Can you control who has access to the customer’s AWS account? The role in the customer’s account can be assumed only by an authenticated AWS identity in the partner’s account. The customer knows that only the APN Partner is accessing their resources, and the APN Partner can focus solely on managing and protecting the IAM roles and users in their own account.
• Is the access policy associated with the key too permissive? A role can’t have root key permissions, and since the cross-account role’s trust policy specifies the partner’s account, it is more likely that the permissions in the role’s access policy will reflect the partner’s requirements. APN Partners can encode cross-account IAM roles in AWS CloudFormation templates to make sure that customers are giving them exactly the permissions they need.

Using AWS CloudFormation to help customers create roles

Providing documentation to customers about how to create roles is straightforward, but if an APN Partner wants to make this simpler for their customers, they can package the role in an AWS CloudFormation template. This approach lets customers deploy a role into their account quickly without having to copy and paste trust and access policy documents.

I’ve provided an example AWS CloudFormation template that creates a cross-account role with an external ID for accessing Amazon S3. If you’re an APN Partner who needs access customer accounts, you can create templates like this with the access and trust policies you need, and instruct your customers to instantiate the template in their account. This template has parameters for the account number to make testing easy. In practice, partners will want to hard code their account number in the trust policy in the template. This template outputs the ARN that the customer can give to you to allow access to their account.

Where to go from here

In this blog post, I’ve explained why using IAM keys to provide AWS account access to third parties is not ideal, and talked about how APN Partners can implement cross-account IAM roles in their products. To learn more, take a look at AWS documentation on IAM roles, cross-account IAM roles, and external IDs. If you’re an APN Partner who wants to discuss this practice in more detail, please feel free to email me: rocamora@amazon.com.

Looking for implementation details? Take a look at our SDK documentation that explains how to use AWS SDKs to build this into your product. Here are links to documentation about assuming roles for the Java, Ruby, Golang, .NET, and Python SDKs. Most partners won’t need this, but if you want to see the low-level details, take a look at the STS API documentation. I also recommend that you audit your own AWS accounts using a credential report to see if you are providing cross-account access with an IAM user.

If you’re a consulting partner or an MSP, you probably find yourself needing to access your customers’ AWS accounts through the AWS Management Console. You can use cross-account IAM roles for this as well by using the switch roles feature of the AWS Management Console. This gives you access to your customers’ accounts without having to manage users, passwords, or keys.

Finally, if you’re an AWS customer and work with an APN Partner who is requiring keys, ask them how you can use cross-account roles with their products, and don’t hesitate to share this post with them.